Priorizar el feedback de producto por ingresos en riesgo: Bellwether cruza tickets, reseñas, llamadas y NPS con el CRM

Este artículo de Towards Data Science, publicado el 7 de noviembre de 2026, propone cambiar la forma de priorizar el feedback de producto en empresas B2B SaaS. Las herramientas habituales agrupan tickets en temas y los ordenan por número de menciones. El autor sostiene que ese criterio está sesgado: gana quien más escribe, y en los productos B2B que conoce, quien más escribe casi nunca es quien más paga. Un ticket de una startup de cinco personas pesa lo mismo que una llamada de renovación con una cuenta de cuatro millones de euros: una fila cada uno. La solución que plantea es unir el feedback con el CRM, que sí sabe cuánto paga cada cuenta.

Nota sobre el material: el texto recibido está cortado en mitad del segundo experimento. Este resumen no cubre las conclusiones finales del artículo, como los tres problemas más difíciles que el autor dice haber encontrado, salvo lo que aparece en la parte descargada.

Advertencia importante sobre los datos. El artículo presenta Bellwether, una herramienta que el autor construyó. En esta versión, la ingesta y el clustering están simulados. Todo gira en torno a una empresa ficticia, Volta, un SaaS de gestión de servicios de campo. Las cuentas, las citas y las cifras en euros son sintéticas, y los temas se conocen por construcción. El autor lo dice expresamente: el «ingreso en riesgo» es una estimación, no una medición. Lo que sí es real es la capa de puntuación. El script de análisis regenera el corpus, recalcula las cifras y ejecuta los dos experimentos, y el código es público en GitHub. Las cifras que siguen no son datos de un negocio real, sino resultados de un ejercicio de demostración.

El escenario de Volta. Tiene unos 19,4 millones de euros de ARR (ingresos recurrentes anuales) y 10 cuentas con nombre: 6 enterprise y 4 mid-market. Además hay dos segmentos agrupados: 214 cuentas SMB y 1.890 self-serve. El corpus suma 6.693 señales de cuatro fuentes y 10 temas por encima del umbral de ruido. Las fuentes son 4.812 tickets de soporte, 386 reseñas de tiendas, 291 notas de llamadas de ventas y renovaciones, y 1.204 comentarios de NPS. Cada fuente sobrerrepresenta a un segmento distinto. Los tickets pesan sobre todo en SMB. Las reseñas vienen sobre todo de usuarios self-serve (un 60% según el autor). Las llamadas de ventas proceden casi exclusivamente de enterprise (un 76% de las seis cuentas enterprise). El NPS sigue a la base de clientes, con el sesgo de quien decide responder. Contar a través de las cuatro fuentes no cancela esos sesgos: los hereda todos a la vez.

Tres decisiones de diseño. La primera es la unidad de datos: no una pieza de feedback, sino una señal que conserva su cuenta. Si se pierde el identificador de cuenta en la ingesta, nada posterior puede valorarse y el producto vuelve a ser otra herramienta de clustering. La segunda es qué significa «ingreso en riesgo». No es el ARR completo de cualquier cuenta que se haya quejado, sino el ARR afectado, filtrado por la parte de sus señales planteada en contexto de abandono, renovación o competencia, y ponderado por lo cerca que esté la renovación. La tercera es que la ponderación debe poder invertir el orden y no solo matizarlo. Un tema con 89 menciones tiene que poder superar a uno con 903. Si no, la fórmula es solo un recuento disfrazado.

La fórmula. La puntuación de un tema es una suma sobre las cuentas que lo plantearon. Cada cuenta aporta su ARR, multiplicado por la proporción de sus señales sobre ese tema en contexto «caliente» (churn, renovación o competencia) y por un peso de proximidad de la renovación. En la versión de la herramienta, la proximidad es una función escalonada: peso completo si la renovación cae dentro de tres meses, la mitad dentro de doce y una quinta parte más allá. El autor subraya que esos coeficientes son una decisión de producto, no una verdad escondida en los datos. Por eso el método debe quedar a un clic de la cifra que acaba en una diapositiva.

El cambio de ranking. Es el resultado central de la demo. Por menciones, el orden es: modo offline móvil (1.247), modo oscuro (903), ruido de notificaciones (726), exportación a Excel (588), programación masiva y edición en bloque (412), complejidad de configuración y onboarding (341), precisión de facturación (197), SSO y SCIM (89), límites de API en la sincronización con el ERP (63) y residencia de datos multirregión (34). Por ingresos en riesgo, el orden es: SSO y SCIM (6,4 M€), residencia de datos (4,2 M€), programación masiva (3,1 M€), límites de API (2,8 M€), onboarding (1,9 M€), facturación (1,4 M€), modo offline (0,9 M€), exportación a Excel (0,6 M€), ruido de notificaciones (0,3 M€) y modo oscuro (50.000 €). SSO y SCIM sube del octavo al primer puesto: son 89 menciones de siete cuentas, seis de ellas enterprise, que suman 15,7 M€ de ARR. La residencia de datos, el tema más silencioso, pasa a ser el segundo, y el autor la presenta como un requisito regulatorio y no como una preferencia. El modo oscuro cae al último puesto sin ninguna llamada enterprise detrás. Cada fila abre un «recibo» con las cuentas implicadas, su ARR, las fechas de renovación y las citas con la cuenta asociada. El autor lo resume así: «un cliente dijo esto» pasa a ser «3,9 M€ dijeron esto».

75% del ruido, 8,5% del dinero. Sobre las 4.600 menciones agrupadas y los 21,6 M€ de ingresos en riesgo del corpus, los cuatro temas más pedidos (offline, modo oscuro, notificaciones y Excel) acumulan el 75% de las menciones y el 8,5% del ingreso en riesgo. Los tres temas que recomienda la vista de consejo suman el 12% de las menciones y el 63% del dinero. Los dos más silenciosos, SSO y SCIM y residencia de datos, aportan el 2,7% de las menciones y el 49% del dinero. Por mención, una petición de SSO y SCIM equivale a unos 72.000 € en riesgo, y una de modo oscuro a unos 55 €. El autor insiste en que los temas ruidosos no están equivocados: el modo offline es un problema real para técnicos en sótanos, pero es barato, y el ranking por volumen no puede decirlo.

Vista de consejo. La herramienta abre con una frase: si se entregan los tres primeros temas este trimestre, se protegen 13,7 M€ de ARR, el 70% de la cartera, en 10 relaciones de cuenta. El propio autor reconoce que esa cifra es un límite superior, porque suma tres estimaciones que comparten cuentas (Nordwind aparece en los tres temas, y Vinca y Adriano en dos). Limitada para que ninguna cuenta cuente más que su ARR, la cifra baja a unos 12 M€, el 63% de la cartera, y esa es la que la herramienta debería mostrar. Admite que todavía no aplica ese límite. Lo mismo vale para la suma de los diez temas: 21,6 M€, más que los 19,4 M€ de la cartera, porque una cuenta aparece en varios temas. Sin el límite, esa suma no significa nada. La vista incluye también una matriz de ingreso en riesgo frente a esfuerzo. El «quick win» es el límite de la API del ERP: 2,8 M€ con poco esfuerzo, porque subir un límite y avisar de los fallos de un trabajo nocturno son días de trabajo y no trimestres. El calendario de renovaciones muestra 11,0 M€ que renuevan en 90 días en 7 cuentas. El modo oscuro y el ruido de notificaciones, sin señal enterprise, se asignan a un sprint de calidad y no a una discusión de consejo.

Cómo se construyó. El autor usó Claude Code como herramienta de pair programming, con Vite, React, TypeScript y Tailwind CSS para la aplicación, y Python, pandas, NumPy y Matplotlib para el análisis. Cuenta que la primera versión salió con el aspecto de los competidores (barra lateral, tarjetas redondeadas, insignias de colores) y la rediseñó como un informe financiero: titulares con serifa, cifras tabulares, filetes finos y un único color, rojo oscuro, reservado al dinero en riesgo. No cambió ningún número. Su argumento es que, para una herramienta cuyo trabajo es que se la crea, el diseño forma parte del argumento.

El experimento de robustez. El script genera con una semilla fija las 6.693 señales con los mismos temas, menciones, fuentes y sesgos. Cada señal recibe un contexto y una fecha al azar. Los segmentos agrupados se modelan como sus miembros, porque una cuenta que nunca escribió no puede estar en riesgo por un tema que nunca planteó. La proporción de señales «calientes» es una tasa base por fuente multiplicada por un factor por tema, calibrada para que la puntuación esperada coincida con la cifra de la herramienta. Es decir, el experimento comprueba si el ranking aguanta, no si los datos son reales. Según el autor, nueve de las diez cifras de la herramienta caen dentro de la banda del percentil 5 al 95 de 30 simulaciones, el orden se mantiene y la prueba de inversión se supera: SSO y SCIM con 89 menciones y 6,4 M€, frente al modo oscuro con 903 menciones y 40.000 €. La excepción es el onboarding: el generador solo llega a 1,9 M€ si el 96% de las señales del tema son «calientes», así que la cifra de la herramienta es generosa y el script lo indica. La banda es además el intervalo de confianza que la interfaz no muestra. En los límites de API, con cinco cuentas y 63 señales, va de 2,1 M€ a 3,9 M€.

Experimento 1: tres funciones de proximidad. Se recalculó la puntuación con la función escalonada, una caída lineal hasta cero a 24 meses y una caída exponencial con semivida de seis meses. Los diez temas mantienen el mismo orden con las tres, con una tau de Kendall de 1,00 en cada par. Los niveles sí se mueven: la función lineal sube un 44% el modo oscuro, cuyas cuentas SMB renuevan a seis meses, y la exponencial lo reduce todo, hasta un 20% en facturación. El orden aguanta porque los huecos entre temas consecutivos son mayores que lo que mueve la función. El más estrecho, entre modo offline y exportación a Excel, es del 11%. Si dos temas estuvieran a pocos puntos, la función decidiría entre ellos, y por eso debe poder consultarse.

Experimento 2: perder el identificador de cuenta. Las señales que una herramienta no puede atribuir no son una muestra aleatoria: son sobre todo las reseñas y los comentarios de NPS de la cola self-serve y SMB. El autor toma el 30%, el 50% y el 70% de las 2.433 señales de reseñas y NPS, con medias sobre 30 simulaciones, en dos escenarios. En el A las señales se eliminan, y menciones y dinero caen juntos: al 70%, el modo oscuro baja de 903 a 407 menciones y de 40.000 € a 31.000 €. En el B, el caso real, la señal se conserva pero sin cuenta. La columna de ingresos es la misma por construcción, pero el consejo sigue viendo 903 menciones del modo oscuro mientras su ingreso en riesgo cae un 22% y solo el 45% de sus menciones está valorado. El ruido de notificaciones mantiene 726 menciones y pierde un 10%, y el modo offline mantiene 1.247 y pierde un 8%. Los temas de cuentas enterprise con nombre suben: SSO y SCIM un 9%, porque los comentarios NPS que pierde eran sus señales más tibias y la puntuación es una proporción. De ahí la conclusión práctica: un número que sube cuando se pierden datos no es fiable por sí solo, y la proporción de menciones valoradas debe mostrarse a su lado. El texto se corta en este punto.

Qué conviene retener. La idea de fondo es razonable y útil para cualquier equipo de producto B2B: conservar la cuenta pegada a cada petición y valorar el feedback con datos de ingresos y renovaciones. Pero las cifras espectaculares del artículo (75% del ruido para el 8,5% del dinero, o la inversión SSO y SCIM frente a modo oscuro) proceden de un corpus sintético calibrado para producir ese contraste. Demuestran que el método puede invertir un ranking y que ese ranking es estable frente a variaciones de la función de proximidad. No demuestran cuánto se invertiría el orden en una empresa real. Como límites reconocidos por el propio autor están la suma sin tope por cuenta, la generosidad de la cifra de onboarding, la ausencia de intervalos de confianza en la interfaz y la fragilidad ante señales sin cuenta atribuida.