Un mensaje de usuario que lleva once días sin leer no está pendiente de priorización. Está pendiente de que alguien decida qué tipo de cosa es. Esas dos esperas se parecen desde fuera y tienen soluciones opuestas.
La respuesta corta. El triage de feedback es la primera pasada sobre los mensajes que entran, y responde a una única pregunta: cómo se maneja esto. Es rápido, se hace sobre mensajes individuales y no requiere reunión. Priorizar es otra cosa: decide qué trabajo de producto va primero, se hace sobre un conjunto y sí requiere criterio compartido.
Las seis decisiones de una primera pasada
El triage no es una sola decisión, son seis pequeñas tomadas casi a la vez. Escribirlas ayuda a que la pasada sea consistente cuando la hacen personas distintas.
Revisar. ¿Se entiende lo que pide? Si no, la acción no es clasificarlo, es preguntar. Un mensaje ambiguo archivado como "mejora de UI" queda mal etiquetado para siempre.
Deduplicar. ¿Existe ya? Enlazarlo con la petición existente conserva la señal de que otra persona más lo ha pedido, que es información que se pierde si se abre un registro nuevo.
Categorizar. ¿De qué trata? Basta con una taxonomía corta. Una lista de veinte categorías garantiza que dos personas clasifiquen el mismo mensaje de forma distinta.
Enrutar. ¿Quién se hace cargo? A veces producto, a veces soporte, a veces documentación. Buena parte del feedback de producto se resuelve explicando algo que ya existe.
Detectar urgencia. ¿Esto está roto ahora mismo para alguien? La urgencia es la única dimensión que justifica saltarse el proceso normal, y por eso conviene definirla de forma estrecha.
Decidir el siguiente paso. Responder, escalar, añadir al tablero, cerrar. Un mensaje que sale del triage sin siguiente paso vuelve a la cola.
Triage y priorización: la diferencia práctica
| Triage | Priorización | |
|---|---|---|
| Pregunta | ¿Cómo se maneja esto? | ¿Qué hacemos primero? |
| Unidad | Un mensaje | Un conjunto de peticiones |
| Frecuencia | Continua o diaria | Por ciclo de planificación |
| Quién | Una persona | El equipo, con criterio acordado |
| Duración | Minutos | Horas |
| Resultado | Un mensaje clasificado y enrutado | Un orden de trabajo |
La confusión entre ambos tiene un síntoma reconocible: reuniones de priorización que se van en discutir qué significa cada petición. Eso es triage sin hacer, ocupando el tiempo de la priorización.
La regla que lo evita es sencilla. Nada entra en una conversación de priorización sin haber pasado por triage. Si llega sin categorizar y sin deduplicar, vuelve.
Cuándo hacerlo
El triage sufre cuando se acumula. Una cola de doscientos mensajes se revisa peor que cinco colas de cuarenta, porque a partir de cierto punto la persona que revisa empieza a clasificar por inercia.
Dos rutinas funcionan razonablemente bien:
- Diaria y corta. Quince minutos, todo lo que haya entrado desde ayer. Funciona con volumen bajo y constante.
- Dos veces por semana, con dueño rotativo. Reduce el coste de interrupción y reparte el conocimiento sobre lo que piden los usuarios, que suele concentrarse en una sola persona.
Lo que no funciona es el triage bajo demanda, cuando alguien se acuerda. Produce colas irregulares y tiempos de respuesta que dependen de la carga de trabajo de esa semana.
El feedback urgente merece una definición estrecha
Casi todos los mensajes suenan urgentes para quien los escribe. Si la urgencia se decide por el tono, la vía rápida se satura y deja de ser rápida.
Una definición utilizable suele parecerse a esto: es urgente cuando algo que funcionaba ha dejado de funcionar, o cuando un usuario no puede completar una tarea principal y no tiene alternativa. Todo lo demás entra por la vía normal, por muy enfática que sea la redacción.
Esta distinción también protege el tramo siguiente. Un tablero donde todo es prioritario no informa ninguna decisión.
Qué automatizar y qué no
La tentación es automatizar la categorización. Suele ser el peor candidato, porque las categorías dependen del vocabulario interno del equipo y una etiqueta incorrecta es más dañina que ninguna: hace que el mensaje deje de aparecer en las búsquedas correctas.
Lo que sí se deja automatizar con menos riesgo:
- Reunir todo en un mismo sitio. Es un requisito, no una mejora. Sin agregación el triage se hace cuatro veces.
- Señalar candidatos a duplicado. Proponer, no fusionar. La confirmación cuesta segundos y evita fusiones erróneas que son difíciles de deshacer.
- Detectar señales de frustración. FlagUp analiza el lenguaje de cada envío y marca las cuentas donde se acumulan señales negativas, lo que ayuda a decidir a qué mensaje mirar antes. Puedes ver cómo funciona en la página de detección de churn.
Lo que conviene dejar en manos de una persona es el enrutado y el siguiente paso. Son las dos decisiones que dependen de saber qué está haciendo el equipo esta semana, y ningún sistema lo sabe.
Preguntas frecuentes
¿Cuánto debería durar el triage de un mensaje?
Entre uno y tres minutos en la mayoría de casos. Si uno concreto lleva más, normalmente es porque falta información y la acción correcta es preguntar al usuario, no seguir analizándolo.
¿Hace falta una herramienta específica?
No. Hace falta un sitio común y una taxonomía corta. La herramienta ayuda cuando el volumen crece o cuando varias personas participan, sobre todo para no perder los enlaces entre duplicados.
¿Quién debería hacerlo?
Cualquier persona que conozca el producto lo bastante para reconocer un duplicado. Rotarlo tiene una ventaja añadida: reparte el contacto directo con lo que dicen los usuarios.
¿Qué se hace con el feedback que no se va a construir?
Se responde igual. Cerrar con una explicación breve es un resultado legítimo del triage y mantiene la confianza mucho mejor que dejarlo abierto sin fecha.
¿El triage decide qué entra en la hoja de ruta?
No. Decide qué llega en condiciones a la conversación donde eso se decide. Un mensaje puede salir del triage perfectamente clasificado y no construirse nunca.
Artículos relacionados
- ¿Qué es la agregación de feedback? Definición y ejemplos
- ¿Qué es la velocidad del feedback? Definición y ejemplos
- Cuando las solicitudes de funciones revelan problemas de UX
Si el triage se te acumula porque el feedback llega por demasiados sitios, reducir la entrada ayuda más que acelerar la revisión. Mira las solicitudes de funciones y los planes.