La frase más cara del soporte
«¿Podrías enviarnos una captura de pantalla y decirnos qué navegador usabas?» Es una pregunta educada y razonable, y es la razón por la que un bug de dos minutos tarda tres días en arreglarse. El cliente está ocupado, así que la respuesta llega mañana. La captura muestra el mensaje de error pero no el clic que lo causó. La versión del navegador es incorrecta porque lo comprobó en el móvil. Cuando ingeniería ve el ticket, nadie recuerda exactamente qué pasó, ni siquiera el cliente.
La solución no es un formulario de reporte mejor. Es dejar de pedirle al cliente pruebas que podrías haber capturado tú mismo, en el momento en que ocurrió el problema.
Qué contiene realmente un buen reporte de bug
Los ingenieros necesitan cinco cosas para reproducir un bug:
- Qué hizo el cliente: los clics y las entradas, en orden.
- Qué esperaba: el resultado que intentaba conseguir.
- Qué pasó en realidad: el error, la pantalla en blanco, el botón que no hacía nada.
- El entorno: página, navegador, dispositivo, tamaño de pantalla y de dónde venía.
- La traza técnica: los errores de consola y las peticiones de red que fallaron.
Un cliente puede darte de forma fiable el segundo punto y parte del tercero. Los otros tres son exactamente lo que graba una repetición de sesión: la secuencia de acciones, la página y el navegador, el log de consola y las llamadas de red. Pedir a la gente que reconstruya eso de memoria es pedirle justo la parte que peor puede dar.
Adjunta la sesión en lugar de pedirla
El punto de partida más sencillo es el propio reporte. Cuando un cliente envía un widget de feedback o un formulario de bug dentro de la app, la sesión está ahí: la página en la que está, los errores que acaban de saltar, las peticiones que fallaron hace un segundo. Captúrala con el reporte y el ticket llega ya con lo que ingeniería necesita.
Eso cambia la primera respuesta. En lugar de «¿puedes enviar una captura?», el agente abre la repetición, ve el TypeError en la consola dos segundos antes de que el cliente volviera a pulsar Pagar, y puede decir en la misma hora «vemos qué falló y aquí tienes una solución provisional».
El correo es más difícil, porque un correo no lleva ninguna sesión adjunta. Dos hábitos ayudan. Identifica a los usuarios con sesión iniciada en tu analítica para que un ticket de una dirección conocida pueda vincularse a sus sesiones recientes, y pon un enlace de feedback dentro del producto para que el próximo reporte llegue desde la página donde está el problema, no desde una bandeja de entrada un día después.
Clasifica por bug, no por ticket
Cuando los tickets llevan el error, puedes agruparlos por él. Aquí es donde la mayoría de los equipos ganan más. Un bug en el pago no produce un ticket; produce treinta, cada uno escrito de forma distinta: «el pago falló», «no puedo comprar», «botón roto». Leídos de uno en uno, parecen treinta problemas. Agrupados por el mensaje de error que comparten, son un solo bug con treinta clientes afectados, y esa es la cifra que hace que se priorice.
Agrupar también cambia cómo cierras el ciclo. Escala el bug una sola vez, a una incidencia en Linear, GitHub o Jira, y vincula a ella cada ticket que coincida. Cuando se publique el arreglo, todos esos clientes pueden enterarse, no solo los cinco que volvieron a escribir.
Para que esto funcione, la agrupación tiene que coincidir con lo que ingeniería ya ve. Si soporte cuenta «problemas de pago» e ingeniería cuenta Cannot read properties of undefined (reading 'total'), las dos listas nunca cuadran. Agrupa los tickets por el mismo mensaje de error normalizado que usa tu seguimiento de errores.
Resuelve la privacidad antes de que te resuelva a ti
Adjuntar sesiones a los tickets significa que los agentes de soporte ven más de lo que hicieron los clientes, así que fija primero las reglas:
- Enmascara los campos de formulario por defecto y nunca grabes contraseñas ni campos de pago.
- Indica en tu política de privacidad que soporte puede revisar la sesión vinculada a una solicitud.
- Limita el acceso a las repeticiones a quienes trabajan los tickets, no a todo el que tenga usuario.
- Respeta el consentimiento: un visitante que rechazó la analítica no debería tener una sesión que adjuntar.
Hecho así, el contexto de sesión es menos invasivo que la alternativa, que es pedir a los clientes que compartan pantalla o envíen por correo capturas de su cuenta.
Un flujo de trabajo para empezar esta semana
- Añade un widget de feedback o de reporte de bugs dentro de la app en las páginas donde más problemas ocurren: pago, onboarding, ajustes.
- Captura la sesión con cada envío, para que cada ticket lleve la repetición, el log de consola y las peticiones fallidas.
- Identifica a los usuarios con sesión iniciada, para que los tickets por correo de clientes conocidos puedan vincularse a sus sesiones.
- Agrupa los tickets por error y revisa cada semana los grupos principales con ingeniería.
- Escala cada bug una sola vez y responde a cada cliente vinculado cuando esté arreglado.
Qué medir
Cuatro cifras te dicen si esto funciona:
- Porcentaje de tickets de bug con una sesión adjunta. Es el indicador adelantado; súbelo primero.
- Tiempo hasta la primera respuesta útil, es decir, una respuesta que no pide más información.
- Tickets por bug. Si baja, estás arreglando los bugs que más carga de soporte generan.
- Tasa de reapertura de los tickets de bug, que baja cuando la primera respuesta es la correcta.
El help desk de PulsePanda está construido en torno a este ciclo: el feedback se convierte en tickets con la repetición y los errores adjuntos, los tickets se agrupan por los mismos errores que la página de Errores, y escalar a Linear, GitHub o Jira te permite responder a cada cliente afectado cuando la incidencia se cierra.