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

En resumen

• Una puerta de primera línea antes de plantear cualquier escalado: «¿Dentro del alcance de primera línea?» y «¿Lo resuelve una solución documentada?» tienen que dar las dos un sí para llegar al desenlace «Resuelto en primera línea». Cualquiera de los dos noes envía el caso a «Revisión de escalado por el responsable»
• La exposición se comprueba la primera, no la última. Un sí en «¿Exposición reputacional o legal?» va directo a «¿Afecta a una cuenta crítica?» en el carril del responsable de guardia, cuyo sí termina en «El responsable de guardia toma el mando» y cuyo no termina en «El gestor de la cuenta asume el caso»
• «¿Objetivo de SLA en riesgo?» separa En riesgo de Dentro del objetivo: En riesgo desvía por la comprobación de cuenta antes de cualquier enrutamiento técnico, y Dentro del objetivo pasa directamente a la pregunta sobre el defecto

La tabla de origen: Diagrama de escalado de soporte al cliente (árbol de decisión)

Escriba un paso por fila en Excel con identificador único, descripción, siguiente paso y responsable. Esta página es un árbol de decisión, no un mapa de proceso. Un mapa de proceso responde a qué pasa después y quién lo hace, desde el ticket registrado hasta el cierre. Un árbol de decisión responde a una pregunta más estrecha y mucho más discutida que vive dentro de él: dado el caso que tienes delante, ¿se queda en primera línea y, si no, quién lo asume? Para el flujo de extremo a extremo, con registro, priorización, tratamiento de incidencias graves y cierre, usa el diagrama del proceso de gestión de incidencias. Para la insatisfacción con el servicio y no para un fallo en él, usa el diagrama del proceso de quejas de clientes. Usa este diagrama cuando la discusión sea sobre el enrutamiento en sí.

Asigne la descripción a Box text, el destino a Line to, el nombre de la rama a Line text y el responsable a Vertical lane. El escalado se tuerce en dos direcciones opuestas y las dos salen caras. Si se escala con demasiada facilidad, el nivel 2 se convierte en una segunda cola de casos que primera línea podría haber cerrado, lo que sube el coste por ticket y alarga la espera de los casos que sí necesitan un especialista. Si se escala demasiado poco, una cuenta protegida por contrato se entera de un incumplimiento por boca de sus propios usuarios. Ninguno de los dos fallos se arregla con más supervisión. Se arregla con comprobaciones escritas, ocho en este caso, todas contestables a partir del ticket y de la ficha de la cuenta y no a partir de cómo suena la conversación. Compruebe todas las ramas y responsabilidades del diagrama frente a la hoja. Consulte también /es/guides/como-estructurar-datos-de-excel-para-un-diagrama-de-flujo.

Cómo funciona

1. Nombra a los cuatro decisores

   Escriba un paso por fila en Excel con identificador único, descripción, siguiente paso y responsable. 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

   Asigne la descripción a Box text, el destino a Line to, el nombre de la rama a Line text y el responsable a Vertical lane. «¿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

   Recorra la ruta normal, los rechazos y los bucles en el diagrama antes de compartirlo. 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.

Errores que debes evitar

• Conexiones ausentes

  Una lista de tareas solo se convierte en mapa de proceso cuando cada paso tiene destino y cada decisión tiene resultados identificados. En tu equipo el escalado lo decide el carácter de cada persona, y dos agentes tratan el mismo caso de forma distinta

Preguntas frecuentes

¿Puedo usar mi archivo Excel?

Sí. Adapte las columnas al editor de hojas de QueryChart y revise los destinos si cambia el orden de las filas. 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.