Cómo mantener actualizada la base de conocimiento de una IA de voz cuando tu fuente de verdad vive en SharePoint, Azure o documentos privados
Sí, y la arquitectura es sencilla una vez que dejas de intentar que Copilot Studio lo haga. Replicas los documentos autorizados de SharePoint, OneDrive o Azure Blob en un índice vectorial que el agente posee, y luego dejas que los webhooks de Microsoft Graph y las notificaciones de Event Grid impulsen las actualizaciones incrementales. Las ediciones en la fuente se propagan al agente en cuestión de minutos de un solo dígito. Sin nuevas cargas.
La mayoría de los equipos se topan con este problema después de haber probado ya los caminos obvios. El conector de SharePoint de Copilot Studio sigue sin actualizarse automáticamente cuando los archivos cambian, una limitación que Microsoft confirmó en julio de 2025 y que no se ha corregido en el momento de escribir esto. Azure AI Search puede acceder a SharePoint mediante un indexador, pero el indexador no puede situarse detrás del Acceso Condicional, solo tiene soporte básico de ACL en versión preliminar y requiere que tú mismo construyas la capa del agente. El patrón que describe esta guía utiliza Retell AI como capa de voz porque su API de base de conocimiento acepta envíos autenticados desde tu propio worker de sincronización, lo que esquiva todas las limitaciones que impone el camino de primera parte de Microsoft.
Un agente de voz que responde a partir de una réplica curada de tu corpus privado, con ediciones que se propagan de extremo a extremo en cinco a quince minutos y una pasada de reconciliación diaria que captura cualquier cosa que el flujo de eventos pierda.
Al final, tu stack:
Antes de empezar, necesitarás:
Sites.Selected es preferible, Sites.Read.All es el respaldo más amplio)Porque las herramientas se diseñaron para un trabajo diferente. Copilot Studio se creó para resumir contenido para una persona que lee una pantalla, no para alimentar a un agente de voz que tiene menos de un segundo para componer una respuesta hablada. El indexador de SharePoint de Azure AI Search se creó para búsqueda empresarial, donde una ventana de actualización de cuatro a seis horas está bien. Ninguno de los dos productos se diseñó partiendo de la suposición de que una política de facturación editada a las 9 a. m. tenga que ser la respuesta que un llamante escucha a las 9:08 a. m.
Tres restricciones separan la voz del texto. La primera es el presupuesto de latencia. Una llamada de recuperación tiene que responder en menos de 100 milisegundos durante una conversación en vivo, así que el índice tiene que estar en la misma red que el agente, y los chunks tienen que ser lo bastante pequeños como para incrustarse en línea sin reventar la ventana de contexto del LLM. La segunda es la tolerancia a fallos. Cuando un chatbot devuelve el enlace equivocado, el usuario vuelve a hacer clic. Cuando un agente de voz cita una política retirada en una llamada de cumplimiento grabada, tienes un problema con registros de auditoría adjuntos. La tercera es la expectativa de frescura. Los equipos de ventas ajustan los precios los martes. Los equipos de soporte publican actualizaciones de política después de la revisión de un incidente el viernes. El agente que cita la cifra de la semana pasada es peor que no tener agente.
Por eso la arquitectura separa la fuente de verdad de la capa de recuperación. SharePoint se mantiene como canónico. El índice vectorial es un artefacto derivado que la pipeline de sincronización mantiene actualizado. Los modos de fallo se vuelven observables en lugar de silenciosos.
Elige por dónde se redacta el documento, no por dónde es más fácil de conectar. Cada fuente señala algo diferente sobre cómo se mantiene el contenido.
Las bibliotecas de documentos de SharePoint son la fuente principal correcta cuando la propiedad es colaborativa y el contenido evoluciona mediante revisión de comité. Los catálogos de servicios, los manuales de políticas, las wikis internas y los playbooks de ventas tienden a vivir aquí, con historial de versiones, comentarios y flujos de aprobación adjuntos. El coste es la dispersión de metadatos: un sitio típico contiene cuatro versiones de la misma política, dos borradores retirados y la carpeta de capturas de pantalla de alguien.
OneDrive rara vez es la fuente principal correcta para un agente de voz. El contenido ligado a la cuenta de una sola persona se va por la puerta cuando esa persona se marcha. Usa OneDrive solo como área de preparación donde los colaboradores individuales redactan borradores que se promueven a una biblioteca de SharePoint tras la revisión.
Los contenedores de Azure Blob son la fuente correcta cuando los documentos son producidos por sistemas anteriores. Los PDF generados por una pipeline de facturación, los contratos depositados por una herramienta CLM, los extractos de un trabajo de exportación y las transcripciones de un sistema de grabación pertenecen todos a Blob. El volumen es más alto, la frescura es más difícil de falsear y la nomenclatura de archivos sigue la convención que imponga el sistema productor, lo que hace que replicar y sincronizar sea más simple que la estructura de forma libre de SharePoint.
La mayoría de los equipos empresariales sincronizan ambos. SharePoint alimenta el lado de política y producto, Blob alimenta el lado operativo y generado por máquina, y la base de conocimiento del agente de voz fusiona ambos detrás de una única API de recuperación.
Registra una aplicación en Microsoft Entra ID, solicita permisos de aplicación y haz que un administrador del inquilino conceda el consentimiento.
Los permisos de aplicación se ejecutan bajo un service principal. El worker sigue funcionando durante toda la noche sin un usuario con sesión iniciada, y el token es coherente entre llamadas. Los permisos delegados, por el contrario, vinculan el acceso a una cuenta de usuario real y fuerzan una reautenticación cada 75 minutos aproximadamente, según las bibliotecas de seguridad que Microsoft usa ahora. Los permisos delegados tampoco pueden preservar las ACL a nivel de documento, como señala la propia documentación del indexador de SharePoint de Microsoft, lo que se convierte en un problema en el momento en que cumplimiento pregunta quién puede escuchar qué.
El alcance es donde la mayoría de los equipos comparten de más. Conceder Sites.Read.All permite a la app leer todos los sitios del inquilino. Es rápido en la configuración e indefendible en una auditoría. La alternativa más estricta es Sites.Selected, donde un administrador del inquilino preautoriza la app únicamente contra IDs de sitio específicos. El worker ve las bibliotecas que el agente necesita y nada más. Usa Sites.Selected desde el primer día. Aplicar el alcance a nivel de sitio de forma retroactiva requiere volver a consentir y, por lo general, una revisión de seguridad para la que no presupuestaste.
Para Azure Blob, asigna al mismo service principal el rol Storage Blob Data Reader sobre el contenedor específico. El alcance a nivel de contenedor gana al alcance a nivel de cuenta por la misma razón.
Combina dos primitivas de Microsoft Graph. Los webhooks te dicen cuándo ocurrió algo. Las consultas delta te dicen exactamente qué cambió.
Una suscripción de webhook es un POST a /subscriptions con una ruta de recurso que apunta a la unidad (por ejemplo, /sites/{site-id}/drive/root), un changeType de updated y una notificationUrl dirigida al endpoint HTTPS de tu worker. El cuerpo de la notificación es intencionadamente escaso. Lleva el ID del recurso y el tipo de cambio, nada más. Esto es por diseño. El worker usa la notificación como una señal para llamar al endpoint delta, donde vive la carga real.
La consulta delta es /sites/{site-id}/drive/root/delta. En la primera ejecución, sin token, obtienes una enumeración completa más un @odata.deltaLink opaco. Persiste ese enlace de forma literal. En cada ejecución posterior, reprodúcelo y Graph devuelve solo los elementos añadidos, modificados, renombrados o eliminados desde la última llamada. La guía de escaneo de Microsoft es explícita: webhooks más delta es el patrón recomendado para bibliotecas grandes, porque el sondeo puro te llevará a ser limitado por throttling, y los webhooks puros perderán datos si el endpoint es lento.
Dos piezas de folclore que vale la pena conocer. El mismo elemento puede aparecer más de una vez en una página delta, por diseño, porque Graph expande las jerarquías de carpetas y fusiona cambios concurrentes. Cuando aparecen duplicados, toma la última ocurrencia. Las suscripciones también caducan. Renueva al 75 % de la vida útil máxima, no en la fecha límite. Un trabajo de renovación que falla en silencio es la razón más común de que una sincronización que antes funcionaba empiece a derivar hacia contenido obsoleto, y te enteras cuando un cliente se queja.
Usa Event Grid para notificaciones en tiempo real y el change feed para la reconciliación por lotes. Resuelven problemas diferentes y la respuesta en producción es ejecutar ambos.
Event Grid envía eventos en el momento en que un blob se crea, reemplaza o elimina. Suscríbete a nivel de cuenta de almacenamiento, filtra por eventType para Microsoft.Storage.BlobCreated y Microsoft.Storage.BlobDeleted, y enruta a tu worker. Para Azure Data Lake Storage Gen2, añade un filtro sobre la llamada a la API FlushWithClose. Esto garantiza que el evento se dispare solo después de que el blob esté totalmente confirmado. Sáltate esto y procesarás cargas parciales, lo que produce errores de ingesta que parecen corrupción de archivos pero no lo son.
El change feed es el registro ordenado y duradero detrás de los eventos. Según la documentación de Microsoft, proporciona un registro de transacciones garantizado persistido como archivos Avro en $blobchangefeed/log/, escrito en pocos minutos tras cada cambio. Event Grid es de mejor esfuerzo y puede descartar notificaciones bajo carga. El change feed no puede. Ejecuta un trabajo diario que recorra el change feed y reconcilie contra el manifiesto de tu base de conocimiento, y tendrás una red de seguridad debajo del camino en tiempo real.
La combinación importa. Event Grid por sí solo es rápido pero con pérdidas. El change feed por sí solo es fiable pero lento. Juntos te dan frescura a escala de minutos en el camino feliz y consistencia completa por la mañana en el camino infeliz.
El worker descarga el archivo, lo normaliza y lo empuja a la API de la plataforma. Tres operaciones: crear, actualizar, eliminar. Renombrar colapsa en eliminar-más-crear.
La base de conocimiento de Retell AI acepta una larga lista de formatos de documento, incluidos PDF, DOCX, PPTX, XLSX, CSV, TSV, TXT, MD, HTML, RTF, ODT, EPUB, además de formatos de mensaje y varios tipos de imagen. Las restricciones que vale la pena conocer: 50 MB por archivo, 25 archivos por base y 1.000 filas por 50 columnas para las hojas de cálculo. Markdown se ingiere de la forma más limpia cuando controlas el formato de la fuente, razón por la cual los equipos a menudo ejecutan un paso de normalización que convierte documentos de Word redactados a Markdown antes de empujarlos.
Cuando un recuento de archivos supera los 25, divide las bases por dominio en lugar de por departamento. Un agente de facturación vinculado a "billing-policies-en", "service-catalog-2026" y "exception-cases" recupera limpiamente entre las tres porque la similitud de recuperación se calcula por chunk, no por base. Dividir por departamento, en cambio, crea los límites equivocados. La misma pregunta del llamante a menudo abarca dos departamentos, y el agente recuperará solo de uno de ellos.
Para el lado operativo, la idempotencia es lo que te salva cuando la misma notificación llega dos veces. Haz un hash del contenido de cada archivo y usa el hash como identificador del documento. Una notificación duplicada de un archivo sin cambios produce una operación nula en lugar de una entrada de índice duplicada.
Un extractor de texto puro perderá silenciosamente entre el 30 y el 40 por ciento del significado en un PowerPoint real o un libro de trabajo financiero. El agente entonces citará con confianza el 60 por ciento superviviente, incluidas las partes que ya no tienen sentido sin la tabla de la que provienen.
Los PowerPoints codifican información en el diseño de las diapositivas, las celdas de tablas, los avisos basados en imágenes y las notas del orador. Excel codifica significado en encabezados de columna que abarcan celdas fusionadas, en fórmulas que hacen referencia a otras pestañas y en el orden de las pestañas. La extracción de texto ingenua devuelve una cadena plana de palabras con la estructura despojada. Dos caminos sobreviven en producción.
El primero es el análisis consciente del diseño. Herramientas como Unstructured, Azure Document Intelligence o LlamaParse preservan las celdas de tabla y la estructura de las diapositivas como Markdown. Son más baratas por documento y predecibles en la salida. La desventaja es que manejan bien las tablas pero mal los gráficos.
El segundo, que ha ganado tracción desde mediados de 2025, es la extracción basada en imágenes. Renderiza cada diapositiva u hoja a una imagen y pásala por un LLM con capacidad de visión que devuelve Markdown. La salida recupera tablas, gráficos y avisos visuales que los extractores de texto pierden. El coste es más alto por documento y más lento, lo que hace de este el camino correcto para los documentos que realmente importan y el camino equivocado para la ingesta masiva de todo lo que hay en un sitio de SharePoint.
La regla de decisión que se sostiene: enruta los documentos de política por el camino barato consciente del diseño, enruta un pequeño conjunto de documentos visuales de alto valor (documentos de una página, presentaciones que los ejecutivos consultan, las tarifas que tu equipo de ventas usa de verdad) por el camino basado en imágenes. No intentes usar un solo enfoque para todo.
División recursiva de caracteres a 512 tokens con un 10 a 20 por ciento de solapamiento, tres chunks recuperados con similitud por defecto. Ajusta a partir de ahí según tus propios datos de llamadas.
Esta no es la respuesta popular. La respuesta popular es el chunking semántico, que suena más inteligente y da peores resultados en los benchmarks. El benchmark de Vecta publicado a principios de 2026 situó la división recursiva de 512 tokens en un 69 por ciento de precisión de recuperación y el chunking semántico en un 54 por ciento sobre el mismo corpus de 50 documentos. La investigación de NVIDIA aterriza en el mismo lugar: las consultas factoides (el tipo que recibe un agente de voz) rinden mejor entre 256 y 512 tokens, con un 10 a 20 por ciento de solapamiento para preservar el contexto de las oraciones a través de los límites.
La implicación práctica para la sincronización: cambiar el tamaño del chunk o el modelo de embedding invalida cada chunk existente en la base. Si la recuperación de repente rinde peor tras una pasada de ajuste, no parchees de forma incremental. Elimina la base, vuelve a ingerir la fuente y acepta el coste de reprocesamiento de unas pocas horas. La claridad que obtienes en cada respuesta futura vale la repetición.
El ajuste del umbral de recuperación ocurre después de que tengas datos de llamadas, no antes. Extrae de 50 a 100 llamadas del análisis posterior a la llamada, etiqueta los fallos de chunk equivocado y ajusta o bien el chunking de la fuente culpable o bien el umbral de similitud. La mayoría de los equipos sobreajustan al principio. Los ajustes por defecto son correctos para el 80 por ciento de los casos de uso.
Construye una prueba de bucle cerrado que rastree desde la edición hasta la respuesta hablada con una frase única y comprobable. Esta es la comprobación de cinco minutos más útil de toda la pipeline.
Elige un documento y edita un valor numérico único en él. "Descuento de nivel Premium: 12,5 %" se convierte en "Descuento de nivel Premium: 14,0 %". Guarda en SharePoint. En cinco a quince minutos (notificación de Graph, procesamiento delta, embedding), el cambio debería estar en vivo en el índice. Realiza una llamada de prueba haciendo la pregunta. Si el agente dice 14,0 %, el bucle funciona.
Cuando no funciona, el fallo se aísla limpiamente. ¿Recibió el worker el webhook? Revisa los logs de tu endpoint. ¿Devolvió la consulta delta el archivo? Revisa los logs del worker. ¿Tuvo éxito la carga? Revisa la respuesta de la API. ¿Llegó el chunk a la recuperación? Revisa el log de recuperación de la llamada en el análisis posterior a la llamada. Cada capa responde a una pregunta sí/no, y encuentras la capa rota en menos de diez minutos.
Ejecuta este bucle después de cada cambio significativo en la pipeline. Nueva estrategia de chunking, nuevo modelo de embedding, nueva fuente, nueva versión del worker de sincronización. Si el bucle se cierra, el cambio es seguro para desplegar. Si no, tienes una reproducción precisa del error.
Tres capas, aplicadas en este orden. Poda en la fuente. Restringe en el prompt. Observa en la llamada.
La poda en la fuente es la capa que la mayoría de los equipos se saltan y pagan más tarde. Cuando una política se retira, saca el archivo de la carpeta sincronizada. El patrón más limpio es una división de directorios synced/ y archive/ dentro de la misma biblioteca de SharePoint, con el worker vigilando solo synced/. Dos versiones indexadas de la misma política son una receta para contradicciones seguras, y no puedes depurar tu salida de documentos de fuente en conflicto.
Restringir en el prompt es la capa dos. Instruye al agente para que responda solo a partir del contexto recuperado de la base de conocimiento y para que escale cuando no haya ninguno disponible. Los benchmarks públicos muestran que el RAG fundamentado reduce las tasas de alucinación entre un 26 y un 43 por ciento frente a los LLM sin fundamentar. La mejora solo se sostiene cuando la recuperación saca a la superficie el documento correcto. Una respuesta de "no se ha encontrado respuesta, le transfiero" es casi siempre mejor que una equivocada con confianza, y una regla de escalado que se dispara con recuperación de baja similitud es uno de los ajustes de mayor apalancamiento en el agente.
Observar en la llamada es la capa tres y donde se cierra el bucle. Etiqueta cada fallo con una categoría: fuente ausente, chunk equivocado recuperado, contenido desactualizado, malinterpretación del modelo. Cada categoría tiene una solución diferente. Las fuentes ausentes entran en la siguiente pasada de ingesta. Los chunks equivocados suelen significar que dos documentos tratan temas similares con vocabulario diferente, lo que se soluciona con etiquetas de metadatos o dividiendo la fuente. El contenido desactualizado se remonta a un hueco de webhook que la reconciliación diaria debería haber capturado, y no lo hizo, lo cual es un error en tu trabajo de reconciliación.
Para un equipo que maneja 5.000 llamadas al mes de tres minutos cada una, el uso de la base de conocimiento es la partida más pequeña por un orden de magnitud.
Retell AI factura 0,07 $ por minuto por el coste base de la llamada, con el uso de la base de conocimiento a 0,005 $ por minuto por encima. Cada workspace incluye 10 bases de conocimiento gratuitas. Las bases adicionales cuestan 8 $ al mes. Para 15.000 minutos de tiempo de llamada mensual, el uso de la base de conocimiento añade 75 $. El coste base de la llamada es de 1.050 $. Compara ambos con el salario del SDR o de recepción que el agente está compensando y la aritmética se vuelve obvia. Los precios son coherentes tanto si usas una base como siete, y no hay tarifa de plataforma por encima.
Los costes ocultos están del lado de Microsoft, y suelen ser pequeños pero fáciles de configurar mal. Microsoft Graph cobra por llamada. Azure Event Grid cobra por millón de operaciones. Ambos son céntimos con un volumen de sincronización típico. La forma de convertir esto en una factura real es sondeando SharePoint cada 30 segundos en lugar de suscribirse a webhooks. Un error así ha disparado los cargos de consumo de Azure por un factor de cincuenta para al menos un equipo que he visto. Webhook más delta mantiene la factura plana independientemente de la frecuencia con la que cambie la fuente.
Estos se repiten con la frecuencia suficiente entre despliegues como para merecer una lista de comprobación.
Caducidad de la suscripción de webhook. Las suscripciones no se renuevan solas. Añade la caducidad a tus alertas y renueva al 75 por ciento de la vida útil máxima. La caducidad silenciosa es la causa de deriva más común.
Manejo de eliminaciones. La mayoría de los equipos publican una sincronización que maneja archivos creados y actualizados y olvida los eliminados. El agente entonces cita una política que se retiró hace tres meses. Cablea el tipo de cambio deleted como un caso de primera clase, no un caso límite.
Alcance de lectura a nivel de todo el inquilino. Conceder Sites.Read.All en la configuración es rápido. Seis meses después, cuando un auditor pregunta qué sitios puede ver el service principal de voz, "todos ellos" es la respuesta equivocada. Usa Sites.Selected desde el principio.
Documentos por encima del techo de 50 MB. Los manuales largos fallan la carga en silencio cuando superan el límite por archivo. Preprocesa los documentos de gran tamaño dividiéndolos por límites lógicos (capítulo, sección, línea de producto) y sube cada pieza como su propio documento. Mantén metadatos padre-hijo para que la recuperación pueda unirlos de nuevo si es necesario.
Deriva entre bases de conocimiento de staging y de producción. Los equipos construyen una pipeline de sincronización contra una base de staging, copian la configuración del agente a producción y olvidan que el agente de producción sigue apuntando a los archivos subidos manualmente del trimestre pasado. Haz explícito el ID de la base de conocimiento en tu configuración de despliegue y verifícalo tras cada lanzamiento.
Sí. La arquitectura es autenticación por service principal mediante Microsoft Entra ID, archivos extraídos por un canal de Graph autenticado y cargas empujadas a la API de la base de conocimiento por HTTPS. Los documentos de origen se mantienen en SharePoint con sus ACL existentes. La base de conocimiento contiene una copia indexada usada solo para la recuperación durante las llamadas, y puedes limitar el service principal a un único sitio si cumplimiento lo requiere.
De cinco a quince minutos de extremo a extremo en el camino feliz. El desglose: entrega del webhook de Graph en pocos minutos, consulta delta y descarga en menos de un minuto, análisis y embedding en uno a tres minutos según el tamaño del documento. Una vez indexado, la recuperación añade menos de 100 milisegundos durante la propia llamada, así que los llamantes no perciben una pausa.
Un trabajo de reconciliación diaria reproduce la consulta delta y compara los resultados contra el manifiesto de la base de conocimiento, capturando cualquier cosa que Event Grid o Graph se hayan perdido. La combinación de webhooks en tiempo real y un barrido delta diario es el patrón estándar, recomendado en la propia documentación de ingeniería de Microsoft precisamente porque las notificaciones son de mejor esfuerzo.
Sí. El mismo patrón de worker se aplica a Google Drive (mediante la Drive Activity API), Amazon S3 (mediante S3 Event Notifications), Confluence, Notion y cualquier fuente que emita eventos de cambio. La API de la base de conocimiento es agnóstica a la fuente. La única pieza que cambia es el código de autenticación y de escucha de eventos.
El conector de SharePoint de Copilot Studio no se actualiza automáticamente cuando los archivos cambian, una limitación que Microsoft confirmó a mediados de 2025 y que no ha publicado una corrección en el momento de escribir esto. Las soluciones alternativas implican flujos de Power Automate que disparan actualizaciones manuales. Más allá del problema de sincronización, Copilot Studio está construido para superficies de chat y no produce latencia de voz de subsegundo. Para agentes telefónicos, la arquitectura de esta guía es el camino.
Retell AI viene con SOC 2 Type II, HIPAA con BAA de autoservicio y GDPR, además de retención de datos configurable y redacción de PII. Para las cargas de trabajo de sanidad, el patrón estándar es habilitar el BAA antes de que cualquier PHI toque el índice. La postura de cumplimiento frente a tu régimen regulatorio específico te corresponde validarla a ti. Las certificaciones a nivel de infraestructura cubren la plataforma, no tu política de clasificación de contenido.
Sí. Un agente puede tener múltiples bases de conocimiento vinculadas, y cada base puede extraer de una pipeline de origen diferente. Un patrón común es una base por dominio lógico (facturación, soporte, especificaciones de producto) con las fuentes claramente separadas. Los nodos de flujo de conversación también pueden vincular una base diferente a un nodo específico cuando los caminos de ventas y soporte necesitan contexto distinto.
Un ingeniero cómodo con OAuth y webhooks para la capa de sincronización, un responsable de operaciones para la construcción del agente y el ajuste del prompt, y un responsable de contenido que decida qué pertenece a la carpeta sincronizada. La división que funciona en la práctica: TI posee el worker y la autenticación; operaciones posee el agente; el equipo de contenido posee lo que está en alcance. La arquitectura soporta una configuración de una sola persona para la prueba de concepto y escala sin rearquitectura.
El indexador de SharePoint de Azure AI Search maneja bien la ingesta pero tiene límites duros que vale la pena conocer. No admite inquilinos con el Acceso Condicional habilitado. La preservación de ACL está en versión preliminar pública, no en GA. La latencia de actualización corre en horas, no en minutos. Y aún necesitas construir la capa del agente de voz por encima. Para búsqueda empresarial pura, AI Search está bien. Para voz, el patrón de sincronización hacia Retell AI es operativamente más simple y más rápido de desplegar.
División recursiva de 512 tokens con un 10 a 20 por ciento de solapamiento. Este es el valor por defecto validado por benchmarks en las evaluaciones de 2026 y supera al chunking semántico en unos 15 puntos en corpus de documentos reales. Tres chunks recuperados con similitud por defecto. Ajusta solo después de tener de 50 a 100 transcripciones de llamadas reales que informen el cambio.
La pipeline de sincronización es la mitad poco glamurosa de la IA de voz, y también es la mitad que decide si el despliegue sale o se estanca. Un piloto que "funciona con datos de demo" y se cae en el momento en que una política cambia es el modo de fallo característico en este espacio, y la arquitectura anterior es la solución.
Una vez que la base de conocimiento es sólida, el mismo agente se expande a flujos de trabajo adyacentes sobre los mismos datos. Atención al cliente con IA para preguntas entrantes, cualificación de leads para salientes, una recepcionista que enruta a cualquiera de las dos. El corpus que has curado para uno se convierte en la fuente de verdad para todos ellos.
Empieza gratis con 10 $ de crédito en retellai.com.
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)
