De la demo de IA de voz a producción: lo que necesitan los compradores en los primeros 30 días

Llevar un agente de voz con IA de la demo a producción en 30 días significa acotar un único tipo de llamada, construirlo y conectarlo en la segunda semana, probarlo con llamadas simuladas y reales en la tercera, y hacer un lanzamiento controlado con una parte del tráfico real en la cuarta, con un responsable designado para cada bloque de trabajo. La demo demuestra que la plataforma puede mantener una conversación. Los 30 días demuestran que tu equipo puede gestionarla, y un cuadro de puntuación de piloto a producción al final te indica cuándo el agente está listo para recibir más tráfico.

¿Por qué una buena demo no te lleva a producción?

Una demo responde a «¿puede hablar?». Producción plantea cuatro preguntas distintas: qué llamadas atiende, en qué sistemas escribe, quién lo arregla cuando una llamada sale mal y cómo se prueba un cambio antes de que lo oigan quienes llaman. La mayoría de los equipos que se estancan tras una demo no están bloqueados por el software. Entienden el panel. Lo que les falta es un plan, un responsable con nombre y apellidos, y alguien a quien preguntar cuando la construcción plantea una duda que la documentación no resuelve para su flujo de trabajo concreto.

Si aún estás eligiendo plataforma, empieza por cómo evaluar una plataforma de agentes de voz antes de la puesta en marcha. Si tienes una favorita pero aún no te has comprometido, pruébala primero con tus propios casos límite, como se describe en la siguiente sección. A partir de ahí, esta guía da por hecho que ya has elegido y ahora necesitas lanzar.

¿Cómo se hace una prueba de concepto de IA de voz con tus propios casos límite?

Haz una prueba de concepto (POC) de IA de voz con las llamadas que la demo se saltó: tu propio personal interpreta a tus interlocutores más difíciles, con registros con la misma estructura que los reales, frente a criterios de éxito que ambas partes han firmado previamente y con el coste de las pruebas acordado de antemano. Una demo recorre el camino ideal. Una POC muestra si el agente aguanta con las reglas que hacen difíciles tus llamadas.

Prueba con tu propio personal y registros reales

Pregunta a quienes atienden hoy estas llamadas qué casos complican a las nuevas incorporaciones y pídeles que llamen al agente haciéndose pasar por esos interlocutores. Ejecuta cada caso con un registro con la misma estructura que el real, porque un registro de prueba limpio oculta lo que uno desordenado deja al descubierto.

Resuelve el tratamiento de datos antes de que los registros reales lleguen a una prueba. La documentación de cumplimiento de Retell exige un BAA firmado antes de que la información sanitaria protegida pase por Retell. Si tus normas aún no permiten usar registros reales, copia su estructura: en una prueba de simulación de Retell, cada caso define sus propios valores de variables dinámicas y resultados de funciones simulados (mock). Consulta lo que permiten tus normas con tu asesoría jurídica o tu equipo de cumplimiento.

Acuerda los criterios de éxito antes de que empiece el piloto

Ambas partes firman los criterios antes de la primera llamada de prueba, porque los criterios redactados a posteriori tienden a ajustarse a lo que el agente haya hecho. Especifica los casos incluidos en el alcance, el umbral de aprobación y el número de ejecuciones de cada uno, qué cuenta como fallo crítico, quién evalúa y a qué conduce un aprobado, para que superar la prueba termine en una decisión y no en más pruebas. Para las métricas, usa la guía de evaluación de plataformas; el cuadro de puntuación que verás más adelante en esta guía cubre una decisión diferente.

Calcula el coste de las pruebas para ambas partes

Tu parte invierte horas de personal en hacer y evaluar llamadas, además del tiempo de TI y de cumplimiento. El proveedor invierte tiempo de construcción en adaptar un agente a tus reglas. Y luego está el uso de la plataforma: según los precios de las pruebas de Retell, las pruebas se facturan a tarifas de producción, sin sandbox gratuito, con la voz desde 0,07 $ por minuto y el texto por mensaje, así que ejecuta la mayoría de los casos en texto. Deja por escrito quién cubre cada coste, cuánto dura la POC y si cuenta para un contrato. Una lista de casos y un plazo fijos la mantienen barata para ambas partes.

¿Cómo deberían ser los primeros 30 días, semana a semana?

Cuatro semanas, cada una con un objetivo y un criterio claro de «terminado cuando». No empieces la semana siguiente hasta terminar la actual.

Acota un tipo de llamada (días 1 a 7)

Elige un tipo de llamada con un volumen estable y un resultado que puedas comprobar en un sistema de registro: una cita concertada, un lead derivado, un ticket creado. Recopila grabaciones o transcripciones reales de ese tipo de llamada, no el guion que tu equipo cree que siguen los interlocutores.

El documento de alcance debe responder a cinco cuestiones:

• El único tipo de llamada incluido en el alcance y todos los tipos explícitamente excluidos.
• La métrica de éxito, definida de forma que una máquina pueda marcarla como verdadera o falsa.
• El único sistema de registro del que el agente lee o en el que escribe.
• Adónde van las llamadas cuando el agente no puede ayudar, y en qué horario.
• Quién aprueba los textos del agente y quién da el visto bueno al lanzamiento.

Construye y conecta (días 8 a 14)

Construye sobre una versión borrador. En Retell, una versión nueva empieza como borrador que puedes editar y probar, y al publicarla pasa a ser de solo lectura, de modo que siempre tienes una configuración fija a la que volver. Conecta solo el sistema que figura en tu alcance. Si esa conexión es nueva para tu equipo, el flujo de trabajo del CRM a la IA de voz explica qué datos se mueven en cada momento de la llamada.

Configura ya la métrica de éxito, no después del lanzamiento. La función Post Call Extraction de Retell se ejecuta al terminar cada llamada e incluye un campo integrado call_successful, además de campos personalizados que defines como booleano, texto, número o selector. Un campo como «appointment_booked» es lo que representarás en gráficos y vigilarás con alertas en la cuarta semana.

Prueba con llamadas simuladas y reales (días 15 a 21)

Prueba primero en texto, después en voz y luego por teléfono. Las pruebas de simulación de Retell ejecutan un caso de prueba sin hacer una llamada: una IA interpreta al interlocutor a partir de un perfil que tú escribes, y la ejecución se califica como aprobada o suspendida según tus criterios de éxito, con una explicación por escrito. Los casos guardados se ejecutan juntos en lote, lo que da una tasa de aprobación, así que la batería se convierte en tu prueba de regresión tras cada cambio. Conductor, el copiloto integrado en el panel de Retell, puede redactar casos de prueba desde cero o a partir de llamadas reales.

Tres cosas que debes hacer bien esta semana:

• Simula (mock) todo lo que escriba en un sistema en producción. La documentación de Retell advierte que una función personalizada sin mock llama a su endpoint real durante una prueba, por lo que una prueba puede crear una reserva o un registro reales.
• Usa llamadas web para la voz y llamadas telefónicas para la telefonía. Una llamada desde el navegador te permite oír las interrupciones y los turnos de palabra, pero las transferencias a un número de teléfono fallan ahí. Usa una llamada telefónica real para comprobar las transferencias, la entrada por teclado y el audio del operador.
• Presupuéstalo. En Retell, las pruebas se facturan a tarifas de producción: las de texto por mensaje, las de voz por minuto.

Cierra la semana con tu personal llamando como lo harían los interlocutores reales, incluidos los más complicados.

Lanzamiento controlado y monitorización (días 22 a 30)

Envía una pequeña parte del tráfico real al agente, revísalo a diario y ten preparada una reversión en un solo paso. Para la primera porción, tu responsable de telefonía deriva una parte de las llamadas al número del agente desde tu IVR o cola actual. A partir de ahí, Retell te ofrece tres herramientas:

• Las pruebas A/B reparten el tráfico de un número de teléfono entre agentes por porcentaje, de modo que una corrección puede recibir una pequeña parte mientras el resto sigue en el agente de confianza.
• Las etiquetas de entorno asocian un número de teléfono a una versión. Mover la etiqueta prod a una nueva versión cambia las llamadas en directo a esa versión; volver a moverla revierte el cambio.
• Las reglas de alerta envían un correo electrónico o un webhook cuando la tasa de éxito de las llamadas, el volumen de llamadas, la concurrencia utilizada, el sentimiento negativo o el coste superan un umbral que tú fijas.

Revisa las llamadas cada día. Call History filtra por resultado, motivo de desconexión y versión del agente. Live Monitoring permite a un supervisor seguir una transcripción en directo, escuchar en silencio o tomar el control de una llamada. El panel de analítica puede representar tu campo de extracción personalizado junto al volumen de llamadas, desglosado por versión del agente, para que veas si una corrección ha movido la cifra. Si necesitas una puntuación estructurada a escala, AI QA de Retell puntúa una muestra de llamadas según criterios que tú defines.

¿Quién es responsable de qué durante el despliegue?

Un responsable por fila. Las filas compartidas son donde se atascan los despliegues.

La fila más importante es la segunda. Si nadie de tu equipo puede modificar el agente sin abrir un ticket, el agente mejora al ritmo de la cola de otra persona. En cada vez más equipos, esa fila corresponde a un ingeniero de automatización de CX: un responsable interno que gestiona el agente en el día a día, después de que los ingenieros desplegados en cliente (forward deployed engineers) del proveedor hayan ayudado a construir la primera versión y formado al equipo.

¿Qué deberías preguntar a un proveedor sobre la capacitación antes de firmar?

Pregunta, por escrito, qué ayuda incluye tu plan y a quién llamas cuando la construcción se atasca. El autoservicio funciona cuando tienes un perfil técnico interno con tiempo. Si no lo tienes, contrata la ayuda desde el principio en lugar de descubrir la carencia en la segunda semana.

En Retell, la página de precios incluye soporte de la comunidad y por correo electrónico en el plan de pago por uso. El plan Enterprise incluye soporte 24/7 con un portal dedicado, un gestor de cuenta asignado y Dedicated Implementation Support como complemento. Si quieres ayuda práctica de un tercero para la construcción, el directorio de partners de soluciones de Retell recoge partners certificados que puedes filtrar por ubicación, idioma, integraciones, si la primera consulta es gratuita y rango de precios.

Preguntas que plantear a cualquier proveedor:

1. ¿Qué canales y horarios de soporte incluye nuestro plan y qué se considera urgente?
2. ¿La ayuda con la implementación está incluida, es un complemento o se presta a través de un partner? ¿Cuánto cuesta y es un precio fijo o se define por proyecto?
3. ¿Revisará alguien nuestro alcance, el diseño del agente y la batería de pruebas antes del lanzamiento controlado?
4. ¿A quién contactamos durante la semana del lanzamiento controlado si algo falla y con qué rapidez responde?
5. ¿Puede nuestro propio equipo ejecutar el ciclo completo de cambios (encontrar una llamada fallida, corregirla, probarla, publicarla y revertirla) sin tickets al proveedor?
6. ¿Cómo se comunican las incidencias de la plataforma?

Si un partner construye contigo, cómo acotan el primer acuerdo los proveedores y partners de IA de voz explica el reparto desde su lado.

¿Cómo se puntúa un piloto de IA antes de pasarlo a producción?

Puntúa el piloto con un cuadro de puntuación fijo tras al menos una semana completa de tráfico real, y pásalo a producción solo cuando todas las filas eliminatorias se superen y el total alcance el umbral que fijaste en la primera semana. El cuadro de puntuación convierte «parece que va bien» en una de tres decisiones: ampliar, mantener y corregir, o redefinir el alcance.

Incluye el umbral en el documento de alcance antes del lanzamiento controlado, para que nadie intente rebajarlo tras ver las cifras. Puntúa cada fila con 0 (no cumplido), 1 (cumplido en parte) o 2 (cumplido). Las filas eliminatorias deben puntuar 2 sea cual sea el total. Nueve filas dan un máximo de 18, y 16 es un umbral razonable por defecto.

Vuelve a puntuar en cada aumento de tráfico, porque una cuota que funcionaba con una porción pequeña puede fallar con una mayor. La fila del ciclo de cambios es la que los equipos más tienden a saltarse, y es la que determina lo rápido que mejora el agente en producción. Trata cada edición del prompt como una versión nueva y comprobable, la práctica conocida como versionado de prompts, para que una corrección que falle pueda deshacerse en un solo paso.

Este cuadro de puntuación sirve para pasar un lanzamiento controlado a producción en una plataforma que ya has elegido. Para comparar proveedores en un piloto, usa la lista de criterios go/no-go de la guía de evaluación de plataformas.

¿Qué deberías ampliar primero?

Cambia una sola cosa cada vez. Primero aumenta la cuota de tráfico, después añade un segundo tipo de llamada y luego un segundo sistema. Cada ampliación reutiliza el mismo ciclo: acotar, construir en un borrador, ejecutar la batería, lanzamiento controlado, revisión. Convierte cada llamada fallida en producción en un nuevo caso de prueba para que la batería crezca con lo que de verdad hacen los interlocutores. Antes de aumentar mucho el tráfico, ejecuta una prueba de carga que siga la ruta real de la llamada.

Empieza con el nivel de ayuda adecuado

Los primeros 30 días avanzan más rápido cuando decides de antemano cuánta ayuda necesitas. Compara lo que incluye cada plan de Retell en la página de precios o, si nadie de tu equipo puede encargarse de la construcción, encuentra un partner certificado en el directorio de partners de soluciones de Retell.

Preguntas frecuentes

¿Qué significa pasar un piloto de IA a producción?

Pasar un piloto de IA a producción es dar el salto de una prueba con una parte del tráfico real a utilizar un agente de IA como vía predeterminada para un tipo de llamada, con responsables designados, monitorización y una forma probada de revertir cambios. El piloto demuestra que el agente puede completar la llamada. La producción demuestra que tu equipo puede mantenerlo funcionando.

¿Qué debe incluir una prueba de concepto de IA de voz?

Tus casos reales más difíciles, planteados por tu propio personal con registros con la misma estructura que los reales; criterios de éxito que ambas partes firman antes de la primera llamada de prueba; y un reparto por escrito de quién paga el uso de la plataforma, el tiempo de construcción y el tiempo del personal. Limítala a una lista de casos y un plazo fijos para que termine en una decisión.

¿Se puede probar un agente de voz sin enviar datos reales de clientes al proveedor?

Sí. Copia la estructura de los registros reales en los casos de prueba. En las pruebas de simulación de Retell, cada caso define sus propios valores de variables dinámicas y resultados de funciones simulados. Simula (mock) cada función que llegue a un sistema en producción y asigna un resultado a cada mock, porque un mock vacío ejecuta la función real, y las herramientas MCP ignoran los mocks. Si deben circular datos reales, firma antes los acuerdos: Retell exige un BAA firmado antes de que la información sanitaria protegida pase por ella. Consulta tus propias normas con tu asesoría jurídica o tu equipo de cumplimiento.

¿Cuánto dura un piloto de IA de voz antes de pasar a producción?

Para un tipo de llamada, calcula unos 30 días: una semana para acotar, otra para construir y otra para probar, y después un lanzamiento controlado con una parte del tráfico real. Puntúa el piloto tras al menos una semana completa de llamadas reales y de nuevo en cada aumento de tráfico.

¿Cómo sabes que un agente de voz está listo para producción?

Cuando todas las filas eliminatorias del cuadro de puntuación obtienen un 2 durante una semana completa de tráfico real: la métrica de éxito se mantiene, las llamadas revisadas no tienen errores críticos, tu equipo ha corregido y revertido una versión sin ayuda del proveedor, cada bloque de trabajo tiene un responsable designado y el visto bueno de cumplimiento está archivado.

¿Qué hacer si el piloto no rinde lo esperado?

Mantén la cuota de tráfico o vuelve a mover la etiqueta de producción a la última versión que funcionó. Corrige en una versión borrador, vuelve a ejecutar la batería de pruebas y puntúa de nuevo tras otra semana. Si la fila de resultado o la de errores críticos sigue puntuando 0 tras dos ciclos de corrección, acota el tipo de llamada o redefine el éxito.