Una de las fuentes de tickets más subestimadas de un SaaS no está en soporte, sino en el producto: los mensajes de error. «Algo ha salido mal.» «Error 500.» «No se ha podido completar la operación.» El usuario no sabe qué ha pasado, ni si es culpa suya, ni qué hacer. Así que hace lo único que puede: escribir a soporte.
Y desde soporte, la conversación empieza igual siempre: «¿Qué estabas haciendo? ¿Qué mensaje te sale? ¿Me mandas una captura?». Un mensaje de error bien escrito resuelve la mitad de esos casos antes de que existan, y la otra mitad llega con la información necesaria.
La respuesta corta
Un buen mensaje de error dice qué ha pasado en palabras del usuario, por qué si se sabe, y qué puede hacer ahora para resolverlo. Evita jerga técnica y culpas, se coloca junto a donde está el problema y, si el usuario no puede resolverlo solo, le da un código o una referencia para que soporte lo encuentre al momento. Los mensajes que más tickets generan se encuentran mirando qué errores mencionan los clientes en las conversaciones de soporte.
Qué tiene que decir
| Parte | Pregunta que responde | Ejemplo |
|---|---|---|
| Qué ha pasado | ¿Qué ha fallado? | No hemos podido importar el archivo |
| Por qué | ¿Es culpa mía? ¿Por qué? | La columna «Email» está vacía en 12 filas |
| Qué hacer | ¿Cómo lo arreglo? | Complétala o elimina esas filas y vuelve a subirlo |
| Referencia (si hace falta) | ¿Cómo pido ayuda? | Si sigue fallando, escríbenos con el código IMP-204 |
No todos los mensajes necesitan las cuatro partes. Pero ninguno debería quedarse solo en la primera.
Ocho ejemplos de antes y después
1. Importación de datos
- Antes: Error al procesar el archivo.
- Después: No hemos podido importar el archivo: 12 filas no tienen email. Complétalas o elimínalas y vuelve a subirlo. [Ver las filas]
2. Límite del plan
- Antes: Has alcanzado el límite.
- Después: Tu plan incluye 3 proyectos y ya tienes 3. Para crear otro, archiva uno o pasa al plan Pro.
3. Permisos
- Antes: Acceso denegado.
- Después: Solo los administradores pueden cambiar la facturación. Pídeselo a Laura García, que es la administradora de tu cuenta.
4. Contraseña
- Antes: Contraseña no válida.
- Después: La contraseña necesita al menos 8 caracteres y un número.
5. Pago
- Antes: Error en el pago.
- Después: Tu banco ha rechazado la tarjeta. Prueba con otra o revisa con tu banco si tiene algún límite. No se ha hecho ningún cargo.
6. Integración
- Antes: Error de conexión con el servicio externo.
- Después: Hemos perdido la conexión con tu calendario. Suele pasar al cambiar la contraseña de la cuenta de Google. [Volver a conectar]
7. Error del servidor
- Antes: Error 500.
- Después: Algo ha fallado por nuestra parte, no es cosa tuya. Tus cambios están guardados. Vuelve a intentarlo en un momento; si sigue pasando, escríbenos con el código SRV-7F3A.
8. Formulario
- Antes: Hay errores en el formulario.
- Después: Revisa el campo «CIF»: falta una letra al final. (Y el mensaje junto al campo, no arriba del todo.)
Reglas que se repiten
- Sin jerga. «Timeout», «excepción», «payload» no existen para el usuario.
- Sin culpas. «Has introducido un dato incorrecto» suena a reproche; «falta la letra final del CIF» ayuda.
- Específico. «12 filas no tienen email» se arregla; «datos no válidos», no.
- Junto al problema. El mensaje al lado del campo que falla, no en una alerta genérica.
- Con una acción. Un botón o un enlace que lleve al siguiente paso.
- Tranquilizar cuando hace falta. «No se ha hecho ningún cargo», «tus cambios están guardados».
Encontrar los que más tickets generan
No hace falta revisar todos los mensajes del producto. Empieza por los que llegan a soporte:
- Busca en las conversaciones frases como «me sale un error», «no me deja», «dice que».
- Agrupa por mensaje o pantalla: unos pocos suelen concentrar la mayoría.
- Reescribe esos primero y mide si bajan las conversaciones sobre ellos.
Si tu herramienta de soporte clasifica de qué va cada conversación, el trabajo es mucho más rápido. Más sobre este método en cómo reducir los tickets repetidos.
El código de referencia
Para los errores que el usuario no puede resolver solo, un código corto en el mensaje cambia la conversación con soporte:
- Sin código: «Me sale un error al guardar.» → cinco preguntas para saber cuál.
- Con código: «Me sale SRV-7F3A.» → soporte busca en los registros y sabe qué pasó.
Si además atiende un agente de IA, puede tener documentado qué significa cada código y qué hacer, y responder al momento. Cómo recoger el resto de información cuando sí es un fallo está en reportes de bugs útiles.
Preguntas frecuentes
¿Qué debe incluir un mensaje de error?
Qué ha pasado en palabras del usuario, por qué si se sabe, qué puede hacer para resolverlo y, si no puede solo, una referencia para pedir ayuda.
¿Cómo reduce tickets un buen mensaje de error?
Resolviendo en el momento lo que el usuario puede arreglar solo y dando a soporte la información necesaria cuando no puede.
¿Hay que mostrar el código de error técnico?
Un código corto de referencia, sí, para que soporte lo encuentre. El detalle técnico completo, no: no ayuda al usuario.
¿Quién escribe los mensajes de error?
Idealmente producto o diseño, con soporte aportando qué mensajes generan más preguntas y qué dudas tienen los clientes.
¿Por dónde empiezo?
Por los mensajes que más aparecen en las conversaciones de soporte. Unos pocos suelen concentrar la mayoría de los tickets.
