Prácticas recomendadas para la comunicación de incidentes

Comunicación de incidentes: ¿para quién es importante?

A tus clientes y compañeros les importa. Y a ti también debería importarte. Los tiempos de inactividad mal gestionados pueden suponer una experiencia desastrosa para tus clientes y equipos, lo que puede afectar a tus resultados. Es posible que a algunos de los clientes les preocupe que puedan verse sorprendidos por más malas experiencias y decidan pasarse a la competencia. Perderás futuros clientes debido a la falta de confianza. La moral del equipo puede resentirse y, como consecuencia, podría bajar la productividad. Además, despídete de todas esas maravillosas recomendaciones que suelen darse del boca a boca.

Por suerte, los tiempos de inactividad imprevistos no tienen por qué convertirse en una pesadilla para la atención al cliente. Resulta que, si se mantiene a los clientes al corriente comunicándoles lo que ocurre y lo que se está haciendo para solucionar el problema, lo entenderán y tendrán una reacción mucho menos negativa ante toda la situación.

Preparación para la comunicación de incidentes

Prepararse adecuadamente evita que el rendimiento flaquee. Si es un eslogan lo suficientemente bueno como para adentrarse en la batalla, es igual de apropiado para tu estrategia de comunicación de incidentes. Cuando te encuentres bajo la presión de un incidente, agradecerás haber dedicado tiempo a la comunicación de incidentes.

Definición de lo que se considera un incidente

Antes de poder comunicar los incidentes, debemos decidir qué es un incidente. Muchas empresas web se basan en un sistema estandarizado de definición de la gravedad en 4 niveles. Aquí tienes una estupenda guía sobre las definiciones de gravedad de nuestro propio manual de gestión de incidentes.

Sean cuales sean tus umbrales de gravedad de los incidentes, resulta fundamental marcar unos límites claros (lo ideal sería que fuera en torno a algún tipo de métrica cuantificable). Si designas un incidente como de gravedad 1, es importante que todos los miembros del equipo sepan exactamente lo que eso significa.

Los sistemas de definición de la gravedad también son útiles para eliminar los matices inherentes al tiempo de inactividad.

Independientemente del sistema que elijas, te recomendamos un plan de comunicación de tolerancia cero para los incidentes que impliquen incidencias de seguridad o pérdida de datos.

Selección de las soluciones de comunicación, canales y plantillas de mensajes con antelación

Los equipos profesionales de soporte y los ingenieros de fiabilidad del sitio no deciden sobre la marcha los canales por los que se van a comunicar. Elaboran un plan de antemano.

Existen seis canales principales para la comunicación de incidentes:

• Página de estado especializada
• Estado insertado
• Correo electrónico
• Herramienta de chat del trabajo
• Redes sociales
• SMS

Página de estado especializada

Nuestra recomendación es que los equipos utilicen una página de estado especializada como principal solución de comunicación de incidentes. Independientemente de que crees tu propia solución u optes por una alojada, como Statuspage, es importante ofrecer a los clientes y compañeros una fuente de información clara durante los incidentes. Statuspage también brinda a los usuarios la posibilidad de suscribirse para conocer las novedades en cuanto se publiquen. Esto alivia la carga de soporte a los equipos que deberían ocuparse de solucionar el problema.

Estado insertado

Statuspage facilita también la introducción de información sobre el estado directamente en cualquier sitio web que gestionen nuestros clientes. Sabemos que la mayoría de los visitantes suelen consultar la página de inicio o de soporte de un proveedor antes de buscar una página de estado. El widget insertado (aquí tienes un ejemplo) permite indicar a esos visitantes de forma sencilla si se ha producido un incidente. Los visitantes también pueden hacer clic en el widget para ir a la página de estado.

Correo electrónico

Puedes dar a tu público la opción de suscribirse para recibir avisos por correo electrónico con un producto como Statuspage a tu disposición. Ya envíes los mensajes directamente desde tu herramienta de correo electrónico o utilices una página de estado para desencadenar el envío de los correos, el correo electrónico es un canal de confianza para la comunicación de incidentes.

Herramientas de chat

Reduce el cambio de contexto y las carencias de información para empleados y agentes con Halp. Halp permite que Jira Service Management sincronice las conversaciones en Slack o Microsoft Teams y tus tickets. La conversación fluida entre las herramientas de chat más populares y la asistencia técnica ayuda a ofrecer buen contexto para los problemas, lo que agiliza su resolución.

Redes sociales

Muchos equipos utilizan canales de redes sociales, como Twitter, para la comunicación durante un incidente. Es buena idea incluirlos en tu estrategia, pero no dependas de ellos como único medio de comunicación.

SMS

Enviar un SMS o mensaje de texto suele ser una forma más inmediata de llegar a alguien y una preferencia para muchas personas cuando se trata de alertas críticas de entrada, como un anuncio de tiempo de inactividad. También constituye un canal donde la gente puede cansarse de los mensajes muy rápidamente y darse de baja si recibe demasiados SMS que no son de interés.

Ninguno de estos canales es una solución milagrosa para la comunicación de incidentes. Todos tienen diferentes puntos fuertes y es al combinarlos cuando se les saca verdadero provecho. Por ejemplo, en Atlassian podemos publicar los incidentes en una página de estado, pero también enviar esas actualizaciones por Twitter. En el portal de Jira Service Management también aparece un mensaje sobre el incidente. Estos mensajes dirigen al usuario de vuelta a la página de estado para obtener más detalles sobre el incidente. La gestión de incidentes en Jira Service Management permite que haya varios puntos de comunicación sin que se crucen los cables ni se pierda la confianza de los clientes en la traducción.

Adapta las alertas y los mensajes a la audiencia

Cuando se produce un incidente, hay que saber con quién hay que hablar, cómo ponerse en contacto y cómo hacerlo con la menor fricción y la menor cantidad de recursos posibles para no torturar al equipo de atención al cliente ni colapsar la comunicación. Lo mejor es empezar internamente con un equipo de respuesta inmediata y trabajar hacia afuera, seleccionando mensajes para cada destinatario.

Aunque cada organización es diferente, en general ayuda pensar en la existencia de 5 grupos distintos de destinatarios para la comunicación:

1. Equipo central de guardia: El primero en saber que algo anda mal, casi inmediatamente después del impacto (normalmente mediante herramientas de monitoreo y alerta). Los equipos internos trabajan entre bastidores para detectar, reunir ayuda, contextualizar y resolver incidentes con herramientas de comunicación colaborativas.
2. Equipo de soporte de primera línea: Este equipo responde directamente a las preguntas y comunica a los clientes cualquier novedad durante el incidente. Es una función de vital importancia, por lo que este equipo debe tener la información adecuada para transmitirla a los usuarios finales.
3. Gerentes y equipo ejecutivo: El equipo central necesita comunicarse con este grupo para ponerlos al tanto de lo que está pasando, del impacto potencial en los otros dos grupos y, con suerte, hacer una estimación de la duración.
4. Plantilla en general: Los empleados deben estar informados, en cuanto los servicios en los que dependen puedan estar provisionalmente inactivos. Con una comunicación proactiva con estos, habrá menos preguntas del tipo "¿cómo va esto?" y menos tickets de soporte de TI duplicados, y se podrá dedicar más atención a solucionar el problema en cuestión.
5. Clientes externos: Si el incidente afecta a clientes externos, se debe enviar alguna comunicación para explicar el problema y cuándo pueden esperar una solución, o al menos una actualización cada enésima vez. En el caso de incidencias que afecten a la capacidad de tus clientes para usar tu producto, te recomendamos que no pases más de una hora sin notificar novedades. También debes indicarles cuándo volverás a informarles. Si se trata de un incidente lo bastante grave (sobre todo, los relacionados con la seguridad o la pérdida de datos) es fundamental agilizar las comunicaciones externas e implicar a los demás equipos necesarios (jurídico, RR.HH., seguridad, etc.).

Configuración de plantillas para la comunicación de incidentes e interrupciones

Bajo la presión de un incidente, lo último de lo que quieres preocuparte es de cómo redactar el anuncio de un incidente. Formular el incidente de manera incorrecta es la excusa perfecta para los gestores no técnicos, que podrían aferrarse a cualquier resquicio para criticar el proceso de respuesta de tu equipo.

Decide el lenguaje que se utilizará habitualmente con antelación, haz que los responsables lo aprueben y guárdalo en una plantilla. De este modo, resultará más fácil introducir los detalles pertinentes y abordar un incidente el mismo día.

Aquí tienes dos de las plantillas de incidentes que usamos para nuestra propia página de estado:

• El sitio está experimentando en estos momentos una carga superior a la normal, lo que puede provocar que las páginas se ralenticen o no respondan. Estamos investigando la causa; comunicaremos las novedades lo antes posible.
• Nuestro proveedor de almacenamiento de datos de métricas públicas está teniendo problemas de infraestructura en estos momentos. Comunicaremos las novedades a medida que se desarrolle la situación o se nos facilite información.

Echa un vistazo a nuestra biblioteca de plantillas de incidentes para ver más ejemplos.

Gestión de la comunicación como un profesional

El ciclo de vida de un incidente incluirá probablemente varios puntos de contacto. Si el proceso se hace bien, un incidente tiene una estructura común que consta de tres partes: primer contacto, actualizaciones durante el incidente y resolución y análisis retrospectivo.

Prólogo: Comunicación centralizada con un equipo interno

Antes que nada, los equipos internos que trabajan dando soporte en un incidente deben tener una plataforma de comunicación establecida y estar preparados para confluir cuando surja una incidencia.

Centralizar y filtrar las alertas en todas tus herramientas de supervisión, inicio de sesión y CI/CD agilizará la respuesta del equipo. Con una plataforma como Jira Service Management, los equipos pueden confluir rápidamente, obtener contexto y mantenerse en contacto durante todo el incidente.

Parte 1: primer contacto

La actualización inicial es la más importante. Todo marca el tono de cómo se percibirá tu respuesta, desde lo que dices hasta cómo y cuándo lo dices. En este aspecto, sirve de gran ayuda contar con una plantilla preparada de antemano.

Tu objetivo debería ser admitir rápidamente el problema, resumir brevemente las consecuencias conocidas, prometer futuras actualizaciones y, si es posible, mitigar cualquier preocupación en torno a la seguridad o la pérdida de datos. Es crucial admitir que hay un problema, aunque todavía no se conozcan los detalles exactos.

Parte 2: actualizaciones periódicas durante el incidente

La comunicación a mitad del incidente resulta esencial.

Según los equipos de SRE de Google, el responsable de comunicación es una de las funciones clave que alguien debe supervisar durante un incidente.

En el libro “Site Reliability Engineering” (Ingeniería de fiabilidad del sitio) de Google, se dice esto sobre la función del responsable de comunicación:

Esta persona es la cara pública del equipo de respuesta ante incidentes. Sus tareas incluyen, sin duda, la comunicación de actualizaciones periódicas al equipo de respuesta ante incidentes y a las partes interesadas (por lo general, por correo electrónico), y también pueden abarcar, por ejemplo, el mantenimiento de un documento de incidentes minucioso y actualizado.

Esta persona también se encargará de continuar actualizando la página de estado o publicar las novedades en los demás canales a medida que la situación evolucione. Incluso una actualización donde se diga “Seguimos trabajando en la incidencia, no hay nada nuevo de lo que informar” es mejor que no comentar nada y dejar al público colgado. La gente que se ve rodeada por la más absoluta oscuridad empieza a temerse lo peor.

Es imprescindible la comunicación con los usuarios afectados y otras partes interesadas. Utiliza tus canales predeterminados para informar a los usuarios de lo que está pasando. En una página de inicio, este canal puede ser una alerta de Statuspage para que los clientes sepan que tu equipo está al tanto del problema. Esto ahorra tiempo a los agentes de lidiar con la redundancia. Mantén a los clientes al tanto de las novedades a través de diferentes canales de notificación, como SMS, correo electrónico o notificaciones móviles.

Da igual cuál sea la herramienta que elijas, te recomendamos que identifiques un canal como tu principal medio de comunicación y canalices ahí a todo el mundo desde los demás canales. Con una gestión de las comunicaciones de incidentes a través de Jira Service Management, te asegurarás de que los mensajes correctos lleguen a las personas adecuadas.

Parte 3: resolución, análisis retrospectivo y lo que viene después

En 2010, Facebook sufrió su mayor interrupción hasta la fecha. Durante unas 2 horas y media, la red social no estuvo disponible para millones de sus entonces quinientos millones de usuarios.

El momento no podía haber sido menos oportuno para el incipiente gigante tecnológico, que aún estaba en los primeros días de su espectacular aumento de usuarios y necesitaba seguir demostrando al mundo empresarial que el servicio merecía la pena.

Cuando las aguas volvieron a su cauce, un ingeniero de Facebook publicó un resumen de 395 palabras en el blog de ingeniería de la empresa sobre el incidente.

Este es un fragmento del blog:

Durant el día de hoy, Facebook ha estado fuera de servicio o inaccesible para muchos de vosotros durante unas 2 horas y media. Esta es la peor interrupción que hemos tenido en más de cuatro años y, en primer lugar, queríamos pedir disculpas por ello. También nos gustaría dar muchos más detalles técnicos sobre lo ocurrido y compartir la gran lección que hemos aprendido.

La estructura del análisis retrospectivo es muy sencilla:

• Admitir el problema, empatizar con los afectados y disculparse
• Explicar lo que ha ido mal y por qué
• Explicar lo que se ha hecho para solucionar el incidente y para evitar que se vuelva a repetir
• Admitir, empatizar y disculparse una vez más

En este tipo de comunicaciones, no es necesario utilizar muchas florituras ni hacer afirmaciones grandilocuentes. Hay que hablar con sencillez e ir al grano. Por ejemplo, también se explicó esto en el blog de Facebook:

Nos disculpamos de nuevo por la interrupción del sitio y queremos que sepáis que nos tomamos muy en serio el rendimiento y la fiabilidad de Facebook.

Esta forma de hablar facilita que los clientes y compañeros confíen en que diriges un equipo sensato y que no pierdes de vista el objetivo. Examina nuestra plantilla de análisis retrospectivo de respuesta ante incidentes para obtener más ideas.

La realidad de los servicios ininterrumpidos es que, en ocasiones, surgen problemas de improviso. Una comunicación eficiente durante el tiempo de inactividad puede infundir confianza tanto en los compañeros como en los clientes. Una buena respuesta puede marcar la diferencia. También hemos creado esta sencilla herramienta para ayudarte a redactar rápidamente comunicaciones eficaces durante los incidentes.