Un proceso de escalación es el camino documentado que toma un problema de cliente desde “el CSM lo notó” hasta “un dueño responsable lo está arreglando contra reloj”. Sin él, cada incendio se trabaja a la velocidad de quien casualmente esté en el canal de Slack, y la percepción de severidad del cliente se aleja de la tuya. Esto es un how-to: construye las cuatro piezas — niveles de severidad, enrutamiento, cadencia de comunicación y seguimiento de causa raíz — en ese orden, porque cada una depende de la anterior.
Prerrequisitos
- Una plataforma de ticketing o de CS que pueda guardar un campo de severidad y registrar timestamps de los cambios de estado. Zendesk, Pylon o Gainsight sirven; el campo importa más que el tool.
- Un workspace de Slack con la capacidad de crear canales por incidente.
- Una rotación on-call nombrada para ingeniería, o como mínimo un dueño responsable por área de producto.
- Una señal de health-score o tier de cuenta para que una asignación de Sev pueda factorizar el valor de la cuenta, no solo el impacto técnico.
Paso 1 — Define niveles de severidad con SLAs de respuesta y resolución
La severidad es una decisión de dos ejes: impacto de negocio por peso de cuenta. Escribe la matriz una vez y aplícala mecánicamente, para que una decisión de Sev no sea un debate a las 4pm un viernes.
| Sev | Disparador | SLA de respuesta | Cadencia de actualización | Objetivo de resolución |
|---|---|---|---|---|
| Sev 1 | Producción caída, pérdida de datos o exposición de seguridad para una cuenta que paga | 15 min | Cada 30 min | 4 horas |
| Sev 2 | Feature mayor rota, sin workaround, o cualquier problema en una cuenta top-tier/en riesgo | 1 hora | Cada 2 horas | 1 día hábil |
| Sev 3 | Función degradada con un workaround | 1 día hábil | Diario | 5 días hábiles |
| Sev 4 | Cosmético, pregunta o feature request mal etiquetado como bug | 2 días hábiles | Al cambiar | Backlog |
El eje de peso de cuenta es lo que CS agrega y que el triage de soporte puro pierde: un problema técnico Sev 3 en una cuenta en trimestre de renovación al 70% de health es un Sev 2 en la práctica. Codifícalo — si account_tier = strategic o health_score < 60, sube el Sev en uno. No dejes que cada CSM lo suba a mano; la regla lo hace.
Paso 2 — Enruta a un dueño nombrado, no a una cola
Una cola es donde las escalaciones van a envejecer. Enrutar significa que cada Sev tiene un dueño preacordado y un canal preacordado antes de que el incidente exista.
- Al asignar el Sev, autocrea un canal de Slack dedicado llamado
#esc-<cuenta>-<fecha>. Los canales por incidente le ganan a una sola manguera compartida porque el historial queda buscable y el resumen de cara al cliente es un solo scroll, no una reconstrucción. - Autoinvita al dueño responsable de la rotación on-call, al CSM de la cuenta y — para Sev 1/2 — al manager de CS. Para Sev 1, haz page, no @-mention: una mención es una notificación, un page es una obligación.
- Abre un issue de tracking en Linear (o tu tracker de ingeniería) enlazado al canal, con el Sev, la cuenta y el reloj del SLA en la descripción. El registro del lado de CS (en Gainsight o tu CRM) enlaza al mismo issue para que el contexto de renovación y del CSM viaje con él.
- El CSM es dueño de la relación con el cliente todo el tiempo; el dueño de ingeniería es dueño del fix. Separar estos dos roles explícitamente previene la falla donde el CSM se queda en silencio porque está esperando a ingeniería, y el cliente no escucha nada.
Paso 3 — Corre la cadencia de comunicación
La ansiedad del cliente es función del silencio, no de la severidad. Un Sev 1 con una actualización cada 30 minutos se siente manejado; un Sev 3 con tres días de silencio se siente como Sev 1.
- Reconoce dentro del SLA de respuesta con un mensaje humano: qué entiendes que es el problema, el Sev que asignaste y cuándo llega la siguiente actualización. Nombrar la hora de la siguiente actualización es la jugada de mayor apalancamiento — convierte la espera abierta en una promesa cumplida.
- Actualiza según la cadencia incluso cuando no hay novedades. “Aún investigando, causa raíz no aislada todavía, siguiente actualización a las 3pm” es una actualización válida. Saltártela porque nada cambió es la escalación-de-la-escalación evitable más común.
- Separa el lenguaje interno del externo. El canal interno puede decir “la tormenta de retries está machacando la cola”; el cliente escucha “identificamos la causa y estamos desplegando un fix”. Nunca pegues chatter crudo de ingeniería al cliente.
- Cierra explícitamente. Declara qué se arregló, confirma que el cliente lo ve resuelto y pide su confirmación antes de marcarlo como cerrado. Un cierre unilateral se lee como desdeñoso y con frecuencia se reabre.
Paso 4 — Seguimiento de causa raíz
Cerrar el ticket no es cerrar el loop. Cada Sev 1 y Sev 2 recibe una revisión post-incidente sin culpas dentro de cinco días hábiles.
- Línea de tiempo. Reconstrúyela desde los timestamps del canal y del tracker: detección, reconocimiento, mitigación, resolución. Mide tiempo-a-reconocer y tiempo-a-resolver contra el SLA.
- Cinco porqués hasta una causa sistémica. Detente en la brecha de proceso o de sistema, no en la persona. “El CSM no vio la alerta” no es una causa raíz; “las alertas se enrutan a email, que el CSM no monitorea durante horas de EU” sí lo es.
- Acciones correctivas con dueños y fechas. Cada acción es un issue trackeado, no una nota de junta. Las acciones sin dueño no existen.
- Aliméntalo de vuelta al Paso 1. Si el mismo Sev se repite, la matriz o el enrutamiento están mal — arregla el sistema, no la siguiente instancia.
Errores comunes
- Inflación de severidad. Todo se vuelve Sev 1, así que nada lo es. Guarda: la matriz es la única autoridad; un override requiere el nombre del manager de CS en el canal y una razón de una línea.
- Enrutar a una cola en vez de a una persona. Los tickets envejecen en inboxes compartidos. Guarda: cada Sev autoasigna un dueño nombrado al crearse; un Sev sin dueño más viejo que su SLA de respuesta hace page al manager.
- Silencio entre actualizaciones. Guarda: la cadencia de actualización la fuerza un bot recordatorio en el canal del incidente, no la memoria del dueño.
- Cerrar sin causa raíz. La misma caída se repite porque nadie arregló el sistema. Guarda: un Sev 1/2 no puede marcarse como “resuelto” hasta que exista un issue post-incidente enlazado con acciones correctivas y dueños.
- Sin factor de peso de cuenta. El triage puramente técnico subprioriza un bug pequeño en una ballena que está churneando. Guarda: la regla de subir el Sev por tier y health score corre automáticamente.
Relacionados
- NRR vs GRR — lo que las escalaciones repetidas te cuestan en retención
- Gainsight — health scores y contexto de cuenta para la regla de subir el Sev
- Pylon — tooling de soporte B2B que guarda severidad y contexto por cuenta
- Linear — el issue de tracking del lado de ingeniería