Cuándo escalar a una persona y cómo resolver ambigüedades

El agente de soporte tiene que resolver la mayoría de los casos en el primer contacto, pero no todos. Si escala de más, no sirve; si escala de menos, toma decisiones que no le corresponden. La clave está en escalar por criterios, no por impresiones.

Los disparadores que sí sirven

La guía nombra tres disparadores de escalamiento (escalation triggers):

1. El cliente pide una persona. Si lo pide de forma explícita, se escala ya, sin investigar antes ni intentar resolver, aunque el caso esté dentro de la autoridad del agente.
2. La política tiene un hueco o pide una excepción (policy gap). Si el cliente pide igualar el precio de un competidor y la política solo habla de ajustes de precio en el sitio propio, la política no dice nada sobre ese pedido. El agente no inventa una regla: escala.
3. El agente no puede avanzar. Después de intentarlo, no hay progreso posible con sus herramientas.

Lo que no es disparador: que el caso sea complejo. Un caso complejo que la política cubre se resuelve.

Enojo no es lo mismo que pedir una persona

Un cliente furioso porque le llegó un paquete roto, con un caso que la política cubre claramente, no necesita un humano: necesita que le resuelvan. El agente reconoce la frustración, pide disculpas y ofrece el reemplazo. Si el cliente insiste en que quiere hablar con alguien, ahí sí se escala.

Situación	Qué hace el agente
“Quiero hablar con un supervisor”	Escala ya
Cliente enojado, caso cubierto por la política	Reconoce, ofrece resolver; escala solo si reitera
Pedido que la política no contempla	Escala
Reembolso de $250 con autoridad hasta $100	Resuelve lo que puede y escala el resto con un resumen
Un mensaje con una devolución y una pregunta sobre un retiro de producto del mercado	Resuelve la devolución, escala solo la otra parte

Por qué no sirven el sentimiento ni la confianza

El escalamiento por sentimiento (sentiment-based escalation) mide el tono, no la complejidad: escala clientes enojados con casos simples y deja pasar clientes amables con pedidos fuera de política. La confianza que el modelo informa sobre sí mismo tampoco: está mal calibrada y el agente se equivoca con total seguridad. Si un enrutamiento por confianza deja pasar errores, reemplazalo por criterios explícitos de escalamiento y medí las escalaciones contra resultados etiquetados.

Esos criterios van en el system prompt con ejemplos de cuándo escalar y cuándo resolver solo, incluidos los casos de frontera.

Varias coincidencias

get_customer devuelve dos cuentas con el mismo nombre. El agente no elige la “más probable” (la más reciente, la que tiene más pedidos): pide un identificador más, como el número de pedido o el email, antes de tocar cualquier cuenta. Lo mismo si el cliente dice “cancelá mi pedido” y tiene tres abiertos: los lista y pregunta cuál. Actuar sobre una suposición puede reembolsarle o cancelarle algo a la persona equivocada.

Estado desconocido

Si process_refund dio timeout dos veces y no sabés si el reembolso se hizo, no reintentes a ciegas (podés pagar dos veces) ni confirmes (afirmarías algo que no sabés). Avisale al cliente que el estado no se sabe y escalá para que alguien lo verifique.

Cuando se escala, el traspaso lleva un resumen estructurado (hechos, lo que ya se hizo, la pregunta abierta); “cliente disconforme, escalo” no le sirve a nadie.

Las trampas típicas

• Investigar o intentar resolver cuando el cliente ya pidió una persona.
• Escalar por enojo, o escalar todo lo complejo aunque esté cubierto.
• Escalar según la confianza del modelo.
• Elegir una cuenta o un pedido por heurística.

En el examen

Leé qué dijo el cliente exactamente. “Quiero una persona” escala ya; “esto es un desastre” no. Después mirá la política: si cubre el caso, se resuelve; si calla, se escala. Y si hay más de una coincidencia, la respuesta pide otro dato.