El escalamiento de casos dentro de las empresas es clave para brindar un buen servicio al cliente, pues no todos los casos requieren el mismo proceso.
Muchas veces, el equipo no sabe qué puede resolver, cuándo pedir ayuda y quién tiene autoridad para intervenir, lo que provoca que todo se escale y llegue hasta gerentes sin ser necesario.
Para evitarlo, te decimos cómo crear un buen proceso de escalamiento de casos, a través de una ruta basada en tres puntos clave: impacto, complejidad y urgencia.
Escalar no quiere decir que un ejecutivo no pudo resolver un caso, sino que la resolución requiere autoridad o conocimiento que no se tiene en el nivel actual.
Por eso, antes de diseñar niveles, hay que establecer qué situaciones justifican mover un caso hacia arriba.
Regla básica: si el caso puede resolverse con una política o procedimiento disponible en el nivel actual, no tiene que escalarse.
Tener cientos de niveles no significa que el proceso sea mucho mejor. Una estructura con tres niveles bien delimitados y operativos es más que suficiente.
El equipo que recibe el caso lo atiende.
Generalmente, para lograrlo, tiene que poder resolver: preguntas frecuentes, solicitudes estándar, incidencias conocidas y cambios permitidos por política.
Siempre se debe tener el objetivo de poder resolver sin escalar, contando con las herramientas y autoridad necesarias.
Si el caso requiere mayor conocimiento, se escala con un especialista.
Aquí entran situaciones como problemas técnicos complejos, excepciones operativas, análisis de cuenta o errores recurrentes.
Lo importante es resolver la complejidad sin que tenga que intervenir el gerente.
En este nivel están los casos que requieren autoridad, intervención transversal o gestión de alto impacto.
Se aplica cuando hay clientes estratégicos en riesgo, incidentes que afectan a diferentes clientes, riesgos legales o de reputación, o situaciones cercanas a incumplimiento de un SLA crítico.
Se tienen que poder tomar decisiones, desbloquear recursos y contener el impacto de las quejas para que no lleguen a instancias mayores.
Un proceso de escalamiento de casos puede fallar cuando se sabe a quién enviar el caso, pero no hay quien decida qué sigue.
Todos los niveles tienen que tener a un responsable para generar una estructura sencilla:
Responsable del caso → Especialista → Líder/Decisor
Pero ojo: escalar no significa abandonar la responsabilidad.
Por ejemplo, si alguien del Nivel 1 escala un caso, tiene que seguir a cargo de informar al cliente hasta que se cierre el ticket, a menos que el proceso implique un cambio de ownership.
Asimismo, hay que definir un tiempo máximo de intervención. No solo hay que saber cuándo escalar.
En vez de establecer «si no puedes resolverlo, escálalo», establece «si no existe una solución después de un tiempo definido —30 minutos, por ejemplo— o si se cumple determinado criterio, escala al Nivel 2».
Esto permite diferenciar entre tiempo de respuesta y tiempo de resolución.
Un caso puede necesitar varias horas para resolverse, pero el cliente no debería quedar varias horas sin saber qué está ocurriendo.
Puedes usar la siguiente matriz como referencia para el escalamiento de casos:
| Criterio | Ejemplo | Nivel inicial | Escalar a | Tiempo máximo para decidir |
|---|---|---|---|---|
| Baja complejidad o impacto | Duda o solicitud general | 1 | No escalar | Según SLA |
| Complejidad técnica | Error que requiere diagnóstico especializado | 1 | 2 | 30 min |
| Excepción operativa | Solicitud fuera de política | 1 | 2 | 30 min |
| Riesgo de incumplir SLA | Caso sin solución cerca del límite | 1 | 2 | Inmediato |
| Impacto en varios usuarios | Incidente que afecta una operación | 2 | 3 | 15 min |
| Cuenta estratégica en riesgo | Problema que amenaza renovación | 2 | 3 | 15 min |
| Riesgo financiero relevante | Solicitud de compensación extraordinaria | 2 | 3 | 30 min |
| Riesgo legal o reputacional | Posible conflicto contractual o exposición pública | 1-2 | 3 | Inmediato |
| Incidente crítico | Servicio esencial detenido | 1-2 | 3 | Inmediato |
Los tiempos son solo referencias: tienen que ajustarse al SLA, la criticidad y la capacidad de tu equipo y de la operación.
La mejor manera de reducir el escalamiento de casos no es pedir que se escale menos, sino establecer un proceso que todos conozcan y, sobre todo, hacer que resolver en primera línea sea más fácil que escalar.
Un agente debe saber qué puede hacer, pero también qué no necesita consultar.
Establece, por ejemplo, si puede ofrecer ciertas compensaciones sin autorización, modificar configuraciones o resolver ciertas incidencias.
La autonomía debe documentarse para que se pueda aplicar.
En vez de saturar al equipo pidiendo que solicite autorización ante cada situación fuera de lo habitual, define reglas de excepción.
Por ejemplo: «puede decidir X siempre que se cumplan A y B».
Esto hace que no se pierda tiempo preguntando y las decisiones repetitivas se vuelven reglas operativas.
Lo importante nunca es saber el número de escalamientos, sino más bien conocer motivo, nivel de origen, nivel de destino, tiempo de escalación y de resolución, responsable y resultado.
A partir de esto, será más fácil detectar patrones y actuar para que se reduzca el número de incidencias.
Si, por ejemplo, el 30 % de escalaciones de Nivel 1 ocurren por una misma pregunta, no tienes un problema de desempeño, sino de documentación y capacitación.
Un indicador muy importante en este aspecto es la tasa de escalamiento innecesario.
Escalamiento innecesario = (casos escalados que podían resolverse en el nivel de origen ÷ total de casos escalados) × 100.
No necesitas perseguir una tasa de escalamiento cercana a cero. El objetivo es que cada escalamiento tenga una razón operativa clara.
Cada escalamiento tiene que ser capaz de alimentar alguno de los activos del equipo: una FAQ, un artículo de conocimiento, una nueva regla, una automatización o un cambio de proceso.
De esta manera, el escalamiento deja de ser solamente una actividad operativa y se convierte en información para mejorar el sistema a largo plazo.
Un buen proceso no debe estar conformado por una cadena rígida de Nivel 1 → Nivel 2 → Nivel 3.
Lo importante es tener claros aspectos como:
Cuando cada escalamiento tiene criterios, responsable y tiempo límite, el equipo deja de trabajar con la lógica de «pregúntale al jefe» y empieza a operar con la lógica de «esta situación corresponde a este nivel».
El resultado, además de menos carga para los líderes, es una mayor autonomía, tiempos de resolución más previsibles y una experiencia de cliente más consistente.
El escalamiento de casos no tiene que ser la salida fácil cuando los colaboradores no saben qué hacer.
Tiene que crearse como un mecanismo para que cada problema se asigne a la persona correspondiente, con la información adecuada, en el momento correcto.
Si todo se escala, el problema no está en el equipo: está en el diseño del proceso. Y si nada se escala, probablemente también exista un problema.
Por eso, es importante contar con procesos claros, que se pongan a prueba y se mejoren continuamente, para brindar un buen servicio al cliente y lograr crecimiento a largo plazo.
¿Quieres mejorar tu seguimiento y proceso de atención? En Media Source by Cebra te podemos ayudar mediante software de servicio al cliente conectado a HubSpot. Contáctanos para saber más.
Es el proceso mediante el cual un caso pasa a un nivel con mayor autoridad, conocimiento o capacidad de resolución porque supera los límites del responsable inicial.
Cuando existe un riesgo relevante, se requiere una decisión fuera de la autoridad del nivel actual, hace falta conocimiento especializado o está en riesgo un SLA crítico.
En muchos equipos, tres niveles son suficientes: resolución directa, especialista y decisión o crisis. La cantidad debe depender de la complejidad real de la operación.
Documentando políticas, aumentando la autonomía del primer nivel, creando reglas de excepción y analizando las causas de las escalaciones recurrentes.
El escalamiento debe transferir la decisión o intervención necesaria, pero no necesariamente la responsabilidad sobre la experiencia del cliente. El proceso debe definir explícitamente quién mantiene el ownership y la comunicación.