Cómo encaja la IA de voz en HubSpot, Salesforce, Zendesk, Zoho, Genesys, AWS Connect, SharePoint y stacks de API personalizados
La IA de voz se sitúa sobre tu stack existente, no en su lugar. Entra en tu entorno a través de tres planos. La telefonía llega mediante SIP trunking. Los datos de los clientes fluyen a través de conectores nativos o de API hacia tu CRM y tus herramientas de ticketing. La lógica personalizada se conecta mediante webhooks y llamadas a funciones. Los números se quedan donde están. Los contratos se quedan donde están. El agente se convierte en otro cliente autenticado dentro de los sistemas que ya pagas por mantener.
Esa distinción importa porque es la pregunta que los compradores están haciendo realmente. No «¿tenéis una integración con HubSpot?» sino «si pongo esto delante de mi cola de Genesys el martes, ¿qué se rompe el miércoles?». La versión honesta de esa conversación es técnica, y el resto de este artículo está escrito para la persona que tiene que dar la respuesta técnica en una revisión de compras. Iremos capa por capa a través de telefonía, CRM, herramientas de soporte, fuentes de conocimiento, calendario y la larga cola de servicios internos, con los modos de fallo y los detalles espinosos incluidos.
El anuncio de Salesforce de Agentforce Contact Center en Enterprise Connect 2026 hizo la pregunta arquitectónica aún más ruidosa. El planteamiento de Salesforce es que la voz pertenece de forma nativa dentro del CRM. Genesys, NICE, Five9 y Amazon Connect responden que la voz pertenece de forma nativa dentro del centro de contacto. Microsoft argumenta desde dentro de Teams. Cada proveedor con un punto de apoyo en el entorno del comprador ahora lucha por la llamada como el próximo sistema de registro.
Los proveedores de IA de voz aterrizan en medio de esa lucha, y los que ganan acuerdos no son los que tienen la demo más natural. Son aquellos cuya arquitectura sobrevive a una revisión seria por parte de un arquitecto de empresa al que no le encantan los nuevos proveedores. Las preguntas que surgen en esa revisión son las mismas cada vez. ¿Por dónde fluye físicamente el audio de la llamada? ¿Qué identidad hace la llamada a la API de Salesforce? ¿Qué tenant de Azure es propietario del indexador de SharePoint? Si el agente está caído, ¿cuál es la ruta de reserva? Si se actualiza nuestro SBC, ¿se rompe algo?
Un agente de voz que no puede responder a esas preguntas en lenguaje claro no está listo para producción. Las secciones a continuación están organizadas en torno a cómo un arquitecto de empresa recorrería realmente el stack.
La IA de voz se conecta a la telefonía empresarial a través de SIP trunking elástico, apareciendo la plataforma como un endpoint SIP con el que tu operador o centro de contacto existente ya sabe hablar. Twilio, Telnyx, Vonage, Avaya, Genesys, Five9 y Amazon Connect admiten todos BYOC sobre SIP, que es lo que hace que la promesa de no portar y no sustituir sea real y no marketing.
Los mecanismos son lo bastante breves como para caber en un párrafo. Configuras el trunk existente para entregar el tráfico entrante al servidor SIP de la plataforma de voz sobre TLS con SRTP. Importas tus números de teléfono en formato E.164. Asignas un agente entrante o saliente a cada número. Desde el lado del operador, la llamada se está enrutando a un endpoint SIP, algo que ha hecho durante quince años. Desde el lado de tu equipo financiero, la factura del operador no cambia.
Hay dos detalles que importan y que los proveedores a menudo pasan por alto. Primero, la autenticación. La mayoría de los SIP trunks empresariales esperan o bien allowlisting de IP o bien registro basado en credenciales, y el servidor SIP de la plataforma de voz puede no anunciar una IP estática. Eso puede surgir como una pregunta que bloquee la compra si tu equipo de seguridad requiere rangos de IP fijos, así que confirma la disponibilidad de IP estática para el tráfico de EE. UU. antes de asumir que el trunk pasará la revisión. Segundo, los mecanismos de transferencia. Con SIP elástico, la transferencia de llamadas nativa a través de SIP REFER funciona como se espera. Con dial-to-SIP-URI (la ruta de reserva para PBX más antiguos), la plataforma de voz nunca ve un REFER, así que la transferencia tiene que implementarse como una función personalizada en el lado de tu operador. Esto hace tropezar a los equipos que esperan paridad entre las dos rutas.
Para Genesys Cloud y Amazon Connect en concreto, el patrón de despliegue más limpio es a nivel de cola en lugar de a nivel de tenant. Las llamadas llegan a tus colas existentes, se clasifican según tus reglas existentes, y solo las colas que designes se enrutan hacia el agente de IA. La transferencia asistida de vuelta a una cola humana utiliza la misma infraestructura de enrutamiento a la inversa. Este modelo por fases te permite poner IA delante del desbordamiento, de las horas fuera de servicio o del triaje de nivel 1 sin exponer el resto del centro de contacto a una nueva superficie de fallo. La mayoría de los despliegues empresariales empiezan ahí, demuestran la contención en una sola cola durante dos meses y se expanden desde una posición de evidencia en lugar de una promesa del proveedor.
El rincón de cumplimiento de esta conversación es la atestación STIR/SHAKEN para las llamadas salientes. Si estás usando BYOC y originando salientes desde un número de EE. UU., la atestación es responsabilidad de tu operador, no de la plataforma de voz. Esa es una pregunta que vale la pena hacer a tu representante de operador antes de firmar nada, porque la atestación de nivel A afecta materialmente a las tasas de respuesta en salientes en frío, y una configuración incorrecta puede arruinar una campaña que pasaste un mes ajustando.
La integración de IA de voz con HubSpot funciona a través de una app nativa del Marketplace que añade una acción de flujo de trabajo Make a Phone Call. Cualquier disparador de flujo de trabajo que ya uses (envío de formulario, cambio de etapa de negocio, actualización de propiedad de ciclo de vida, inscripción en lista) puede lanzar una llamada saliente, pausar el flujo de trabajo hasta que termine la conversación, y ramificar el siguiente paso según el resultado de la llamada.
El patrón que sobrevive en producción es el contacto basado en eventos con resultados estructurados. El envío de un formulario de demo inscribe al contacto, el flujo de trabajo marca en segundos, el agente cualifica presupuesto y plazos mediante conversación natural, y el resultado se escribe de vuelta como propiedades de contacto antes de que ninguna persona mire el registro. Después de la llamada, puedes ramificar el flujo de trabajo según el éxito de la llamada, el sentimiento o cualquier variable de resultado personalizada que hayas definido. Ventas ve un lead puntuado con una transcripción. Marketing ve pipeline atribuible. Operaciones ve cero transferencias manuales.
Dos notas de implementación ahorran semanas de depuración. La acción de HubSpot pausa el flujo de trabajo hasta que la llamada se completa, lo cual está bien para casos de uso de bajo volumen pero es problemático si disparas miles de flujos de trabajo en una ventana ajustada, porque pausar un flujo de trabajo consume cuota de operaciones de HubSpot. Para salientes de alto volumen, el patrón más limpio es disparar los flujos de trabajo de HubSpot hacia un webhook que encole las llamadas en el endpoint de llamadas por lotes de la plataforma de voz, en lugar de llamar de una en una desde dentro de HubSpot. Obtienes el mismo resultado con un coste predecible y cero riesgo de alcanzar los límites de flujos de trabajo durante un empuje de campaña.
Segundo, vigila el mapeo de propiedades. La integración por defecto escribe el resumen y el análisis de la llamada en la línea de tiempo de actividad, lo cual está bien para la revisión humana pero es invisible para la mayoría de las herramientas de reporting. Si quieres que los resultados de las llamadas impulsen automatización posterior (enrutamiento de leads, puntuación de MQL, segmentación de listas), mapea las extracciones estructuradas del agente a propiedades de contacto dedicadas desde el primer día. Los equipos que ejecutan este patrón a escala normalmente lo combinan con llamadas en frío con IA para prospección saliente y cualificación de leads para demanda entrante. La guía paso a paso de configuración está en la página de integración de HubSpot.
La integración de IA de voz con Salesforce utiliza llamadas a la API autenticadas con OAuth que el agente hace en mitad de la conversación. La búsqueda de leads, las actualizaciones de contactos, los cambios de etapa de oportunidad y la creación de casos ocurren durante la llamada en lugar de como una sincronización posterior a la llamada con retraso.
El tiempo real importa más de lo que la gente asume, y la mayoría de las «integraciones con Salesforce» pasan por alto esta distinción. Un conector que publica una transcripción en un registro de actividad una hora después de que termine la llamada es suficiente para el archivo de cumplimiento pero inútil para la personalización. El agente que extrae el contexto de la cuenta en el momento en que quien llama dice su nombre mantiene una conversación distinta a la de uno que trabaja desde un guion genérico. Puede confirmar la fecha de renovación, referirse a un caso abierto o saltarse las preguntas de cualificación que el lead ya respondió el trimestre pasado. Esa es la diferencia entre un chatbot que resulta estar al teléfono y un agente de voz que representa genuinamente a tu negocio.
La pregunta arquitectónica a resolver el primer día es qué identidad de Salesforce usa el agente. Existen tres patrones en la práctica. Una Connected App con un usuario de cuenta de servicio es el más común, con alcance limitado a los objetos que el agente toca realmente. Un flujo de identidad externa que autentica a quien llama y luego el agente actúa en su nombre es más elegante para el autoservicio, pero más difícil de conectar. Un patrón de eventos de plataforma, donde el agente emite eventos y los flujos de Salesforce gestionan las escrituras, es la opción correcta para empresas con una separación estricta de responsabilidades entre el runtime de voz y el CRM.
La misma arquitectura gestiona los salientes a escala. Los casos de Service Cloud disparan llamadas de estado. Las oportunidades de Sales Cloud disparan contacto de renovación. Los journeys de Marketing Cloud entregan los puntos de contacto de voz al agente y se reanudan según el resultado. Para los equipos de RevOps que ya ejecutan disparadores de Apex y flujos, la voz se convierte en otro canal de ejecución dentro de la superficie de automatización que existe, en lugar de un sistema paralelo que necesita su propio modelo de datos.
El factor Agentforce no se puede ignorar en las conversaciones de compra de 2026. Salesforce está posicionando la voz nativa como una razón para consolidar. Las plataformas de IA de voz especializadas responden con profundidad en la gestión de turnos, latencia, flexibilidad de telefonía y la capacidad de traer tu propio modelo. El planteamiento honesto para un comprador es este: si hoy ejecutas un centro de contacto solo con Salesforce en Service Cloud Voice, Agentforce reducirá tu superficie de integración, y eso tiene un valor real. Si tu stack abarca Salesforce, Zendesk, Zoho, apps personalizadas y un centro de contacto que tu CRM no posee, una plataforma de voz agnóstica al CRM encaja estructuralmente mejor porque no te empuja hacia la visión del mundo de un único proveedor.
Una integración de IA de voz con Zendesk funciona como una capa de contención delante de la creación de tickets, no como otro canal que se suma al volumen de tickets. El agente responde la llamada, intenta la resolución contra las fuentes de conocimiento conectadas, y solo abre un ticket de Zendesk si el escalado es genuinamente necesario, con la transcripción completa y la intención identificada precargadas.
Los cálculos sobre la automatización del soporte se malinterpretan a menudo. A los proveedores les encanta citar porcentajes de contención, pero la contención de forma aislada no significa nada. Una tasa de contención del 90 % donde las llamadas contenidas eran clientes que colgaron frustrados es peor que una tasa del 60 % donde cada llamada contenida terminó en un problema resuelto. Las métricas que realmente correlacionan con la calidad del soporte son la resolución en la primera llamada de las llamadas contenidas, la tasa de llamadas repetidas en siete días, y las puntuaciones de CSAT del grupo contenido frente al grupo gestionado por humanos. Los estándares del sector para una resolución saludable en la primera llamada rondan del 70 al 85 %, y un agente de voz bien ajustado en un dominio estrecho puede situarse en ese rango en unas pocas semanas de iteración.
Los mecanismos de integración con Zendesk siguen un patrón familiar. El agente se autentica con credenciales de token de API, ejecuta búsquedas de tickets por número de teléfono o email, intenta la resolución con la capa de conocimiento, y crea un ticket solo cuando la conversación termina con una solicitud sin resolver o un escalado deliberado. Cuando ocurre el escalado, la conversación en vivo se entrega a una cola humana con la transcripción ya adjunta, lo que significa que quien llama no se repite y los agentes de nivel 2 empiezan con contexto completo.
Vale la pena tomar prestados dos patrones de los equipos que han desplegado esto bien. Primero, establece el umbral de escalado en dos o tres intentos de aclaración fallidos en lugar de uno. La mayoría de quienes llaman reformulan con éxito en el segundo intento, y una transferencia demasiado ansiosa destruye la contención sin ningún beneficio de calidad. Segundo, trata el primer mes del agente como una auditoría de la base de conocimiento, no como un producto terminado. Cada llamada en la que el agente escaló porque no conocía la respuesta es un artículo que falta en tu centro de ayuda, y el análisis posterior a la llamada saca a la luz esas lagunas de una forma que los responsables de soporte encuentran genuinamente útil para la planificación de contenido. El patrón más amplio está documentado en los despliegues de atención al cliente con IA.
La integración de IA de voz con Zoho CRM funciona a través de la API REST de Zoho con alcances de OAuth definidos por agente, actuando el agente como un cliente autenticado que crea leads, actualiza contactos, obtiene el contexto de la cuenta y dispara flujos de trabajo de Deluge durante la llamada.
La configuración se ajusta al ritmo en el que los administradores de Zoho ya trabajan. Genera un cliente de Zoho, delimita su alcance a los módulos que el agente necesita (Leads, Contacts, Deals, a veces Desk y Books), y configura los endpoints de llamadas a funciones dentro del flujo del agente. Quien llama pide concertar una demo: el agente crea el lead, programa a través de la capa de calendario, y escribe la marca de tiempo de la reunión en el registro del lead antes de despedirse.
Este patrón se gana su valor en los stacks multiproducto de Zoho donde los datos de la llamada necesitan aterrizar en un registro pero disparar acciones posteriores a través de CRM, Desk, Campaigns y Books. El agente dispara un único evento de finalización, las reglas de flujo de trabajo de Zoho lo despliegan hacia los módulos correctos, y el resto del stack se actualiza sin intervención manual. Hay una nota al pie sobre límites de tasa que vale la pena conocer de antemano. El nivel de API de Zoho en los planes de menor coste limita de forma agresiva, y un despliegue de voz de alto volumen alcanzará esos límites más rápido de lo que la mayoría de los equipos esperan. Planifica un nivel de CRM de pago con un margen de API mayor si vas a ejecutar cualquier cosa más allá de un pequeño piloto, y cachea los datos de referencia que el agente lee con frecuencia en lugar de llamar a Zoho en cada turno. La guía de implementación está en la página de integración de Zoho CRM.
La IA de voz lee de SharePoint, Azure y fuentes de conocimiento internas mediante recuperación en streaming contra contenido indexado, refrescado según un calendario de sincronización configurable. Apunta la base de conocimiento a una biblioteca de documentos de SharePoint, un contenedor de Azure Blob, una wiki interna o cualquier lista de URL, y el agente tiene acceso de recuperación en vivo durante las llamadas.
Para las organizaciones estandarizadas en Microsoft 365, esta es la integración que decide si un agente de voz puede representar de forma creíble a la empresa por teléfono. Los datos de entrenamiento estáticos se quedan obsoletos en semanas. Los guiones codificados a mano no pueden seguir el ritmo de los cambios de política, las actualizaciones de producto o las revisiones de precios. Un indexador que extrae del mismo sitio de SharePoint donde el equipo de operaciones publica significa que el agente en una llamada en vivo ahora mismo está referenciando el documento publicado esta mañana.
El modelo de permisos es lo que la mayoría de los equipos de seguridad quieren entender primero, y también es donde muchos proveedores de IA de voz esquivan el tema. La arquitectura defendible es sencilla. El indexador se autentica como una entidad de servicio en tu tenant de Azure AD. Le concedes acceso de lectura a las bibliotecas de documentos específicas que el agente necesita. El indexador lee, incrusta y almacena esos documentos en un índice vectorial que vive dentro de tu tenant o en un entorno controlado del proveedor según tus requisitos de residencia de datos. El agente recupera a través de ese índice en el momento de la llamada. Los documentos que la entidad de servicio no puede leer siguen siendo documentos que el agente no puede referenciar. No hay un sistema de control de acceso paralelo que mantener.
Vale la pena fijar dos preguntas arquitectónicas antes de firmar. ¿La generación de incrustaciones ocurre dentro de tu tenant o en el entorno del proveedor? Para la mayoría de las empresas eso determina si el contenido de SharePoint sale alguna vez del límite de confianza de Microsoft. Y ¿está el índice cifrado en reposo con claves gestionadas por el cliente o con claves gestionadas por el proveedor? Las claves gestionadas por el cliente son cada vez más un requisito básico para las industrias reguladas y vale la pena preguntar por ellas en la revisión de seguridad en lugar de descubrirlo más tarde.
La IA de voz se sincroniza con Google Calendar a través de la Calendar API, invocada por el agente dentro de la conversación en lugar de después de ella. Las comprobaciones de disponibilidad, la creación de eventos y los mensajes de confirmación ocurren dentro de la misma llamada de 90 segundos, que es lo que separa a un agente que concierta de uno que toma una solicitud de devolución de llamada.
La capacidad suena simple y es genuinamente difícil de implementar bien. La parte difícil no es la llamada a la API. Es la lógica de conversación en torno a la llamada a la API. Las citas reales tienen casos límite. Quien llama quiere el martes por la tarde y tú solo tienes el miércoles por la mañana. Quien llama pide una franja de 30 minutos pero el tipo de cita requiere 60. Quien llama está en una zona horaria distinta a la del calendario. Quien llama quiere reprogramar una cita existente pero no recuerda la hora original. Un agente de voz que gestiona esos casos con elegancia se siente humano. Uno que no lo hace se siente como un IVR con una mejor voz.
Pine Park Health desplegó este patrón en su red de proveedores de cuidado de mayores y registró un aumento del 38 % en el NPS de programación mientras llenaba franjas de proveedores que habían estado abiertas. La razón estructural es simple y el comportamiento subyacente está bien documentado en la investigación sanitaria. El buzón de voz y la devolución de llamada pierden citas ante el proveedor que respondió primero en vivo. La concertación en llamada cierra la cita en la misma conversación que la abrió, antes de que quien llama tenga la oportunidad de coger el teléfono de nuevo. El flujo completo de concertación está documentado en la página de la función concertar citas.
La IA de voz se conecta a APIs personalizadas y servicios internos a través de tres mecanismos complementarios: llamadas a funciones para lecturas y escrituras síncronas durante la llamada, webhooks para la entrega asíncrona de eventos después de la llamada, y MCP (Model Context Protocol) para el acceso estandarizado a herramientas a través de muchas integraciones. Cualquier cosa accesible por HTTP se convierte en parte de la superficie de la conversación.
La llamada a funciones es el momento dentro de la llamada. El agente necesita buscar un pedido, verificar una cuenta, ejecutar una comprobación de saldo o disparar un reembolso, así que hace una llamada HTTP en tiempo real a tu endpoint, analiza la respuesta y sigue hablando. La pregunta de configuración que hunde a los equipos es la gestión de timeouts. El agente no puede esperar seis segundos a que tu endpoint responda, porque en ese punto quien llama ya ha empezado a decir «¿hola?». La mejor práctica es un timeout de cinco segundos combinado con un mensaje de reserva que el agente usa si el endpoint no responde, más un reintento asíncrono en el backend para que la acción ocurra igualmente aunque la respuesta dentro de la llamada haya sido una de reserva.
Los webhooks son todo lo que necesita ocurrir después de que el agente deje de hablar. Cuando una llamada empieza, termina o finaliza el análisis, la plataforma publica un payload JSON (ID de llamada, transcripción, sentimiento, extracciones estructuradas, variables personalizadas) en tu endpoint, reintenta en caso de fallo hasta tres veces, y firma la solicitud con una cabecera x-retell-signature para que puedas verificar el origen. Dos detalles operativos: el presupuesto de reintentos es pequeño, así que tu endpoint necesita confirmar con un 2xx rápido y procesar de forma asíncrona, y necesitas una clave de deduplicación en tu manejador porque los reintentos sí ocurren y escribir la misma llamada dos veces en tu almacén es el tipo de problema que sale a la luz un trimestre después en una auditoría financiera.
MCP es la capa que más importa para los equipos de ingeniería que gestionan una superficie de integración creciente. En lugar de escribir lógica de integración personalizada para cada nueva herramienta, el agente actúa como un cliente universal y cualquier servidor compatible con MCP expone sus herramientas sobre un protocolo estándar. El problema N×M de conectar muchos agentes a muchas herramientas se colapsa en un problema N+M de construir servidores compatibles con MCP una sola vez. Para plataformas internas (bases de datos propietarias, verificación de identidad personalizada, sistemas de facturación), MCP es el modelo de integración que escala sin reconstruir código de pegamento cada trimestre, y es el patrón en el que más vale la pena invertir si tu hoja de ruta implica más de dos o tres sistemas internos que el agente necesitará tocar.
Nada en el stack existente se sustituye. Los contratos con el operador se quedan, porque el SIP trunking es agnóstico al proveedor. Los CRM se quedan, porque la integración está basada en API. Las fuentes de conocimiento se quedan en SharePoint, Confluence o donde vivan actualmente, porque la recuperación lee in situ. Los números de teléfono se quedan en el operador, porque se importan, no se portan.
Lo que cambia es lo que le pasa a una llamada entre el momento en que llega y el momento en que se escribe un registro. Las llamadas que antes llegaban al buzón de voz, a un menú IVR o a una cola con cinco minutos de espera se responden de inmediato. Los registros que antes se creaban una hora después de la llamada se crean durante ella. Las transcripciones que vivían en un archivo de audio ahora fluyen como datos estructurados hacia los sistemas que tu equipo ya abre cada mañana. La integración es aditiva. El diagrama de arquitectura no necesita redibujarse, solo anotarse.
Las cifras que la mayoría de los prospectos piden, recogidas en un solo lugar para que sea fácil incorporarlas a una revisión de seguridad o a un cuestionario de proveedores:
Pruebas a nivel de cliente que vale la pena citar en las discusiones sobre el stack:
La revisión de cumplimiento en la mayoría de las empresas sigue una secuencia predecible, e ir preparado es la diferencia entre una revisión de cuatro semanas y una de cuatro meses. Tres cajones cubren la mayor parte.
La residencia de datos va primero. ¿Dónde viven físicamente las grabaciones de llamadas, las transcripciones y la PII? ¿Se pueden excluir las grabaciones por completo para cargas de trabajo sensibles? ¿Se pueden mantener los datos en la región para operaciones de la UE o APAC? El despliegue on-premise es la respuesta cuando la residencia es innegociable, con el mismo runtime del agente ejecutándose dentro de tu VPC y los datos de la llamada quedándose dentro de tu perímetro.
El cifrado es el segundo cajón y es en su mayoría un requisito básico. SRTP para los medios en tránsito, cifrado en reposo para los datos almacenados, TLS para la señalización SIP. La pregunta de seguimiento es si puedes usar claves gestionadas por el cliente para el contenido almacenado. Para la mayoría de las industrias reguladas, eso ha pasado de un extra deseable a un requisito, así que vale la pena preguntar explícitamente en lugar de asumir.
Los registros de auditoría cierran el círculo. Cada llamada genera un registro de eventos estructurado con ID de llamada, ID de agente, marcas de tiempo y resultados, que además sirve como los datos que alimentan tus paneles de análisis posterior a la llamada. Para HIPAA, el BAA es de autoservicio a través del panel, lo que colapsa el típico ciclo de compras de BAA de cuatro a seis semanas en el mismo día hábil. Para SOC 2, los informes Type II están disponibles bajo NDA estándar. Para GDPR, la redacción de PII por agente y las ventanas de retención definidas por el usuario gestionan la postura del derecho al olvido. Para cargas de trabajo reguladas, pregunta por la atestación STIR/SHAKEN de nivel A si las llamadas salientes importan, y confirma que tu SBC impone el cifrado y las políticas de cabeceras de extremo a extremo en la ruta SIP.
Un primer paso útil es una sesión de mapeo de integración de 30 minutos. Enumera cada sistema del que el agente necesitará leer o en el que necesitará escribir. Etiqueta cada uno como telefonía, CRM, ticketing, conocimiento, calendario o personalizado. Empareja cada uno con el mecanismo correcto (SIP, app nativa, API, RAG, llamada a función, webhook o MCP). La mayoría de los stacks empresariales se resuelven limpiamente en esos cajones en una hora. Los que no lo hacen normalmente sacan a la luz un único sistema heredado que necesita un adaptador personalizado, y nombrar eso pronto es mejor que descubrirlo durante las pruebas de aceptación del usuario.
Desde el mapeo, la ruta más rápida hacia un piloto funcional es conectar un flujo entrante (normalmente enrutamiento de soporte o concertación de citas) a través del operador y el CRM existentes, y luego expandirse una vez que el patrón de integración esté probado. Retell AI ofrece 10 $ en créditos gratuitos y 20 llamadas simultáneas gratuitas en cada cuenta, lo cual es suficiente para validar la arquitectura contra llamadas en vivo antes de que empiece cualquier conversación de compra. Empieza en retellai.com.
Sí. Cualquier operador que admita SIP trunking elástico, incluidos Twilio, Telnyx, Vonage, Amazon Connect, Genesys Cloud, Avaya y Five9, puede enrutar llamadas hacia el agente mediante la configuración de SIP URI. Los números de teléfono se quedan en el operador y se importan a la plataforma del agente en formato E.164. La pregunta de seguimiento que vale la pena hacer pronto a tu equipo de seguridad es si requiere allowlisting de IP estática para el tráfico SIP, porque eso restringe qué plataformas califican desde el principio.
Ambos. La app del Marketplace añade una acción de flujo de trabajo Make a Phone Call para salientes disparados por eventos de HubSpot, y escribe resúmenes de llamadas, transcripciones y análisis estructurado en la línea de tiempo de actividad del contacto independientemente de la dirección en que se originó la llamada. Para salientes de alto volumen, el patrón más limpio es disparar los flujos de trabajo de HubSpot hacia un webhook que encole en un endpoint de llamadas por lotes en lugar de llamar de una en una dentro de HubSpot.
Mediante OAuth 2.0 estándar, dependiendo el patrón específico de tu postura de seguridad. Una Connected App con un usuario de cuenta de servicio es el punto de partida más común. Para empresas que requieren separación de responsabilidades entre el runtime de voz y el CRM, un patrón de escritura basado en eventos de plataforma o webhooks es más limpio porque los flujos de Salesforce gestionan las escrituras dentro de tu tenant.
Las llamadas a funciones tienen umbrales de timeout configurables, y la respuesta correcta es un timeout de cinco segundos con un mensaje de reserva que el agente usa si el endpoint no responde a tiempo. La conversación continúa sin romperse. El agente reconoce el retraso y o bien reintenta o bien transfiere la llamada a un humano con contexto completo. En el backend, encola la solicitud original para un reintento asíncrono para que la acción ocurra igualmente aunque la experiencia dentro de la llamada haya usado una de reserva.
Sí, pero la respuesta exacta depende de si el indexador se ejecuta dentro de tu tenant de Azure AD o en el entorno del proveedor. La arquitectura defendible tiene el indexador autenticado como una entidad de servicio en tu tenant con acceso de lectura delimitado a las bibliotecas de documentos específicas que el agente necesita. Los documentos que la entidad de servicio no puede leer siguen siendo invisibles para el agente. Si las incrustaciones salen alguna vez de tu tenant es la pregunta de seguridad que vale la pena hacer explícitamente.
Sí. El agente de voz se sitúa detrás de la capa de enrutamiento, no por encima de ella. Las llamadas llegan a las colas existentes, se clasifican según las reglas actuales, y solo las colas que designes se enrutan hacia el agente de IA. La transferencia asistida de vuelta a una cola humana utiliza la misma infraestructura de enrutamiento a la inversa. Este enfoque por fases es también cómo la mayoría de los despliegues exitosos entran realmente en producción, con una cola cada vez en lugar de todo el centro de contacto.
Los webhooks empujan eventos del ciclo de vida de la llamada desde la plataforma hacia tu endpoint en momentos fijos (llamada iniciada, llamada terminada, llamada analizada). MCP permite al agente extraer de tus herramientas durante la llamada como un cliente estandarizado. Los webhooks tratan de decir a los sistemas externos qué ha pasado. MCP trata de dar al agente acceso en vivo a las herramientas mientras la conversación sigue en curso.
Para HubSpot, la app del Marketplace es totalmente sin código. Para Salesforce, Zoho, Zendesk y plataformas similares, la configuración de las llamadas a funciones es una tarea del panel una vez que las credenciales de API están listas. La mayoría de los equipos llegan a una integración funcional el mismo día. Para una personalización más profunda sin escribir código, la integración con Make y la integración con n8n cubren la mayoría de las necesidades de orquestación.
El despliegue on-premise está disponible para equipos empresariales con requisitos estrictos de residencia o soberanía de datos. El mismo runtime del agente se ejecuta dentro de tu VPC, con los datos de la llamada, las transcripciones y las grabaciones quedándose dentro de tu perímetro y tus sistemas existentes de identidad y gestión de claves manejando el acceso.
No. La capa de integración es independiente del modelo de lenguaje subyacente. Traer tu propio LLM está admitido en las familias GPT-4o, GPT-4.1, Claude y Gemini. Cambiar de modelo no requiere reconfigurar las conexiones de telefonía, CRM o conocimiento, lo cual importa porque los modelos están mejorando rápido y quedar atado a uno es un lastre en un horizonte de varios años.
Descubre cuánto podría ahorrar tu empresa al pasar a agentes de voz impulsados por IA.
Total Human Agent Cost
AI Agent Cost
Estimated Savings
Un número de teléfono de demostración de Retell Clinic Office
Start building smarter conversations today.
.avif)
.avif)
