Una alarma aparece en pantalla.
Después otra.
Luego llega un correo.
Un grupo de WhatsApp recibe dos mensajes más.
El sistema de monitoreo envía una notificación.
Alguien reenvía la misma información por Telegram.
Nadie sabe con certeza cuál de todos los avisos requiere una acción inmediata.
Hay mucha información.
Pero poca señal.
Más notificaciones no significan más control
Cuando una organización descubre que ciertos eventos pasan desapercibidos, la respuesta habitual es crear nuevas alertas.
La intención es correcta.
El resultado no siempre lo es.
Cada sistema comienza a avisar por su cuenta.
Cada área define sus propias reglas.
Cada plataforma utiliza un canal diferente.
Con el tiempo, las personas reciben tantos mensajes que dejan de distinguir entre:
- una condición crítica;
- una advertencia preventiva;
- un cambio esperado;
- un duplicado;
- una notificación informativa;
- una falsa alarma.
La saturación no mejora la capacidad de respuesta.
La debilita.
La atención se acostumbra al ruido
Cuando un sistema avisa repetidamente sobre situaciones que no requieren acción, las personas aprenden a ignorarlo.
No es indiferencia.
Es adaptación.
Si una alarma se activa diez veces al día y nueve no significan nada, su credibilidad disminuye.
Cuando finalmente aparezca una condición real, el mensaje competirá contra el recuerdo de todas las alertas anteriores.
Este fenómeno suele llamarse fatiga de alarmas.
Pero no pertenece únicamente a hospitales, centros de control o plantas industriales.
También aparece en:
- equipos de TI;
- áreas comerciales;
- soporte;
- logística;
- administración;
- operaciones;
- seguridad;
- monitoreo de precios;
- automatizaciones empresariales.
Cualquier sistema que interrumpe a una persona puede generar fatiga si no utiliza criterio.
Una alerta no es útil solo porque sea correcta
Una notificación puede ser técnicamente correcta y, aun así, ser inútil.
Por ejemplo:
CPU alta: 92 %.
El mensaje puede describir exactamente lo que ocurre.
Pero todavía deja abiertas varias preguntas:
- ¿desde cuándo?;
- ¿es normal para ese servidor?;
- ¿está afectando un servicio?;
- ¿quién debe revisar?;
- ¿qué prioridad tiene?;
- ¿se trata de un evento nuevo o repetido?;
- ¿qué sucede si nadie responde?;
- ¿hay que hacer algo ahora?
Una alerta útil no se limita a transmitir un valor.
Entrega contexto suficiente para decidir.
El costo invisible de cada interrupción
Cada notificación obliga a la persona a cambiar de foco.
Leer.
Interpretar.
Evaluar.
Decidir si corresponde actuar.
Buscar más información.
Volver a la tarea anterior.
Incluso cuando el mensaje no requiere acción, ya consumió atención.
Multiplicado por decenas o cientos de avisos diarios, el costo se vuelve significativo.
Por eso el diseño de alertas no debería medirse solamente por cuántos eventos detecta.
También debería medir cuántas interrupciones evita.
Qué transforma una alerta en señal
Una señal debe justificar la interrupción que provoca.
Para ello necesita, como mínimo, responder cuatro preguntas.
1. ¿Qué ocurrió?
La condición debe expresarse de forma clara.
No basta con mostrar un código técnico si el destinatario no puede interpretarlo inmediatamente.
2. ¿Por qué importa?
La señal debe explicar el contexto.
No es lo mismo una temperatura alta con el equipo detenido que con el equipo operando a plena carga.
3. ¿Quién debe actuar?
Cada evento necesita un propietario.
Enviar una alerta a un grupo amplio puede diluir la responsabilidad.
4. ¿Qué debe ocurrir después?
La señal debe indicar la acción esperada, el tiempo disponible y el mecanismo de escalamiento.
Sin estas respuestas, el mensaje puede informar sin producir una reacción.
La prioridad no puede depender del color
Muchos sistemas utilizan etiquetas como:
- baja;
- media;
- alta;
- crítica.
Pero una prioridad no debería ser solo una propiedad visual.
Debe tener consecuencias operativas.
Por ejemplo:
- qué canal se utiliza;
- cuánto tiempo se espera;
- quién recibe la primera señal;
- cuándo se escala;
- qué nivel jerárquico participa;
- qué evidencia debe quedar;
- si se ejecuta alguna acción automática.
Si todas las prioridades terminan enviándose al mismo grupo por el mismo canal, la clasificación aporta poco.
La deduplicación también es criterio
Un mismo evento puede ser detectado por varias fuentes.
El sensor informa una condición.
El SCADA genera una alarma.
La plataforma de observabilidad registra una anomalía.
El servidor envía un correo.
El operador escribe en un grupo.
Sin una capa de correlación, cinco mensajes pueden representar un solo problema.
La deduplicación no consiste únicamente en eliminar mensajes idénticos.
Consiste en reconocer que varias observaciones pertenecen al mismo evento.
Eso permite entregar una señal más completa y evitar interrupciones innecesarias.
No todo debe enviarse inmediatamente
Algunos eventos requieren una respuesta urgente.
Otros pueden agruparse.
Una estrategia razonable puede distinguir entre:
- señal inmediata;
- resumen cada cierto tiempo;
- informe diario;
- registro silencioso;
- acción automática;
- evento que solo escala si persiste.
Por ejemplo:
Una caída completa de un servicio puede requerir una señal inmediata.
Variaciones menores durante el día pueden aparecer en un resumen.
Una condición transitoria puede registrarse sin interrumpir a nadie.
El objetivo no es ocultar información.
Es asignarle el ritmo correcto.
El canal también puede generar ruido
Enviar el mismo aviso por correo, WhatsApp, Telegram y SMS no convierte el sistema en multicanal.
Lo convierte en repetitivo.
Un diseño multicanal debería utilizar cada vía con una función definida.
Por ejemplo:
- correo para resúmenes;
- Telegram para oportunidades o monitoreo;
- WhatsApp para coordinación operacional;
- SMS para escalamiento crítico;
- CRM para seguimiento comercial;
- ticket para asignación y cierre.
El canal debe responder al contexto del evento.
No a la disponibilidad de una integración.
Escalar no es reenviar
El escalamiento debe ocurrir cuando una condición objetiva no se cumple.
Por ejemplo:
- nadie confirmó recepción;
- el evento continúa activo;
- el tiempo máximo fue superado;
- la primera acción no resolvió el problema;
- el responsable está fuera de turno.
Escalar no es enviar el mismo mensaje a más personas desde el comienzo.
Es aumentar progresivamente la atención cuando el evento lo justifica.
Una buena señal también sabe cuándo callar
Un sistema maduro debe tener reglas para iniciar, actualizar y cerrar un evento.
Si una condición vuelve a la normalidad, la señal debe reflejarlo.
Si el evento ya fue confirmado, no debería seguir enviando avisos idénticos.
Si el problema fue resuelto, el ciclo debe cerrarse.
Si reaparece, debe decidirse si corresponde abrir un nuevo evento o reactivar el anterior.
Saber cuándo dejar de avisar es tan importante como saber cuándo comenzar.
Menos mensajes. Más señales.
La filosofía detrás de NOISE parte de una observación simple:
La atención es un recurso limitado.
Cada mensaje compite por ella.
Por eso el objetivo no debería ser maximizar la cantidad de notificaciones enviadas.
Debería ser aumentar la proporción de mensajes que realmente merecen atención.
Eso exige diseño.
Contexto.
Prioridad.
Destinatario.
Canal.
Escalamiento.
Cierre.
Evidencia.
Una organización no necesita que todos sus sistemas hablen al mismo tiempo.
Necesita que lo importante pueda hacerse escuchar.
Una pregunta para comenzar
Revisa las alertas que hoy recibe tu equipo y pregúntate:
¿Cuántas de ellas exigen una acción concreta?
Después:
¿Cuáles podrían agruparse, contextualizarse, escalarse mejor o simplemente dejar de interrumpir?
El problema no siempre es que falten alertas.
A veces el primer paso es reducirlas.
Cuéntanos qué debería avisarte y qué mensajes ya no deberían hacerlo.