¿Te ayudamos a aplicar esta guía?Pregunta al equipo de DripTell
Mida la tasa de escalación como el porcentaje de casos únicos elegibles que necesitaron un nivel superior de autoridad, conocimiento o responsabilidad de riesgo. Cuente cada caso una vez, separe transferencias y consultas, y lea la tasa junto con la calidad. Un número más bajo no siempre es mejor. La escalación necesaria protege al cliente; la evitable revela una brecha corregible.
El panel de resumen de Customer Service de Microsoft define la tasa como el porcentaje de casos que han sido escalados. Parece sencillo. La dificultad real está en acordar qué significa una escalación en su operación.
Defina qué cuenta como escalación
Escriba primero la definición del evento. Una escalación debe significar que una decisión o tarea material pasó más allá de la autoridad o capacidad normal del primer nivel. El caso puede ir a un nivel superior de soporte, al dueño de una política, a un especialista técnico o a un responsable de riesgo.
No llame escalación a cada transferencia. Un cambio por idioma, turno, consulta o enrutamiento correcto puede mover trabajo sin elevar el nivel de decisión. Microsoft explica en sus métricas por segmentos que cada entrada, transferencia o salida de una cola crea un segmento separado. Por eso las transferencias entrantes y salientes se miden aparte de la escalación en el nivel del caso.
Si un caso pasa por tres colas, el informe de segmentos puede mostrar tres registros, pero el cálculo de escalación debe conservar un solo caso de cliente. Mantenga el identificador original de la necesidad entre canales y reasignaciones.
Fije el grupo y cuente cada caso una vez
Elija un grupo estable y documéntelo. Una cohorte de creación muestra qué parte de la nueva demanda necesitó escalación. Una cohorte de resolución muestra qué parte del trabajo terminado la utilizó. Ambos enfoques sirven, pero alternarlos rompe la tendencia.
- 1Defina el eventoIndique qué autoridad, experiencia o responsabilidad de riesgo superior cuenta como escalación.
- 2Fije la cohorteUse un grupo de casos creados o resueltos y una sola ventana de observación.
- 3Elimine duplicadosCuente cada caso una vez y mida aparte las escalaciones repetidas.
- 4Clasifique el motivoSepare ayuda necesaria de brechas de enrutamiento, conocimiento, autoridad y responsabilidad.
- 5Compruebe el resultadoLea escalación junto con resolución, reapertura, calidad y contacto repetido.
Para una cohorte de creación, establezca una ventana fija. Excluya spam, pruebas, duplicados y registros fuera de soporte. Mantenga cancelaciones y abandonos como resultados separados.
La fórmula es el número de casos únicos elegibles escalados al menos una vez dividido por todos los casos únicos elegibles de la misma cohorte, multiplicado por cien. Las escalaciones repetidas del mismo problema deben alimentar otra medida, no aumentar otra vez el numerador principal.
Si 52 de 400 casos elegibles llegaron al nivel superior, la tasa es 13 por ciento. Muestre las repeticiones aparte porque señalan rebotes o falta de responsable.
Separe escalaciones necesarias y evitables
La tasa solo es útil después de clasificar motivos. Revise casos reales y pregunte qué faltaba en primera línea.
| Qué ocurrió | Clasificación justa | Respuesta operativa |
|---|---|---|
| Se necesitó una habilidad especializada real | Experiencia necesaria | Conservar el contexto y vigilar la capacidad especializada |
| Una excepción de reembolso o política superó la autoridad inicial | Autoridad necesaria | Mantener una aprobación clara y limitada en tiempo |
| Un riesgo de seguridad o privacidad exigió un responsable | Control de riesgo necesario | Escalar pronto y conservar la evidencia |
| El caso entró en la cola equivocada | Enrutamiento evitable | Corregir reglas de entrada y probarlas con casos reales |
| La respuesta existía pero no se encontraba | Brecha de conocimiento evitable | Mejorar la búsqueda y probar el contenido durante el trabajo |
| El mismo caso se escaló varias veces sin decisión | Fallo de responsabilidad | Nombrar un dueño de resolución y una siguiente acción aceptada |
No convierta las escalaciones necesarias en fallos del agente. Si la primera línea no puede aprobar un reembolso, presionarla para reducir la cifra puede causar demora o una acción no autorizada. Una meta de cero escalaciones también puede ocultar cierres prematuros.
Lea la tasa junto con los resultados
Microsoft presenta la tasa de escalación al lado de casos entrantes y activos, tiempo medio de resolución, antigüedad, satisfacción y sentimiento de encuestas. El porcentaje necesita contexto.
Combine la tasa con la resolución en el primer contacto, el tiempo de resolución, reaperturas, calidad y contacto repetido. Si baja la escalación mientras suben las reaperturas, quizá el equipo esté evitando ayuda necesaria. Si la escalación y el tiempo aumentan después de un lanzamiento, la causa puede estar en el producto o la base de conocimiento.
Convierta el resultado en una reparación
Empiece por el mayor motivo evitable, no por la persona con la tasa más alta. Revise casos representativos y encuentre el control que falló. La reparación puede ser una regla de enrutamiento, autoridad más clara, mejor contenido, un turno de especialistas o una matriz de escalación más segura.
Asigne dueño y fecha al cambio. Compare después la misma definición de cohorte antes y después. Use hallazgos de calidad para distinguir un defecto del sistema de una necesidad de formación. Aplique análisis de causa raíz si distintos problemas apuntan al mismo fallo.
No persiga un benchmark genérico. El rango depende de complejidad, autoridad, riesgo y definición. Su línea base, motivos y resultados son más defendibles.
Mantenga unido el contexto del cliente
Una escalación debe añadir capacidad sin hacer que el cliente empiece de nuevo. El especialista necesita solicitud, acciones, evidencia, promesas, responsable y siguiente decisión. La primera persona debe saber si aún informa al cliente.
El espacio de soporte y el inbox de equipo de DripTell se organizan alrededor de historial compartido, asignación, notas y estado del ticket. Use el sistema que use, conserve un registro del problema durante la transferencia. Así la medición es más limpia y la experiencia menos frustrante.
Preguntas frecuentes
Cómo se calcula la tasa de escalación
Divida los casos únicos elegibles escalados al menos una vez por todos los casos únicos elegibles de la misma cohorte fija y multiplique por cien. Publique la definición, la ventana de observación y las exclusiones.
Cuenta cada transferencia como escalación
No. Cuente una transferencia solo cuando una decisión o tarea material pasa a un nivel superior de autoridad, conocimiento especializado o responsabilidad de riesgo. Mida aparte el enrutamiento normal, las consultas y los cambios de turno.
Qué tasa de escalación es buena
No existe una cifra universal. Compare periodos estables y grupos de casos parecidos, luego examine motivos y resultados. Una tasa menor con más reaperturas o decisiones inseguras no es una mejora.
Se debe penalizar a los agentes por escalar
No por la tasa bruta. Compruebe si la escalación fue necesaria, oportuna y bien documentada. Corrija primero las brechas de enrutamiento, conocimiento, autoridad, producto y capacidad.
DripTell Editorial
Guías prácticas revisadas por el equipo de producto y flujos de cliente de DripTell.
Consulta cómo DripTell verifica el producto, utiliza fuentes primarias y corrige errores.
Política editorial y de fuentes