«Me sale un error.» «No me deja guardar.» «Desde ayer va fatal.» Así llegan la mayoría de los fallos a soporte en un SaaS. Y es normal: el cliente no tiene por qué saber qué información necesita un desarrollador para reproducir un problema.
El trabajo de convertir ese «no funciona» en algo que se pueda arreglar es de soporte. Hecho bien, el desarrollador recibe un fallo que reproduce en cinco minutos. Hecho mal, el caso va y viene entre tres personas durante una semana y el cliente acaba pensando que nadie le hace caso.
La respuesta corta
Para que un bug reportado por un cliente se pueda arreglar hace falta saber qué intentaba hacer, qué esperaba que pasara, qué pasó en realidad, los pasos para reproducirlo y el contexto: cuenta, navegador o dispositivo, hora y una captura o el mensaje de error. Soporte pide solo lo que falta, comprueba si es un fallo o un problema de configuración y lo pasa a desarrollo con una plantilla fija. Al cliente se le dice qué va a pasar sin prometer fechas, y se le avisa cuando se arregla.
Qué información hace falta
| Dato | Por qué | Quién lo aporta |
|---|---|---|
| Qué intentaba hacer | El contexto del fallo | Cliente |
| Qué esperaba y qué pasó | Define el fallo | Cliente |
| Pasos para reproducirlo | Sin ellos, el desarrollador adivina | Cliente y soporte |
| Mensaje de error o captura | El dato más rápido de todos | Cliente |
| Cuenta y usuario | Para mirar sus datos y registros | Soporte (no hace falta preguntarlo) |
| Navegador, dispositivo, versión de la app | Muchos fallos dependen de esto | Soporte o el propio producto |
| Hora aproximada | Para buscar en los registros | Cliente |
| Si le pasa a más gente | Gravedad | Soporte |
La regla: no preguntes al cliente lo que puedes saber tú. Su cuenta, su plan y, muchas veces, su navegador ya los tienes. Preguntarlos le hace sentir que repite trabajo.
Cómo pedírsela sin agobiar
Una lista de diez preguntas al primer mensaje cansa. Mejor pedir solo lo que falta, en una frase, y explicar para qué:
Gracias, Laura. Para poder reproducirlo: ¿qué estabas intentando guardar cuando apareció el error? Si puedes, mándame una captura de la pantalla con el mensaje; con eso el equipo técnico lo encuentra mucho antes.
Y lo que ayuda a largo plazo es que el producto lo haga más fácil:
- Mensajes de error con un código que el cliente pueda copiar.
- Un botón de «informar de un problema» que adjunte solo la versión, el navegador y la pantalla.
- Una página de estado donde el cliente vea si el problema es general antes de escribir. Más en cómo comunicar una incidencia.
Fallo, configuración o pregunta
Antes de pasar nada a desarrollo, soporte comprueba qué es:
- Un fallo: el producto no hace lo que debería, y se reproduce.
- Un problema de configuración: el producto funciona, pero la cuenta está mal configurada. Lo resuelve soporte.
- Una pregunta disfrazada de fallo: «no me deja exportar» porque su plan no incluye la exportación. Lo resuelve soporte, y quizá es una petición de funcionalidad: más en cómo gestionar las peticiones de funcionalidades.
Este filtro es lo que más tiempo de desarrollo ahorra. Cómo organizarlo por niveles está en niveles de soporte técnico.
La plantilla para desarrollo
Cuando es un fallo, se pasa siempre con la misma forma:
Título: Error al guardar una factura con descuento del 100 %
Qué pasa: Al guardar una factura con un descuento del 100 %, aparece «Error 500» y la factura no se guarda.
Qué debería pasar: La factura se guarda con importe 0.
Pasos para reproducirlo:
1. Crear una factura nueva.
2. Añadir una línea de 50 €.
3. Aplicar un descuento del 100 %.
4. Pulsar Guardar.
Contexto: Cuenta 4821, plan Pro, Chrome en Windows. 3 de octubre, 10:42.
Alcance: 2 clientes afectados que sepamos. Hay alternativa: aplicar un descuento del 99,99 %.
Conversaciones: [enlace a las conversaciones]
La línea de alcance y la de alternativa son las que permiten priorizar.
Cómo priorizar
| Prioridad | Cuándo | Ejemplo |
|---|---|---|
| Crítica | Muchos clientes no pueden usar algo esencial, sin alternativa | No se puede iniciar sesión |
| Alta | Afecta a algo importante, con alternativa incómoda | Una exportación falla con ciertos datos |
| Media | Molesta, con alternativa razonable | Un filtro no guarda la selección |
| Baja | Detalles | Un texto mal alineado |
Qué decirle al cliente
Lo hemos reproducido: es un fallo nuestro al guardar facturas con un descuento del 100 %. Ya está en manos del equipo técnico. Mientras tanto, puedes aplicar un 99,99 % y se guarda sin problema. Te escribo en cuanto esté arreglado.
Lo que tiene: confirma que es un fallo (y que no es culpa suya), da una alternativa si existe y promete avisar, no una fecha.
Cerrar el círculo
Cuando se arregla, avisa a cada cliente que lo reportó. Es un mensaje de un minuto y uno de los que más confianza construyen. Si el fallo está enlazado a sus conversaciones, saber a quién avisar es inmediato.
Con Jira o GitHub conectados, el agente de Intake puede crear la incidencia desde la conversación, consultar en qué estado está cuando el cliente pregunta y, con GitHub, avisar cuando se cierra el issue.
Errores frecuentes
- Pasar a desarrollo todo lo que parece un fallo, sin filtrar.
- Pedir al cliente datos que ya tienes.
- Reportes sin pasos para reproducir, que vuelven a soporte.
- Prometer fechas de arreglo que no controlas.
- No avisar cuando se arregla.
Preguntas frecuentes
¿Qué debe incluir un reporte de bug?
Qué se intentaba hacer, qué se esperaba y qué pasó, los pasos para reproducirlo, el mensaje de error o una captura, y el contexto: cuenta, navegador o dispositivo y hora.
¿Cómo pido a un cliente que reporte un bug?
Pidiendo solo lo que falta, en una frase y explicando para qué. Lo que ya sabes de su cuenta no se pregunta.
¿Quién decide si algo es un bug?
Soporte hace el primer filtro: comprueba si se reproduce y si no es un problema de configuración o una pregunta. Desarrollo confirma.
¿Hay que decir al cliente cuándo se arreglará?
Mejor no prometer fechas. Sí confirmar que es un fallo, dar una alternativa si la hay y avisarle cuando esté arreglado.
¿Cómo evito que los bugs reportados se pierdan?
Registrándolos siempre en la misma herramienta, enlazados a las conversaciones de los clientes afectados.
