Telefonía
Recibe o realiza la llamada y transporta el audio.
De la llamada a la acción
Cada turno de una llamada atraviesa una cadena técnica. La calidad final depende tanto del modelo como de la telefonía, las instrucciones, los datos y el diseño de las acciones.
Recibe o realiza la llamada y transporta el audio.
Reconoce voz, interpreta contexto y genera la respuesta.
Conectan agenda, CRM, mensajería, webhooks o transferencias.
La cadena técnica
La llamada entra por un número o una conexión SIP. El audio se transforma en texto o en representaciones que el sistema puede interpretar. Las instrucciones aportan el papel, los límites y los datos del negocio. El modelo decide qué responder o qué herramienta utilizar. Una voz sintetiza la respuesta y la telefonía la devuelve a la persona.
Este ciclo se repite en segundos mientras la persona interrumpe, corrige o cambia de tema. Una demora pequeña en varias capas puede acumularse. Por eso la experiencia no se explica con una sola cifra de latencia ni con una demostración grabada.
Conviene separar el tiempo hasta la primera respuesta del tiempo necesario para terminar una acción. Un saludo rápido puede ir seguido de una consulta lenta a la agenda. Para comparar dos configuraciones, utiliza el mismo recorrido y observa cuándo deja de hablar el cliente, cuándo empieza la respuesta y cuándo existe el resultado. Así no atribuyes al modelo una espera causada por otra herramienta.
Entrada, salida, país, proveedor y concurrencia.
Convierte la voz y distingue pausas, ruido e interrupciones.
Objetivo, datos, tono, límites y condiciones.
Interpreta el contexto y decide la siguiente acción.
Convierte la respuesta en audio comprensible.
Guarda resultado, transcripción y eventos necesarios.
Herramientas e integraciones
Para reservar una cita, la IA necesita consultar disponibilidad, proponer opciones, confirmar la selección y escribir el resultado. Para registrar una consulta, necesita validar campos y evitar duplicados. Cada acción debería devolver una respuesta clara de éxito o fallo.
Una integración no se considera fiable solo porque aparezca en un catálogo. Hay que comprobar permisos, zonas horarias, campos obligatorios, reintentos y qué escucha el cliente cuando la herramienta tarda o falla.
Leer, crear, modificar y cancelar sin dobles reservas.
Buscar y actualizar sin mezclar personas o registros.
Enviar confirmaciones con consentimiento y contenido correcto.
Elegir destino y conservar el contexto útil.
Instrucciones y estado
Un buen sistema no necesita memorizar una conversación exacta. Necesita saber el resultado permitido, los datos imprescindibles, las preguntas que puede responder, las condiciones para usar una herramienta y la salida cuando algo no encaja.
El estado de la conversación evita volver a preguntar un dato o confirmar una acción que no se completó. Las pruebas deben incluir cambios de idea, interrupciones y correcciones porque esos momentos revelan si el contexto se conserva de verdad.
El estado debe actualizarse cuando el cliente corrige un dato. Si primero pide una cita en la sede norte y después elige la sede sur, cambia también la agenda consultada y cualquier regla asociada a esa sede. Repetir verbalmente la corrección sin cambiar los datos enviados a la herramienta deja una conversación aparentemente correcta y una reserva equivocada.
Después del lanzamiento
Los horarios, precios, equipos y procesos cambian. Alguien debe revisar transcripciones, fallos de herramientas, transferencias, costes y preguntas no resueltas. La ausencia de mantenimiento convierte una configuración correcta en una fuente de errores.
Empieza con un alcance pequeño, conserva una muestra de llamadas y define métricas antes de ampliar. El objetivo no es automatizar el mayor porcentaje posible, sino resolver de forma segura el trabajo que se ha decidido automatizar.
Decisión práctica
Imagina que alguien pide una cita para el martes por la tarde. El agente identifica el servicio y la sede, consulta huecos y ofrece una hora. La persona cambia al miércoles. El agente debe actualizar la búsqueda; no sirve reutilizar la primera respuesta de disponibilidad.
Tras elegir las 17:00, la agenda tarda en contestar. El agente puede explicar que está comprobando la reserva, pero solo debe confirmarla al recibir el identificador del evento correcto. Si el tiempo se agota, el siguiente paso es una solicitud pendiente o una transferencia, según el proceso del negocio.
Para localizar un fallo, separa lo que se oyó, la intención que se entendió, la consulta enviada y el resultado guardado. Un nombre mal reconocido apunta a una capa distinta de una cita creada dos veces. Cambiar la voz no arregla un reintento que duplica eventos.
Cuando algo sale mal
Empieza por el primer punto donde el resultado deja de coincidir con la petición. No cambies a la vez la voz, las instrucciones y la integración: después será difícil saber qué resolvió el problema. Conserva un caso de prueba con datos ficticios y repítelo cuando ajustes la capa responsable.
Estos síntomas orientan la revisión, pero no identifican una causa de forma automática. Una llamada cortada también puede deberse a la red o al operador. Contrasta la conversación con los eventos de telefonía y las respuestas de las herramientas antes de modificar el flujo.
Compara lo que se dijo con el dato reconocido. Si la entrada ya es incorrecta, revisa la comprensión del audio y la confirmación del nombre; cambiar un campo del CRM no corrige lo que se oyó.
Comprueba si el dato estaba disponible y se conservó tras la interrupción. Puede faltar una regla para reutilizarlo o haberse perdido el estado al pasar a otro agente.
Revisa la petición enviada, la respuesta de la agenda y el identificador de reserva. Una frase de confirmación o una transcripción no prueba que se haya creado el evento.
Busca envíos repetidos o reintentos después de una espera. La integración necesita reconocer una operación ya ejecutada antes de volver a crearla.
Resultado verificable
Pedir una acción, recibir una respuesta y confirmar el resultado son tres momentos distintos. Una herramienta puede aceptar una solicitud para procesarla después; también puede completar una reserva y perderse la respuesta por un problema de conexión. En ambos casos, el agente necesita saber qué estado puede comunicar al cliente.
Si una consulta de disponibilidad falla, repetirla puede ser razonable porque solo se está leyendo información. Si falla la respuesta al crear una cita, repetir la creación sin comprobar el resultado puede producir un duplicado. El sistema de destino debe permitir buscar la operación o reconocer una referencia única para ese intento. Esa protección suele denominarse idempotencia: repetir la misma petición no debería crear otra reserva.
La salida al cliente debe corresponder al estado comprobado. Puedes decir que se ha recibido una solicitud cuando está guardada para revisión; puedes confirmar una cita cuando existe el evento correcto. Si no se conoce el resultado, explica que queda pendiente y deriva el caso al equipo según las reglas del negocio. Esa distinción evita que una espera técnica se convierta en una promesa incorrecta.
Guarda una referencia de la llamada y de la operación, el resultado esperado y la respuesta recibida. Limita los datos personales al acceso y conservación que haya definido el negocio.
Resume servicio, sede, fecha y estado de la petición. Comunica el siguiente paso acordado sin presentar una solicitud pendiente como una cita cerrada.
Fuentes primarias
Los datos comerciales y técnicos pueden cambiar. Comprueba siempre las condiciones vigentes en el destino.
Preguntas frecuentes
Depende de la arquitectura. Muchas cadenas convierten voz a texto antes del modelo; otras usan modelos de voz a voz. El resultado debe probarse como sistema completo.
El flujo debe reconocer el fallo, no confirmar una acción inexistente y ofrecer una alternativa o transferencia.
Algunas plataformas permiten importar números o conectar telefonía propia. La disponibilidad por país y proveedor debe verificarse.