Un usuario escribe con un problema. El agente que lo atiende no puede resolverlo y lo pasa al nivel dos. Ahí le piden información que ya estaba en la primera conversación y el usuario la repite. Dos días después el caso vuelve al nivel uno porque, revisado con calma, era simple. Nadie incumplió un tiempo de respuesta, ningún indicador se puso en rojo, y aun así la operación gastó tres veces el esfuerzo necesario y el usuario contó su problema dos veces.
El diseño del escalamiento es de las decisiones que menos se discuten al montar una operación tercerizada y de las que más determinan su costo real. Se suele resolver con una frase en el contrato —"casos complejos pasan a segundo nivel"— y esa frase no significa nada operativamente. Complejo para quién, con qué criterio, con qué información y con qué camino de vuelta.
Un nivel no es una jerarquía
El error más común es tratar los niveles como rangos: el nivel dos sabe más, gana más y decide sobre el nivel uno. Cuando se organiza así, escalar se vuelve un acto de rendición y el equipo lo evita hasta que el caso ya se dañó, o lo usa como vía de escape para no pensar.
Un nivel es otra cosa: un conjunto de casos que se resuelven con las mismas herramientas, los mismos accesos y el mismo tiempo promedio. El nivel uno atiende lo que se resuelve en una interacción con el conocimiento y los permisos que tiene a la mano. El nivel dos atiende lo que exige un permiso que el nivel uno no tiene, una herramienta a la que no accede, o una investigación que no cabe en el tiempo de una conversación.
Definido así, el criterio deja de ser subjetivo. La pregunta no es "¿esto es difícil?" sino "¿tengo el acceso, el dato y el tiempo para resolverlo?". Si la respuesta es sí, no se escala aunque incomode. Si es no, se escala de inmediato aunque parezca simple.
Si el criterio de escalamiento es la dificultad percibida, cada agente tendrá el suyo y la operación no será medible.
Cada salto tiene un precio
Un escalamiento no es gratis. Cuesta el tiempo del agente que documenta, el tiempo del especialista que se pone al día, el tiempo del usuario que espera y, casi siempre, una interacción adicional de seguimiento. Un caso que pasa por dos manos consume bastante más que el doble del esfuerzo de uno que se resuelve en la primera.
De ahí una consecuencia práctica: subir el porcentaje de casos que se resuelven en el primer contacto suele valer más que acelerar el segundo nivel. Y ese porcentaje casi nunca sube contratando gente más experimentada. Sube dando permisos. La mayoría de los escalamientos evitables ocurren porque el agente sabía exactamente qué hacer y no tenía el botón para hacerlo.
Revisar la lista de accesos del nivel uno es, en general, el ejercicio de mayor retorno al inicio de una operación. Aparecen restricciones que se pusieron por prudencia hace años, sin límite de monto ni condición, y que hoy solo generan tránsito interno.
Funcional y jerárquico no son lo mismo
Conviene separar dos cosas que suelen mezclarse bajo la misma palabra.
El escalamiento funcional mueve el caso hacia quien tiene la capacidad técnica de resolverlo: del nivel uno al dos, del dos a un especialista, del especialista al equipo del cliente. Es horizontal en autoridad y vertical en conocimiento.
El escalamiento jerárquico mueve el caso hacia quien tiene autoridad para decidir por fuera de la norma: autorizar una excepción, aprobar una compensación, asumir un riesgo. No requiere más conocimiento técnico, requiere mandato.
Mezclarlos produce dos síntomas típicos. Uno, supervisores atendiendo casos técnicos que no saben resolver, porque el equipo escala "hacia arriba" por costumbre. Dos, casos técnicos estancados días esperando una decisión que nadie tiene facultad de tomar. Las dos rutas deben existir, estar escritas por separado y tener disparadores distintos.
Qué viaja con el caso
La calidad de un escalamiento se decide en lo que se envía, no en la rapidez con que se envía. Un paquete mínimo evita casi todo el reproceso:
- Qué pidió el usuario, en sus términos, no interpretado.
- Qué se intentó y qué resultado dio cada intento.
- Los datos de identificación ya verificados, para que nadie los vuelva a pedir.
- La razón del escalamiento según el criterio acordado: falta de acceso, falta de herramienta, necesidad de investigación o necesidad de autorización.
- Qué se le prometió al usuario y cuándo.
Ese último punto es el que más se omite y el que más daño hace. El segundo nivel trabaja sin saber qué expectativa quedó abierta, y el usuario recibe una respuesta que no corresponde a lo que le dijeron. Es material natural de la base de conocimiento: el formato del paquete de escalamiento debería estar definido antes del día uno, no negociarse caso por caso.
El camino de vuelta
Casi todos los diseños describen cómo sube un caso. Muy pocos describen qué pasa después.
Cuando el nivel dos resuelve, la solución se queda en el nivel dos. La misma consulta vuelve a llegar la semana siguiente, escala otra vez y se resuelve otra vez de cero. El escalamiento sin retorno de conocimiento convierte al segundo nivel en una fábrica de repeticiones.
El retorno se diseña con dos reglas simples. Primera: quien resuelve un caso escalado deja el procedimiento por escrito si el caso puede repetirse, aunque sea en tres líneas. Segunda: alguien revisa periódicamente los motivos de escalamiento más frecuentes y decide si pasan a nivel uno, con el permiso o el artículo que haga falta. Sin ese segundo paso, la distribución entre niveles se congela el día del arranque y nunca mejora.
También existe el caso que se devuelve porque no debió escalar. Devolverlo está bien, siempre que la devolución explique qué faltó y no se registre como un error individual. Si devolver se vuelve un reproche, el equipo deja de escalar cuando debe.
Qué medir
Cuatro indicadores describen bien un modelo de niveles, y ninguno funciona solo:
- Tasa de escalamiento, por motivo. El agregado no dice nada; el desglose por motivo es lo que permite actuar.
- Tasa de devolución: casos escalados que el segundo nivel regresa. Si es alta, el criterio no está claro o falta entrenamiento.
- Reescalamiento: casos que suben más de una vez. Suele indicar que los niveles están mal delimitados.
- Tiempo de espera en cola de segundo nivel, medido aparte del tiempo total. Es donde se acumula la demora invisible para el usuario.
Estos cuatro deberían estar en el reporte desde el principio, junto con el resto de lo que se acuerda al inicio en el primer mes de operación. Añadirlos después obliga a discutir tendencias sin historia.
Cómo lo trabaja smartBPO
Definimos los niveles por acceso, herramienta y tiempo, no por antigüedad, y dejamos el criterio escrito en una frase que un agente nuevo pueda aplicar sin consultar. Separamos la ruta funcional de la jerárquica, con disparadores propios para cada una. Estandarizamos el paquete que viaja con el caso antes del arranque y revisamos los motivos de escalamiento con el cliente en la reunión periódica, para mover a nivel uno lo que solo necesitaba un permiso. Medimos devolución y reescalamiento, no solo la tasa agregada. El objetivo no es tener un segundo nivel rápido: es que la mayoría de los casos no necesite llegar hasta allá.