Probar un IVR significa llamar a tu sistema telefónico como lo haría un cliente y comprobar que cada llamada termina en el lugar correcto. La mayoría de los IVR rotos fallan en las uniones: un mensaje que cambió sin que cambiara la regla de enrutamiento, una transferencia a una cola que cerró a las 18:00, un modelo de voz que entiende “farmacia” como “fama de Lucía”. Estos fallos solo aparecen al hacer llamadas reales por la ruta telefónica real.
Esta guía cubre los tipos de prueba habituales para IVR de teclado y de voz, y después lo que cambia cuando quien contesta el teléfono es un agente de voz con IA. En resumen: un menú de teclado tiene un guion correcto por ruta, mientras que un agente de voz tiene muchas conversaciones aceptables y un único resultado correcto. Tus pruebas tienen que comprobar el resultado.
Tipos de pruebas de IVR
| Prueba | Qué responde | Cuándo ejecutarla |
|---|---|---|
| Funcional | ¿Esta ruta reproduce los mensajes correctos y termina en el destino correcto? | Al crear o cambiar una ruta |
| Regresión | ¿Siguen funcionando todas las rutas tras un cambio? | Antes de cada versión |
| Reconocimiento de voz | ¿El sistema entiende las palabras que usan realmente quienes llaman? | Al añadir una intención, un idioma o un nuevo grupo de llamantes |
| Carga | ¿Sigue funcionando con el volumen pico esperado? | Antes del lanzamiento y de los picos de temporada |
| Estrés | ¿Qué falla primero por encima del pico, y falla de forma segura? | Antes del lanzamiento y tras cambios de infraestructura |
| Resistencia | ¿Algo se degrada tras horas de tráfico normal? | Antes del lanzamiento |
| Experiencia | ¿Cuánto esperan quienes llaman y suena bien? | De forma continua, con llamadas de producción |
| Conmutación por error | ¿Qué pasa cuando un sistema interno, una cola o el operador no responde? | Antes del lanzamiento y luego cada trimestre |
Las pruebas funcionales y de regresión detectan la mayoría de los problemas. Las de carga, estrés y resistencia importan cuando el IVR está delante de un centro de contacto con picos reales, como un periodo de inscripción, una retirada de producto o el lunes después de una facturación.
Probar un menú de teclado o de voz
Un IVR tradicional es un árbol. Cada nodo tiene un mensaje y un conjunto fijo de entradas, así que cada ruta se puede escribir y comprobar.
Empieza exportando el flujo de llamadas y convirtiendo cada ruta en un caso de prueba. Una ruta es la secuencia de entradas más el resultado esperado: pulsa 2, luego 1, introduce un número de cuenta, y la llamada debe llegar a la cola de facturación con la cuenta asociada. Incluye las rutas que la gente toma por accidente, no solo las ideales:
- Ninguna entrada, hasta que se agote el tiempo
- Una tecla no válida y después una válida
- Pulsar
0o decir “agente” en cada nivel - Llamar fuera del horario de atención
- Un número de cuenta que no existe
- Introducir dígitos antes de que termine el mensaje (quien conoce el menú lo hace)
En los menús de voz, las entradas de prueba son grabaciones. Usa distintos hablantes, una línea telefónica en lugar de un micrófono de estudio y ruido de fondo, como un coche o una cocina. Las palabras deben ser las que dicen los clientes en tus registros de llamadas, no las etiquetas del menú: la gente pregunta por “mi factura” mucho más a menudo que por “servicios de cuenta”.
Comprueba los datos además del audio. Una prueba pasa cuando la llamada llega a la cola de facturación y la pantalla del agente muestra la cuenta correcta. Si el IVR recogió el número pero la transferencia lo perdió, la persona tiene que repetirlo, y eso es un fallo aunque todos los mensajes se hayan reproducido bien.
Probar un IVR conversacional o un agente de voz con IA
Cuando un agente de voz con IA contesta el teléfono, comparar guiones deja de funcionar. El agente puede decir “Claro, se la cambio” en una llamada y “De acuerdo, puedo mover esa cita” en la siguiente. Las dos están bien. Una prueba que compara el texto exacto falla en cada ejecución y no te dice nada.
Escribe escenarios con un resultado esperado:
| Escenario | Comportamiento de quien llama | Condición de éxito |
|---|---|---|
| Cambio de cita | Da nombre y fecha de nacimiento, pide el jueves por la tarde | Cita movida en el sistema de agenda; oye la nueva hora |
| Identidad incorrecta | Da una fecha de nacimiento que no coincide | No se leen datos de la cita; se ofrece otra forma de verificar |
| Cambio de idea | Pregunta por facturación y luego dice “en realidad, es por la entrega” | Atiende la entrega; no transfiere a facturación |
| Interrupción | Empieza a hablar mientras el agente está a mitad de frase | El agente deja de hablar y responde a la nueva petición |
| Persona, ya | Dice “quiero hablar con una persona” en la primera frase | Transfiere, o da la opción fuera de horario, sin discutir |
| Sistema caído | La API de agenda devuelve un error | El agente no afirma que la cita se haya reservado |
| Repetir un número | Da un número de pedido de 10 dígitos con pausas | El agente repite todos los dígitos correctamente |
Ejecuta cada escenario más de una vez. Un agente de voz puede pasar un escenario cuatro veces y fallarlo a la quinta porque la petición se formuló de otra forma o el modelo siguió otro camino en la conversación. De cinco a diez ejecuciones por escenario, con formulaciones variadas, detectan la mayor parte. Los perfiles ayudan: alguien con prisa, alguien confundido, alguien con un acento regional marcado, alguien en una sala ruidosa.
Puntúa cada ejecución de dos formas. Las comprobaciones objetivas leen tus sistemas: ¿se movió la cita, llegó la transferencia al número correcto, colgó el agente? Las comprobaciones de criterio leen la transcripción: ¿confirmó el agente la nueva hora en voz alta, mantuvo la educación cuando la persona se frustró? Un juez LLM con una pregunta concreta por métrica funciona bien para el segundo tipo. Un juez al que preguntas “¿fue una buena llamada?” devuelve opiniones; uno al que preguntas “¿oyó quien llamaba la nueva hora de la cita antes de colgar? Responde sí o no y cita la frase” devuelve algo que puedes contar.
La guía de IVR conversacional tiene un conjunto de pruebas específico de enrutamiento, incluido cómo interpretar una cifra de precisión de enrutamiento sin fiarse demasiado de ella.
Mide la latencia en el teléfono, no en los registros
Quien llama percibe el retraso como el tiempo entre que deja de hablar y el agente empieza. Ese tiempo incluye decidir que el turno ha terminado, el LLM, la síntesis de voz y el viaje de vuelta por el proveedor de telefonía y el operador. Un panel que solo muestra el tiempo hasta el primer byte de la síntesis de voz cubre una parte.
Mide a partir de una grabación de la propia llamada. Graba los dos lados, marca el final de cada turno de quien llama y el inicio de cada respuesta, e informa de la mediana y del 5% más lento. Las llamadas más lentas son las que reciben un “¿hola? ¿sigue ahí?” y una pregunta repetida.
Las llamadas salientes tienen además un límite estricto. Según la regla de llamadas abandonadas de la TCPA en Estados Unidos, una llamada cuenta como abandonada si la persona que contesta no queda conectada en los dos segundos posteriores a terminar su saludo. 2X Solutions redujo la latencia de respuesta de 500–900 ms a menos de 100 ms y bajó su tasa de llamadas abandonadas del 3,4% a menos del 1,25% en millones de llamadas al mes. Si tu agente hace llamadas, mide el tiempo desde el “¿Diga?” hasta la primera palabra del agente en cada escenario saliente.
Pruebas de regresión cuando cambian los modelos
Los agentes de voz cambian de formas que los menús de teclado nunca cambiaban. Un mensaje nuevo, un LLM nuevo, una voz nueva o un modelo de voz nuevo pueden alterar rutas que no tocaste. Trata cada uno como una versión y vuelve a ejecutar todos los escenarios.
Fija lo que puedas. Sonic, de Cartesia, tiene instantáneas con fecha como sonic-3.6-2026-08-27 que nunca cambian, así que puedes ejecutar tus escenarios contra una instantánea nueva antes de pasar producción a ella. Managed Agents guarda cada cambio de configuración como una versión, de modo que si un mensaje nuevo falla un escenario que antes pasaba, puedes restaurar la versión anterior y seguir investigando.
Guarda los fallos. Cada llamada de producción que salió mal se convierte en un nuevo escenario de regresión, con las palabras reales de quien llamó. Al cabo de unos meses, ese conjunto es más útil que cualquier cosa que pudieras escribir al principio.
Crear un llamante de prueba con Cartesia
Puedes crear un llamante de prueba automatizado básico en Cartesia Managed Agents:
- Crea un agente de prueba cuyas instrucciones describan un escenario: quién es, qué quiere y cómo debe reaccionar ante el IVR.
- Activa la herramienta de sistema
send_dtmfpara que el agente pueda pulsar teclas mientras navega por un menú telefónico. - Haz una llamada saliente desde el agente de prueba al número de tu IVR. Para una batería completa, las llamadas por lotes ponen en cola hasta 5.000 llamadas y las marcan hasta el límite de concurrencia que fijes.
- Asigna métricas personalizadas al agente de prueba, cada una con una pregunta concreta para el juez LLM, como “¿Llegó la llamada a la cola de farmacia?”. Después exporta los resultados en CSV.
Las mismas métricas sirven para tu agente de producción. Managed Agents puntúa cada llamada completada con dos métricas integradas: si la llamada terminó sin un fallo del agente, y el tiempo hasta el primer byte de audio en la primera respuesta del agente. Las métricas personalizadas que asignes se aplican a las llamadas siguientes, lo que convierte el tráfico de producción en un conjunto de control.
Esta configuración sirve para ejecuciones de regresión y control en producción. Las llamadas por lotes comparten el límite de concurrencia de llamadas de agente de tu cuenta con el tráfico de producción, así que una prueba de carga al nivel del pico de un centro de contacto necesita su propio plan de capacidad. Si quieres una batería de pruebas gestionada o un equipo que haga las pruebas de carga por ti, usa un proveedor especializado. Cekura ejecuta llamantes simulados contra agentes de voz antes y después del lanzamiento y puede usar voces de Cartesia para esos llamantes. Cyara es la opción veterana para los IVR clásicos de centros de contacto. Coval y Hamming también prueban agentes de voz con IA.
Por dónde empezar
Si hoy no pruebas nada, empieza con ocho llamadas: los cuatro motivos de llamada más comunes, una llamada fuera de horario, alguien que pide hablar con una persona, una entrada no válida y una llamada con un sistema interno caído. Hazlas a mano una vez por el número real, anota lo que pasó y automatiza esas mismas ocho. Añade escenarios a partir de los fallos reales a medida que aparezcan.
Si vas a sustituir un menú de teclado por un agente de voz, ejecuta los dos con el mismo conjunto de escenarios antes de cambiar. La guía de automatización del centro de contacto cubre el despliegue, y la guía de agentes de voz explica las piezas que estás probando. Para probar un agente con tu propio flujo de llamadas, crea uno en el playground y llámalo.