¿De dónde proviene el tiempo de espera al llamar a un servicio de atención al cliente con inteligencia artificial?
Después de que la llamada pasa por la línea telefónica y la ruta SIP/PBX, y el audio se procesa, el sistema debe determinar si el usuario ha terminado de hablar. Luego, el modelo interpreta la información y activa las herramientas empresariales. Finalmente, la respuesta se convierte en audio y se envía de vuelta al teléfono. Si la consulta de CRM o la creación de un ticket requieren tiempo de espera, también se introduce una latencia perceptible. Solo se mide el primer token del modelo, lo que ignora la ruta completa que realmente experimenta el llamante.
Análisis de la latencia de extremo a extremo en el servicio de atención al cliente con inteligencia artificial por voz.| Fase | Medición de inicio y fin | Riesgos comunes |
|---|
| Transmisión telefónica | Acceso y salida de la plataforma de audio por llamada de voz | Rutas de telecomunicaciones, codificación/decodificación, latencia de la red y pérdida de paquetes. |
| Identificación de contornos | El usuario debe dejar de hablar hasta que el sistema confirme que la operación ha finalizado. | Esperar demasiado o interrumpir demasiado pronto. |
| Respuesta de ejemplo | Enviar datos válidos para generar contenido reproducible. | Contexto excesivamente largo, selección del modelo y razonamiento complejo. |
| Llamada a herramienta | Enviar una solicitud API para obtener los resultados disponibles. | Gestión de tiempos de espera, reintentos y colas en sistemas empresariales. |
| Reproducción de audio | El texto o el audio comienzan a reproducirse en el dispositivo telefónico. | Buffer de síntesis, espera de la primera carga y cancelación de la reproducción. |
VAD se centra en determinar si hay "sonido", mientras que la detección de bordes se centra en determinar si "la conversación ha terminado".
El VAD (Voice Activity Detection) generalmente determina el inicio y el final de un habla basándose en el volumen y el tiempo de silencio; el VAD semántico va un paso más allá y estima si el significado aún no ha sido expresado. Esperar más tiempo puede reducir el riesgo de cortar la conversación, pero también aumenta el tiempo de pausa; una respuesta demasiado rápida puede cortar frases como "mhm... creo que debería cambiarlo" en dos partes. Los parámetros no pueden utilizarse de forma uniforme para todos los casos; el tiempo de espera requerido para nombres, direcciones completas, códigos y descripciones abiertas es diferente.
"Barge-in" se refiere al control de interrupciones, y no implica necesariamente el final de una ronda de conversación.
"Barge-in" permite que la persona que llama interrumpa la conversación mientras la IA está hablando, deteniendo la respuesta original. Esto es útil para corregir información, omitir contenido conocido o acortar menús. Es importante distinguir entre "Barge-in" y la capacidad del sistema para determinar que el usuario ha terminado de hablar. En general, las interrupciones deben ser permitidas; sin embargo, la grabación de mensajes, la solicitud de información o la verificación de campos importantes deben ser evaluadas individualmente según los procesos y requisitos legales de cada empresa. Desactivar "Barge-in" por completo puede hacer que la conversación sea menos fluida, mientras que activarlo por completo podría impedir que se reproduzca el contenido necesario.
No se limite a informar sobre la latencia promedio; también debe considerar la latencia p50, p95 y la tasa de errores.
El promedio puede verse distorsionado por un pequeño número de respuestas muy lentas o un gran número de respuestas muy rápidas. El valor p50 se utiliza para medir la experiencia general de comunicación, mientras que el valor p95 se utiliza para identificar los casos más extremos, aunque aún comunes. Además, se registran los tiempos de respuesta desde que el usuario deja de hablar hasta que se recibe la primera respuesta, el tiempo que tarda la herramienta en completarse, los errores de truncamiento, los tiempos de espera y la falta de activación de interrupciones. Cada conjunto de respuestas también debe incluir información sobre la tarea, la red, el idioma y si se ha llamado a la API de la empresa. De lo contrario, la información se mezclará y será difícil identificar la causa del problema.
Es necesario registrar tanto los retrasos como los cambios de turno.| Áreas de observación | Definición de eventos | Para qué se utiliza |
|---|
| Retraso en la primera respuesta. | Verificar que el ciclo de interacción haya finalizado hasta que el usuario reciba una respuesta. | Distinción entre etapas, modelos y tiempos de espera. |
| Esperando herramientas | La API ha devuelto los resultados, que ahora están disponibles. | Identificar los cuellos de botella en los sistemas empresariales o en sistemas de terceros. |
| Error de truncamiento | El usuario comenzó a responder antes de que terminara de hablar. | Ajustar la estrategia de VAD, rangos y campos. |
| Error de espera | El usuario ha terminado de hablar, pero el sistema sigue sin responder. | Verificación de finalización, tiempo de espera y estado de las herramientas. |
| La intervención ha tenido éxito. | Después de que el usuario haga una pregunta, la respuesta anterior se detiene y se guarda la nueva entrada. | Verificar la coherencia entre la acción de cancelar la reproducción y el contexto. |
Para la prueba de línea telefónica, es necesario incluir ruido, eco, acento y campos largos.
El micrófono de la página web, cuando se prueba en una oficina tranquila, no puede representar el sonido de teléfonos móviles, coches, auriculares manos libres, dispositivos Bluetooth o teléfonos fijos. La prueba debe cubrir al menos: ruido de fondo, eco, interferencias, velocidad del habla (rápida o lenta), acentos comunes, números, códigos alfanuméricos y direcciones largas. En los campos importantes, el objetivo no es solo la precisión literal, sino si el sistema puede repetir la información, permitir que el usuario la corrija y detenerse si no hay certeza.
Cuando haya pasado mucho tiempo esperando una respuesta, evita llenar el silencio con respuestas falsas o poco útiles.
Las APIs de CRM, ERP o de asignación de tareas pueden tardar varios segundos, o incluso iniciar un proceso asíncrono. El sistema puede proporcionar actualizaciones breves para evitar la sensación de inactividad, pero no puede decir "completado" antes de que se obtengan los resultados. Cuando el tiempo de espera sea excesivo, se debe establecer un estado de "pendiente de confirmación", una tarea manual o una notificación posterior, y utilizar un identificador único para evitar la ejecución repetida. Si la optimización de la latencia compromete la precisión de los resultados, simplemente se revela el error más rápidamente.
"3 segundos" solo puede ser un objetivo de diseño, no un Acuerdo de Nivel de Servicio (SLA) que GoGoCha haya publicado.
Los casos públicos de GoGoCha demuestran la eficacia de la entrada telefónica y el flujo de trabajo de asignación inmediata, pero no hay información pública sobre la distribución de la latencia, el entorno de telecomunicaciones, ejemplos de llamadas o acuerdos de nivel de servicio (SLA). No se deben establecer objetivos de diseño de productos como niveles de servicio alcanzados sin una definición y medición precisas de los eventos y cantidades reales. Las empresas deben volver a implementar p50, p95 y ejemplos de fallos en sus sistemas PBX/SIP, API y bajo sus condiciones específicas.
