Diagrama de flujo del escalado de soporte: de nivel 1 a nivel 2

Cómo funciona

1. Renombra los carriles con tus roles reales

   Sustituye Cliente, Soporte nivel 1, Nivel 2 / especialista, Responsable de soporte e Ingeniería por las funciones que existen en tu organización. Los equipos pequeños suelen fusionar el nivel 2 con ingeniería; los equipos con gestores de cuenta nombrados a menudo dividen el carril del responsable de soporte en un responsable de guardia y un gestor de cuenta. Mantén el carril Cliente aunque solo tenga dos nodos, porque son los puntos en los que el flujo lo controla el cliente y no tú.

2. Define qué puede hacer la primera línea

   «¿Resuelto en nivel 1?» necesita un alcance y un tiempo máximo asociados: a qué sistemas puede acceder un agente, qué acciones puede ejecutar y cuánto dura un intento de primera línea antes de que el caso avance. Sin las dos cosas, el volumen de escalados cambia según quién esté de turno. Deja escrito de forma explícita que escalar dentro de ese tiempo es el resultado correcto y no un fracaso, o los agentes retendrán casos para proteger sus números.

3. Fija el contenido del registro de traspaso

   Decide qué debe contener «Registrar las notas de traspaso» y conviértelo en una plantilla dentro de tu herramienta de soporte: cuenta y entorno afectados, pasos para reproducir, qué se ha probado y qué se ha descartado, el impacto en el cliente y qué se le ha contado ya. Un traspaso copiado de un hilo de chat es la causa más habitual de que un especialista repita la primera hora de trabajo.

4. Escribe disparadores objetivos para la rama crítica

   «¿Crítico o cuenta estratégica?» no debería depender de con cuántas mayúsculas escribió el cliente. Usa condiciones comprobables: un proceso crítico de negocio bloqueado, una cuenta estratégica nombrada, un objetivo de respuesta contractual en riesgo o un caso ya reabierto una vez. Indica a quién se avisa en cada disparador y deja claro que el aviso, por sí solo, no reordena la cola; si no, todos los casos acaban siendo críticos.

5. Decide qué pasa cuando ingeniería aún no puede corregirlo

   Una vez aceptado un defecto, este pasa al reloj de versiones de ingeniería, que es más lento que el de soporte. Acordad quién mantiene la relación con el cliente durante ese periodo, cada cuánto se envían actualizaciones aunque no haya novedades, y si os comprometéis a una versión objetivo en lugar de a una fecha. La rama «Todavía no» existe para que la solución temporal sea un acuerdo explícito con el cliente en vez de silencio.

6. Acordad la regla de reapertura y publicad una versión controlada

   Esta plantilla devuelve al paso de traspaso los casos cuya confirmación falla, de modo que un caso reabierto se vuelve a documentar y a evaluar en lugar de caer en una cola. Cámbialo si en tu equipo las reaperturas deben volver directamente al último responsable. Después recorre el diagrama con cada carril, corrige los pasos que la gente ejecuta de verdad y publícalo como versión vigente con una aprobación, para que quien lo lea más adelante sepa qué revisión estaba en vigor.

Preguntas frecuentes

¿Qué es un proceso de escalado de soporte al cliente?

Es el recorrido documentado que sigue un caso de soporte cuando la primera línea no puede resolverlo. En lugar del ciclo de vida completo del ticket, cubre la parte que empieza en el límite de la capacidad de primera línea: la decisión de escalar, el traspaso a un especialista, una reevaluación de la gravedad y del impacto en el SLA ahora que el caso va a durar más, la investigación en sí, y la confirmación y la revisión que lo cierran. El valor no está en los pasos por separado, que casi todos los equipos ya ejecutan, sino en acordar de quién es el caso en cada punto y qué hay que dejar por escrito antes de que cambie de manos.

¿Cuándo hay que escalar un caso de nivel 1 a nivel 2?

Usa condiciones que un agente pueda comprobar, no criterios personales. Las tres que cubren la mayoría de los casos son: al agente le faltan los accesos o las herramientas que exige el diagnóstico; el síntoma queda fuera del alcance documentado de primera línea; o el tiempo máximo de un intento de primera línea ha expirado sin solución. Una cuarta, deliberadamente separada, es que el caso requiera una decisión que solo puede tomar otra persona, como un abono o una concesión contractual. Lo que no debería ser un disparador por sí solo es que el cliente pida que se escale, porque eso convierte la asignación de nivel en una negociación: gestiona esa petición por la rama de aviso.

¿Qué diferencia hay entre escalado funcional y escalado jerárquico?

El escalado funcional mueve el caso en horizontal, hacia alguien con más conocimiento, como cuando nivel 1 lo pasa a un especialista. El escalado jerárquico lo mueve hacia arriba, hacia alguien con más autoridad o más visibilidad, como avisar al responsable de soporte y al gestor de la cuenta. Resuelven problemas distintos y los dos aparecen en este diagrama como ramas separadas: la rama de escalar de «¿Resuelto en nivel 1?» es funcional, y la rama crítica de «¿Crítico o cuenta estratégica?» es jerárquica. El fallo habitual es hacer uno y dar por hecho que cubre el otro, con un especialista trabajando en silencio un caso del que el gestor de la cuenta se entera por el cliente.

¿En qué se diferencia de la gestión de incidencias?

El escalado mueve el caso de un cliente hacia alguien mejor situado para resolverlo. La gestión de incidencias restablece un servicio para todos los afectados por un mismo fallo. El disparador, el reloj y la medida del éxito son distintos: un caso escalado se mide por si ese cliente queda resuelto y lo confirma; una incidencia, por la rapidez con la que vuelve el servicio. Cuando varios casos escalados resultan apuntar al mismo fallo, el proceso de incidencias toma el relevo, los casos se vinculan a él y se cierran cuando el servicio se restablece y cada cliente lo confirma. Mantener los dos separados es lo que evita que una mesa de soporte gestione una caída como cincuenta investigaciones en paralelo.

¿De quién es el caso una vez escalado y qué debe contener el traspaso?

La propiedad de la investigación pasa al especialista, pero la de la relación con el cliente suele quedarse con el agente inicial, y el diagrama lo refleja volviendo a Soporte nivel 1 para «Confirmar la resolución con el cliente». Deja ese reparto explícito, porque un caso en el que cada parte cree que la otra está informando al cliente es el origen más habitual del silencio. El registro de traspaso debe llevar la cuenta y el entorno afectados, los pasos para reproducir, qué se ha probado y qué se ha descartado, el impacto en el cliente y qué se le ha contado ya. Manténlo como un único registro y no como un hilo, para que un caso reabierto que vuelve a pasar por el mismo paso sume a un solo historial.