Experiencia · Integraciones y automatizaciones

Que tus sistemas se hablen, sin que nadie vuelva a teclear los mismos datos.

Conectamos el sistema de reservas, la tienda, el CRM, las hojas de cálculo y los canales de mensajes, para que un agente o una regla programada pueda leer y escribir en ellos en tiempo real. Las claves permanecen en el servidor, las herramientas tienen límites escritos y cada integración también se prueba en el caso en que el otro sistema caiga.

Habla de un proyecto

Ya construidoIntegraciones propias, escritas y ejecutadas, medidas hoy en código: el conector para el sistema de reservas Altegio (946 líneas, con seis herramientas expuestas al agente), el conector de CRM amoCRM (2.888 líneas en la plataforma de mensajería, más 12 funciones de servidor en la plataforma vocal), Bitrix24 (903 líneas, más 4 funciones), Google Sheets (615 líneas, más 10 funciones y una cuenta de servicio dedicada), el catálogo vivo sobre la tienda (servicio de plataforma, 318 líneas), notificaciones de lead por Telegram (1.776 líneas), SMS por Infobip con límites antimal uso, automatizaciones programadas (1.088 líneas) y el canal de chat de una plataforma local de anuncios (2.459 líneas). En ejecución, el agente puede llamar a 15 tipos de herramientas internas, además de herramientas por webhook y herramientas con código propio ejecutado en aislamiento.

Una integración no es un logo en una página. Es la respuesta a una pregunta muy concreta: ¿puede este sistema leerse y escribirse en tiempo real, por quién, con qué permisos, y qué pasa cuando no responde? Por eso nuestra primera pregunta en cualquier integración no es «con qué API», sino «qué gate público tiene». A veces la respuesta cambia por completo el coste del trabajo: las tiendas en WooCommerce, por ejemplo, exponen públicamente una API de tienda que no pide ninguna clave de consumidor, así que un cliente nuevo se conecta solo con la dirección de su sitio — no con credenciales que tenga que generar, enviar y luego rotar.

En nuestra plataforma de mensajería, una herramienta que el agente puede llamar durante la conversación tiene uno de tres tipos: llamada a un webhook, código propio ejecutado de forma aislada, o una herramienta interna de la plataforma. Las herramientas internas son las que preferimos, porque mantienen las claves fuera de la base de datos: hoy son quince, desde la lectura de una página y la escritura en una hoja de cálculo, hasta la disponibilidad y la creación de una reserva, el envío de un SMS y la consulta del catálogo de productos.

La diferencia entre una integración que se mantiene y una que se rompe está casi siempre en pequeños detalles, encontrados sobre el terreno. El sistema de reservas no devuelve nada si preguntas por las horas de un especialista para un servicio que no realiza — el servicio y el especialista viajan siempre juntos. El mismo sistema responde con un rechazo si la solicitud llega con la cabecera por defecto de la biblioteca HTTP, así que cada solicitud debe identificarse explícitamente. Una tienda puede informar precio cero para los productos con variantes, y una búsqueda con palabras vacías devuelve todo el catálogo. Son diez detalles así por integración, y ninguno está en la documentación.

Encima de las integraciones están las automatizaciones: reglas que se ejecutan en el tiempo, no a petición de alguien. En nuestro caso están programadas con un planificador en proceso — la reanudación de conversaciones sin respuesta, el primer mensaje a un contacto nuevo, la pausa y el reinicio del agente después del horario laboral — cada una con sus propios contadores, para ver cuántas ejecuciones hubo, cuántos mensajes salieron, cuántos se omitieron y por qué. Una automatización sin contador es una automatización de la que no puedes decir si funciona.

Automatización transparente — integraciones que se pueden verificar · vídeo en rumano, con subtítulos y transcripción en español

La transcripción completa

Entremos directamente en materia. Hoy vamos a diseccionar las realidades técnicas y, sinceramente, a menudo ignoradas, de la automatización mediante asistentes basados en inteligencia artificial. Nos vamos a centrar en un enfoque súper pragmático de la plataforma iCat.md desarrollada por Mega Promoting. Hoy no tenemos promesas de marketing y, sin duda, no tenemos conceptos vagos. Hablamos de una plataforma en producción, con funcionalidades explicadas directamente desde la arquitectura de la base de datos. Así que vamos a ver cómo se ve, de hecho, la automatización totalmente transparente. La agenda de este análisis es simple y al grano. Pasamos por el problema del tiempo, la mecánica de la tecnología, un caso real, los límites claros del sistema, la gestión de datos y los siguientes pasos.

Empezamos con la primera sección, el problema del tiempo. Todos conocéis esa pregunta extremadamente frustrante: ¿por qué todo un equipo de soporte pierde horas, día tras día, escribiendo a mano respuestas a las mismas cinco preguntas? La información ya existe en la web de la empresa, pero aun así los clientes siguen pidiendo los detalles una y otra vez. Y precisamente esa es la esencia de nuestro problema. Sin una solución técnica adecuada, todas estas solicitudes repetitivas simplemente saturan la mensajería directa, da igual si es Instagram o Messenger. Como consecuencia, las respuestas se retrasan mucho para los clientes que de verdad tienen un problema complejo, las solicitudes se pierden en un mar de mensajes, y todo el proceso de soporte se convierte prácticamente en una caja negra que no puedes ni verificar ni medir.

Parte dos. ¿Cómo funciona realmente la tecnología bajo el capó? Mira, así es como va. La configuración de la plataforma se basa en cuatro pasos muy lógicos. Primero conectamos los canales de comunicación usando código propio. Luego se indexa toda la base de conocimientos. Después viene la vinculación de las herramientas que pueden ejecutar acciones en vuestros sistemas existentes. Y al final, y este detalle es vital, se configura un recorrido claro registrado directamente en la base de datos por el que el bot entrega la conversación a un operador humano. Todo es un sistema visible y perfectamente configurable. Ahora, un aspecto absolutamente fascinante. No hablamos de pianos aquí. Estas son configuraciones extraídas directamente del esquema de la base de datos.

Cuando el asistente necesita una respuesta, utiliza lo que se llama una búsqueda híbrida. Por defecto, el algoritmo extrae 5 fragmentos de texto, aplica un umbral estricto de similitud de 0-70 y da un 30% de importancia a la coincidencia exacta de las palabras. Todo se procesa mediante el modelo Text Embedding 3 Small. Básicamente, el sistema transforma las palabras en conceptos matemáticos para captar el contexto exacto. Las respuestas no son adivinanzas, sino matemática pura. Recordad este número. 15. Es un límite técnico absoluto en el sistema. Representa el tiempo máximo, en segundos, asignado para ejecutar cualquier herramienta o búsqueda. Si una integración externa tarda más que eso, digamos que necesita 40 segundos, no podemos dejarla en el flujo en vivo de la conversación.

Debe procesarse de forma asíncrona, de lo contrario se rompería por completo el ritmo natural del diálogo. Y hay más. La gente escribe por chat en ráfagas, ¿no? 2, 3, 4 mensajes cortos enviados uno tras otro. Para no volver loco al sistema, existe un búfer de concatenación de 15 segundos. Todo lo que entra en esa ventana se pega y se convierte en una sola solicitud clara. Además, en plataformas como Meta, donde a veces os topáis con mensajes duplicados enviados por error, el sistema aplica un filtro de memoria de 120 segundos sobre el ID del mensaje. Así, el cliente recibe una sola respuesta coherente, no 3 falsas alarmas. Sección tres. Veamos un caso real. Tenemos este escenario clásico de e-commerce.

Tenemos una tienda online, con un catálogo impecable en la web, pero que recibe una avalancha de mensajes privados en Instagram y Messenger. ¿Sigue en stock? ¿Qué precio tiene? Aquí la integración se hizo de forma elegante, conectando el asistente directamente a la interfaz pública Store API de WooCommerce. Sin complicaciones de seguridad, el catálogo vivo de la tienda se puso simplemente en manos del asistente. Solo que aquí entra la realidad técnica de cada plataforma, incluso bajo el paraguas de la misma empresa, como Meta. En Messenger, el asistente os puede mostrar carruseles de productos estupendos. En Instagram, el bot solo os responderá con texto y, como mucho, una imagen sencilla. ¿Por qué? Simplemente porque Meta no admite esas plantillas genéricas en Instagram.

El asistente tiene que jugar exactamente según las reglas del canal en el que esté. Aquí está el punto crítico. ¿Qué pasa cuando el bot se ve superado por la situación? Pues bien, en la base de datos la conversación tiene estados explícitos. Cuando una pregunta sale de la zona de confort del catálogo, el hilo de la conversación pasa inmediatamente del estado bot al estado humano. Y la parte genial es que el sistema contabiliza el tiempo en que responde el operador humano, marcándolo todo claramente: estado OK, aviso o plazo superado. Todo el contexto se entrega a la persona, sin que se pierda absolutamente nada por el camino. Sección A4 Los límites del sistema Porque la transparencia significa saber lo que no puede hacer.

Hay varios límites firmes que tenemos que aceptar. No podéis enviar mensajes proactivos por WhatsApp si han pasado más de 24 de horas desde el mensaje del cliente. Meta devolverá un error, más exactamente el error 131047, y la acción fallará. El sistema no hace archivos RPDF, no lee adjuntos. En cuanto a idiomas extranjeros, las traducciones funcionan solo en un sentido. El cliente recibe la respuesta traducida, pero el operador ve el original. Y, aunque la integración con 999.md funciona, no es oficial y se basa en las cookies del navegador. Si la plataforma modifica sus mecanismos, la conexión cae y necesita reparación. Y recordad esto sí o sí. El asistente es el espejo de vuestros datos. Un precio incorrecto en la web se convertirá garantizado en un precio incorrecto en la conversación.

Actúa como lector, no como gestor de la tienda. No corregirá por iniciativa propia los errores humanos en los catálogos. La infraestructura técnica aquí no es ninguna broma. Todo está alojado en un servidor privado Microsoft Azure. Hablamos de una base de datos MySQL extremadamente estructurada, con más de 80 tablas modeladas claramente para separar los canales y para auditoría. Las claves de acceso para WhatsApp, que son supersensibles, usan cifrado fernet. Además de eso, a nivel web, los dominios para el widget de chat se añaden manualmente a una lista blanca. Nadie se conecta sin permiso explícito. Pero hay que abordar una realidad evidente. La gente escribirá todo tipo de datos personales en esas ventanas de chat, números de teléfono, direcciones.

Técnicamente, no puedes bloquear un campo de texto libre. Así que la solución es administrativa. Cuando implementáis un sistema así, necesitáis, desde el segundo 1, políticas claras de retención que dicten exactamente quién tiene derecho a ver esos datos y durante cuánto tiempo se almacenan. Y hemos llegado al punto 6. Los pasos siguientes. La filosofía central de todo el sistema se puede resumir con esta cita. Un asistente útil no es el que compone poemas o escribe bonito, sino el que está conectado a información real y, muy importante, sabe exactamente dónde debe detenerse. La automatización eficiente en business significa la toma correcta de datos y la seguridad con la que cedes el control a un operador humano en el momento oportuno.

Por lo tanto, el siguiente paso no es comprar un software, sino analizar con atención vuestros procesos actuales. Evaluad qué flujos de trabajo realmente merecen ser construidos y automatizados, cómo se pueden conectar de forma segura y, lo más importante, estableced cómo mediréis los resultados con datos reales, no con ilusiones de marketing. Y os dejo con esta cuestión para reflexionar. De todos los procesos de comunicación en un negocio, ¿cuáles son los que realmente requieren la empatía y el tacto de una persona y cuáles son, de hecho, solo tareas repetitivas que esperan simplemente ser conectadas con precisión a la base de datos correcta? Cualquier plan de automatización debería partir de esta pregunta. ¡Gracias por acompañarnos en este análisis!

Qué incluye

El trabajo, por componentes

Primero verificamos qué gate público tiene el sistema

Para las tiendas en WooCommerce usamos la API pública de la tienda, que no requiere clave de consumidor: el cliente se conecta solo con la dirección del sitio. Es una elección que tiene consecuencias reales, no solo estéticas — la hemos sustituido por herramientas escritas a mano que mantenían claves de la tienda en claro en la base de datos. Cuando el sistema no tiene gate público, pasamos a la autenticación, pero entonces la clave se convierte en una pieza que se administra, no en una que se deja en una fila de la base de datos.

Las claves quedan en el servidor, no en la herramienta ni en la página

La herramienta de SMS es interna de la plataforma precisamente porque el entorno en el que se ejecuta el código propio de una herramienta no tiene acceso a las variables de entorno — si el envío se hiciera desde código de la herramienta, la clave tendría que escribirse en la base de datos, y esa clave puede enviar mensajes a costa de todos. Lo mismo en el sistema de reservas: el token de partner es único, se guarda en el entorno del servidor, mientras que el cliente solo introduce el identificador de su empresa.

El agente llama a la herramienta durante la conversación, con parámetros y plazo

Cada herramienta tiene una descripción escrita para el modelo, parámetros tipados con lo que es obligatorio y lo que no, y un plazo propio de ejecución — de 15 segundos para una lista de servicios hasta 30 para una búsqueda de disponibilidad. El plazo por herramienta no es un detalle: sin él, una integración lenta bloquea la conversación, y la persona al otro lado oye silencio.

Reservas reales en el sistema del salón o de la clínica

Seis herramientas sobre Altegio: la lista de servicios con los precios reales, los especialistas, la disponibilidad completa, la creación de la reserva, la cancelación y la modificación. La disponibilidad no devuelve solo «libre/ocupado»: devuelve qué especialistas hacen el servicio pedido y las primeras horas libres para cada uno, ordenadas por la más temprana, precisamente para que el agente proponga una alternativa concreta en lugar de decir «no está disponible».

El catálogo de la tienda, leído en vivo

El precio y la disponibilidad se leen de la tienda en el momento de la pregunta, no de una copia obsoleta. El catálogo se carga paginado, hasta 30 páginas de 100 productos cada una, se guarda en una memoria temporal de diez minutos por sitio y se normaliza en una sola forma, leída sin modificaciones por todos los consumidores — incluido el carrusel de productos de mensajería, que necesita un precio numérico, y el widget de la página, que necesita el título.

CRM, hojas de cálculo y canales de mensajes

amoCRM y Bitrix24 con OAuth completo, renovación de token y verificación de estado. Google Sheets mediante una cuenta de servicio dedicada, separada del resto de credenciales, con escritura activada por el agente. Telegram para notificaciones de lead. SMS por Infobip. Además, el canal de chat de una plataforma local de anuncios, conectado con su propio token de renovación — el tipo de integración que no existe en ningún catálogo internacional y que cuenta muchísimo a nivel local.

Automatizaciones que se ejecutan en el tiempo, con contadores

La reanudación de conversaciones sin respuesta, el primer mensaje a un contacto nuevo, la pausa y el reinicio del agente después del horario. Cada ejecución incrementa contadores visibles: cuántas ejecuciones, cuántos mensajes enviados, cuántos omitidos porque el agente estaba apagado, cuántos porque no tenía configuración, cuántos errores. Sin ellos, la única forma de saber que una automatización murió es la reclamación de un cliente.

Límites antiabuso, porque la decisión la toma un modelo

Una herramienta llamada por un modelo lingüístico necesita márgenes que el modelo no puede superar. En SMS: en el modo «hacia la empresa», el destinatario viene de la configuración, nunca del modelo; en el modo «hacia el cliente», el número se normaliza y valida. Encima de eso, tope diario por agente, pausa de un minuto hacia el mismo número y límite de longitud del mensaje. Son vallas escritas en código, no instrucciones en el prompt — un prompt se puede saltar, una valla no.

Filtros de salida, para los datos que no tienen permiso para salir

Cuando una integración devuelve más de lo que el cliente debería saber, filtramos a la salida, no esperamos que el agente se abstenga. Un ejemplo real: para un cliente de transporte, la política prohíbe que el agente dicte el número de teléfono del conductor, pero la API devolvía esos números en la respuesta. Escribimos un filtro que recorre recursivamente el resultado de la herramienta y elimina los campos de contacto del conductor, manteniendo los números del despacho. El filtro se aplica exactamente donde hace falta, no de forma global, para no ocultar otra cosa por error.

Qué aspecto tiene

El recorrido, paso a paso.

Inventario: qué sistemas, qué puertas, qué derechos

Qué sistemas están en juego, qué expone cada uno, quién tiene derecho a crear credenciales y quién las rota. En cada uno, la pregunta básica: ¿se puede leer sin autenticación? Si sí, la integración se vuelve mucho más barata y mucho más fácil de repetir con el segundo cliente.

El conector: herramientas declaradas, claves en el servidor, plazos

Cada acción se convierte en una herramienta con nombre, descripción escrita para el modelo, parámetros tipados y plazo propio. Las claves permanecen en el entorno del servidor. Al final, el agente no “sabe hacer” algo difuso: tiene un conjunto finito de acciones, cada una con sus límites.

La prueba en el caso que falla, no solo en el que funciona

Un conector se prueba con la solicitud correcta, con la solicitud incompleta, con el sistema que responde lento y con el sistema que no responde en absoluto. Lo que dice el agente cuando la integración cae es una decisión de diseño, no un error que descubre el cliente: preferimos un mensaje honesto y una derivación a un humano, en lugar de una improvisación plausible.

La resistencia a la inestabilidad del otro sistema

Reintento con pausas crecientes, pero solo en los errores que tiene sentido reintentar — una limitación de tasa o un error de servidor, no una solicitud incorrecta, que será incorrecta también la segunda vez. Y cuando el problema está al nivel de la red del otro, el tratamiento es otro; el ejemplo de abajo es precisamente un caso así.

La entrega: qué cambia cuando cambia el proveedor

Anotamos qué se rompe si el otro sistema cambia su API, qué credenciales expiran y cuándo, qué hay que renovar manualmente. Una integración sin esta lista es una deuda oculta: funciona perfectamente hasta el día en que deja de funcionar y nadie sabe por qué.

Los sistemas externos alrededor de la conversación: reservas, el catálogo de la tienda, CRM, hojas de cálculo, SMS y canales de mensajes — cada uno leído a demanda, con las claves permaneciendo en el servidor.

Los datos

Qué tocamos, dónde están y cuánto se quedan

Las preguntas que hace cualquiera que tenga un delegado de protección de datos — hechas aquí antes de que las haga él.

Dónde están las credenciales: Las claves de proveedor de la plataforma están en el entorno del servidor, no en la base de datos y nunca en la página del cliente. Las credenciales propias de un cliente — donde la integración las pide — se almacenan cifradas. La diferencia importa: una clave de plataforma comprometida afecta a todos, una credencial de cliente afecta a una cuenta; las tratamos de forma distinta porque el riesgo es distinto.
Qué se almacena de los sistemas externos y qué no: El catálogo de productos no se copia: se lee a demanda y se mantiene en una memoria temporal de diez minutos, para que diez preguntas consecutivas sobre la misma tienda no signifiquen diez recorridos completos. Las reservas no se duplican en nuestro sistema — la fuente de verdad sigue siendo el sistema del salón. Lo que conservamos es el rastro de la conversación y el resultado de la acción, no una réplica de la base de datos del otro sistema.
Lo que llega al modelo lingüístico: El resultado de una herramienta entra en la conversación, así que también entra en el contexto del modelo. Por eso el filtrado se hace sobre el resultado, antes de dárselo al modelo, no en las instrucciones. Los campos que el cliente no tiene derecho a oír se eliminan en origen; lo que se ha eliminado no puede ser dictado, sin importar cómo pregunte el agente.
¿Quién puede vincular una integración?: Conectar una integración es una operación autenticada, vinculada a la cuenta de la empresa, y las herramientas resultantes se adjuntan a un agente concreto — no a todos. Un agente tiene exactamente las herramientas que necesita para su rol. Es la misma lógica que el acceso de un empleado: no se le dan todas las llaves porque sea más simple.
Lo que queda por arreglar, dicho abiertamente: No todos los módulos de integración de nuestra plataforma están al mismo nivel. Los enumerados aquí están escritos y ejecutados. También hay módulos iniciados, de unas pocas decenas de líneas, que aún no hacen nada útil — no los presentamos como disponibles y no los ponemos en ninguna oferta. Si necesitas un sistema que para nosotros esté en ese estado, lo tratamos como un trabajo por construir, con una verificación de compatibilidad antes, no como una casilla para marcar.

Un caso

La integración se caía intermitentemente, y no era culpa nuestra

La situación

Un conector de CRM funcionaba a veces y otras no, sin un patrón a primera vista. Las solicitudes quedaban colgadas hasta superar el límite de ejecución del entorno de servidor, así que en los registros aparecía un tiempo de espera agotado — la señal que te lleva, erróneamente, a buscar lentitud en tu propio código.

Qué construimos

La causa estaba en la red, en el otro extremo. El nombre de dominio de la cuenta de CRM se resuelve en varias direcciones IP, y parte de los nodos del clúster estaban en mal estado. Una solicitud HTTP habitual elige una dirección y, si esa no responde, no prueba las demás direcciones devueltas por DNS — no hay paso automático al siguiente resultado. La reparación fue dejar de usar el cliente HTTP predeterminado para ese dominio: resolvemos nosotros el nombre, abrimos conexiones cifradas directamente a cada dirección en paralelo, con un plazo corto para cada una, y usamos la primera que responde; si todas están frías en una ronda, se repite.

Qué salió

Las caídas intermitentes dejaron de ser una lotería. Más importante para el cliente: el diagnóstico se volvió decible en una frase — «los nodos del proveedor están intermitentemente no disponibles, y nosotros los evitamos» — en lugar de «a veces no funciona».

Qué no dice el caso

Es una reparación que compensa un problema de otro, y hay que decirlo. Añade complejidad en nuestro código por un defecto en la infraestructura del proveedor; si este repara su clúster, la complejidad se queda con nosotros. La documentamos como tal, para que pueda retirarse cuando ya no sea necesaria.

Preguntas

Lo que nos pregunta la gente antes de llamar

¿Qué sistemas habéis conectado efectivamente, no teóricamente?

El sistema de reservas Altegio, con seis acciones llamadas por el agente. amoCRM y Bitrix24, con OAuth completo y renovación de token. Google Sheets, con cuenta de servicio dedicada. Tiendas en WooCommerce, mediante la API pública de la tienda. Telegram, para notificaciones. Infobip, para SMS. El canal de chat de una plataforma local de anuncios. Además de los canales de mensajería de Meta y Telegram para conversaciones. Para cualquier otro sistema —incluidas plataformas de tienda que no hemos llevado hasta el final— la respuesta honesta es: a petición, después de una verificación de compatibilidad, tratada como un trabajo, no como una configuración.

¿Mi tienda tiene que generar mis claves API?

Para WooCommerce, no. Usamos la API pública de la tienda, que no pide clave de consumidor: te conectas con la dirección del sitio. También es más seguro, no solo más simple: sustituimos con este enfoque herramientas más antiguas que guardaban claves de tienda escritas en claro en la base de datos. Para otras plataformas, depende de lo que expongan; lo verificamos antes de prometer.

¿Puede el agente hacer una reserva real, no solo decir que la hace?

Sí, si el sistema de reservas lo permite. Crea la reserva, la puede cancelar y modificar, y verifica la disponibilidad antes. Un detalle que solo se aprende sobre el terreno: en ese sistema, el servicio y el especialista viajan juntos — si pides las horas libres de un especialista para un servicio que él no hace, obtienes cero resultados, no un error. Por eso la herramienta de disponibilidad devuelve a todos los especialistas que hacen el servicio y las primeras horas libres de cada uno, para que el agente proponga una alternativa concreta.

¿A dónde van mis claves?

Las claves de la plataforma permanecen en el entorno del servidor, nunca en la base de datos y nunca en tu página. Las credenciales que son tuyas se almacenan cifradas. La regla que aplicamos: si una clave puede gastar dinero o puede leer datos de todos los clientes, no tiene nada que hacer en ningún lugar al que llegue código que se ejecuta a petición de un modelo lingüístico.

¿Puede el agente enviar SMS a quien quiera?

No, y es una restricción deliberada. En el modo de notificación a la empresa, el destinatario viene de la configuración — el modelo no lo puede elegir. En el modo hacia el cliente, el número se normaliza y se valida. Además, existe un techo diario por agente, una pausa de un minuto hacia el mismo número y un límite de longitud del mensaje. Son barreras en el código, no instrucciones en el prompt; un prompt se puede eludir en conversación, una barrera no.

¿Qué pasa cuando el sistema del otro falla o responde lento?

Cada herramienta tiene su propio tiempo límite de ejecución, para que un sistema lento no bloquee la conversación. Reintentamos con pausas crecientes, pero solo en los errores que vale la pena reintentar — una limitación de tasa o un error de servidor, no una solicitud incorrecta. Y el comportamiento del agente ante el fallo se escribe en el escenario: dice que no puede verificar ahora y cede la conversación, en lugar de inventar una respuesta plausible.

¿Qué pasa si el proveedor cambia su API?

Algo se rompe, y por eso preferimos las puertas oficiales en lugar de leer páginas. Las herramientas que extraen la información del HTML de un sitio se rompen con cualquier cambio de tema — las reemplazamos deliberadamente por una sola implementación sobre la API oficial, precisamente para no mantener decenas de variantes frágiles. Cuando no existe alternativa, decimos que es una solución frágil y la tratamos como tal.

¿Pueden hacer automatizaciones sin agente, solo con reglas programadas?

Sí. La reanudación de conversaciones sin respuesta, el primer mensaje a un contacto nuevo, la parada y el reinicio del agente según el horario de trabajo — son tareas programadas que se ejecutan solas. Cada una tiene sus propios contadores de ejecuciones, mensajes enviados, mensajes omitidos y errores, para poder responder a la pregunta «¿se ejecutó?» con una cifra, no con una suposición.

¿Cómo se aseguran de que el agente no diga lo que no debe, a partir de una integración?

Filtramos el resultado antes de que llegue al modelo, no después. El caso concreto que resolvimos: la política de un cliente prohibía que el agente dictara el número de teléfono del conductor, pero la API devolvía esos números. Escribimos un filtro que recorre recursivamente la respuesta de la herramienta y elimina los campos de contacto del conductor, conservando los números del despacho, aplicado exactamente a esa herramienta. Lo que no llega al modelo no puede ser dicho, sin importar cómo se le pregunte al agente.

En qué se basan las afirmaciones anteriores (18 fuentes)

18 de ellas son código y archivos de nuestros repositorios. No publicamos su nombre ni la línea: juntos, en una sola página, describirían con demasiada precisión cómo están construidos sistemas que no son solo nuestros. Los repasamos contigo, en el repositorio, a petición — la verificación sigue siendo posible, solo que se hace en una conversación.

Cómo trabajamos Todos los servicios

¿Qué te gustaría que funcionara mejor?

Cuéntanos tu proceso. Juntos decidimos qué merece la pena construir, qué podemos conectar y cómo verificamos el resultado.

Vamos a hablar