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 de entrada empiezan a llegar 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. La gente perdona bastante bien una caída y bastante mal que la dejen a oscuras.
¿Cómo comunicar una incidencia sin perder clientes?
Avisa antes de saber la causa, di qué no funciona y qué sí, comprométete con la hora de la siguiente actualización y no con la de la solución, y escribe a esa hora aunque no haya novedades, siempre en un solo sitio y con una sola voz. Cuando pase, publica un post mortem con qué pasó, por qué, qué habéis cambiado y qué pasa con los afectados. Y ten preparado de antemano una plantilla, una página de estado, quién escribe y un aviso automático en la bandeja de entrada.
Lo que el cliente quiere saber
Cuando algo se rompe, quien lo sufre no está juzgando tu ingeniería. Quiere respuesta a tres preguntas:
- ¿Lo saben? Si no, tiene que avisar él, y eso ya es trabajo suyo.
- ¿Cuándo vuelve? No para exigir, sino para decidir qué hace mientras: esperar, avisar a su equipo o buscar otra forma.
- ¿Va a volver a pasar? Esta llega después, y es la que decide si renueva.
Comunicar bien una incidencia es responder esas tres, en ese orden, y dejar todo lo demás.
Los primeros veinte minutos
Avisar antes de saber la causa
El error más común es esperar al diagnóstico para escribir. Se entiende, porque nadie quiere decir algo que luego resulte falso, pero hace falta justo lo contrario.
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 además corta el goteo de mensajes. Cada cliente que ve el aviso es un ticket que no llega, 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 cada cliente sabe si le afecta.
Casi nadie escribe la lista de lo que sí funciona, y es lo que más tranquiliza.
Comprometerse con la siguiente actualización, no con la solución
«Volvemos a escribir a las 11:30» es un compromiso que puedes cumplir. «Estará resuelto en una hora» depende de cosas que no controlas, y si lo incumples, un problema técnico se convierte en un problema de credibilidad.
Luego escribe 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» puede parecer un mensaje vacío, pero confirma que hay alguien trabajando en ello.
La plantilla del primer aviso
Para tenerla guardada y rellenar los huecos:
[Hora] — Estamos viendo que [qué falla, como lo diría el cliente] desde aproximadamente las [hora de inicio]. [Qué sí funciona] funciona con normalidad. Estamos trabajando en ello y volveremos a escribir aquí a las [hora + 30 min], haya novedades o no.
Cuatro huecos, sin causa, sin plazo de solución y con la hora de la siguiente actualización.
Durante la incidencia
Toda la información, en un solo sitio: una página de estado, un hilo o un canal. Si lo que se contesta en el chat, lo que se publica en la cuenta de la empresa y lo que sabe quien preguntó por correo no coinciden, el problema se dobla en cuanto dos clientes lo comparan.
Mantén el ritmo aunque no pase nada. Si has dicho cada treinta minutos, escribe cada treinta minutos. El silencio siempre se lee como abandono.
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 lo está, ese cliente tiene una promesa incumplida y los demás no. Se evita con una regla previa: los plazos los da la actualización oficial y nadie más.
La bandeja de entrada responde lo mismo que la página de estado: cada mensaje sobre la caída recibe el estado actual y la hora de la siguiente actualización, no un «lo miramos». Si lo hace un aviso automático, mejor, porque el equipo está arreglando el problema y no contestando.
Qué canal para qué
| Canal | Para qué | Cuándo |
|---|---|---|
| Página de estado | La fuente oficial, con histórico | Desde el primer aviso hasta el post mortem |
| Aviso en la bandeja de entrada y el chat | Que quien escribe reciba el estado sin esperar | Mientras dure |
| Email a los afectados | Avisar a quien no preguntó | Al resolverlo, con el post mortem, o antes si dura horas |
| Redes | Solo si tus clientes te buscan ahí | Un enlace a la página de estado y nada más |
| Aviso dentro del producto | Que quien entra sepa qué no funciona | Si la caída es parcial y se puede entrar al producto |
Todos los canales apuntan al mismo texto, y ninguno dice algo que no digan los demás.
Después: el post mortem
El post mortem responde la tercera pregunta, si va a volver a pasar. Casi todo el mundo se lo salta porque, cuando el problema se resuelve, parece que ya ha terminado.
Un buen post mortem tiene cuatro partes:
- Qué pasó, contado como lo vive el cliente y no el sistema: «Durante 1 h 47 min, las exportaciones fallaron en el 30 % de las cuentas».
- Por qué, con detalle sincero. No hace falta un diagrama, pero no puede sonar a excusa. «Un cambio en cómo guardamos los ficheros no contemplaba las cuentas con más de 50.000 registros» basta y es verdad.
- Qué habéis cambiado para que no se repita, en concreto. «Hemos añadido una prueba con un volumen realista antes de cada despliegue» sirve; «hemos reforzado nuestros procesos» no dice nada, y todo el mundo lo sabe.
- Qué pasa con los afectados. Si hay compensación, se dice aquí; si no la hay, también. Si tienes un SLA firmado con alguien, cumple lo que diga sin esperar a que te lo pidan.
Publicarlo en abierto da miedo la primera vez, y es lo que más confianza construye con el tiempo. Una empresa que cuenta sus caídas con detalle demuestra que las investiga. Publícalo en las 48 horas siguientes: dos semanas después ya no lo lee nadie.
Los cuatro errores que cuestan clientes
1. Una disculpa en lugar de 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 busca si le afecta y cuándo vuelve, y tiene que atravesar un párrafo de cortesía para no encontrarlo.
Pon una disculpa corta al principio y el dato justo después. El orden importa.
2. La voz corporativa
En una incidencia, el tono institucional suena a que se está tapando algo. «Se ha producido una degradación del servicio» y «llevamos una hora caídos» dicen lo mismo, y solo la segunda suena a una persona.
3. Quitarle importancia
Hablar de «un pequeño problema que afectó a algunos usuarios» cuando a alguien le costó la mañana es la forma más rápida de convertir a un cliente comprensivo en uno enfadado. Si la incidencia fue grave, dilo.
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 quedan con la idea 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 lo improvisas a las once de la noche:
- Una plantilla de primer aviso con los huecos por rellenar: qué falla, qué no y cuándo se vuelve a escribir. La de arriba sirve.
- Una página de estado que exista antes de la primera caída y que no dependa de la infraestructura que se cae.
- Una persona que escribe, decidida de antemano. Con dos redactando a la vez salen dos versiones.
- Un aviso automático en la bandeja de entrada mientras dure la incidencia. Es la diferencia entre atender ochenta mensajes o quince, y los ochenta llegan justo cuando menos gente hay para leerlos.
- La lista de clientes con SLA, para avisarles primero y para saber qué les debes después.
Qué hace un agente de IA durante una incidencia
En una caída, un agente de IA es útil si reconoce que la pregunta que llega es sobre la incidencia, da el estado actual con la hora de la siguiente actualización y no finge que lo resuelve. Un sistema que en mitad de una incidencia contesta con un artículo de ayuda genérico empeora las cosas, porque parece que nadie se ha enterado.
También puede separar lo que es de la caída de lo que no. La duda de facturación que llega a las 11:15 no tiene por qué esperar a que se arregle la base de datos: el agente la cierra y deja al equipo con la incidencia. Cómo se configura está en pasar a una persona con el historial.
Lo que queda cuando pasa
Casi ningún cliente se va por una caída. Se va por la suma de una caída y la sensación de que nadie estaba al otro lado, y eso depende de quién escribe y cuándo.
Seis meses después nadie recuerda que estuvisteis dos horas parados. Recuerdan si os enterasteis antes que ellos.
Preguntas frecuentes
¿Cuándo aviso de una incidencia?
En cuanto la confirmes, aunque no sepas la causa. Diez minutos es un buen objetivo. Si esperas al diagnóstico, el cliente lo descubre solo.
¿Cada cuánto actualizo?
Cada treinta minutos en una caída total, cada hora en una parcial, y siempre a la hora que hayas dicho aunque no haya novedades.
¿Tengo que publicar el post mortem?
No es obligatorio, pero es lo que más confianza construye. Como mínimo, mándalo a los afectados. Las empresas que se lo toman en serio lo publican en la página de estado en las 48 horas siguientes.
¿Compenso a los clientes?
Si tienes un SLA firmado, lo que diga, sin que te lo pidan. Si no, depende de la gravedad: un mes gratis a quien perdió una mañana suele costar menos que perder al cliente. Y si no compensas, dilo.
¿Necesito una página de estado si soy pequeño?
Sí, y cuanto más pequeño, más: es lo que permite que una persona avise a cuatrocientos clientes. Alójala fuera de tu infraestructura, para que no se caiga con ella.
Para seguir
- Página de estado para un SaaS
- Cómo comunicar una subida de precios
- Qué es un SLA, y qué debes cuando se incumple
- Cómo reducir el tiempo de respuesta en soporte
- Paso a una persona, para que lo que no es de la incidencia no se quede esperando
- Matriz de escalado de incidencias, con plantilla
