Cuándo debe escalar un agente de IA a una persona: cómo diseñar el traspaso

Dos historias reales de pilotos, con el mismo producto y resultados opuestos. En la primera, el agente atiende la queja de uno de los mayores clientes de la empresa e insiste en resolverla con la política estándar de devoluciones. Técnicamente no se equivoca; comercialmente, el daño tarda meses en repararse. En la segunda, el agente escala prácticamente todo lo que entra "por si acaso". A las tres semanas, el equipo gestiona el mismo volumen de siempre, pero ahora con una herramienta más de por medio, y el piloto se cancela por no aportar nada.

Ninguno de los dos agentes falló por falta de capacidad. Los dos fallaron por lo mismo: nadie había diseñado el límite entre lo que el agente resuelve y lo que pasa a una persona. Ese límite —cuándo escalar, con qué contexto, a quién y qué pasa después— es la decisión de diseño más importante de un agente operativo, por delante del tono, los guiones o las integraciones. Y es también la más descuidada, porque no se ve en una demo.

Este artículo explica cómo dibujarlo. Hablamos de agentes que ejecutan flujos operativos reales —llamadas, correos, seguimientos, con estados y registro—, como los que describimos en cómo los agentes de IA están transformando las operaciones B2B, no de chatbots que responden preguntas sueltas.

El escalado no es un fallo del agente: es parte del diseño

La intuición equivocada más extendida es tratar el escalado como una derrota: "si el agente escala, es que no funciona". De ahí salen agentes configurados para resolverlo todo, que es exactamente como se fabrica el primer error visible delante de un cliente que importa.

La lógica correcta es la contraria. Un agente operativo vale por dos cosas: por lo que resuelve solo y por la calidad con la que entrega lo que no le corresponde resolver. La segunda mitad es la que protege a la primera: el equipo confía en dejar volumen en manos del agente precisamente porque sabe que lo sensible le va a llegar a tiempo y con contexto. Sin esa confianza, alguien acaba revisándolo todo "por si acaso", y el ahorro desaparece.

Por eso el escalado se diseña antes de lanzar, con la misma seriedad que el flujo principal. En la práctica, forma parte de acotar el alcance —los estados, qué se resuelve solo, las condiciones de parada— que ya recomendamos definir al elegir el primer proceso que automatizar.

Los dos modos de fallar: escalar demasiado y demasiado poco

El límite mal puesto falla en dos direcciones, y conviene reconocer las dos porque se corrigen de forma distinta.

Escalar demasiado poco produce errores visibles: una queja tratada como consulta rutinaria, una condición especial concedida sin criterio comercial, un caso con implicación legal respondido con una plantilla. Cada uno de estos errores es caro por sí mismo, pero el coste real es otro: la credibilidad del proyecto. Un solo caso sensible mal resuelto en público pesa más que cien casos rutinarios bien despachados.

Escalar demasiado produce un fracaso silencioso: el agente funciona, no comete errores, y aun así no sirve. Si la mitad de los casos acaban en una persona, el equipo no ha recuperado horas; ha añadido un paso. Este modo de fallar es más traicionero porque no genera incidentes que investigar: simplemente, al final del piloto, las métricas de ahorro no aparecen, como se ve enseguida al poner en números cuánto ahorra un agente.

Los dos fallos tienen la misma raíz: un límite definido por sensaciones ("esto parece delicado") en lugar de por reglas explícitas. La solución no es un agente más listo, es un límite mejor dibujado.

Resolver, sugerir, escalar: el límite se dibuja en tres zonas

La herramienta práctica para dibujar el límite es clasificar cada tipo de caso del flujo en una de tres zonas.

Resolver. El agente actúa de principio a fin: responde la consulta de horario, confirma la cita, registra el motivo de la llamada, envía el recordatorio. Aquí van los casos con respuesta correcta definible y coste del error bajo. Es la zona que genera el ahorro.

Sugerir. El agente prepara el trabajo y una persona aprueba: redacta el borrador de respuesta a una reclamación, propone una clasificación dudosa, prepara la ficha del lead con su recomendación. Es la zona intermedia para casos donde el agente aporta el 80 % del esfuerzo pero la decisión final necesita criterio humano. En una bandeja compartida, por ejemplo, esta zona es la diferencia entre un piloto prudente y uno temerario.

Escalar. El agente transfiere el caso completo, con contexto, a la persona adecuada, y deja de actuar sobre él. Aquí van los casos sensibles por definición, estén bien o mal resueltos: la zona no existe porque el agente no sepa, sino porque no le corresponde.

El ejercicio de diseño consiste en recorrer los tipos de caso del proceso y asignar cada uno a una zona, por escrito. La regla de oro: lo que no está asignado explícitamente acaba en "resolver" por defecto, porque es lo que el agente hará si nadie le dice lo contrario. Los huecos del mapa son los futuros incidentes.

Las señales que deben disparar un traspaso

Con las zonas definidas, faltan los disparadores: las condiciones concretas que mueven un caso a "escalar" aunque en principio fuera rutinario. En la práctica se repiten ocho, casi con independencia del flujo:

• El cliente pide una persona. Se respeta siempre, a la primera. Insistir en resolver tras esa petición es la forma más rápida de quemar la confianza en el canal.
• Lenguaje hostil o carga emocional alta. Enfado, amenaza de baja, mención a reclamación formal. El objetivo del agente pasa de resolver a aterrizar bien el traspaso.
• Cuenta estratégica o importe alto. Una lista de cuentas y un umbral económico que se consultan antes de actuar, no después.
• Implicación legal o de cumplimiento. Menciones a reclamaciones, protección de datos, condiciones contractuales. Zona de persona, sin excepciones.
• Petición de condiciones especiales. Descuentos, aplazamientos, excepciones a la política. El agente puede capturar la petición; la decisión es comercial, como vimos en los recordatorios de pago.
• Datos insuficientes o contradictorios. Si la fuente de verdad no responde o se contradice, el agente no inventa: escala con lo que tiene.
• Confianza baja en la propia interpretación. Caso ambiguo que no encaja en ningún patrón conocido. Mejor un escalado de más que una respuesta inventada.
• Reintentos agotados. Si tras el número de intentos definido el caso no avanza (nadie confirma, nadie firma, nadie responde), pasa a una persona en lugar de insistir sin límite.

Cada flujo añade los suyos —urgencias en llamadas fuera de horario, señales de intención en cualificación de leads—, pero estos ocho cubren la mayoría de los casos sensibles desde el primer día.

Un buen traspaso es un expediente, no un aviso

Aquí se decide la mitad de la experiencia. Un escalado que solo dice "tienes un caso pendiente" obliga a la persona a reconstruir la historia y, peor, obliga al cliente a repetirla. Ese "ya se lo he contado al asistente" es el momento exacto en el que el cliente concluye que la automatización empeora el servicio.

Un traspaso bien diseñado entrega cinco cosas:

• El hilo completo: cada mensaje, llamada o intento, en orden, sin resúmenes que sustituyan al original.
• Un resumen operativo: qué pide el cliente, qué se ha hecho ya y —clave— por qué se escala, citando el disparador concreto.
• Los datos capturados: cliente, referencia, fechas, importes, documento pendiente. Todo lo que el agente ya validó, para que nadie lo vuelva a pedir.
• El estado del caso: en qué punto del flujo queda y qué acciones automáticas se han detenido.
• La urgencia: no es lo mismo una consulta que puede esperar a mañana que un cliente enfadado con un servicio parado.

La prueba de calidad es simple: la persona que recibe el caso debería poder actuar sin hacerle al cliente ni una sola pregunta que el agente ya hubiera hecho. Si no puede, el traspaso ha fallado, aunque el enrutado haya funcionado perfectamente.

A quién llega cada caso: enrutado y urgencia

"Escalar a una persona" es una simplificación: en una operación real hay varias personas posibles, y equivocarse de destino cuesta casi tanto como no escalar. Las quejas de cuentas estratégicas van al responsable de la cuenta; las peticiones de condiciones, a comercial; las urgencias técnicas fuera de horario, a la guardia; el resto, a la cola general del equipo con su prioridad.

El diseño mínimo es una tabla de dos columnas —tipo de caso, destino— más una regla de urgencia: qué casos pueden esperar al siguiente día laborable y cuáles avisan de inmediato por el canal que el equipo mire de verdad. Sin esa tabla, todos los escalados caen en la misma bandeja, los urgentes esperan detrás de los triviales y la ventaja de escalar a tiempo se pierde en la cola.

Conviene definir también el compromiso de respuesta interno: de nada sirve un traspaso impecable si el caso espera dos días a que alguien lo abra. El agente puede decirle al cliente "una persona del equipo te contactará hoy" solo si el enrutado y el compromiso interno lo hacen verdad.

Qué pasa después del traspaso

Tres decisiones cierran el diseño y suelen olvidarse.

El agente para. Desde el momento del traspaso, ninguna acción automática más sobre ese caso: ni recordatorios, ni reintentos, ni mensajes de cortesía. Nada erosiona más la confianza que un cliente que ya está hablando con una persona y sigue recibiendo mensajes del agente.

El cierre queda registrado. Cuando la persona resuelve, el caso se cierra con su resultado en el mismo registro donde el agente documentó su parte. Sin eso, las métricas del proceso se rompen justo en los casos más importantes.

Cada escalado enseña algo. La revisión periódica de los casos escalados es el mecanismo de mejora del límite: los que la persona resolvió en un minuto con una respuesta estándar son candidatos a pasar a "resolver" o "sugerir"; los casos que el agente resolvió solo y luego se reabrieron son candidatos a nuevos disparadores. El límite del primer día es una hipótesis; el de la semana ocho debería ser mejor.

Las métricas que dicen si el límite está bien puesto

Cuatro números bastan para saber si el diseño funciona, y conviene mirarlos juntos porque se compensan entre sí:

• Tasa de resolución sin intervención: porcentaje de casos que el agente cierra solo. Es la métrica del ahorro.
• Precisión del escalado: de los casos escalados, cuántos necesitaban de verdad una persona. Los "falsos positivos" —casos que la persona devuelve o despacha en un minuto— señalan un límite demasiado prudente.
• Fugas: casos que el agente resolvió solo y acabaron en reapertura, queja o corrección. Son los "falsos negativos", los más caros; deberían tender a cero en los tipos de caso sensibles.
• Tiempo hasta persona: cuánto tarda un caso escalado en estar atendido. Mide si el enrutado y los compromisos internos funcionan.

La trampa habitual es optimizar la primera a costa de la tercera: subir la resolución automática dejando pasar casos que no tocaba. Por eso se miran juntas. Un buen ajuste del límite sube la resolución sin intervención y mantiene las fugas a raya; si solo consigue una de las dos, el límite está mal puesto.

En las primeras semanas, una tasa de escalado alta no es mala señal: es un límite prudente mientras se calibra. La señal de alarma es que no evolucione: mismo porcentaje de escalados en la semana uno que en la ocho significa que nadie está revisando y ajustando.

Cómo encaja BeeAgent

En BeeAgent el escalado no es una función añadida: es parte del flujo desde el diseño. Cada agente se configura con sus tres zonas —qué resuelve solo, qué prepara como sugerencia, qué transfiere—, sus disparadores (petición de persona, cuentas señaladas, umbrales, señales de riesgo, reintentos agotados) y su enrutado por tipo de caso y urgencia. El traspaso viaja con el hilo completo, el resumen, los datos capturados y el motivo del escalado, y el caso queda parado para el agente hasta que una persona lo cierra.

Y como es una plataforma sin código, ajustar el límite —añadir un disparador, mover un tipo de caso de "resolver" a "sugerir", cambiar un destino— lo hace el equipo de operaciones en minutos, sin proyecto de desarrollo. Ese ciclo corto de ajuste es lo que permite que el límite mejore semana a semana, como explica la guía para configurar tu primer agente sin código. Es, de hecho, la diferencia de fondo entre un agente operativo y un bot de respuestas, que desarrollamos en bot de atención al cliente vs agente de IA.

Diseña el límite esta semana

No hace falta un proyecto para empezar: hace falta una tarde y a las personas que conocen el proceso.

Primero, lista los tipos de caso del flujo que quieres automatizar y asigna cada uno a una zona: resolver, sugerir o escalar. Todo lo que quede sin asignar, trátalo como hueco a cerrar, no como detalle menor. Segundo, escribe los disparadores partiendo de los ocho de este artículo y añadiendo los tuyos: tu lista de cuentas estratégicas, tus umbrales, tus urgencias. Tercero, dibuja la tabla de enrutado —tipo de caso, destino, urgencia— y acuerda el compromiso de respuesta interno con cada destino.

Con eso lanzado, reserva 30 minutos a la semana para las dos listas que afinan el límite: escalados que sobraban y resoluciones que se fugaron. Cuatro semanas de ese ciclo valen más que cualquier configuración inicial perfecta.

Conclusión

Un agente de IA operativo no se juzga solo por lo que resuelve, sino por cómo entrega lo que no le corresponde resolver. El límite entre las dos cosas —las zonas, los disparadores, el traspaso con contexto, el enrutado y las métricas que lo vigilan— es diseño, no azar: se define antes de lanzar y se afina cada semana con datos. Bien puesto, es lo que permite al equipo confiar volumen real al agente sin miedo a la sorpresa visible; mal puesto, es la razón por la que la mayoría de los pilotos que fracasan lo hacen.

Si estás diseñando ese límite para tu operación, en los casos de uso puedes ver cómo se concreta en flujos reales —de la atención al cliente a las llamadas salientes— o escríbenos y lo dibujamos juntos sobre tu proceso.