Puntos clave
- Un IVR clásico resuelve entre el 20% y el 30% de las llamadas sin pasar a un agente humano. Los agentes de voz con IA alcanzan entre el 60% y el 80% de resolución en los primeros 90 días.
- La variable técnica que decide si la conversación se siente natural es la latencia de respuesta. Por debajo de 500 ms la conversación fluye; por encima de 800 ms el usuario empieza a hablar encima y el sistema se rompe.
- Hay dos arquitecturas: cascada (voz→texto→LLM→voz, más controlable y auditable) y speech-to-speech (modelo único, más natural y rápido, menos controlable). No hay una mejor: hay una mejor para cada caso.
- El error más caro no es técnico: es medir el proyecto por llamadas contenidas en lugar de por problemas resueltos. Un agente que retiene la llamada y no resuelve nada es un IVR con mejor voz.
Un agente de voz con IA es un sistema que atiende llamadas telefónicas manteniendo una conversación natural, consultando sistemas reales (CRM, ERP, plataforma de pedidos) y resolviendo o enrutando la petición. Se diferencia de un IVR en que no hay menús ni opciones numeradas: el usuario explica su problema con sus palabras. La métrica que lo hace viable es la latencia por debajo de 500 ms.
Por qué el IVR está agotado
Un IVR (Interactive Voice Response, respuesta de voz interactiva) es el sistema de menús telefónicos con opciones numeradas. Su límite es estructural: obliga al usuario a traducir su problema al árbol de opciones que alguien diseñó hace años. Cuando el problema no encaja en ninguna rama, el usuario pulsa cero o se resigna.
Los números lo reflejan: un IVR clásico retiene entre el 20% y el 30% de las llamadas; el resto acaba en un agente humano. Y una parte significativa de las que sí retiene llegan mal enrutadas, lo que genera transferencias y repetición de contexto — el motivo principal de insatisfacción en atención telefónica.
Lo que un agente de voz NO es: no es un IVR con síntesis de voz mejorada. Si el sistema sigue teniendo un árbol de opciones y solo cambia la voz robótica por una natural, has cambiado la estética sin tocar el problema. La diferencia real es que el agente entiende lenguaje abierto y consulta sistemas para resolver, no solo para clasificar.
La analogía: el IVR es un formulario leído en voz alta. El agente de voz es una persona en el mostrador que te escucha, mira el sistema y te resuelve o te lleva a quien puede.
Las dos arquitecturas: cascada vs speech-to-speech
Esta es la decisión técnica que más condiciona el resultado, y la que casi ningún proveedor explica bien.
Arquitectura en cascada (STT → LLM → TTS). La voz se transcribe a texto (speech-to-text), el texto lo procesa un modelo de lenguaje, y la respuesta se convierte en voz (text-to-speech). Tres componentes independientes.
Arquitectura speech-to-speech. Un único modelo multimodal procesa audio de entrada y genera audio de salida, sin pasar por texto intermedio. Menos saltos, menos latencia acumulada, y conserva la prosodia y las señales no verbales.
| Criterio | Cascada (STT→LLM→TTS) | Speech-to-speech |
|---|---|---|
| Latencia típica | Mayor (suma de tres etapas) | Menor (una sola etapa) |
| Naturalidad e interrupciones | Buena con buen diseño | Superior |
| Auditabilidad de la conversación | Alta (hay transcripción en cada paso) | Menor (requiere transcripción aparte) |
| Control sobre lo que dice | Alto (se puede validar el texto) | Menor |
| Idiomas y acentos poco frecuentes | Depende del motor STT | Depende del modelo |
| Adecuación en sectores regulados | Mejor | Requiere más control añadido |
Nuestra recomendación: en sectores regulados o donde cada respuesta debe ser auditable —financiero, sanitario, seguros— la cascada sigue siendo la elección más defendible, porque tienes texto verificable en cada etapa y puedes validar la respuesta antes de sintetizarla. En atención generalista de alto volumen, donde la naturalidad importa más que la auditoría fina, speech-to-speech gana.
Y una tercera opción que funciona bien: híbrida, con speech-to-speech para la conversación y una capa de validación en texto antes de cualquier acción con efecto sobre sistemas.
La latencia: la variable que decide todo
En una conversación telefónica humana, el silencio entre turnos ronda los 200-300 ms. Ese es el listón perceptivo, y explica por qué la latencia manda por encima de cualquier otra métrica técnica:
- Por debajo de 500 ms: la conversación se siente natural. Es el objetivo, y los mejores sistemas de 2026 lo alcanzan de forma consistente.
- Entre 500 y 800 ms: perceptible pero tolerable. El usuario nota una pausa, no se rompe la conversación.
- Por encima de 800 ms: el usuario cree que el sistema no ha entendido, repite o habla encima. A partir de ahí la conversación se degrada rápido.
Tres cosas que suben la latencia y que conviene vigilar desde el diseño:
- Cada llamada a un sistema externo. Consultar el CRM añade su propia latencia. Si el CRM tarda 900 ms, ninguna optimización del modelo lo compensa.
- La distancia de red. Un modelo servido lejos del punto de terminación de la llamada añade ida y vuelta. La colocalización de la inferencia con la red de voz es lo que diferencia a los proveedores más rápidos.
- El diseño del turno. Un sistema que espera al silencio total antes de empezar a procesar pierde cientos de milisegundos que un sistema con procesamiento incremental aprovecha.
Datos clave del mercado
- Un IVR clásico retiene entre el 20% y el 30% de las llamadas, mientras los agentes de voz con IA alcanzan entre el 60% y el 80% de resolución en los primeros 90 días de operación (Shelf.io, 2026).
- Los sistemas punteros de 2026 operan por debajo de 500 ms de latencia, y los proveedores más rápidos lo consiguen ejecutando la inferencia colocalizada con su propia red de telefonía, no solo optimizando el modelo.
- El enrutado erróneo es uno de los mayores focos de coste oculto en atención telefónica: cada llamada mal transferida consume tiempo de agente y obliga al cliente a repetir su contexto desde cero.
Nuestra lectura: el salto del 20-30% al 60-80% de resolución es real, pero solo se sostiene si el agente tiene acceso a sistemas. Un agente de voz sin integración con el CRM entiende mejor la pregunta y sigue sin poder responderla.
Cuándo tiene sentido sustituir el IVR (y cuándo no)
Señales de que es el momento:
- Tienes volumen alto de llamadas repetitivas con respuesta objetiva: estado de pedido, horarios, saldo, cita previa, incidencia conocida.
- Tu tasa de abandono en el IVR es alta, o mucha gente pulsa cero nada más entrar.
- Hay transferencias frecuentes entre departamentos por enrutado incorrecto.
- Atiendes fuera de horario con buzón o con nada, perdiendo contactos.
- Tus sistemas exponen APIs para consultar la información que se pide por teléfono.
Cuándo NO tiene sentido todavía:
- Cuando el volumen de llamadas es bajo y variado. Si cada llamada es distinta y son pocas, el esfuerzo de diseño no se amortiza.
- Cuando tus sistemas no exponen la información por API. Un agente de voz sin datos es un IVR más caro.
- Cuando la conversación tiene carga emocional alta por naturaleza: reclamaciones graves, comunicación de incidencias sensibles, cancelaciones delicadas. Ahí el agente debe identificar y transferir rápido, no intentar resolver.
Casos de uso habituales
Caso 1 — Sustitución del menú de entrada por triaje conversacional.
- Problema: el IVR obliga a navegar cuatro niveles de menú y mucha gente pulsa cero de inmediato.
- Solución: el agente pregunta en abierto ("¿en qué puedo ayudarte?"), identifica la intención, resuelve lo que puede contra el sistema y transfiere el resto al departamento correcto con el contexto ya recogido.
- Stack: agente de voz + telefonía + API del CRM + integración con la centralita para transferencia con contexto.
- Resultado: menos transferencias erróneas y el cliente no repite su caso al llegar al humano.
Caso 2 — Gestión de citas por teléfono.
- Problema: un volumen alto de llamadas son solicitudes, cambios y cancelaciones de cita, con reglas simples y verificables.
- Solución: agente que consulta disponibilidad real, agenda, modifica y confirma por SMS o WhatsApp, con transferencia inmediata ante cualquier caso ambiguo.
- Stack: agente de voz + API de agenda + confirmación por canal escrito.
- Resultado: el bloque de llamadas más repetitivo se atiende también fuera de horario.
Caso 3 — Desbordamiento en picos de llamada.
- Problema: en horas punta o durante incidencias masivas, la cola crece y el abandono se dispara.
- Solución: el agente de voz atiende el desbordamiento, resuelve las consultas objetivas e informa del estado de la incidencia conocida, dejando la cola humana para lo que la necesita.
- Stack: agente de voz + reglas de desbordamiento en la centralita + fuente de estado de incidencias.
- Resultado: la tasa de abandono en picos baja sin ampliar plantilla.
Cómo implementarlo paso a paso
- Analiza tus llamadas antes de diseñar nada. Clasifica una muestra real por intención y mide qué porcentaje representa cada tipo. Casi siempre tres o cuatro intenciones concentran la mayoría del volumen.
- Empieza por la intención más repetitiva y objetiva. No intentes cubrir todo el árbol el primer día. Un agente que resuelve muy bien el 40% de las llamadas es mejor que uno que resuelve regular el 100%.
- Conecta los sistemas antes de pulir la voz. El agente necesita datos reales. Sin API de consulta, el proyecto no avanza por mucho que la voz suene bien.
- Fija el presupuesto de latencia por componente. Cuánto puede tardar el reconocimiento, el modelo, la consulta al CRM y la síntesis. Si la suma supera 800 ms, hay que rediseñar, no ajustar.
- Diseña la transferencia como parte del producto. Con contexto completo al agente humano y sin pedir al cliente que repita. Es lo que más impacta en satisfacción y lo que peor se suele hacer.
- Da salida clara a la persona. "Si prefieres hablar con alguien, dímelo en cualquier momento." Esconder la salida no reduce las transferencias, reduce la satisfacción.
- Escucha llamadas reales cada semana durante los primeros meses. Ninguna métrica sustituye a oír diez conversaciones completas: los fallos de diseño se detectan ahí antes que en un dashboard.
Errores comunes (y cómo evitarlos)
Error: medir el proyecto por llamadas contenidas. → La realidad: contener una llamada sin resolverla solo desplaza el problema, y el cliente vuelve a llamar más enfadado. La métrica correcta es resolución en primera llamada, no contención.
Error: cambiar la voz del IVR y llamarlo agente de IA. → La realidad: si sigue habiendo un árbol de opciones, sigues teniendo un IVR. La diferencia está en el lenguaje abierto y en el acceso a sistemas, no en la síntesis de voz.
Error: no presupuestar la latencia de las integraciones. → La realidad: un CRM lento arruina la experiencia por mucho que el modelo sea rápido. La latencia se diseña de extremo a extremo, incluyendo cada consulta externa.
Error: ocultar la opción de hablar con una persona. → La realidad: aumenta la frustración y las reseñas negativas sin reducir el contacto humano real. Ofrécela de forma explícita y temprana.
Error: desplegar sin escuchar llamadas reales. → La realidad: las métricas agregadas no capturan que el agente interrumpe, no entiende un acento o repite una fórmula. Diez llamadas escuchadas enteras valen más que un dashboard semanal.
Error: no cumplir la obligación de informar de que es un sistema de IA. → La realidad: desde el 2 de agosto de 2026, el artículo 50 del AI Act obliga a informar de forma clara cuando el usuario interactúa con un sistema de IA. En voz, eso significa decirlo al principio de la llamada, no en un aviso legal.
Tiempos y esfuerzo realistas
- Agente de voz para una intención acotada (citas, estado de pedido, información objetiva): 5-8 semanas hasta producción, si los sistemas exponen APIs.
- Sustitución del menú de entrada con triaje conversacional y transferencia con contexto: 8-12 semanas, incluyendo integración con la centralita.
- Ampliación a nuevas intenciones: 1-3 semanas por intención una vez la base está montada. La primera es la cara; las siguientes, mucho menos.
- Dónde está el esfuerzo oculto: en la integración con la centralita y en la transferencia con contexto. La parte de voz está madura; el traspaso limpio al agente humano es donde se atascan la mayoría de los proyectos.
Métricas que medir desde el día 1: tasa de resolución en primera llamada (no de contención), latencia p95 de extremo a extremo, tasa de transferencia con su motivo, tiempo medio de conversación frente a la línea base humana, tasa de abandono durante la conversación con el agente y CSAT comparado con el canal humano. La tasa de abandono a mitad de conversación es el mejor indicador temprano de que algo en el diseño no funciona.
Preguntas frecuentes
¿Qué diferencia hay entre un IVR y un agente de voz con IA?
Un IVR presenta menús con opciones numeradas y obliga al usuario a encajar su problema en un árbol predefinido. Un agente de voz con IA entiende lenguaje abierto, consulta sistemas reales para resolver y transfiere con contexto cuando no puede. La diferencia no es la voz, es la comprensión y el acceso a datos.
¿Cuánta latencia puede tener un agente de voz?
Por debajo de 500 ms la conversación se siente natural; entre 500 y 800 ms es perceptible pero tolerable; por encima de 800 ms el usuario empieza a hablar encima y la conversación se degrada. La latencia se mide de extremo a extremo, incluyendo las consultas a sistemas externos.
¿Qué es la arquitectura speech-to-speech y en qué se diferencia de la cascada?
La cascada transcribe la voz a texto, procesa el texto con un LLM y sintetiza la respuesta: tres etapas independientes, más latencia y más auditabilidad. Speech-to-speech usa un modelo único que procesa y genera audio directamente: menos latencia y más naturalidad, con menos control sobre lo que se dice.
¿Cuánto puede resolver un agente de voz frente a un IVR?
Los IVR clásicos retienen entre el 20% y el 30% de las llamadas, mientras los agentes de voz con IA alcanzan entre el 60% y el 80% de resolución en los primeros 90 días. Ese salto solo se sostiene si el agente tiene acceso real a los sistemas donde está la información.
¿Hay que avisar al cliente de que habla con una IA?
Sí. Desde el 2 de agosto de 2026, el artículo 50 del AI Act obliga a informar de forma clara cuando una persona interactúa con un sistema de IA. En una llamada, eso significa indicarlo al inicio de la conversación de forma explícita.
¿Puede un agente de voz transferir a una persona?
Debe poder hacerlo, y con contexto completo: quién llama, qué ha pedido y qué se ha hecho ya. La transferencia limpia es la parte del proyecto que más impacta en satisfacción y la que más se descuida en las implantaciones.
¿Funciona bien con acentos y con varios idiomas?
Los sistemas actuales manejan bien los idiomas y acentos principales, pero conviene probar con grabaciones reales de tus clientes antes de decidir. En la arquitectura en cascada la calidad depende del motor de reconocimiento; en speech-to-speech, del modelo.
¿Qué casos no conviene automatizar por voz?
Las conversaciones con carga emocional alta —reclamaciones graves, comunicación de incidencias sensibles, cancelaciones delicadas— y aquellas cuyos datos no están disponibles por API. En esos casos el papel del agente es identificar la situación y transferir rápido, no intentar resolver.
¿Tu IVR resuelve tres de cada diez llamadas?
En Naxia implementamos agentes de voz conectados a tus sistemas reales: triaje conversacional en lugar de menús, resolución de las intenciones más repetitivas, transferencia con contexto completo a tu equipo y presupuesto de latencia diseñado de extremo a extremo. Con la arquitectura adecuada a tu sector, incluida la opción auditable en cascada si estás en un entorno regulado.
Si quieres saber qué porcentaje de tus llamadas actuales podría resolverse sin intervención humana, habla con nosotros. Sin compromiso y sin powerpoints de 40 páginas.
O si prefieres, explora primero nuestro proceso de implementación.