Una petición con doscientos votos de usuarios del plan gratuito y una con nueve votos de cuentas que renuevan el mes que viene no son comparables. La primera ordena mejor una lista. La segunda predice mejor una baja.
La respuesta corta. Un tablero de votación se usa casi siempre para ordenar por popularidad. La lectura que afecta a la retención es otra: quién vota, qué está bloqueado por lo que pide, y cuánto tiempo lleva pidiéndolo. Un voto no es un deseo, es un usuario diciendo que algo le falta ahora mismo.
Popularidad y riesgo no son la misma columna
El recuento total de votos responde a "cuánta gente quiere esto". El riesgo de churn responde a "quién se va si esto no llega". Puntuar el feedback por impacto es la forma de combinar ambas preguntas en un solo orden. Un tablero ordenado solo por la primera pregunta puede llevar a construir lo correcto para la población equivocada.
| Lectura | Ordena por | Sirve para | Riesgo |
|---|---|---|---|
| Popularidad | Número total de votos | Ver temas generales | Sobrerrepresenta a quien más participa |
| Riesgo | Quién vota y qué le bloquea | Detectar cuentas en peligro | Puede ignorar problemas de base amplia |
Ninguna de las dos es suficiente sola. La popularidad ignora que una parte de quienes votan nunca pagarán. El riesgo ignora que un problema muy extendido acaba pasando factura aunque ninguna cuenta grande lo mencione.
Un apunte importante: pesar los votos según los ingresos de la cuenta suena razonable y tiene un efecto secundario grave, porque convierte la hoja de ruta en la lista de deseos de los clientes más grandes. Es una decisión con consecuencias, no un ajuste técnico. FlagUp cuenta los votos por igual y muestra quién votó, de modo que la ponderación, si se hace, la hace una persona con criterio y no un cálculo automático.
Las cuatro señales que sí anticipan una baja
Bloqueo declarado. El usuario no pide una mejora, describe que no puede completar una tarea. El vocabulario lo delata: "no podemos", "tenemos que hacerlo a mano", "nos obliga a exportar". Estas peticiones pesan más que su recuento.
Repetición del mismo usuario. Una cuenta que vota o comenta tres peticiones distintas del mismo tema en pocas semanas está describiendo un problema estructural, no tres deseos.
Antigüedad sin respuesta. Una petición votada hace ocho meses y sin ningún cambio de estado es una promesa incumplida a ojos de quien la votó, aunque nunca se prometiera nada.
Concentración en un segmento. Si las peticiones bloqueantes vienen casi todas del mismo plan o del mismo tipo de empresa, ese segmento tiene un problema de encaje que la media global no muestra.
Las cuatro son observables sin ninguna herramienta predictiva. Solo hace falta que el tablero registre quién vota y cuándo.
Cruzar votos con salud de cuenta
El cruce que convierte el tablero en instrumento de retención es sencillo de describir y exige que el feedback esté asociado a la cuenta.
Para cada cuenta, tres datos: qué ha pedido, si alguno de esos temas está sin resolver desde hace tiempo, y si el tono de sus mensajes ha empeorado. Las cuentas que puntúan alto en los tres son las que conviene contactar antes de que se acerque la renovación.
FlagUp analiza el lenguaje de cada envío en busca de señales de frustración y destaca las cuentas donde se acumulan, lo que reduce ese cruce a mirar una lista en lugar de reconstruirla a mano. Puedes ver cómo funciona en la página de detección de churn.
Lo que no conviene hacer es tratar esa lista como una predicción. Es una lista de conversaciones pendientes, y ese matiz es lo que separa una herramienta útil de una que genera falsas alarmas, como se explica en el artículo sobre señales de churn.
Cerrar el círculo con quien votó
El voto crea una expectativa. Ignorarla produce el efecto contrario al que se buscaba al abrir el tablero.
Tres momentos merecen una comunicación, y ninguno requiere escribir correos individuales:
- Cuando se decide construirlo. Cambiar el estado de la petición basta. Quienes votaron reciben la señal.
- Cuando se entrega. El changelog enlazado desde la petición conecta lo que se pidió con lo que se hizo.
- Cuando se decide no hacerlo. Es el más incómodo y el más valioso. Un "no vamos por ahí, y esta es la razón" cierra el asunto. El silencio lo mantiene abierto durante meses.
Los tableros de votación fracasan casi siempre por esto y no por falta de participación. Los usuarios votan al principio, no ven movimiento, y dejan de volver.
Medir si sirvió de algo
Entregar la función más votada y ver que el churn no se mueve es un resultado frecuente y desconcertante. Casi siempre significa que se midió lo que no era.
Lo que hay que mirar después de entregar:
- Adopción entre quienes lo pidieron. Si la gente que votó no usa lo entregado, se construyó otra cosa distinta de lo que pedían.
- Retención del segmento que lo pedía, no la global. El efecto de una función concreta se diluye por completo en la media.
- Peticiones nuevas sobre el mismo tema. Si siguen llegando, la entrega resolvió el síntoma que se veía y no el problema.
Comparar esa retención por cohorte evita atribuir a la función un cambio que venía de otra parte.
Preguntas frecuentes
¿Debería un tablero de votación ser público?
Depende de tu tolerancia a que se vea lo que aún no has hecho. Público reduce duplicados y genera confianza; privado da más control. La mayor parte del beneficio de retención viene de que quien pide vea movimiento, y eso se puede lograr en ambos casos.
¿No acabará el tablero dominado por los usuarios más ruidosos?
En parte sí, y por eso el recuento no debería decidir por sí solo. Leer quién vota corrige buena parte del sesgo sin necesidad de ponderar nada.
¿Qué hago con peticiones muy votadas que no encajan con la estrategia?
Decirlo, y decir por qué. Una negativa razonada mantiene el tablero creíble. Dejarlas flotando en la lista da a entender que se están considerando.
¿Cuántos votos hacen falta para que una petición importe?
Menos de los que se piensa, si quien vota está bloqueado. Tres cuentas que no pueden trabajar sin ello suelen importar más que cincuenta votos de curiosidad.
Artículos relacionados
- Cómo segmentar el feedback para priorizar mejores funciones
- Cómo crear un bucle de feedback para reducir el churn SaaS
- Cuando las solicitudes de funciones revelan problemas de UX
Si tu tablero no registra quién vota, la lectura de riesgo no es posible. Mira las solicitudes de funciones y consulta los planes.