El producto lleva catorce minutos caído. Sabes que está caído, no sabes por qué, y hay tres personas mirándolo. En la bandeja empiezan a entrar mensajes.
Lo que hagas en los próximos veinte minutos va a pesar más en la relación con esos clientes que lo que tardes en arreglarlo. Y no es una frase bonita: es que la gente perdona bastante bien una caída, y bastante mal la sensación de que le han dejado a oscuras.
Lo que el cliente está calculando
Cuando algo se rompe, quien lo sufre no está evaluando tu ingeniería. Está respondiendo tres preguntas:
- ¿Lo saben? Porque si no lo saben, tiene que avisar él, y eso ya es trabajo suyo.
- ¿Cuándo vuelve? No para exigir, sino para decidir qué hace mientras: si espera, si avisa a su equipo, si busca otra forma.
- ¿Va a volver a pasar? Esta llega después, y es la que decide si renueva.
Toda la comunicación de una incidencia consiste en responder esas tres, en ese orden, y no perder el tiempo con nada más.
Los primeros veinte minutos
Avisar antes de saber la causa
El error más común es esperar a tener el diagnóstico para escribir. Es comprensible —nadie quiere decir algo que resulte falso— y es exactamente al revés de lo que hace falta.
Un mensaje a los diez minutos que diga «hemos detectado que las exportaciones están fallando, estamos en ello, escribimos otra vez en treinta minutos» responde las dos primeras preguntas sin comprometerse con ninguna causa. Y hace algo más importante: corta el goteo de mensajes. Cada cliente que ve ese aviso es un ticket que no entra, y en mitad de una caída el equipo no tiene manos para contestarlos.
Decir qué no funciona, no qué ha fallado
«Estamos teniendo problemas con un servicio interno» no le sirve a nadie. «Las exportaciones a CSV están fallando; el resto del producto funciona con normalidad» sí, porque le dice a cada cliente si le afecta.
La lista de lo que sí funciona es la parte que casi nadie escribe y la que más tranquiliza.
Comprometer la siguiente actualización, no la solución
«Volvemos a escribir a las 11:30» es un compromiso que puedes cumplir. «Estará resuelto en una hora» es un compromiso que no controlas, y si lo incumples has convertido un problema técnico en un problema de credibilidad.
Y luego, escribir a las 11:30 aunque no haya novedades. «Seguimos en ello, sabemos que es de la base de datos, próxima actualización a las 12:00» es un mensaje que parece vacío y no lo es: confirma que hay alguien despierto.
Durante
Un solo sitio. Una página de estado, o un hilo, o un canal. Lo que no puede ser es que la información esté repartida entre lo que se contesta en el chat, lo que se dice en la cuenta de la empresa y lo que sabe quien preguntó por correo. En cuanto dos clientes comparan lo que les han dicho y no coincide, el problema se dobla.
El mismo ritmo aunque no pase nada. Si has dicho cada treinta minutos, cada treinta minutos. El silencio se interpreta como abandono, siempre.
Nadie promete plazos por su cuenta. En mitad de una caída, alguien del equipo, con toda la buena intención, le dice a un cliente grande que «en media hora estará». Cuando no está, ese cliente tiene una promesa incumplida y los demás no. Esto se evita antes: la regla es que las fechas las da la actualización oficial y nadie más.
Después: el post mortem
Es la parte que responde la tercera pregunta —si va a volver a pasar— y la que casi todo el mundo se salta porque, cuando el problema se resuelve, la sensación es de haber terminado.
Un post mortem que sirve tiene cuatro cosas y ninguna más:
Qué pasó, en lenguaje del cliente y no del sistema. «Durante 1 h 47 min, las exportaciones fallaron para el 30 % de las cuentas.»
Por qué, con el nivel de detalle honesto. No hace falta un diagrama; hace falta que no suene a excusa. «Un cambio en cómo guardamos los ficheros no contemplaba las cuentas con más de 50.000 registros» es suficiente y es verdad.
Qué habéis cambiado para que no se repita. Concreto. «Hemos añadido una prueba con un volumen realista antes de cada despliegue» vale; «hemos reforzado nuestros procesos» no vale nada, y además todo el mundo sabe que no vale nada.
Qué pasa con quien se vio afectado. Si hay compensación, aquí. Si no la hay, decirlo también.
Publicarlo en abierto da miedo la primera vez y es lo que más confianza construye a medio plazo. Una empresa que cuenta sus caídas con detalle está diciendo, sin decirlo, que las mira.
Los cuatro errores que cuestan clientes
1. La disculpa que ocupa el sitio de la información
«Lamentamos profundamente las molestias ocasionadas y agradecemos vuestra paciencia mientras nuestro equipo trabaja incansablemente…». Cuatro líneas y ni un dato. Quien lo lee está buscando si le afecta y cuándo vuelve, y tiene que atravesar un párrafo de cortesía para no encontrarlo.
Una disculpa corta al principio y el dato inmediatamente después. El orden importa.
2. La voz corporativa
En una incidencia, el registro institucional suena a que se está tapando algo. «Se ha producido una degradación del servicio» describe lo mismo que «llevamos una hora caídos», y solo una de las dos frases suena a alguien.
3. Minimizar
«Un pequeño problema que afectó a algunos usuarios» cuando ese pequeño problema le costó la mañana a alguien es la forma más rápida de convertir un cliente comprensivo en un cliente enfadado. Si la incidencia fue grave, se dice que fue grave.
4. Contarlo solo a quien preguntó
Es lo más habitual en equipos pequeños: se contesta a los ocho que escribieron y no se avisa a los cuatrocientos que lo sufrieron en silencio. Esos cuatrocientos se han quedado con la experiencia de que el producto falla y nadie dice nada.
Lo que se puede tener preparado
Todo esto es mucho más fácil si no se improvisa a las once de la noche:
- Una plantilla de primer aviso con los huecos por rellenar: qué falla, qué no falla, cuándo se vuelve a escribir.
- Un sitio de estado que exista antes de la primera caída y que no dependa de la misma infraestructura que se cae.
- Quién escribe. Una persona, decidida de antemano. Con dos redactando en paralelo salen dos versiones.
- Un aviso automático en la bandeja mientras dure la incidencia. Es la diferencia entre atender ochenta mensajes o quince, y los ochenta llegan justo cuando menos gente hay disponible para leerlos.
Ese último punto es donde un agente de IA hace algo útil de verdad en una incidencia, y no es responder: es reconocer que la pregunta que entra es sobre la caída, dar el estado actual y no fingir que resuelve. Un sistema que en mitad de una incidencia contesta con un artículo de ayuda genérico empeora las cosas, porque suena a que nadie se ha enterado.
Lo que queda cuando pasa
Casi ningún cliente se va por una caída. Se van por la suma de una caída y la sensación de que nadie estaba al otro lado —y eso no depende de la infraestructura, depende de quién escribe y cuándo.
Lo que se recuerda seis meses después no es que estuvisteis dos horas parados. Es si os enterasteis antes que ellos.
