Agentes de IA por voz: qué probar antes de atender clientes

Elegir una conversación que se pueda comprobar

Para evaluar un agente de IA por voz, proponemos comprobar una conversación completa: entender la solicitud, permitir correcciones, consultar información y cerrar con un resultado verificable o una derivación clara. Esta guía utiliza documentación de proveedores para plantear pruebas empresariales. Las capacidades descritas pertenecen a servicios diferentes y necesitan una implementación; no representan una solución que funcione automáticamente al combinar sus nombres.

Imaginemos una empresa chilena de servicio técnico que quiere recibir solicitudes de visita. En este ejemplo hipotético, el cliente identifica un equipo, explica una falla y propone un horario. Antes del piloto, negocio y tecnología deberían acordar si el agente solo recoge antecedentes o puede confirmar una reserva. Esa diferencia determina qué evidencia necesita al terminar la conversación.

Una pausa también puede ser parte de la solicitud

La documentación de Deepgram sobre transcripción provisional y detección de pausas distingue el cierre de un segmento de audio del aviso de una pausa. Explica que una intervención larga puede contener varios segmentos finalizados y que deben acumularse para reconstruirla. Además, las transcripciones provisionales pueden cambiar. Es una distinción técnica que importa al diseñar cuándo responder.

En nuestra prueba de servicio técnico, el cliente podría decir el nombre del equipo, detenerse a buscar su código y continuar. Recomendamos verificar que la aplicación conserva lo dicho antes de la pausa y permite completar la información. También conviene probar correcciones espontáneas: que la persona cambie un número o aclare que se refiere a otro producto. El criterio de aceptación debe describir qué dato queda finalmente registrado.

Para el contexto chileno, proponemos incluir apellidos, comunas, siglas, correos deletreados y diferentes formas de pronunciar números. El conjunto de prueba debería representar a quienes usarán el canal. Estas son recomendaciones de validación; el soporte general de un idioma no demuestra por sí solo el desempeño en esas conversaciones.

Interrumpir debe detener lo que el cliente escucha

La guía de capacidades de Gemini Live API describe un servicio en versión preliminar y documenta detección de actividad de voz configurable. Cuando reconoce una interrupción, cancela la generación y avisa al cliente de software. La guía indica que la aplicación debe detener la reproducción y vaciar el audio pendiente. Detectar la interrupción y resolver su efecto audible requieren trabajo coordinado.

Proponemos una prueba sencilla: mientras el agente enumera horarios, la persona corrige el día solicitado. Hay que observar si la voz se detiene, si recoge la corrección y si continúa con el dato nuevo. También conviene probar ruido y una segunda voz de fondo. El equipo debe revisar qué eventos provocan interrupciones y cómo recupera la conversación cuando la detección no coincide con la intención del usuario.

Comprobar la diferencia entre entender y resolver

Nuestra recomendación es revisar por separado lo que el agente entendió, lo que consultó y lo que efectivamente ocurrió en el sistema de negocio. En el ejemplo de la visita técnica, reconocer correctamente un horario no confirma que exista disponibilidad. El resultado aceptable depende del alcance acordado: solicitud recibida, horario propuesto o reserva confirmada deben tener evidencias distintas.

Para datos que cambian una acción, proponemos una confirmación breve y específica antes de continuar. Si el usuario corrige el número del equipo, debería poder comprobarse que la consulta posterior usa el número corregido. Cuando falla la consulta de disponibilidad, la respuesta debe explicar que falta confirmación y ofrecer un siguiente paso real. Estos escenarios se pueden ensayar con datos ficticios antes de incorporar información de clientes.

También conviene probar el canal previsto: una conversación dentro de una aplicación y una llamada telefónica requieren recorridos de conexión y operación distintos. La demostración debe permitir observar el comportamiento en el entorno donde se utilizará.

Derivar a una persona con un destino definido

Twilio documenta en ConversationRelay un mensaje para terminar la sesión y devolver el control de la llamada, junto con datos que la aplicación puede recibir para continuar el flujo. Ese mecanismo permite preparar una derivación, pero el equipo debe implementar el destino y la continuidad de atención. La existencia del mensaje no acredita que haya una persona disponible para responder.

Recomendamos probar la petición de hablar con un ejecutivo tanto al comienzo como después de varios intentos. El receptor debería contar con el motivo, los datos necesarios y lo pendiente de resolver, según el alcance autorizado. Si no hay atención disponible, el agente necesita comunicar una alternativa cierta, como registrar una solicitud cuando ese flujo exista. La prueba termina al comprobar el resultado de la derivación.

Una pauta de aceptación para el piloto

Proponemos registrar por escenario la solicitud esperada, las pausas o correcciones introducidas, el dato comprendido, el resultado y el motivo de cualquier fallo. Medir la espera hasta una respuesta audible y contar repeticiones innecesarias ayuda a describir la experiencia. La resolución correcta debe evaluarse junto con esas medidas: contestar rápidamente aporta poco si la persona termina con una reserva que no existe.

Antes de ampliar el uso, conviene revisar los fallos con el responsable del servicio y acordar qué situaciones debe resolver el agente y cuáles requieren apoyo. Nuestra página de modelos conversacionales por voz describe los prototipos dentro de una interfaz y el alcance adicional que requiere la telefonía. La guía de autonomía y evaluación de agentes profundiza en cómo comprobar las acciones sobre sistemas empresariales.