Detección de contestador automático para IA de voz: diseña cada resultado de llamada

La detección de contestador automático (AMD) es el paso que decide si una llamada saliente la ha contestado una persona, un mensaje de buzón de voz o un menú telefónico automatizado. En un despliegue de IA de voz, cada una de esas respuestas debería ser un estado de llamada propio, con una acción, una entrada de registro y una regla de reintento definidas.

Muchas llamadas salientes terminan en un mensaje de buzón de voz o en un árbol telefónico, no en una persona. Cuando la detección vive en un marcador independiente colocado delante del agente, esas llamadas se convierten en restos que alguien tiene que clasificar después de la campaña. Esta guía las incorpora al diseño, para que quienes construyen sepan qué configurar y los responsables de operaciones sepan qué llega al CRM.

¿Qué decide realmente la detección de contestador automático?

Decide quién o qué ha contestado, con la antelación suficiente para que el agente cambie lo que hace en la misma llamada. En Retell, esa decisión procede de dos detectores independientes:

• La detección de buzón de voz reconoce un mensaje de buzón de voz y, a continuación, cuelga o deja un mensaje.
• La detección de IVR reconoce un menú telefónico automatizado y, con IVR Hangup activado, finaliza la llamada.

Ambos funcionan en llamadas telefónicas salientes (y en llamadas web, que es como se prueban). No tienen efecto en las llamadas entrantes, porque es una persona quien te llama. La detección solo se ejecuta durante los primeros 3 minutos tras conectarse la llamada, y esa ventana no es configurable. El tiempo pasado en un menú telefónico o hablando con una persona cuenta para esa ventana.

Hay dos resultados más junto a la AMD. Los teléfonos que filtran llamadas de desconocidos pueden pedir al agente su nombre y el motivo de la llamada antes de que la persona decida contestar. Y algunas llamadas nunca llegan a conectarse (sin respuesta, ocupado, rechazada, bloqueada), por lo que la detección nunca se ejecuta. Un diseño completo los cubre todos.

¿Por qué tratar el buzón de voz y el IVR como estados de llamada y no como limpieza posterior?

Porque la acción correcta tiene que producirse durante la llamada, y el resultado determina el siguiente intento. Si el agente solo descubre que ha llegado a una máquina cuando la llamada ya ha terminado, fallan tres cosas:

1. El agente suelta su presentación completa a un mensaje grabado, o habla por encima de él.
2. El CRM registra como «completada» una llamada que no llegó a nadie.
3. La lógica de reintentos no distingue entre «dejó un mensaje hace una hora» y «nunca consiguió contactar», así que o llama en exceso a las personas o se rinde con las que sí están localizables.

Un estado de llamada empareja una señal de detección con una acción y una tipificación.

¿Qué estados de llamada necesita un agente de voz saliente?

Como mínimo, estos ocho. Las columnas de detección y registro describen el comportamiento documentado de Retell. La columna de reintento es una regla que tu equipo define en su propio marcador o backend.

¿Cuándo debe el agente dejar un mensaje en el buzón de voz en lugar de colgar?

Deja un mensaje cuando este cumpla una función útil aunque nadie devuelva la llamada, y cuelga cuando un intento posterior vaya a hacer mejor el trabajo. Los recordatorios, las solicitudes de devolución de llamada y los plazos son buenos candidatos para un mensaje. Las presentaciones comerciales, y cualquier cosa que no querrías que un familiar o un compañero de trabajo escuchara en altavoz, normalmente no lo son.

Retell te ofrece dos tipos de mensaje:

• Frase estática: texto fijo con variables dinámicas, como Hi {{first_name}}, this is the clinic confirming your appointment. Please call us back.
• Prompt: instrucciones que el agente utiliza para generar el mensaje, como resumir por qué ha llamado y pedir una devolución de llamada.

En ambos casos, el agente espera su turno para hablar, de modo que el mensaje no empieza por encima del saludo grabado. Vigila los valores predeterminados: los agentes nuevos en blanco del dashboard empiezan con la detección de buzón de voz activada y configurada para colgar, pero los agentes existentes, las configuraciones importadas y los agentes de transferencia mantienen sus ajustes, y en los agentes creados por API hay que definir voicemail_option explícitamente. La API también acepta un detection_prompt opcional que describe qué debe considerarse buzón de voz.

Para la redacción del mensaje, consulta 5 buenas prácticas de buzón de voz al usar agentes de voz con IA.

¿Qué debe hacer el agente cuando llega a un árbol telefónico?

Primero decide si el menú es un callejón sin salida o una ruta. Si una campaña de recordatorios a consumidores llega a la centralita de una empresa, probablemente el número sea erróneo, así que activa IVR Hangup y registra ivr_reached. Si la persona que buscas está detrás de un menú, como ocurre con las líneas de aseguradoras, proveedores o facturación, navega por él y deja IVR Hangup desactivado, ya que finalizaría la llamada al detectarlo.

Para navegar, los agentes de prompt único y de varios prompts usan la herramienta Press Digit, y los agentes de flujo de conversación usan el nodo Press Digit. Hay algunos ajustes documentados importantes:

• Pause Detection Delay define cuánto espera el agente tras la pausa del menú antes de pulsar. Por defecto es de 1000 ms y admite de 0 a 5000 ms. Auméntalo para menús lentos.
• El agente puede pulsar del 0 al 9, * y #, solos o en secuencia, como una extensión.
• En un flujo, escribe transiciones para el éxito y para el fallo, como llegar al departamento correcto, que el menú se repita tres veces, que sea la empresa equivocada o un mensaje de fuera de horario o de buzón de voz.

Esa última transición es importante por la ventana de 3 minutos. Un buzón de voz al que se llega tras un menú largo, o después de que alguien transfiera la llamada, puede no activar la detección de buzón de voz, así que el flujo tiene que reconocerlo por sí mismo.

Si tienes activado colgar en el buzón de voz pero una llamada no se cuelga, lo más probable es que el sistema haya clasificado el saludo como un IVR. Activa IVR Hangup para cubrir ese caso. Más información sobre menús en Navegar por IVR.

¿Qué hay que registrar en cada resultado de llamada?

Registra el motivo de desconexión de la plataforma y asígnalo a un campo de tipificación que gestionen tus propios sistemas. Retell proporciona tres capas:

• call_status: registered, not_connected, ongoing, ended o error.
• disconnection_reason: el resultado concreto de la tabla anterior.
• in_voicemail en call_analysis: si la llamada llegó a un buzón de voz.

El webhook call_ended incluye todos los campos de la llamada excepto call_analysis, que llega con call_analyzed. Las llamadas que nunca se conectan omiten call_started, pero siguen enviando ambos. Los webhooks se reintentan hasta 3 veces si no reciben un 2xx en 10 segundos, así que deduplica por evento más call_id.

Para tipificaciones más completas, añade campos de extracción posterior a la llamada. Un campo selector funciona bien para una tipificación, y la documentación de IVR de Retell incluye definiciones de campos listas para usar, como reached_human, ivr_outcome e ivr_path. Retell no rellena los campos de extracción personalizados en llamadas que no se conectaron o no tuvieron conversación, así que construye la tipificación primero a partir de disconnection_reason y usa los campos de extracción para añadir detalle.

Los responsables de operaciones pueden seguir la métrica Voicemail Rate del panel de analítica y representar las llamadas voicemail_reached por versión del agente, lo que muestra si una nueva versión envía más llamadas al buzón de voz. Para enviar las tipificaciones a un registro del CRM, consulta el flujo de trabajo del CRM a la IA de voz.

¿Quién gestiona la regla de reintento?

Tu marcador o tu backend. La documentación de Retell no describe ninguna rellamada automática e indica que Retell no limita la frecuencia con la que tu agente llama a un número. Las llamadas por lotes no tienen un ajuste de retardo por llamada ni comprueban el indicador de no llamar; la API Create Phone Call solo lo comprueba con honor_internal_dnc: true.

Retell sí te da los datos de entrada para una política de reintentos:

• Contactos registra cada llamada telefónica saliente como una conversación, incluidas las de buzón de voz y las no contestadas. Por tanto, un periodo de espera basado en last_conversation_timestamp también cubre los intentos de marcación.
• List contact conversations devuelve el motivo de desconexión de cada llamada, para que puedas contar los intentos por resultado, por ejemplo: «dos mensajes de buzón de voz esta semana, detente».
• La detección de no llamar (do-not-call) finaliza la llamada con user_requested_dnc y marca el contacto. Trátalo como una parada permanente.

Consulta con tu equipo legal qué normas de frecuencia de llamadas se aplican a tu sector y región antes de fijar los límites.

Vigila un efecto secundario. Los operadores pueden marcar un número como spam cuando realiza muchas llamadas cortas en poco tiempo, y entonces las llamadas fallan como dial_failed. Una campaña que cuelga en todos los buzones de voz produce exactamente ese patrón, así que dosifícala y registra tus números. La checklist de números de teléfono salientes cubre la verificación y el identificador de llamada con marca.

¿Cómo se prueba la detección de contestador automático antes del lanzamiento?

Prueba todos los estados de la tabla antes de la primera campaña real. Retell admite dos pasadas:

1. Llamada web: reproduce un mensaje de buzón de voz grabado o un aviso de menú en una llamada web. El agente usa la misma detección y las mismas acciones, sin llegar a un buzón ni a un menú reales.
2. Llamada telefónica: realiza llamadas de prueba salientes reales, que también ponen a prueba la ruta de audio del operador.

Un conjunto breve de pruebas:

• Un saludo de buzón de voz estándar, con dejar mensaje activado y con colgar activado
• Un mensaje de fuera de horario de una empresa
• Un menú de teclado, incluida una opción errónea y un menú repetido
• Un filtrado de llamadas del teléfono que pide nombre y motivo
• Una persona que contesta con una pausa larga
• Cada prueba termina con el disconnection_reason esperado y la tipificación correcta en tu CRM

Integra los estados de llamada en tus campañas salientes

La AMD funciona mejor cuando forma parte del flujo de trabajo, no cuando es un filtro delante de él. Retell mantiene la detección de buzón de voz, la gestión de IVR, el filtrado de llamadas y los motivos de desconexión en la misma plataforma que el agente, para que cada resultado tenga su propia acción y su propia entrada de registro. Para aplicar estos estados de llamada a una lista de contactos, empieza con las llamadas por lotes de Retell.