Diagrama de escalado de soporte al cliente (árbol de decisión)

Cómo funciona

1. Nombra a los cuatro decisores

   Sustituye agente de primera línea, responsable de soporte, gestor de la cuenta y responsable de guardia por los roles que existen en tu organización. Los equipos pequeños suelen fusionar el gestor de la cuenta con el responsable de soporte; las organizaciones con cobertura fuera de horario suelen mantener separado al responsable de guardia porque ese rol cambia por turno. Cada carril tiene que ser una persona localizable y con autoridad para decidir, no el nombre de un departamento.

2. Deja escrito qué significa el alcance de primera línea

   «¿Dentro del alcance de primera línea?» es la comprobación que decide qué parte de tu volumen no escala nunca, así que merece una definición escrita. Delimítalo por capacidad y no por esfuerzo: un artículo publicado, un cambio de configuración documentado o una acción estándar sobre la cuenta están dentro del alcance; todo lo que exija código, acceso a datos de producción o una concesión contractual queda fuera por definición, por mucha voluntad que le ponga el agente.

3. Fija el disparador de riesgo de SLA antes del vencimiento

   Decide qué porcentaje del tiempo restante de respuesta o resolución dispara «¿Objetivo de SLA en riesgo?» y acordadlo por adelantado para que la herramienta lo lance sola. Todo el valor de la rama está en que salte mientras el objetivo todavía se puede cumplir. Un disparador puesto en el propio vencimiento solo te informa de que el compromiso ya se ha incumplido.

4. Define de antemano la lista de cuentas protegidas

   «¿Cuenta estratégica o protegida?» tiene que poder contestarse desde el CRM en segundos. Mantén una lista explícita y deja registrado qué hace que una cuenta esté protegida: figurar como cuenta estratégica, o tener compromisos de respuesta y resolución escritos en el contrato. Decidirlo caso por caso es justo lo que permite que reciba trato prioritario el cliente que más grita en lugar del más importante.

5. Acuerda los disparadores de exposición con el área legal

   «¿Exposición reputacional o legal?» es la rama que se impone a todas las demás comprobaciones, así que sus criterios deberían validarse fuera de soporte: datos personales expuestos, un regulador o un auditor implicado, un riesgo para la seguridad, una publicación pública o una consulta de prensa, o una penalización contractual en juego. Deja la lista lo bastante corta como para recordarla bajo presión y haz que cualquiera de los disparadores baste por sí solo.

6. Acuerda qué es un defecto confirmado y una solución alternativa aceptable

   Pon un listón de evidencia para «¿Defecto de producto confirmado?», por ejemplo reproducido en una versión soportada y con pasos que otro ingeniero pueda seguir, para que los reportes no reproducidos vayan a nivel 2 a diagnóstico y no a ingeniería. Después decide quién juzga si la solución alternativa es aceptable. Si ese juicio está solo en soporte, el desenlace «Registrado como defecto, sin escalar» acabará discutido por clientes que nunca lo aceptaron.

Preguntas frecuentes

¿En qué se diferencia esto de un diagrama del proceso de escalado de soporte?

Un diagrama de proceso es una secuencia: registrar el ticket, clasificarlo, trabajarlo, resolverlo y cerrarlo, con carriles que muestran quién ejecuta cada paso. Este diagrama es un árbol de decisión, así que su columna vertebral es una cadena de preguntas y no de tareas, y sus ramas terminan en cinco desenlaces distintos con nombre en lugar de converger en un único cierre. Usa el mapa de proceso para ver el ciclo de vida completo de un caso y usa este árbol en el punto exacto de ese ciclo en el que alguien tiene que elegir una vía. Son complementarios: el diagrama de gestión de incidencias enseña dónde está la decisión de escalado, y este enseña cómo tomarla.

¿Cuándo hay que escalar un caso de soporte?

Cuando una de un número reducido de comprobaciones escritas da un sí, no cuando el caso lleva simplemente mucho tiempo abierto. Cinco de las ocho comprobaciones de este diagrama deciden si se escala o no: el caso está fuera de la capacidad de primera línea, ninguna solución documentada lo resuelve, el objetivo de SLA está en riesgo, la cuenta es estratégica o está protegida por contrato, o hay exposición reputacional o legal. Las tres restantes deciden adónde va. El tiempo transcurrido es un buen disparador para revisar un caso, pero uno malo para escalarlo por sí solo, porque mueve trabajo sin aportar ninguna capacidad que el caso necesitara.

¿Qué diferencia hay entre escalar a nivel 2 y escalar a un responsable?

Resuelven problemas distintos, e ITIL los separa como escalado funcional y jerárquico. El escalado funcional lleva el caso a gente con más especialización o más acceso a los sistemas, que es lo que representan aquí «Escalado a soporte de nivel 2» y «Escalado a ingeniería como defecto». El escalado jerárquico implica a alguien con más autoridad, para recolocar las expectativas del cliente, autorizar una excepción o comprometer recursos, que es lo que representan los desenlaces del gestor de la cuenta y del responsable de guardia. Un caso puede necesitar los dos. Subir por la línea de mando un caso que lo que necesita es un especialista gasta el tiempo de un responsable y no mueve el ticket.

¿Hay que escalar a ingeniería todos los defectos confirmados?

No, y tratar cada defecto como un escalado es justo la forma de que el escalado pierda su significado. Este diagrama se bifurca en «¿Existe solución alternativa?». Sin una solución alternativa aceptable el cliente está bloqueado, así que el caso termina en «Escalado a ingeniería como defecto» y lleva prioridad de servicio afectado. Con solución alternativa, el agente la entrega y el caso termina en «Registrado como defecto, sin escalar»: el fallo sigue llegando a ingeniería por la vía normal de entrada y priorización de defectos, simplemente no interrumpe a nadie. Ese segundo desenlace es un terminador de rechazo a propósito, porque decidir no escalar es un resultado legítimo de la evaluación y debe registrarse como tal.

¿Quién puede decir que no a un escalado?

Quien sea dueño de la comprobación que ha fallado, y por eso los carriles de este diagrama son derechos de decisión y no departamentos. El responsable de soporte puede rechazar un caso que no supera las comprobaciones de exposición, SLA y defecto, y devolverlo a primera línea. Es el gestor de la cuenta, y no soporte, quien decide si una cuenta está protegida. El responsable de guardia decide si una cuenta es crítica, y solo se le pregunta cuando la exposición ya está establecida, lo que reserva ese rol para situaciones de mando reales. Los escalados rechazados sin un motivo registrado son los que vuelven, así que anota contra el caso qué comprobación falló.