Lista para evaluar agentes de voz antes de escalar

Define el éxito como un resultado de negocio verificado. En un flujo de citas, comprueba que se registraron la hora, el servicio y los datos de quien llama correctos, y que la confirmación hablada coincide con ese registro. Una conversación fluida o una transcripción no vacía no bastan como prueba de que la tarea se completó.

Separa la conexión, la calidad de la conversación y la tarea completada. Un rechazo del operador es una falla distinta de un nombre mal entendido, y ambas son distintas de una API de citas que devuelve un error. Registra la categoría de la falla para que las correcciones apunten a la capa correcta.

Arma un conjunto de pruebas a partir de las tareas e idiomas que esperas atender. Usa evaluadores que den su consentimiento y datos sintéticos cuando sea posible. Mantén versionadas las instrucciones y los escenarios para poder repetir la misma evaluación después de cambiar un motor o una integración.

Los siguientes casos son una lista inicial. Son pruebas propuestas, no afirmaciones de que todos los motores las superan. Agrega el comportamiento de quien llama y las condiciones de falla que importan para tu aplicación.

• Una solicitud sencilla con un resultado esperado sin ambigüedad.
• Un nombre, número de teléfono u hora de cita corregido a mitad de la conversación.
• Una interrupción mientras habla el agente, seguida de una solicitud diferente.
• Ruido de fondo, silencio, un acento poco familiar y cada idioma de destino admitido.
• Una pregunta fuera de la base de conocimiento y una solicitud que el agente no tiene permitido atender.
• Un backend no disponible, un evento duplicado y una persona que cuelga antes de completar la tarea.
• Una solicitud para hablar con una persona, probada contra el escalamiento que tu aplicación implementa de verdad.

Registra el escenario, el motor y la versión de las instrucciones, el identificador de la llamada, el resultado de la conexión, el resultado de la tarea, la duración y el costo. Pide a un revisor que compruebe el registro de negocio subyacente en lugar de dejar que el mismo agente califique su propia respuesta.

Para la capacidad de respuesta, define el intervalo que mides, por ejemplo desde el final de lo que dice quien llama hasta el inicio de la voz audible del agente. Informa la distribución, el tamaño de la muestra y las condiciones de prueba. No conviertas una demo rápida en una promesa general de latencia.

• Tasa de tareas completadas = tareas completadas verificadas / conversaciones evaluadas para esa tarea.
• Tasa de conexión = llamadas conectadas / llamadas intentadas, informada por separado.
• Costo por tarea completada = todo el gasto del piloto / tareas completadas verificadas; indica que no está definido cuando no hay ninguna.
• Registra por separado los errores críticos para que un promedio no oculte una reserva equivocada o una respuesta inventada.

Lee el registro de la llamada para ver el estado, la transcripción y cost_micros. Cuando una llamada no se conectó, revisa failure_code y failure_reason antes de cambiar las instrucciones. Concilia los cargos con los eventos de uso. Revisa las entregas de webhooks cuando la llamada terminó pero tu aplicación no se actualizó.

Usa claves de idempotencia al iniciar llamadas para que el reintento de una solicitud no genere una segunda marcación. Prueba tu propio manejador de eventos con entregas duplicadas y verifica el resultado que guarda. La autenticación y la verificación de firmas de webhooks deben estar en la integración antes de que el piloto crezca.

Amplía cuando se cumplan los criterios de aceptación que definiste, los errores críticos tengan un responsable y el proceso operativo esté probado. Elige umbrales según el riesgo y el valor de tu caso de uso; no existe una tasa de tareas completadas universal que deje lista cualquier flujo de voz.

Aumenta el tráfico en incrementos controlados, revisa las llamadas fallidas y compara el gasto observado con el presupuesto. Mantén una forma de revertir los cambios de instrucciones y de modelo. Comparte los resultados medidos con su metodología y sus limitaciones si publicas un caso de estudio.

Este recurso lo publica Wixzel Voice. Los detalles del producto provienen de las referencias de abajo; las recomendaciones de evaluación son un método propuesto, no resultados de pruebas comparativas.

• Errores de llamada y códigos de falla
• Entrega y verificación de webhooks
• Reintentos seguros con idempotencia

¿Encontraste un error? Envía una corrección.