Durante una caída, los clientes te juzgan por dos cosas: lo rápido que se resuelve el problema y lo que oyen mientras se resuelve. Lo primero no siempre está en tu mano. Lo segundo depende por completo de ti, y es la parte que la mayoría de los equipos improvisa.
Improvisar sale mal de formas previsibles. Nadie publica nada durante una hora porque todo el mundo está arreglando el problema. Tres personas publican tres versiones distintas. La actualización dice «una degradación en el clúster eu-west» y los clientes no tienen ni idea de si les afecta. Esta guía te da un plan de una página para decidir todo eso de antemano, y plantillas para copiar.
El plan de una página
Escríbelo una vez, guárdalo donde la persona de guardia pueda encontrarlo y revísalo dos veces al año.
Roles
Responsable del incidente: es el dueño del incidente, decide la gravedad y coordina la solución.
Comunicador: redacta y publica todas las actualizaciones de cara al cliente. No es la misma persona que arregla el problema; arreglar y escribir a la vez significa que una de las dos cosas sale perdiendo.
Soporte: responde a las preguntas que llegan con un enlace a la página de estado y transmite lo que informan los clientes.
En un equipo pequeño, las mismas personas asumen varios papeles. Lo importante es decidir quién hace qué antes de la caída, no durante. Si lo combinas con un calendario de guardias, los dos primeros roles siempre tendrán nombre.
Niveles de gravedad
Para la mayoría de los equipos bastan tres niveles:
Grave: el producto, el checkout o el inicio de sesión están caídos o son inutilizables para la mayoría de los clientes. Actualiza cada 30 minutos.
Leve: una funcionalidad no funciona o va lenta, o afecta a una parte de tus clientes. Actualiza cada hora.
Mantenimiento: trabajo planificado. Anúncialo con antelación y actualiza cuando empiece y cuando termine.
Canales
Página de estado: siempre, en cada incidente que afecte a los clientes. Es la fuente de verdad a la que enlazan los demás canales.
Notificaciones a suscriptores: avisos por email y chat desde la página de estado, para que los clientes no tengan que estar recargándola.
Banner en la aplicación: para incidentes graves, si tu producto lo tiene.
Email directo: para incidentes graves que hayan afectado a cuentas clave, y para el resumen posterior.
Redes sociales: para incidentes graves, con un enlace a la página de estado, no con una versión aparte de lo ocurrido.
Compromisos
Primera actualización en un máximo de 15 minutos desde que sabes que hay un problema que afecta a los clientes.
Cada actualización dice cuándo llegará la siguiente.
Cada incidente termina con una actualización de resuelto.
Los incidentes graves reciben un breve resumen por escrito en un plazo de cinco días laborables.
Qué debe incluir una buena actualización
Cada actualización, en cualquier fase, responde a cuatro preguntas en este orden:
Qué está afectado, con las palabras que usan los clientes: «el pago», «la app móvil», «el inicio de sesión», no el nombre interno del servicio.
Qué notan: errores, lentitud, emails que no llegan.
Qué pueden hacer, si es que pueden hacer algo: una alternativa provisional, o «no es necesario hacer nada».
Cuándo sabrán más.
Lo que conviene dejar fuera: suposiciones sobre la causa, nombres internos y jerga, culpar a un proveedor o compañero con nombre propio, y promesas sobre cuándo estará resuelto salvo que estés seguro. «Esperamos resolverlo en los próximos 30 minutos» es una promesa que los clientes te van a recordar.
Plantillas para cada fase
Sustituye las partes entre corchetes. Mantén un tono sencillo y tranquilo.
Investigando
Estamos investigando avisos de [errores / carga lenta] cuando [los clientes intentan pagar]. [El resto de la web funciona con normalidad.] Publicaremos una actualización en un máximo de [30 minutos].
Identificado
Hemos identificado la causa: [un problema con nuestro proveedor de pagos / una actualización defectuosa que publicamos a las 14:05]. [Los pagos con tarjeta fallan; las facturas y Swish no están afectados.] Estamos [revirtiendo la actualización / trabajando con el proveedor] y volveremos a informar en un máximo de [30 minutos].
En observación
Hemos aplicado una solución y [el pago] vuelve a funcionar. Seguimos vigilando para asegurarnos de que se mantiene estable. [Los pedidos realizados entre las 14:05 y las 14:40 pueden aparecer como pendientes; se procesarán automáticamente.] Próxima actualización en un máximo de [una hora], o antes si hay cambios.
Resuelto
Este incidente está resuelto. Entre [las 14:05 y las 14:40 CET], [los pagos con tarjeta en el checkout fallaron para la mayoría de los clientes]. [La causa fue una actualización defectuosa, que ya hemos revertido.] [Estamos añadiendo una comprobación para que este tipo de error detenga una publicación antes de que llegue a los clientes.] Sentimos las molestias.
Sin novedades
Seguimos trabajando en [los errores del pago]. No hay cambios desde la última actualización. Próxima actualización en un máximo de [30 minutos].
Esta última importa más de lo que parece. Una página de estado que lleva una hora sin cambiar hace pensar a los clientes que nadie se está ocupando del problema.
Email a los clientes afectados
En incidentes graves que afectan a cuentas clave, un email breve tras el incidente vale más que cualquier página de estado. Envíalo desde una persona, no desde una dirección no-reply.
Asunto: Sobre la caída del pago de hoy
Hola, [nombre]: hoy, entre las 14:05 y las 14:40, los pagos con tarjeta en el checkout fallaron para la mayoría de nuestros clientes, también para ti. La causa fue una actualización defectuosa por nuestra parte, que ya hemos revertido. [Los pedidos que hiciste en ese intervalo ya se han procesado.] Estamos [añadiendo una comprobación automática que detenga este tipo de publicaciones]. Si viste algo que no encaja con esto, responde a este email y lo revisaré personalmente. [Nombre, cargo]
Redes sociales
Sé breve y remite a la página de estado para los detalles:
Estamos detectando errores en el pago y ya estamos trabajando en ello. Actualizaciones aquí: [enlace a la página de estado]
El pago vuelve a funcionar. Gracias por vuestra paciencia y perdonad las molestias. Resumen: [enlace a la página de estado]
Después del incidente
En los incidentes graves, publica un breve resumen en la página de estado o por email en pocos días: qué pasó, cuánto duró, a quién afectó, qué lo causó y qué vas a cambiar. Nuestra plantilla de postmortem cubre la revisión interna que va primero y cómo convertirla en una versión para clientes.
Después, revisa la propia comunicación. ¿Cuánto tardó la primera actualización? ¿Se cumplieron las horas de actualización prometidas? ¿Recibió soporte preguntas que las actualizaciones deberían haber respondido? Corrige el plan, no solo el sistema.
Haz que seguir el plan sea fácil
Un plan solo funciona si seguirlo es más rápido que ignorarlo. Hay unas cuantas cosas que marcan la diferencia:
Entérate antes que tus clientes. Uptimecheck comprueba tus webs y API hasta cada minuto desde Estocolmo, Londres y Nueva York, confirma cada fallo desde una segunda ubicación y avisa a la persona de guardia, para que el reloj de los 15 minutos empiece cuando empieza el problema, no cuando llega el primer ticket de soporte.
Plantillas listas en la herramienta. Las páginas de estado de Uptimecheck ofrecen un primer borrador listo para cada fase (investigando, identificado, en observación, resuelto) en el idioma de la página, además de tus propias plantillas guardadas, en las que {components} rellena las partes afectadas.
Avisa a las personas adecuadas. Los suscriptores siguen la página entera o solo los componentes que usan, por email, Slack, Microsoft Teams, Discord o webhook, y solo reciben aviso quienes siguen los componentes afectados.
Anuncia el mantenimiento con antelación. El mantenimiento programado aparece en la página y se envía por email a los suscriptores antes de que empiece.
Nuestra guía para crear una página de estado en la que confíen tus clientes explica qué poner en la propia página.
Checklist
Asigna de antemano los roles de responsable del incidente, comunicador y soporte.
Acordad tres niveles de gravedad y una frecuencia de actualización para cada uno.
Usa la página de estado como fuente de verdad; los demás canales enlazan a ella.
Publica la primera actualización en un máximo de 15 minutos, aunque lo único que sepas es que lo estás investigando.
Responde qué está afectado, qué notan los clientes, qué pueden hacer y cuándo sabrán más.
Indica la hora de la próxima actualización y cúmplela.
Cierra cada incidente con una actualización de resuelto.
Envía un breve resumen tras los incidentes graves y revisa tanto la comunicación como la solución.