Volver al blog
Operaciones
Operaciones 6 min

Severidades y SLAs: como definir Critica/Alta/Media/Baja sin que explote el inbox

Cuando todo es critico, nada es critico. Definiciones practicas de severidad, ejemplos por categoria y como entrenar al equipo y al cliente para usarlas bien.

El problema de las severidades no es tecnico, es de comportamiento. Cuando todo entra como critico, el sistema deja de filtrar y el equipo pierde capacidad de priorizar. Disenar bien las severidades es disenar comportamiento.

Por que explotan los inboxes

Patron comun: un cliente marca su ticket como P1 porque "es urgente para mi". El agente lo trata como P1 para no discutir. El equipo termina con 40% de tickets en P1 y el concepto pierde sentido.

La solucion no es entrenar al cliente a ser mas razonable. Es disenar criterios que no dependan de la percepcion del cliente.

Definiciones practicas

Critica (P1):

  • Sistema productivo caido totalmente
  • Multiples clientes / toda la operacion afectada
  • Perdida de datos en curso
  • Riesgo de seguridad activo

Tiempos tipicos: respuesta 15 min, resolucion 2-4 horas, escalamiento automatico a supervisor.

Alta (P2):

  • Funcionalidad importante no disponible pero hay workaround
  • Un cliente importante afectado
  • Degradacion significativa de performance
  • Sistema no productivo caido (staging, reportes)

Tiempos: respuesta 1 hora, resolucion 8 horas habiles, reporte diario al supervisor.

Media (P3):

  • Funcionalidad secundaria no disponible
  • Bug que afecta tareas especificas pero no criticas
  • Consultas de configuracion con impacto en operacion
  • Solicitudes con fecha limite en dias

Tiempos: respuesta 4 horas, resolucion 2 dias habiles, reporte semanal.

Baja (P4):

  • Consultas informativas
  • Solicitudes sin fecha limite
  • Mejoras o features requests
  • Errores cosmeticos sin impacto funcional

Tiempos: respuesta 1 dia, resolucion 5 dias habiles, reporte mensual.

El truco: criterios, no percepcion

La clave es que la severidad se asigna por criterios objetivos, no por como se siente el cliente:

  • Cuantos usuarios afectados?
  • Hay workaround?
  • Es sistema productivo?
  • Hay perdida de datos o riesgo de seguridad?

Si el ticket no cumple criterios de P1, no es P1. Aunque el cliente insista.

Matriz de impacto x urgencia

Una forma mas fina de asignar severidad:

| Urgencia \ Impacto | Alto | Medio | Bajo | | Alta | P1 | P2 | P3 | | Media | P2 | P3 | P3 | | Baja | P3 | P3 | P4 |

Esta matriz se automatiza con reglas en Freshdesk/Freshservice: categoria + tipo de cliente + sistema afectado = severidad.

Entrenar al cliente

La educacion del cliente es parte del proceso:

  1. Documentacion publica con ejemplos por severidad.
  2. Formulario de alta de ticket con preguntas guiadas en lugar de campo libre "severidad".
  3. Respuesta automatica que confirma la severidad asignada y la justifica.
  4. Reclasificacion explicita. Si el cliente marco P1 pero no cumple criterios, el agente reclasifica y notifica.

Entrenar al equipo

Un equipo mal entrenado sobre-eleva severidades por miedo a equivocarse. Antidoto:

  • Reuniones de calibracion mensual. Revisar 10 tickets y discutir severidad asignada vs correcta.
  • Criterio claro: si hay duda, P3 por default. Casi nada es P1.
  • Reconocer reclasificaciones correctas. Si un agente bajo un P1 mal asignado a P3, eso es buen trabajo.

Metricas de salud

  • % de P1 sobre total (objetivo: <5%)
  • % de reclasificaciones (objetivo: 5-15%; si es 0% algo esta mal, si es >30% el proceso de entrada falla)
  • Cumplimiento de SLA por severidad (objetivo: >90% en P1-P2, >85% en P3-P4)
  • SLA de respuesta vs resolucion separadas. Respuesta suele cumplirse, resolucion es donde se ve la verdad.

Senales de alarma

  • Mas del 20% de tickets son P1: los criterios son muy laxos o el equipo no los aplica
  • El cliente siempre esta molesto con la severidad: falta comunicacion al crear ticket
  • SLA de P3 se cumple al 100%: probablemente tienes mas capacidad de la que reconoces
  • Nadie recuerda cuando se reviso la matriz de severidades: hora de hacerlo

El balance

Severidades bien calibradas no son estrictas ni laxas. Son consistentes. Un cliente que recibe la misma clasificacion por el mismo tipo de problema confia en el proceso. Un equipo que aplica los mismos criterios cada vez trabaja con menos friccion. Y una direccion que ve el mix de severidades real puede tomar decisiones de staffing con data, no con sensacion.

Resolvik

Implementacion Freshworks para mesas de servicio en Mexico.

Agenda diagnóstico

Resolvik · Soporte inteligente, desde el primer ticket