Especialização · Integrações e automatizações

Os vossos sistemas a falar entre si, sem que alguém volte a introduzir os mesmos dados.

Ligamos o sistema de marcações, a loja, o CRM, as folhas de cálculo e os canais de mensagens, para que um agente ou uma regra agendada possa ler e escrever neles em tempo real. As chaves ficam no servidor, as ferramentas têm limites escritos e cada integração é testada também no caso de o outro sistema falhar.

Fale sobre um projeto

Já construídoIntegră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.

Uma integração não é um logótipo numa página. É a resposta a uma pergunta muito concreta: este sistema pode ser lido e escrito em tempo real, por quem, com que direitos, e o que acontece quando não responde? Por isso, a nossa primeira pergunta em qualquer integração não é “com que API”, mas “que gate público tem”. Às vezes, a resposta muda completamente o custo do trabalho: as lojas em WooCommerce, por exemplo, expõem publicamente uma API de loja que não pede nenhuma chave de consumidor, portanto um novo cliente liga-se apenas com o endereço do seu site — não com credenciais que tem de gerar, enviar e depois rodar.

Na nossa plataforma de mensagens, uma ferramenta que o agente pode chamar durante a conversa tem um de três tipos: chamada a um webhook, código próprio executado de forma isolada, ou uma ferramenta interna da plataforma. As ferramentas internas são as que preferimos, porque mantêm as chaves fora da base de dados: hoje são quinze, desde a leitura de uma página e a escrita numa folha de cálculo, até à disponibilidade e criação de uma marcação, ao envio de um SMS e à interrogação do catálogo de produtos.

A diferença entre uma integração que se mantém e uma que se rompe está quase sempre em pequenos detalhes, encontrados no terreno. O sistema de marcações não devolve nada se perguntar os horários de um especialista para um serviço que ele não faz — o serviço e o especialista viajam sempre juntos. O mesmo sistema responde com recusa se o pedido vier com o cabeçalho predefinido da biblioteca HTTP, por isso cada pedido tem de se identificar explicitamente. Uma loja pode reportar preço zero para produtos com variantes, e uma pesquisa com palavras vazias devolve todo o catálogo. São dez desses detalhes por integração, e nenhum está na documentação.

Por cima das integrações estão as automatizações: regras que são executadas ao longo do tempo, não a pedido de alguém. No nosso caso, são agendadas com um programador em processo — retoma de conversas sem resposta, a primeira mensagem para um novo contacto, colocar em pausa e reiniciar o agente após o horário de trabalho — cada uma com contadores próprios, para se ver quantas execuções houve, quantas mensagens foram enviadas, quantas foram ignoradas e porquê. Uma automatização sem contador é uma automatização sobre a qual você não pode dizer se 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

Primeiro verificamos qual é o gate público que o sistema tem

Para lojas em WooCommerce usamos a API pública da loja, que não exige chave de consumidor: o cliente liga-se apenas com o endereço do site. É uma escolha que tem consequências reais, não apenas estéticas — substituímos por ela ferramentas escritas à mão que guardavam chaves da loja em claro na base de dados. Quando o sistema não tem gate público, passamos para autenticação, mas aí a chave torna-se uma peça que se gere, não uma que se esquece numa linha da base de dados.

As chaves ficam no servidor, não na ferramenta e não na página

A ferramenta de SMS é interna da plataforma precisamente porque o ambiente em que o código próprio de uma ferramenta é executado não tem acesso às variáveis de ambiente — se o envio fosse feito a partir do código da ferramenta, a chave teria de ser escrita na base de dados, e essa chave pode enviar mensagens à custa de todos. O mesmo no sistema de marcações: o token de parceiro é um só, guardado no ambiente do servidor, enquanto o cliente insere apenas o identificador da sua empresa.

O agente chama a ferramenta durante a conversa, com parâmetros e prazo

Cada ferramenta tem uma descrição escrita para o modelo, parâmetros tipados com o que é obrigatório e o que não é, e um prazo próprio de execução — de 15 segundos para uma lista de serviços até 30 para uma pesquisa de disponibilidade. O prazo por ferramenta não é um detalhe: sem ele, uma integração lenta bloqueia a conversa, e a pessoa do outro lado ouve silêncio.

Marcações reais no sistema do salão ou da clínica

Seis ferramentas por cima de Altegio: a lista de serviços com os preços reais, os especialistas, a disponibilidade completa, a criação da marcação, o cancelamento e a alteração. A disponibilidade não devolve apenas «livre/ocupado»: devolve que especialistas fazem o serviço pedido e as primeiras horas livres para cada um, ordenadas pela mais cedo, precisamente para que o agente proponha uma alternativa concreta em vez de dizer «não está disponível».

O catálogo da loja, lido em tempo real

O preço e a disponibilidade são lidos da loja no momento da pergunta, não de uma cópia desatualizada. O catálogo é carregado de forma paginada, até 30 páginas de 100 produtos cada, é mantido numa memória temporária de dez minutos no site e é normalizado numa única forma, lida sem alterações por todos os consumidores — incluindo o carrossel de produtos na mensageria, que precisa de preço numérico, e o widget na página, que precisa de título.

CRMs, folhas de cálculo e canais de mensagens

amoCRM e Bitrix24 com OAuth completo, renovação de token e verificação de estado. Google Sheets através de uma conta de serviço dedicada, separada do resto das credenciais, com escrita acionada pelo agente. Telegram para notificações de lead. SMS via Infobip. Além disso, o canal de chat de uma plataforma local de anúncios, ligado com um token de renovação próprio — o género de integração que não existe em nenhum catálogo internacional e que conta muito localmente.

Automatizações que correm no tempo, com contadores

Retoma de conversas sem resposta, primeira mensagem para um novo contacto, colocar em pausa e reiniciar o agente após o horário. Cada execução incrementa contadores visíveis: quantas execuções, quantas mensagens enviadas, quantas ignoradas porque o agente estava parado, quantas porque não tinha configuração, quantos erros. Sem eles, a única forma de saber que uma automatização morreu é a reclamação de um cliente.

Limites antiabuso, porque a decisão é tomada por um modelo

Uma ferramenta chamada por um modelo linguístico precisa de margens que o modelo não pode ultrapassar. Em SMS: no modo «para a empresa», o destinatário vem da configuração, nunca do modelo; no modo «para o cliente», o número é normalizado e validado. Além disso, limite diário por agente, pausa de um minuto para o mesmo número e limite de comprimento da mensagem. São guardas escritas em código, não instruções no prompt — um prompt pode ser contornado, uma guarda não.

Filtros na saída, para os dados que não podem sair

Quando uma integração devolve mais do que o cliente deve saber, filtramos à saída, não esperamos que o agente se contenha. Um exemplo real: para um cliente de transportes, a política proíbe que o agente dite o número de telefone do motorista, mas a API devolvia esses números na resposta. Escrevemos um filtro que percorre recursivamente o resultado da ferramenta e elimina os campos de contacto do motorista, mantendo os números da central. O filtro é aplicado exatamente onde é necessário, não globalmente, para não ocultar outra coisa por engano.

Qué aspecto tiene

El recorrido, paso a paso.

O inventário: que sistemas, que gates, que direitos

Que sistemas estão em jogo, o que cada um expõe, quem tem o direito de criar credenciais e quem as roda. Em cada um, a pergunta de base: pode-se ler sem autenticação? Se sim, a integração torna-se muito mais barata e muito mais fácil de repetir para o segundo cliente.

O conector: ferramentas declaradas, chaves no servidor, prazos

Cada ação torna-se uma ferramenta com nome, descrição escrita para o modelo, parâmetros tipados e prazo próprio. As chaves ficam no ambiente do servidor. No fim, o agente não “sabe fazer” algo difuso: tem um conjunto finito de ações, cada uma com os seus limites.

O teste no caso que falha, não apenas no que funciona

Um conector testa-se no pedido correto, no pedido incompleto, no sistema que responde devagar e no sistema que não responde de todo. O que o agente diz quando a integração cai é uma decisão de projeto, não um erro que o cliente descobre: preferimos uma mensagem honesta e uma transferência para um humano, em vez de uma improvisação plausível.

A resistência à instabilidade do outro sistema

Nova tentativa com pausas crescentes, mas apenas nos erros que fazem sentido serem repetidos — uma limitação de taxa ou um erro de servidor, não um pedido errado, que continuará errado da segunda vez. E quando o problema está ao nível da rede do outro, o tratamento é diferente; o exemplo abaixo é precisamente um desses casos.

A entrega: o que muda quando o fornecedor muda

Registamos o que se estraga se o outro sistema alterar a sua API, que credenciais expiram e quando, o que tem de ser renovado manualmente. Uma integração sem esta lista é uma dívida oculta: funciona na perfeição até ao dia em que deixa de funcionar e ninguém sabe porquê.

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.

Os dados

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.

Onde ficam as credenciais: As chaves de fornecedor da plataforma ficam no ambiente do servidor, não na base de dados e nunca na página do cliente. As credenciais próprias de um cliente — quando a integração as exige — são armazenadas encriptadas. A diferença importa: uma chave de plataforma comprometida afeta toda a gente, uma credencial de cliente afeta uma conta; tratamo-las de forma diferente porque o risco é diferente.
O que é armazenado dos sistemas externos e o que não é: O catálogo de produtos não é copiado: é lido a pedido e mantido numa memória temporária de dez minutos, para que dez perguntas consecutivas sobre a mesma loja não signifiquem dez leituras completas. As marcações não são duplicadas connosco — a fonte da verdade continua a ser o sistema do salão. O que guardamos é o rasto da conversa e o resultado da ação, não uma réplica da base de dados do outro sistema.
O que chega ao modelo linguístico: O resultado de uma ferramenta entra na conversa, logo entra também no contexto do modelo. Por isso, a filtragem é feita sobre o resultado, antes de ser dado ao modelo, não nas instruções. Os campos que o cliente não tem permissão para ouvir são eliminados na origem; o que foi eliminado não pode ser ditado, independentemente de como o agente é perguntado.
Quem pode ligar uma integração: Ligar uma integração é uma operação autenticada, associada à conta da empresa, e as ferramentas resultantes são anexadas a um agente específico — não a todos. Um agente tem exatamente as ferramentas de que precisa para a sua função. É a mesma lógica que no acesso de um funcionário: não lhe dão todas as chaves só porque é mais simples.
O que falta reparar, dito abertamente: Nem todos os módulos de integração na nossa plataforma estão ao mesmo nível. Os listados aqui estão escritos e em execução. Existem também módulos iniciados, de algumas dezenas de linhas, que ainda não fazem nada útil — não os apresentamos como disponíveis e não os colocamos em nenhuma oferta. Se você precisar de um sistema que esteja connosco nesse estado, tratamo-lo como trabalho a construir, com uma verificação de compatibilidade antes, não como uma caixa de seleção.

Un caso

A integração caía de forma intermitente, e não era connosco

A situação

Um conector de CRM funcionava às vezes e outras não, sem padrão à primeira vista. Os pedidos ficavam presos até ultrapassarem o limite de execução do ambiente de servidor, por isso nos registos aparecia uma ultrapassagem de tempo — o sinal que o leva, erradamente, a procurar lentidão no seu próprio código.

Qué construimos

A causa estava na rede, do outro lado. O nome de domínio da conta de CRM resolve-se em vários endereços IP, e parte dos nós do cluster estava pouco saudável. Um pedido HTTP normal escolhe um endereço e, se esse não responder, não tenta os outros endereços devolvidos pelo DNS — não existe passagem automática para a próxima resposta. A correção foi deixar de usar o cliente HTTP predefinido para esse domínio: nós próprios resolvemos o nome, abrimos ligações encriptadas diretamente para cada endereço em paralelo, com um prazo curto para cada uma, e usamos a primeira que responder; se todas estiverem frias numa ronda, repete-se.

Qué salió

As falhas intermitentes deixaram de ser uma lotaria. Mais importante para o cliente: o diagnóstico tornou-se possível de dizer numa frase — „os nós do fornecedor estão intermitentemente indisponíveis, e nós contornamo-los” — em vez de „às vezes não funciona”.

Qué no dice el caso

É uma correção que compensa um problema de outra pessoa, e isso tem de ser dito. Acrescenta complexidade ao nosso código por causa de um defeito na infraestrutura do fornecedor; se ele corrigir o seu cluster, a complexidade fica connosco. Documentamo-la como tal, para poder ser removida quando deixar de ser necessária.

Perguntas

Lo que nos pregunta la gente antes de llamar

Que sistemas vocês ligaram efetivamente, não teoricamente?

O sistema de marcações Altegio, com seis ações chamadas pelo agente. amoCRM e Bitrix24, com OAuth completo e renovação de token. Google Sheets, com conta de serviço dedicada. Lojas em WooCommerce, através da API pública da loja. Telegram, para notificações. Infobip, para SMS. O canal de chat de uma plataforma local de anúncios. Mais os canais de mensagens Meta e Telegram para conversas. Para qualquer outro sistema — incluindo plataformas de loja que não concluímos — a resposta honesta é: a pedido, após uma verificação de compatibilidade, tratada como trabalho, não como configuração.

A minha loja tem de gerar-me chaves API?

Para WooCommerce, não. Usamos a API pública da loja, que não pede chave de consumidor — você liga-se com o endereço do site. É também mais seguro, não apenas mais simples: com esta abordagem substituímos ferramentas mais antigas que guardavam chaves de loja escritas em claro na base de dados. Para outras plataformas, depende do que expõem; verificamos antes de prometer.

O agente pode fazer uma marcação real, e não apenas dizer que a faz?

Sim, se o sistema de marcações o permitir. Cria a marcação, pode cancelá-la e alterá-la, e verifica a disponibilidade antes. Um detalhe que só se aprende no terreno: nesse sistema, o serviço e o especialista viajam juntos — se você pedir as horas livres de um especialista para um serviço que ele não faz, recebe zero resultados, não um erro. Por isso, a ferramenta de disponibilidade devolve todos os especialistas que fazem o serviço e as primeiras horas livres de cada um, para que o agente possa propor uma alternativa concreta.

As minhas chaves vão para onde?

As chaves da plataforma ficam no ambiente do servidor, nunca na base de dados e nunca na sua página. As credenciais que são suas são armazenadas encriptadas. A regra que aplicamos: se uma chave pode gastar dinheiro ou pode ler dados para todos os clientes, não tem lugar em lado nenhum onde chegue código que corre a pedido de um modelo linguístico.

O agente pode enviar SMS a quem quiser?

Não, e é uma restrição deliberada. No modo de notificação para a empresa, o destinatário vem da configuração — o modelo não o pode escolher. No modo para o cliente, o número é normalizado e validado. Além disso, existe um limite diário por agente, uma pausa de um minuto para o mesmo número e um limite de comprimento da mensagem. São guardrails no código, não instruções no prompt; um prompt pode ser contornado pela conversa, um guardrail não.

O que acontece quando o sistema do outro falha ou responde lentamente?

Cada ferramenta tem o seu próprio prazo de execução, para que um sistema lento não bloqueie a conversa. Repetimos com pausas crescentes, mas apenas nos erros que valem a pena repetir — uma limitação de taxa ou um erro de servidor, não um pedido incorreto. E o comportamento do agente em caso de falha é escrito no cenário: diz que não pode verificar agora e passa a conversa adiante, em vez de inventar uma resposta plausível.

O que acontece se o fornecedor alterar a sua API?

Algo se estraga, e é por isso que preferimos os portais oficiais em vez de ler páginas. As ferramentas que extraem a informação do HTML de um site quebram com qualquer mudança de tema — substituímo-las deliberadamente por uma única implementação sobre a API oficial, precisamente para não manter dezenas de variantes frágeis. Quando não existe alternativa, dizemos que é uma solução frágil e tratamo-la como tal.

Podem fazer automatizações sem agente, apenas regras agendadas?

Sim. A retoma de conversas sem resposta, a primeira mensagem para um novo contacto, a paragem e o arranque do agente após o horário de trabalho — são tarefas agendadas que funcionam sozinhas. Cada uma tem contadores próprios para execuções, mensagens enviadas, mensagens ignoradas e erros, para que se possa responder à pergunta „correu?” com um número, não com uma suposição.

Como garantem que o agente não diz o que não deve, vindo de uma integração?

Filtramos o resultado antes de chegar ao modelo, não depois. O caso concreto que resolvemos: a política de um cliente proibia que o agente ditasse o número de telefone do motorista, mas a API devolvia esses números. Escrevemos um filtro que percorre recursivamente a resposta da ferramenta e remove os campos de contacto do motorista, preservando os números da central, aplicado exatamente a essa ferramenta. O que não chega ao modelo não pode ser dito, independentemente de como o agente é questionado.

Em que se baseiam as afirmações acima (18 fontes)

18 delas são código e ficheiros dos nossos repositórios. Não publicamos o nome nem a linha: juntos, numa única página, descreveriam com demasiada precisão como estão construídos sistemas que não são só nossos. Percorremo-los consigo, no repositório, a pedido — a verificação continua possível, só que se faz numa conversa.

Como trabalhamos Todos os serviços

O que gostaria que funcionasse melhor?

Conte-nos o seu processo. Em conjunto decidimos o que vale a pena construir, o que podemos ligar e como verificamos o resultado.

Vamos falar