Un equipo recibe cuarenta comentarios por semana y responde a tres. Otro recibe ocho y responde a todos en dos días. Cuando la cola crece más rápido de lo que se puede atender, acortar el camino hasta el primer valor suele reducir la entrada más que acelerar la respuesta. El primero tiene más feedback. El segundo tiene más velocidad de feedback.
La respuesta corta. La velocidad del feedback describe cuánto tarda una opinión de usuario en recorrer el camino que va desde que se recibe hasta que alguien decide algo y se lo comunica al usuario. Conviene saber desde el principio que no es una métrica estandarizada: no existe una definición oficial ni un valor de referencia publicado con el que compararte. Es un nombre útil para un conjunto de tiempos que sí puedes medir en tu propio producto.
Por qué no es una métrica estándar
Términos como churn o NPS tienen una definición reconocida y una metodología publicada detrás. "Velocidad del feedback" no. Es vocabulario de la práctica del producto, no un estándar del sector.
Esto importa por dos razones. La primera es que si alguien te presenta un valor de referencia de velocidad del feedback, deberías preguntar cómo lo define exactamente, porque no hay un consenso al que apelar. La segunda es que tienes libertad para definirlo de la forma que sea útil para tu equipo, siempre que la definición quede escrita y no cambie cada trimestre.
Lo que sigue es una forma de descomponerlo. No es la única.
Los cuatro tiempos que sí puedes medir
La palabra "velocidad" sugiere un único número. En la práctica hay al menos cuatro tramos distintos, y el problema de un equipo casi nunca está en los cuatro a la vez.
| Tramo | Qué mide | Qué revela cuando es lento |
|---|---|---|
| Volumen por periodo | Feedback recibido en una semana o un mes | Un problema de recogida, no de proceso |
| Recepción a triage | Cuánto tarda alguien en leer y clasificar | Falta de rutina de revisión |
| Triage a decisión | Cuánto tarda en decidirse qué se hace | Falta de criterio de priorización |
| Decisión a comunicación | Cuánto tarda el usuario en enterarse | El tramo que más afecta a la confianza |
El volumen por periodo es el que más se publica y el menos informativo de los cuatro. Recibir más feedback no significa gestionarlo mejor. Un equipo puede duplicar su volumen instalando un widget y empeorar su velocidad real, porque ahora hay el doble de mensajes sin leer.
El tramo que casi siempre es el cuello de botella
En la mayoría de equipos que revisan sus propios tiempos, el tramo más lento es el último: decisión a comunicación.
La razón es estructural. Los tres primeros tramos ocurren dentro del equipo y tienen dueño. El cuarto exige salir hacia el usuario, y rara vez está asignado a nadie en concreto. La decisión se toma en una reunión, se anota en una herramienta interna y ahí se queda.
Desde fuera, un feedback decidido pero no comunicado es indistinguible de un feedback ignorado. El usuario que propuso algo hace tres meses y no ha sabido nada asume que su mensaje se perdió, aunque la funcionalidad esté en construcción.
Aquí es donde una hoja de ruta pública y un changelog hacen un trabajo que ninguna métrica interna hace: convierten una decisión ya tomada en una señal visible, sin que nadie tenga que escribir un correo individual.
Volumen y calidad no son lo mismo
Conviene resistirse a la tentación de tratar el volumen como un indicador de salud.
Un aumento de feedback puede significar que el producto interesa más. También puede significar que algo se ha roto y mucha gente lo está reportando a la vez. Los dos casos producen la misma subida en el gráfico y exigen respuestas opuestas.
Por eso la velocidad del feedback funciona mejor como diagnóstico que como objetivo. Si la conviertes en un número que hay que subir, el camino más corto para subirlo es pedir más feedback, que es justamente lo que no arregla el proceso.
Una lectura más útil consiste en mirar los tiempos por tipo de mensaje. El feedback que describe algo roto y el que propone algo nuevo no deberían tener el mismo ritmo, y promediarlos esconde exactamente la diferencia que importa. Separarlos es parte de lo que hace el triage de feedback.
Cómo empezar a medirlo sin montar nada
No hace falta instrumentación para obtener la primera lectura. Hace falta una muestra.
Coge los últimos veinte mensajes de usuarios y anota cuatro fechas para cada uno: cuándo llegó, cuándo lo leyó alguien del equipo, cuándo se decidió qué hacer y cuándo se le contó al usuario. Muchos tendrán la tercera o la cuarta columna vacía, y ese vacío ya es el resultado.
Una muestra de veinte mensajes suele bastar para ver dónde está el atasco. Si el patrón es evidente, medirlo con más precisión no va a cambiar la conclusión.
Ejemplo hipotético. Un equipo revisa veinte mensajes y encuentra una media de un día hasta el triage, cuatro días hasta la decisión y ninguna comunicación en catorce de los veinte casos. El problema no está en la recogida ni en la clasificación. Está en que nadie tiene asignado cerrar el círculo.
Cómo se relaciona con conceptos parecidos
La velocidad del feedback se confunde con facilidad con otras tres ideas cercanas:
- La agregación de feedback reúne mensajes de varias fuentes en un mismo sitio. Es un requisito previo para medir tiempos, porque no puedes cronometrar lo que está repartido en cinco bandejas.
- El triage decide cómo se maneja cada mensaje. Es uno de los cuatro tramos, no el conjunto.
- El bucle de feedback describe el proceso completo de principio a fin. La velocidad es la lectura temporal de ese proceso.
Preguntas frecuentes
¿Existe un valor de referencia para la velocidad del feedback?
No de forma fiable. Al no ser una métrica estandarizada, cualquier cifra que encuentres publicada depende de una definición concreta que probablemente no coincida con la tuya. La comparación útil es contra tu propio histórico.
¿Es mejor recibir más feedback?
No necesariamente. Más volumen sin más capacidad de procesarlo alarga los tiempos y aumenta el número de usuarios que no reciben respuesta. La recogida y la capacidad de gestión conviene que crezcan juntas.
¿Cuál de los cuatro tramos conviene atacar primero?
El último, en general, porque es el que el usuario percibe y el que suele estar sin dueño. Además es el más barato de arreglar: comunicar una decisión ya tomada no requiere trabajo de producto.
¿Sirve para equipos que no son SaaS?
Sí. Los tramos son los mismos en una agencia, una escuela o una organización sin ánimo de lucro. Cambia el canal por el que llega el feedback, no la estructura del recorrido.
Artículos relacionados
- ¿Qué es el triage de feedback? Definición y proceso
- ¿Qué es la agregación de feedback? Definición y ejemplos
- Cómo segmentar el feedback para priorizar mejores funciones
¿Quieres acortar el tramo entre decisión y comunicación? Un buzón de sugerencias público mantiene la conversación en el mismo sitio donde empezó. Consulta los planes disponibles.