Flujos de escalado de voz con AI: la guía de ingeniería

Todas las demos de los proveedores muestran el camino feliz: el interlocutor pregunta, el agente responde, la llamada termina. Nadie hace una demo del momento en que el agente choca contra un muro y tiene que decir "déjeme buscar a alguien que pueda ayudarle". Ese momento —el escalado— es donde la mayoría de los despliegues de voz se rompen en silencio. También es la parte sobre la que nadie escribe con honestidad, porque la mecánica es fea y los modos de fallo son vergonzosos.

Esta es una guía de constructor a constructor sobre los flujos de escalado de voz con AI: cómo el agente decide traspasar la llamada, cómo se mueve realmente la transferencia por SIP, cómo se pasa el contexto completo al humano y las formas no documentadas en que todo se desmorona en producción. Sin adornos de proveedor: solo la ingeniería.

Por qué el escalado es la parte más difícil de un agente de voz

Responder una pregunta acotada es un problema resuelto. Fundamentas el modelo, restringes las intenciones y lo lanzas. El escalado es difícil porque es un problema de sistemas distribuidos disfrazado de conversación.

En el traspaso estás haciendo simultáneamente: una decisión en tiempo real bajo incertidumbre (¿debo transferir?), la ejecución de un cambio de estado de telefonía (unir dos tramos, o cerrar uno y marcar otro) y la serialización del estado conversacional a través de una frontera hacia un sistema —la pantalla del CRM del humano— que nunca se diseñó para recibirlo. Si te equivocas en cualquiera de los tres, el interlocutor repite todo ante un humano confundido, o la llamada cae en el silencio.

Lo que está en juego es asimétrico. Una mala respuesta molesta. Un escalado mal ejecutado pierde al cliente y quema un minuto de un agente y enseña al interlocutor a machacar el "0" la próxima vez. En un contact center que hace 10.000 llamadas al día, incluso con una tasa de escalado del 12%, eso son 1.200 traspasos en los que se notan las costuras. Esta es la razón principal por la que los equipos que quieren automatizar las llamadas de atención al cliente se atascan en el límite del escalado.

Detectar cuándo traspasar: confianza, intención, sentimiento

La decisión de transferir es la fusión de tres señales. Usar una sola te da o bien un bot que transfiere todo (inútil) o uno que atrapa a los interlocutores en un bucle (peor).

Señales de confianza

La señal más barata es la propia incertidumbre del modelo. Fuentes prácticas:

Umbral mínimo de puntuación de recuperación. Si la similitud del top-k de tu RAG cae por debajo de un umbral, el agente no tiene una respuesta fundamentada. Transfiere en lugar de alucinar. Consulta nuestro manual sobre cómo detener las alucinaciones de la AI de voz para entender por qué rechazar y escalar es mejor que una respuesta segura pero equivocada.
Falta de coincidencia repetida. Dos turnos consecutivos en los que la clasificación de intención devuelve baja confianza son un fuerte disparador de escalado. Uno es ruido; dos son un patrón.
Fallo explícito de herramienta. Si el agente llama a una API —consulta de pedido, comprobación de saldo— y devuelve un 500 o viene vacía, eso es un traspaso determinista, no una cuestión de criterio.

Señales de intención

Algunas intenciones nunca deberían ser gestionadas por un bot, sin importar la confianza: "quiero cancelar", "esto es por una muerte en la familia", "los voy a demandar". Mantén una lista explícita de intenciones de escalado y corta el circuito al haber coincidencia. Es más barato y más seguro que confiar en que el modelo elija bien.

Señales de sentimiento

La frustración creciente es la señal a la que los proveedores dan menos peso. Hazle seguimiento a lo largo de los turnos, no turno a turno:

Tasa de interrupciones en aumento (barge-in en cada indicación)
Respuestas más cortas y más secas
Léxico explícito de enfado o palabrotas
Que el interlocutor diga literalmente "agente", "humano", "representante"

Un interlocutor que dice "representante" debería estar siendo transferido antes de que termine de decir la palabra. Bloquear eso es la forma más rápida de conseguir una reseña de una estrella.

Regla práctica con la que trabajamos: transferir si escalation_intent OR (confidence < floor for 2 turns) OR sentiment_slope < negative_threshold. Un OR booleano, no una puntuación ponderada: un promedio ponderado permite que una confianza alta enmascare un enfado real.

Transferencia asistida vs. transferencia ciega: mecánica sobre SIP

Aquí es donde la transferencia de llamadas con AI deja de ser conceptual. La distinción entre transferencia asistida y transferencia ciega es una diferencia real de estado en la telefonía.

Transferencia ciega (cold transfer). El agente emite un REFER al SBC/operador. El tramo original se libera; el interlocutor se reencamina al destino sin ningún contexto. Barata, una sola transacción SIP, y deja al interlocutor en una cola como un desconocido. Úsala solo cuando realmente no haya nada que pasar.

Transferencia asistida (warm transfer). El agente mantiene al interlocutor en el tramo A, marca al humano en el tramo B, espera a que el tramo B conteste, opcionalmente le susurra un resumen al humano y luego une A y B en una sola ruta de medios. El humano llega ya informado.

Dos formas de implementar la transferencia asistida:

SIP REFER con Replaces. Cumple con los estándares, pero cedes el control a la operadora/SBC y pierdes la capacidad de insertar un susurro o mantener el contexto en tu propio servidor de medios.
Conferencia/bridge en tu propio servidor de medios. El agente lleva ambas patas a un bridge que él controla (Asterisk Bridge, un SFU de WebRTC, etc.). Más infraestructura, pero eres dueño del susurro, de la música en espera y —lo más importante— puedes mantener la pata del AI escuchando unos segundos después del traspaso para detectar una conexión caída. Nuestro análisis a fondo del traspaso de WebRTC a SIP cubre la ruta de bridging de baja latencia.

El compromiso es control frente a simplicidad. La transferencia en frío es un REFER y listo. La transferencia asistida te cuesta una pata en espera, una segunda marcación y orquestación del bridge, pero es el único camino que preserva el contexto, así que es el que vale la pena diseñar.

Pasar el contexto al agente humano

Un bridge asistido sin contexto no es más que una transferencia en frío más lenta. Todo el sentido está en que el humano conteste sabiendo. Hay tres cargas útiles que mover:

La transcripción. Completa, turno por turno, con marcas de tiempo y el motivo de la transferencia señalado. No solo un resumen: los humanos quieren revisar las palabras exactas cuando quien llama discute lo que dijo.
La intención y las entidades extraídas. Número de pedido, ID de cuenta, la petición concreta. Estructuradas, para que caigan en campos del CRM y no en un muro de texto.
Estado del CRM / de la sesión. Lo que el agente ya hizo: autenticar a quien llama, recuperar el pedido, intentar un reembolso que falló. Evita que el humano rehaga el trabajo que el bot ya completó.

Mecanismos de entrega, del más rápido al más completo:

Susurro SIP: un resumen por TTS de 3 segundos reproducido solo para el humano antes del bridge. No requiere ninguna integración de pantalla; funciona con cualquier softphone.
Screen pop mediante API del CRM: escribe el contexto en el ticket o la ficha de contacto usando el ID de la llamada como clave, para que la pantalla del humano se actualice justo cuando entra la llamada. Este es el estándar de excelencia y el más difícil de lograr bien. Nuestra guía de traspaso de contexto en transferencias asistidas recorre el patrón de screen pop en el CRM de principio a fin.
Cabeceras SIP: mete una URL de contexto o un ID corto en una cabecera X- personalizada del INVITE para que el sistema receptor pueda obtener el estado completo. Cuidado con el borrado de cabeceras por parte de las operadoras.

El fallo que hay que evitar: que el humano tenga que preguntar «¿y de qué se trata esto?» después de que el bot prometiera «le paso con alguien que puede ayudarle». Esa única pregunta destruye por completo la ilusión de un traspaso inteligente.

Modos de fallo en la escalación: llamadas caídas, contexto perdido, bucles

Lo que los posts de los proveedores se saltan.

La carrera del bridge. El agente libera la pata A un instante antes de que la pata B conteste del todo. Quien llama oye silencio, luego aire muerto, luego nada. Solución: nunca liberes A hasta confirmar que el medio de B está fluyendo; un 200 OK con SDP no basta, espera al RTP real. Mira por qué los agentes de voz AI cortan llamadas en los traspasos SIP.
El contexto llega después que el humano. El screen pop se dispara de forma asíncrona y aterriza 4 segundos después de que el humano diga «hola». El humano ya le pidió a quien llama que repitiera. Solución: condiciona el bridge a la confirmación de escritura del pop, o recurre a un susurro SIP que sea síncrono con el bridge.
El bucle de escalación. El humano está ocupado, la llamada vuelve al bot, el bot ejecuta de nuevo la misma intención fallida e intenta escalar otra vez. Infinito. Solución: marca un contador escalation_attempts en la sesión; en el segundo intento, ve directo al buzón de voz o a una devolución de llamada, nunca de vuelta al mismo flujo del bot.
Borrado de cabeceras. Tu precioso ID de contexto en una cabecera X- acaba eliminado por un SBC intermedio. El contexto se pierde en silencio. Solución: nunca dependas de cabeceras personalizadas como único canal; ten siempre una consulta por API con el Call-ID estándar como clave.
Reversión a cola en frío. Has creado la transferencia asistida, pero cuando todos los humanos están ocupados el respaldo degrada en silencio a un vaciado en cola en frío. Detecta explícitamente el estado de «no hay agente disponible» y ofrece una devolución de llamada en lugar de soltar a quien llama en frío.

Diseñar la UX del traspaso para el agente humano

El humano también es un usuario, y su experiencia decide si la escalación se siente premium o rota.

Susurro antes del bridge, siempre. Tres segundos: «Disputa de reembolso, quien llama está verificado, el bot ya intentó un reembolso y falló». El humano entra orientado.
Pantalla antes que voz. El pop de contexto debería renderizarse antes de que la primera palabra de quien llama llegue al humano. Diseña el pop para una lectura rápida de 2 segundos: motivo arriba, entidades después, transcripción plegable.
Motivo de la transferencia de un vistazo. En negrita, arriba de la ficha. No enterrado en una transcripción que el humano tiene 2 segundos para leer.
Deja que el humano la devuelva de forma limpia. Si la escalación fue equivocada, el humano necesita un «devolver al bot con una nota» de un solo clic, no un corte en frío que reinicia el bucle.

La UX de la escalación es un producto de dos caras: quien llama y el agente. Los equipos que construyen soluciones serias de call center automatizado diseñan ambos lados de forma deliberada.

Cómo gestiona Finn la escalación y la transferencia asistida

Finn trata la escalación como una ruta de primera clase, no como un caso de error. La capa de decisión combina la confianza, una lista explícita de intenciones de escalación y la pendiente del sentimiento a lo largo de los turnos —con un OR booleano, para que la frustración real nunca quede diluida en un promedio—. Al activarse, Finn ejecuta una transferencia asistida con bridge en su propia capa de medios: pone en espera a quien llama, marca al humano, reproduce un susurro SIP síncrono, escribe la transcripción completa, las entidades extraídas y el estado de la sesión en tu CRM usando el Call-ID como clave, y solo hace el bridge cuando se confirma que el RTP del humano está fluyendo. Los intentos de escalación se cuentan, de modo que un humano ocupado nunca rebota a quien llama de vuelta al mismo bucle fallido. El resultado es un traspaso en el que el humano ya sabe, y quien llama nunca tiene que repetirse.

Preguntas frecuentes

¿Qué es un flujo de escalado de voz con AI? La ruta de extremo a extremo que sigue un agente de voz para transferir una llamada en curso a una persona: detectar la necesidad (confianza, intención, sentimiento), ejecutar la transferencia telefónica (warm o cold mediante SIP) y pasar el contexto conversacional y del CRM al agente humano.

¿Cuál es la diferencia entre una transferencia warm y una cold? La transferencia cold (a ciegas) libera a la persona que llama y la redirige sin contexto: un solo SIP REFER, y quien llama llega como un desconocido. La transferencia warm (asistida) mantiene en espera a quien llama, marca a la persona que atenderá, la pone al tanto y luego une ambas partes de la llamada, de modo que el humano llega conociendo ya la situación.

¿Cómo decide un voicebot cuándo escalar a un humano? Combinando tres señales: la confianza del modelo o de la recuperación cae por debajo de un mínimo, una intención explícita de alto riesgo (cancelación, temas legales, fallecimiento, o que la persona pida hablar con un "humano") y un sentimiento negativo que aumenta a lo largo de los turnos. La práctica recomendada es un OR booleano, de modo que cualquier señal fuerte por sí sola active el traspaso.

¿Por qué se cortan las llamadas durante las transferencias con AI? Normalmente por una condición de carrera en el puente: el agente libera la pata de la llamada de quien llama antes de que el audio del humano esté fluyendo realmente. La solución es esperar a que haya RTP confirmado, no solo un 200 OK, antes de cerrar la pata original.

¿Listo para lanzar un escalado que no pierde llamadas?

Finn ejecuta la ruta completa de transferencia warm — detección, puente SIP, apertura sincrónica del contexto del CRM, protección contra bucles — desde el primer momento. Reserva una demo y recorreremos tu flujo de escalado en vivo, con modos de fallo incluidos.