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 construidoIntegrări proprii, scrise și rulate, măsurate azi în cod: conectorul pentru sistemul de programări Altegio (946 de linii, cu șase unelte expuse agentului), conectorul de CRM amoCRM (2.888 de linii în platforma de mesagerie, plus 12 funcții de server în platforma vocală), Bitrix24 (903 linii, plus 4 funcții), Google Sheets (615 linii, plus 10 funcții și un cont de serviciu dedicat), catalogul viu peste magazin (serviciu de platformă, 318 linii), notificări de lead pe Telegram (1.776 de linii), SMS prin Infobip cu limite anti-abuz, automatizări programate (1.088 de linii) și canalul de chat al unei platforme locale de anunțuri (2.459 de linii). În execuție, agentul poate chema 15 tipuri de unelte interne, pe lângă unelte prin webhook și unelte cu cod propriu rulat în izolare.

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.

Automatizare transparentă — integrări care se pot verifica · video în română, cu subtitrare și transcriere

Transcrierea completă

Să intrăm direct în subiect. Astăzi vom diseca realitățile tehnice și, sincer, adesea ignorate, ale automatizării prin asistenți bazați pe inteligență artificială. Ne vom concentra pe o abordare super pragmatică a platformei iCat.md dezvoltată de Mega Promoting. Nu avem promisiuni de marketing astăzi și, cu siguranță, nu avem concepte vagi. Discutăm despre o platformă aflată direct în producție, cu funcționalități explicate direct din arhitectura bazei de date. Așa că haideți să vedem cum arată, de fapt, automatizarea complet transparentă. Agenda acestei analize este simplă și la obiect. Trecem prin problema timpului, mecanica tehnologiei, un caz real, limitele clare ale sistemului, managementul datelor și pașii următori. Începem cu prima secțiune, problema timpului. Știți cu toții acea întrebare extrem de frustrantă? De ce o întreagă echipă de suport pierde ore bune, zi de zi, scriind de mână răspunsuri la fix aceleași cinci întrebări? Informația există deja pe site-ul companiei, dar, cu toate astea, clienții continuă să ceară detaliile în mod repetat. Și exact asta este esența problemei noastre. Fără o soluție tehnică potrivită, toate aceste solicitări repetitive pur și simplu înfundă mesageria directă, nu contează dacă e Instagram sau Messenger. În consecința, răspunsurile întârzie masiv pentru clienții care au cu adevărat o problemă complexă, cererile se rătăcesc în marea de mesaje, iar întregul proces de suport devine practic o cutie neagră pe care nu o poți nici verifica, nici măsura. Partea a doua. Cum funcționează, de fapt, tehnologia sub capotă? Uite care-i treaba. Setarea platformei se bazează pe patru pași foarte logici. Mai întâi conectăm canalele de comunicare folosind cod propriu. Apoi se indexează toată baza de cunoștințe. Urmează legarea uneltelor care pot executa acțiuni în sistemele voastre existente. Iar la final, și acest detaliu este vital, se configurează un traseu clar înregistrat direct în baza de date prin care botul predă discuția unui operator uman. Totul este un sistem vizibil și perfect configurabil. Acum, un aspect absolut fascinant. Nu vorbim din plian de aici. Acestea sunt setări extrase direct din schema bazei de date. Când asistentul are nevoie de un răspuns, el folosește o așa numită căutare hibridă. Implicit, algoritmul extrage 5 fragmente de text, aplică un prag strict de similitudine de 0-70 și acordă o importanță de 30% potrivirii exacte a cuvintelor. Totul este procesat prin modelul Text Embedding 3 Small. Practic, sistemul transformă cuvintele în concepte matematice pentru a prinde contextul exact. Răspunsurile nu sunt oghicitoare, ci matematică pură. Rețineți acest număr. 15. Este o limită tehnică absolută în sistem. Reprezintă timpul maxim, în secunde, alocat pentru a rula orice unealtă sau căutare. Dacă o integrare externă durează mai mult de atât, să zicem că are nevoie de 40 de secunde, nu o putem lăsa în fluxul live-a conversației. Ea trebuie procesată asincron, altfel s-ar rupe complet ritmul natural al dialogului. Și mai e ceva. Oamenii scriu pe chat în rafale, nu? 2, 3, 4 mesaje scurte trimise unul după altul. Pentru a nu înnebuni sistemul, există un tampon de concatenare de 15 secunde. Tot ce intră în această fereastră se lipește și devine o singură cerere clară. Mai mult, pe platforme ca Meta, unde uneori te lovești de mesaje duplicate trimise din eroare, sistemul aplică un filtru de memorie de 120 de secunde pe ID-ul mesajului. Astfel, clientul primește un singur răspuns coerent, nu 3 alarme false. Secțiunea a treia. Să vedem un caz real. Avem acest scenariu clasic de e-commerce. Avem un magazin online, cu un catalog impecabil pe site, dar care primește o avalanșă de mesaje private pe Instagram și Messenger? Mai e în stoc? Ce preț are? Aici integrarea s-a făcut elegant, conectând asistentul direct la interfața publică Store API de la WooCommerce. Fără complicații de securitate, catalogul viu al magazinului a fost pur și simplu pus în mânile asistentului. Doar aici intervine realitatea tehnică a fiecărei platforme, chiar și sub umbrela aceleiași companii, cum e Meta. Pe Messenger, asistentul vă poate arăta carusele de produse superbe. Pe Instagram, botul o să vă răspundă doar cu text și cel mult o imagine simplă. De ce? Pur și simplu pentru că Meta nu suportă acele șabloane generice pe Instagram. Asistentul trebuie să joace exact după regulile canalului unde se află. Aici este punctul critic. Ce se întâmplă când botul este depășit de situație? Ei bine, în baza de date conversația are stări explicite. Când o întrebare iese din zona de confort a catalogului, firul de discuție trece imediat din starea bot în starea umană. Și partea genială e că sistemul contorizează timpul în care răspundă operatorul uman, marcând totul clar, status OK, avertiziment sau termen depășit. Tot contextul este predat omului, fără să se piarda absolut nimic pe drum. Secțiunea A4 Limitele sistemului Pentru că transparența înseamnă să știm ce nu poate face. Sunt câteva limite ferme pe care trebuie să le acceptăm. Nu puteți trimite mesaje proactive pe WhatsApp dacă au trecut mai mult de 24 de ore de la mesajul clientului. Meta va trânti o eroare, mai exact eroarea 131047, iar acțiunea va eșua. Sistemul nu face fișie RPDF, nu citește atașamente. La partea de limbi străine, traducerile merg doar într-un singur sens. Clientul primește răspunsul tradus, dar operatorul vede originalul. Și, deși integrarea cu 999.md funcționează, este neoficială și se bazează pe cookie-urile din browser. Dacă platforma își modifică mecanismele, conexiunea cade și necesită reparații. Și rețineți neapărat asta. Asistentul este oglinda datelor voastre. Un preț greșit pe site va deveni garantat un preț greșit în conversație. El acționează ca un cititor, nu ca un manager de magazin. Nu va corecta din proprie inițiativă erorile umane din cataloge. Infrastructura tehnică de aici nu e o joacă. Totul este ținut pe un server privat Microsoft Azure. Discutăm despre o bază de date MySQL extrem de structurată, cu peste 80 de tabele modelate clar pentru a separa canalele și pentru audit. Cheile de acces pentru WhatsApp, care sunt supersensibile, folosesc criptare fernet. Pe lângă asta, la nivel de web, domeniile pentru widgetul de chat sunt adăugate manual într-o listă albă. Nimeni nu se conectează fără permisiune explicită. Trebuie însă să abordăm o realitate evidentă. Oamenii vor scrie tot felul de date personale în acele ferestre de chat, numere de telefon, adrese. Tehnic, nu ai cum să blochezi un câmp de text liber. Așa că soluția este administrativă. Când implementați un astfel de sistem, aveți nevoie, din secunda 1, de politici clare de retenție care să dicteze exact cine are voie să vadă acele date și pentru cât timp sunt stocate. Și am ajuns la punctul 6. Pașimul mători. Filozofia centrală a întregului sistem poate fi rezumată prin acest citat. Un asistent utim nu este cel care compune poezii sau scrie frumos, ci acela care este conectat la informații reale și, foarte important, știe exact unde trebuie să se oprească. Automatizarea eficientă în business înseamnă preluarea corectă a datelor și siguranța cu care cedes controlul unui operator uman la momentul oportun. Prin urmare, pasul următor nu este să cumpărați un soft, ci să vă analizați cu atenție procesele actuale. Evaluați ce fluxuri de lucru merită cu adevărat să fie construite și automatizate, cum se pot conecta ele în siguranță și, cel mai important, stabiliți cum veți măsura rezultatele cu date reale, nu cu iluzii de marketing. Și vă las cu această temă de gândire. Dintre toate procesele de comunicare dintr-o afacere, care sunt acelea care necesită cu adevărat empatia și tactul unui om și care sunt, de fapt, doar sarcinii repetitive ce așteaptă pur și simplu să fie conectate cu precizie la baza de date corectă? Orice plan de automatizare ar trebui să plece de la această întrebare. Mulțumim că ați fost alături de noi în această analiză!

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é.

Sistemele externe din jurul conversației: programări, catalogul magazinului, CRM, foi de calcul, SMS și canale de mesaje — fiecare citit la cerere, cu cheile rămase pe server.

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