Puntos clave
- Distingue entre alertas e incidencias para que el cliente entienda qué desencadena una respuesta y por qué.
- Explica el ciclo de vida de una alerta en lenguaje sencillo: detección, creación del ticket, clasificación, respuesta, escalado y cierre.
- Traduce los SLA a escenarios concretos en lugar de citar tiempos de respuesta sin contexto.
- Aclara las rutas de escalado para que el cliente sepa quién da la primera respuesta y cuándo pasa al nivel 2 o a un proveedor externo.
- Muestra al cliente qué verá durante y después de una incidencia, y explica cómo los umbrales y el filtrado evitan la fatiga por alertas.
Como proveedor de servicios gestionados (MSP), tienes que ser capaz de explicar tu proceso de gestión de alertas a tus clientes de forma clara y eficaz. Si no lo haces, puedes dar la impresión de que no los estás atendiendo como merecen o de que tu trabajo se queda corto (aunque sigas las mejores prácticas del sector y cuentes con un equipo competente y bien dotado de recursos que resuelve los problemas a tiempo).
Esta guía te ofrece un marco para comunicar tu proceso de gestión de alertas de una manera que tus clientes puedan entender. Así se fijan expectativas realistas y se mantiene la confianza durante las incidencias.
¿Buscas una guía completa sobre el tema? Mira nuestro vídeo: Cómo explicar con claridad tu proceso de gestión de alertas a los clientes.
¿Qué diferencia hay entre alertas e incidencias?
Una incidencia es una interrupción de los servicios de TI que proporcionas o gestionas para tus clientes. Normalmente no están planificadas y pueden ir desde un servicio de internet degradado por una conexión caída hasta la caída total de un servidor de archivos por un fallo del sistema. Las incidencias de ciberseguridad, como las filtraciones de datos, no siempre interrumpen el servicio de forma inmediata o evidente, pero pueden provocar otros efectos negativos.
Una alerta se genera como consecuencia de una incidencia y se envía a tu equipo técnico para que tenga constancia de ella. Puede proceder de sistemas de monitorización o de plataformas de ciberseguridad, y enviarse en la primera aparición de la incidencia (por ejemplo, un servidor deja de responder) o cuando se alcanzan determinados umbrales (por ejemplo, un usuario acumula cierto número de intentos de inicio de sesión fallidos). Las alertas también pueden tener origen humano, en forma de ticket de soporte, y revelar actividad inusual o un mal funcionamiento en tu infraestructura que los sistemas automatizados quizá no detecten.
¿En qué consiste el proceso de gestión de alertas?
El proceso de gestión (o clasificación) de alertas es la forma en que configuras las alertas y respondes a ellas. Un proceso eficaz garantiza que se fijen umbrales razonables y que las alertas se prioricen y se escalen cuando haga falta, de modo que no se pase nada por alto y las incidencias críticas tengan preferencia sobre las molestias menores.
Para tu equipo de MSP, el objetivo del proceso de gestión de alertas es ganar visibilidad sin caer en la fatiga por alertas. Para tus clientes, todo esto debe resultar comprensible: tienes que ser capaz de desmitificar las razones técnicas por las que tu proceso de clasificación de alertas está configurado como está. Así, cuando inevitablemente se produzca una incidencia grave, se quedarán tranquilos sabiendo que tiene prioridad sobre el resto del trabajo en curso y que tu equipo ya está encima.
Explica con claridad tu proceso de gestión de alertas
La tecnología te ayuda a transmitir a tus clientes que tu equipo está preparado. Puedes hacer una demostración del software de monitorización y mostrar los paneles y las notificaciones en funcionamiento. Las políticas de monitorización y alertas (incluidos los niveles de escalado) pueden compartirse a través de la plataforma de documentación de tu MSP, y el software de helpdesk puede dar soporte a una comunicación clara con el cliente y a las actualizaciones de estado de una incidencia.
Las revisiones trimestrales de negocio (QBR) son una buena ocasión para presentar informes generados a partir de las métricas de monitorización y del helpdesk, y demostrar que tu proceso de gestión de alertas ha funcionado.
Al explicar tu proceso de gestión de alertas, tus clientes deberían obtener una respuesta clara a estas preguntas:
- ¿Qué pasa cuando algo falla?
- ¿Con qué rapidez responderéis?
- ¿Cómo sé que no se va a quedar nada sin atender?
Ninguna de estas respuestas debería sonar abstracta: deben ser respuestas concretas, basadas en tus políticas, que se demostrarán cuando surja la necesidad real.
Requisito 1: explica el ciclo de vida de la alerta en lenguaje sencillo
Evita la jerga técnica al explicar tus sistemas de monitorización y tus métodos de alerta. Cubre las siguientes tecnologías y conceptos, y explica cómo los usas para responder a los problemas del cliente:
- Detección: explica qué herramientas de monitorización usas para identificar problemas.
- Creación del ticket: explica cómo se crean los tickets, tanto de forma automática desde los sistemas de monitorización como por parte de los usuarios al reportar un problema.
- Clasificación: detalla cómo tu técnico valida una alerta y evalúa su prioridad.
- Respuesta: si la alerta ha detectado una incidencia, recorre el proceso de asignación y resolución.
- Escalado: asegúrate de que el cliente entiende que, si una incidencia no se resuelve con rapidez, la alerta pasa a personal de mayor nivel o a un proveedor externo. Por ejemplo, puede ser necesario escalar al soporte de Microsoft un problema de Microsoft 365 que no se puede resolver desde fuera.
- Cierre e informes: los detalles y los tiempos de resolución documentados se incluyen en los informes y sirven para revisiones y mejoras futuras.
Aquí ayudan mucho los diagramas y diagramas de flujo que muestran cómo avanzan los distintos tipos de alerta. Por ejemplo, puedes mostrar cómo una alerta de prioridad baja se escala a medida que se alcanzan los umbrales.
Requisito 2: traduce los SLA a escenarios
Los escenarios prácticos ayudan a tranquilizar al cliente porque le dan un ejemplo que puede trasladar a sus propios procesos de negocio para valorar el impacto de tu proceso de alertas.
Por ejemplo, en lugar de limitarte a citar un tiempo de respuesta, dale contexto: «Si tu servidor se cae a las 2 de la madrugada, nuestro sistema genera una alerta al instante y un técnico de guardia responde en menos de 15 minutos. Lo normal es que lo tengamos de nuevo operativo en los 30 minutos siguientes y, si no lo conseguimos, escalaremos a un técnico presencial en el plazo de una hora».
Requisito 3: aclara las rutas de escalado
Explica por qué una incidencia no se va a quedar atascada en una cola ni en manos de un técnico que no ha logrado resolverla. Cubre estos puntos:
- Quién se encarga de la primera respuesta (nivel 1)
- Quién escala los problemas complejos (nivel 2/3 o proveedor externo)
- Cómo se avisa a los clientes y a las partes interesadas durante el escalado
Requisito 4: muestra a tus clientes qué verán cuando algo falle
Durante el onboarding del cliente, muéstrale ejemplos de lo que verá durante y después de las incidencias que han disparado alertas. Pueden ser informes con las alertas resueltas y las métricas de disponibilidad, o paneles para el cliente con datos en tiempo real.
Destaca los casos excepcionales en las QBR para demostrar la eficacia de tu proceso de gestión de alertas.
Requisito 5: diferencia entre alertas y ruido
Conviene explicar qué tecnologías hay detrás de tu monitorización y tus alertas, y cómo permiten a tu equipo prestar un servicio eficiente que prioriza la disponibilidad. La fatiga por alertas aparece cuando los técnicos se ven desbordados por alertas de problemas menores y, por eso, se les pasan incidencias importantes.
Muestra a tus clientes cómo lo evitas y cómo usas umbrales, filtrado y automatización para que las incidencias se prioricen con criterio según su gravedad.
NinjaOne ofrece una solución unificada de monitorización, alertas, gestión de tickets y documentación
NinjaOne pone a disposición de los MSP un conjunto completo de herramientas para la monitorización, las alertas y la respuesta a incidencias. Los umbrales se pueden configurar por cliente y, cuando ocurre algo, las notificaciones se envían por SMS, correo electrónico y notificación push, para que los técnicos nunca lleguen tarde con una solución en la mano.
Los tickets del helpdesk de NinjaOne pueden generarse automáticamente a partir de alertas procedentes de una amplia variedad de servidores, herramientas y plataformas, y se pueden crear paneles con métricas de disponibilidad y resolución. NinjaOne Documentation te permite guardar SLA, documentación de procesos, diagramas, informes, ejemplos y otros documentos de cara al cliente que aportan contexto valioso y tranquilidad a tu proceso de gestión de alertas.
