Buena demo, malas llamadas reales: ¿qué capa ha fallado?

La respuesta corta

Un agente de voz que supera la demo y falla en las llamadas reales no ha empeorado de repente. Las llamadas reales atraviesan las mismas siete capas que la demo, desde el audio de la línea y el reconocimiento de voz hasta las herramientas, el traspaso y la medición. La demo nunca puso a prueba la capa que ahora falla en condiciones reales.

Por eso, no empiece por reescribir el prompt. Tome las llamadas fallidas reales, haga pasar cada una por las capas en orden y asígnela a la primera capa que falló. La capa con más llamadas es la que está fallando, y es lo primero que hay que corregir. Haga esa única corrección, vuelva a pasar las mismas llamadas y compare.

Este artículo está pensado para una línea que ya está en producción. Si todavía no la ha lanzado, empiece por nuestra guía para probar un agente de IA de voz antes de pasar a producción.

Por qué la demo salió bien

Una demo es una prueba amable. Quien llama conoce el guion, habla con claridad en una sala silenciosa y espera a que el agente termine. Los datos de prueba están limpios: el pedido existe y hay hueco en la agenda.

En las llamadas reales, la gente interrumpe. Llama desde el coche o desde un almacén, usa expresiones locales y abreviaturas, y pregunta por temas relacionados que el flujo no contempla. A veces al teléfono ni siquiera está la persona que el flujo esperaba: contesta el contable en lugar del dueño, coge el teléfono un familiar o la llamada acaba en otro departamento.

Cada una de estas situaciones pone a prueba una capa distinta. Una buena demo muestra que las capas aguantan cuando todo llega limpio, no cuál cede primero con el tráfico real.

Las siete capas que atraviesa una llamada

Todas las llamadas atraviesan las mismas capas en el mismo orden. Un fallo en una de las primeras capas produce síntomas en las siguientes, así que los síntomas por sí solos suelen señalar el sitio equivocado.

• Audio de la línea y telefonía: la llamada se conecta, el audio va y viene sin retrasos ni eco, y la llamada termina de forma limpia.
• Reconocimiento de voz: lo que dice quien llama se convierte en texto.
• Conocimiento: la información que el agente puede usar, como políticas, datos de producto y respuestas a preguntas frecuentes.
• Decisión: la lógica de la conversación, es decir, qué decir o preguntar a continuación, cuándo confirmar, cuándo pasar la llamada a una persona y cómo terminar.
• Herramientas y acciones en sistemas: consultas y escrituras en el CRM, en el sistema de reservas o en el de incidencias.
• Traspaso a una persona: la transferencia o la llamada de vuelta, y el contexto que recibe su compañero.
• Medición: el resultado registrado coincide con lo que pasó de verdad.

Hay además un filtro de negocio, que no es una capa de IA. Algunas llamadas fallan por el lado del negocio: no hay stock, no hay hueco libre o los datos de su propio sistema están desactualizados. El agente hizo su trabajo y el negocio no pudo cumplir. Cuente esas llamadas aparte y envíelas al responsable de ese proceso.

Empiece por las llamadas reales, no por la hoja de pruebas

Tome todas las llamadas reales de un periodo reciente, no los escenarios de su hoja de pruebas. Después, descarte las llamadas de prueba internas: el mismo número y las mismas frases de guion, repetidas con pocos minutos de diferencia. Quien hace pruebas no habla como un cliente de verdad.

A continuación, revise las etiquetas de resultado en una muestra. Si los buzones de voz cuentan como conversaciones o las reservas completadas cuentan como fallos, el propio conjunto de llamadas fallidas está mal. La medición es la última capa, pero la primera que hay que verificar.

Por último, escuche el audio. La transcripción muestra lo que entendió el reconocimiento de voz, y solo la grabación muestra lo que dijo de verdad quien llamaba.

Tabla de diagnóstico: del síntoma a la capa

Aplique la tabla a una llamada fallida cada vez y busque la evidencia antes de asignar la capa.

Cuente cada llamada fallida una sola vez, en su primer fallo

Así leemos las llamadas fallidas en DRING. Cada llamada fallida pasa por las capas en orden y recibe una sola etiqueta: la primera capa que falló. Una frase mal oída que lleva a una respuesta equivocada y después a una reserva fallida es un fallo de reconocimiento, no tres problemas.

Con un único valor por llamada, los recuentos suman el total de llamadas fallidas, y el recuento más alto muestra dónde una sola corrección puede recuperar más llamadas.

La alternativa habitual es etiquetar cada síntoma allí donde aparece. Contadas así, las 200 llamadas fallidas del ejemplo que sigue recibieron 355 etiquetas. La decisión acumuló más etiquetas que ninguna otra capa, 104, porque una frase mal oída suele hacer que la respuesta siguiente también salga mal. Sin embargo, la decisión fue el primer fallo solo en 40 llamadas. Las etiquetas de síntoma se solapan, su total no coincide con el número de llamadas fallidas y hacen que todas las capas parezcan urgentes. Muéstrelas aparte si le resultan útiles, pero ordene las correcciones por primeros fallos.

Las cifras de este apartado son un ejemplo para este artículo, no datos de una implantación real.

En este ejemplo, el reconocimiento de voz es la primera capa en la que trabajar: es el primer fallo en 62 de las 200 llamadas. Las 22 llamadas del lado del negocio no son un defecto de la IA. Ningún cambio en el agente crea un hueco libre en la agenda ni corrige una lista de precios desactualizada en su propio sistema.

Reconocimiento de voz: la mayoría de las correcciones se hacen en la capa de decisión

El primer fallo muestra dónde se torció la llamada, no siempre dónde va la corrección. En una línea telefónica, muchos errores de reconocimiento no se pueden corregir en la propia capa de reconocimiento: el audio va comprimido y una carretilla elevadora puede sonar más fuerte que la voz. La conversación tiene que seguir siendo correcta aunque el texto esté mal, y ese trabajo se hace en la capa de decisión:

• No deje que el agente responda a una frase que no encaja. Cuando el texto reconocido no corresponde a la pregunta que el agente acaba de hacer, el agente no actúa sobre él ni abre un tema nuevo. Dice que no lo ha entendido y vuelve a preguntar.
• Mantenga una lista de confusiones conocidas. Las palabras que el reconocimiento entiende mal en las llamadas reales van a una lista, y el agente las confirma con una pregunta en lugar de adivinar.
• Use los datos del sistema. Cuando el pedido o el registro ya se conoce, el agente se lo lee a quien llama y pregunta: «¿Es este?».
• Añada al final una lista de palabras clave. Una lista de nombres y términos de producto es un ajuste de reconocimiento barato, pero va después de los tres pasos anteriores.

Un ejemplo escrito para este artículo, no una llamada real: un turno mal oído, gestionado de dos maneras.

La primera respuesta convierte un error de reconocimiento en un pedido anulado. La segunda se queda con la parte que encaja y vuelve a preguntar por el resto. Para profundizar en esta capa, lea cómo corrige la IA de voz lo que oye mal.

Herramientas y traspaso: fíese del log, no de la frase

Un agente que dice «Su cita está reservada» ha producido una frase, no una reserva. Revise el log de la herramienta en cada acción: ¿se envió la petición, qué respondió el sistema y llegó un ID de registro? El agente solo debe confirmar una acción tras recibir una respuesta correcta del sistema. Nuestra guía sobre el registro del resultado en el CRM explica qué debe quedar registrado tras cada llamada.

El traspaso también falla sin hacer ruido. La transferencia se hace, pero el resumen llega tarde o no llega. Escuche los primeros segundos después de cada transferencia. Si su compañero pregunta por qué llama el cliente, el traspaso ha fallado. Consulte cómo diseñar el traspaso a una persona para saber qué contexto debe incluir.

El final: cuente las despedidas

Muchos flujos terminan la llamada con un temporizador o en cuanto la tarea está hecha. En las llamadas reales, eso corta a la gente en mitad de una pregunta o de un «gracias». El agente no debe colgar antes de oír la despedida de quien llama.

En cada llamada que terminó el agente, lea la última frase de quien llamaba antes del cuelgue. ¿Había una despedida? El porcentaje de llamadas sin despedida es su tasa de cortes, y corresponde a la capa de decisión.

Corrija una capa cada vez

La tabla de primeros fallos marca el orden de trabajo:

1. Elija la capa de IA con el recuento más alto. El filtro de negocio va a su responsable.
2. Haga un solo cambio dirigido a esas llamadas. En los fallos de reconocimiento, ese cambio suele hacerse en la capa de decisión, como se ha explicado más arriba. Con dos cambios a la vez, no sabrá cuál ha ayudado.
3. Vuelva a pasar las mismas llamadas fallidas. Ahora son su batería de pruebas de regresión: las mismas frases de quien llama y, cuando sea posible, las mismas condiciones de audio.
4. Compare los recuentos de primeros fallos antes y después con el mismo tipo de tráfico: la misma campaña, el mismo tipo de lista o la misma franja horaria de llamadas entrantes. Con una lista más fácil, cualquier cambio parece bueno.

Cuente con que algunas llamadas se desplacen en lugar de desaparecer. Una llamada que ahora supera el reconocimiento puede fallar más adelante, en las herramientas. Eso es avanzar: la siguiente corrección ya está a la vista. Agent Factory, la forma en que DRING crea, prueba y mejora agentes, sigue la misma regla: un cambio cada vez, probado antes de publicarse.

Dónde encaja DRING

Si un flujo en producción no rinde como debería, pida una llamada para revisarlo. Tenga preparada una muestra de llamadas fallidas, con grabaciones si su política lo permite, y el resultado que debería haber alcanzado cada llamada. Nuestro equipo puede revisarlas con usted como se describe en este artículo y ver dónde falló primero cada una.

El alcance de los cambios que afectan a sus propios sistemas se define por separado. Las acciones que un agente puede hacer en un CRM dependen de la edición del CRM, los permisos y el acceso a la API. En DRING se pueden definir campos de análisis adicionales, que se devuelven a través de la API, el CRM, el panel y los informes. La primera capa que falló puede ser uno de ellos.

Cada agente que crea DRING pasa por entre 1.000 y 10.000 conversaciones simuladas, creadas para su empresa, antes de la primera llamada real. Aun así, las llamadas reales muestran lo que la simulación no detectó, así que la mejora tras el lanzamiento parte de quienes llaman de verdad.