Política de escalamiento en atención al cliente: plantilla

Un cliente escribe que le cobraron, pero el pedido nunca aparece. La agente que recibió el mensaje no tiene acceso a los registros de pago, así que le pregunta a un compañero en el chat del equipo y espera. Dos horas después el cliente vuelve a escribir y un segundo agente empieza de cero. Nadie hizo nada mal. Simplemente no había una regla escrita sobre qué pasa cuando un problema es más grande que la persona que lo tiene.

Una política de escalamiento en atención al cliente es esa regla. Este artículo repasa sus partes y termina con una plantilla que puedes copiar y adaptar.

Qué es una política de escalamiento en atención al cliente

Es un documento corto que responde cuatro cosas: cuándo un caso sube de nivel, a quién, cómo se traspasa y de cuánto tiempo dispone cada persona antes de que el caso vuelva a moverse. No es lo mismo que un SLA. El SLA es la promesa que haces al cliente; la política de escalamiento es tu ruta interna para cumplirla cuando la primera persona no puede.

«Escalar» se entiende en dos direcciones. El escalamiento funcional pasa el caso a alguien con otras habilidades o accesos (facturación, ingeniería). El escalamiento jerárquico suma a alguien con más autoridad (la persona al frente del equipo, un gerente). Tu política debería nombrar ambos.

Niveles: pocos

Tres niveles bastan para la mayoría de los equipos. Con más, los casos rebotan de una persona a otra.

¿Equipo pequeño? El nivel 2 puede ser una persona concreta cada semana. No hace falta que sea un departamento aparte.

Disparadores: cuándo sube un caso

Escribe los disparadores como condiciones que alguien pueda comprobar, no como impresiones. Cuatro tipos cubren la mayoría de las situaciones:

• Habilidad o acceso: el agente no puede resolverlo con lo que tiene, por ejemplo consultar un pago o cambiar código.
• Tiempo: el caso se acerca a su plazo o ya lo superó.
• Impacto: varios clientes reportan lo mismo, o un cliente no puede pagar ni iniciar sesión.
• Señal del cliente: pide hablar con un responsable, menciona una reclamación ante un organismo o ha escrito tres veces sin avances.

En Hodhod el disparador de tiempo se puede automatizar. El escalado automático de tickets reacciona ante «vencido», «inactivo durante un tiempo» o «a la espera del cliente», y puede subir la prioridad, reasignar a un equipo, añadir un seguidor, poner una etiqueta o añadir una nota. Antes de activar una regla ves una vista previa de los tickets que habría detectado.

Quién es responsable de qué

El fallo más común es el caso «escalado» que no es de nadie. Fija dos reglas:

1. Un solo responsable a la vez. Cuando el caso pasa al nivel 2, la persona de nivel 2 es dueña de la relación con el cliente hasta que se resuelva o se traspase de nuevo.
2. El primer agente sigue informado, pero deja de ser responsable. Sigue el ticket y ve el resultado, pero ya no lo persigue.

Decide también quién habla con el cliente. Una opción habitual es que el nivel 1 envíe un solo mensaje corto diciendo que el caso pasó a un especialista y cuándo habrá novedades, y que desde ahí escriba el nuevo responsable. En Hodhod asignas el ticket a un equipo o persona, añades al primer agente como seguidor y mantienes la conversación interna en notas privadas para que el cliente no la vea.

La nota de traspaso

Casi todo el tiempo perdido está en el traspaso. Si la siguiente persona tiene que volver a preguntarle al cliente, el escalamiento hizo todo más lento. Exige esta nota en cada traspaso:

Nota de traspaso
Cliente / número de ticket:
Problema en una frase:
Qué espera el cliente:
Qué he revisado o probado:
Qué te pido:
Prioridad y motivo:
Plazo (con el cliente y interno):
Qué se le ha dicho al cliente:

La línea más importante es «qué se le ha dicho al cliente». Evita que la siguiente persona contradiga una promesa que no sabía que existía.

Plazos

Da a cada nivel un límite para actuar sobre el caso, no para resolverlo. Un ejemplo para un caso urgente, en horas laborales:

Haz la suma: un caso urgente llega al nivel 3 como máximo a las 3,5 horas, y el cliente oye a una persona al menos en el minuto 15 y en el 90. Son cifras de partida. Empieza por lo que tu equipo puede hacer hoy, como con un SLA, y endurécelas después. Para prioridades más bajas, amplía los límites. Cómo asignar las prioridades se explica en triaje y prioridad de tickets.

Escalamientos a ingeniería

Cuando la causa es un defecto, no envíes diez tickets sueltos a desarrollo. Vincula los tickets a una sola incidencia para que ingeniería vea un problema con el número de clientes afectados. En Hodhod esto se hace con el seguimiento de incidencias, y una incidencia puede enviarse a Jira. Cuando se corrige, puedes escribir de una vez a las conversaciones vinculadas.

Plantilla para copiar

POLÍTICA DE ESCALAMIENTO (equipo, versión, fecha)

Niveles
  N1: [nombres/equipo]  - atiende: [lista]
  N2: [nombres/equipo]  - atiende: [lista]
  N3: [nombres/equipo]  - atiende: [lista]

Escalar cuando (basta con uno)
  - Hace falta un acceso o habilidad que el nivel actual no tiene
  - Al ticket le quedan [X] para su plazo o ya lo superó
  - [N] o más clientes reportan el mismo problema
  - El cliente no puede pagar ni iniciar sesión
  - El cliente pide un responsable o menciona una queja formal

Responsabilidad
  - Un solo responsable a la vez; el responsable habla con el cliente
  - El responsable anterior sigue como seguidor y no lo persigue
  - La conversación interna, solo en notas privadas

Nota de traspaso (obligatoria)
  Problema / expectativa / revisado / petición / prioridad /
  plazo / qué se le dijo al cliente

Plazos (horas laborales)
  Respuesta N1: [  ]   Traspaso N1: [  ]
  Asunción N2: [  ]   Resolución o traspaso N2: [  ]
  Estado N3: [  ]

Fuera de horario
  Quién atiende los casos urgentes y cómo se le localiza: [  ]

Revisión
  Mensual: leer cada caso escalado que superó un límite.
  Trimestral: cambiar niveles, disparadores o plazos si se repite la misma causa.

Revisar la política

Una política que nadie revisa acaba siendo decoración. Una vez al mes, toma los casos escalados que superaron un plazo y pregunta qué tienen en común: un turno, un tema, un permiso que faltaba, una nota de traspaso con campos vacíos. Mira también el problema contrario. Si el nivel 1 escala más de la mitad de lo que recibe, lo más probable es que falte formación o respuestas predefinidas, no que falle la política. Mide el volumen de escalamientos con tus KPI de atención al cliente en lugar de juzgar a ojo.

La revisión de calidad de Hodhod también ayuda: quien puntúa una muestra de conversaciones puede incluir «escaló a tiempo» como criterio.

Para probar reglas de escalamiento y traspasos en tu propio equipo, solicita una demo gratuita. Si quieres tickets con prioridades, plazos y escalado automático, descubre el sistema de tickets.

Preguntas frecuentes