Competenza · Integrazioni e automazioni

I vostri sistemi che si parlino, senza che qualcuno debba reinserire gli stessi dati.

Connettiamo il sistema di programmazione, il negozio, il CRM, i fogli di calcolo e i canali di messaggi, così che un agente o una regola programmata possano leggere e scrivere in essi in tempo reale. Le chiavi restano sul server, gli strumenti hanno limiti scritti, e ogni integrazione viene testata anche sul caso in cui l'altro sistema cada.

Parliamo di un progetto

Già costruitoIntegră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.

Un’integrazione non è un logo su una pagina. È la risposta a una domanda molto concreta: questo sistema può essere letto e scritto in tempo reale, da chi, con quali diritti, e cosa succede quando non risponde? Per questo la nostra prima domanda in qualsiasi integrazione non è “con quale API”, ma “quale gate pubblico ha”. A volte la risposta cambia completamente il costo del lavoro: i negozi su WooCommerce, per esempio, espongono pubblicamente un’API di negozio che non richiede alcuna chiave consumatore, quindi un nuovo cliente si collega solo con l’indirizzo del suo sito — non con credenziali che deve generare, inviare e poi ruotare.

Nella nostra piattaforma di messaggistica, uno strumento che l’agente può chiamare durante la conversazione ha uno di tre tipi: chiamata a un webhook, codice proprio eseguito in isolamento, oppure uno strumento interno della piattaforma. Gli strumenti interni sono quelli che preferiamo, perché tengono le chiavi fuori dal database: oggi sono quindici, dalla lettura di una pagina e scrittura in un foglio di calcolo, fino alla disponibilità e creazione di una prenotazione, l’invio di un SMS e l’interrogazione del catalogo prodotti.

La differenza tra un’integrazione che regge e una che si rompe sta quasi sempre in cose piccole, sul campo. Il sistema di prenotazioni non restituisce nulla se chiedete gli orari di uno specialista per un servizio che non svolge — il servizio e lo specialista viaggiano sempre insieme. Lo stesso sistema risponde con un rifiuto se la richiesta arriva con l’intestazione predefinita della libreria HTTP, quindi ogni richiesta deve identificarsi esplicitamente. Un negozio può riportare prezzo zero per i prodotti con varianti, e una ricerca con parole vuote restituisce l’intero catalogo. Sono dieci dettagli del genere per integrazione, e nessuno è nella documentazione.

Peste le integrazioni ci sono le automazioni: regole che vengono eseguite nel tempo, non su richiesta di qualcuno. Da noi sono programmate con uno scheduler di processo — la ripresa delle conversazioni rimaste senza risposta, il primo messaggio a un nuovo contatto, la messa in pausa e la riattivazione dell’agente dopo l’orario di lavoro — ognuna con i propri contatori, così si vede quante esecuzioni ci sono state, quanti messaggi sono partiti, quanti sono stati saltati e perché. Un’automazione senza contatore è un’automazione di cui non si può dire se funzioni.

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ă!

Cosa comprende

Il lavoro, per componenti

Prima verifichiamo quale gate pubblico abbia il sistema

Per i negozi su WooCommerce usiamo l’API pubblica del negozio, che non richiede una chiave consumatore: il cliente si collega solo con l’indirizzo del sito. È una scelta che ha conseguenze reali, non solo estetiche — l’abbiamo sostituita a strumenti scritti a mano che tenevano le chiavi del negozio in chiaro nel database. Quando il sistema non ha un gate pubblico, passiamo all’autenticazione, ma allora la chiave diventa un elemento da gestire, non uno da cercare in una riga di database.

Le chiavi restano sul server, non nello strumento e non nella pagina

Lo strumento SMS è interno alla piattaforma proprio perché l’ambiente in cui gira il codice proprio di uno strumento non ha accesso alle variabili d’ambiente — se l’invio avvenisse dal codice dello strumento, la chiave dovrebbe essere scritta nel database, e quella chiave può inviare messaggi a spese di tutti. Lo stesso per il sistema di programmazioni: il token partner è uno solo, conservato nell’ambiente del server, mentre il cliente inserisce soltanto l’identificatore della propria azienda.

L’agente richiama lo strumento durante la conversazione, con parametri e timeout

Ogni strumento ha una descrizione scritta per il modello, parametri tipizzati con ciò che è obbligatorio e ciò che non lo è, e un proprio timeout di esecuzione — da 15 secondi per un elenco di servizi fino a 30 per una ricerca di disponibilità. Il timeout per strumento non è un dettaglio: senza di esso, un’integrazione lenta blocca la conversazione, e la persona dall’altra parte sente silenzio.

Programmazioni reali nel sistema del salone o della clinica

Sei strumenti sopra Altegio: l’elenco dei servizi con i prezzi reali, gli specialisti, la disponibilità completa, la creazione della programmazione, l’annullamento e la modifica. La disponibilità non restituisce solo «libero/occupato»: restituisce quali specialisti svolgono il servizio richiesto e le prime ore libere per ciascuno, ordinate per la più precoce, proprio per consentire all’agente di proporre un’alternativa concreta invece di dire «non è disponibile».

Catalogo del negozio, letto dal vivo

Il prezzo e la disponibilità vengono letti dal negozio al momento della domanda, non da una copia obsoleta. Il catalogo viene caricato in modo paginato, fino a 30 pagine da 100 prodotti ciascuna, viene conservato in una memoria temporanea di dieci minuti sul sito e viene normalizzato in un’unica forma, letta senza modifiche da tutti i consumatori — inclusa la carosello dei prodotti nella messaggistica, che ha bisogno del prezzo numerico, e il widget nella pagina, che ha bisogno del titolo.

CRM, fogli di calcolo e canali di messaggi

amoCRM e Bitrix24 con OAuth completo, aggiornamento del token e verifica dello stato. Google Sheets tramite un account di servizio dedicato, separato dal resto delle credenziali, con scrittura attivata dall’agente. Telegram per le notifiche di lead. SMS tramite Infobip. Più il canale chat di una piattaforma locale di annunci, collegato con un proprio token di aggiornamento — il tipo di integrazione che non esiste in nessun catalogo internazionale e che conta moltissimo a livello locale.

Automazioni che girano nel tempo, con contatori

La ripresa delle conversazioni rimaste senza risposta, il primo messaggio a un nuovo contatto, la messa in pausa e la riattivazione dell’agente dopo l’orario. Ogni esecuzione incrementa contatori visibili: quante esecuzioni, quanti messaggi inviati, quanti saltati perché l’agente era spento, quanti perché non aveva configurazione, quanti errori. Senza di essi, l’unico modo per scoprire che un’automazione è morta è il reclamo di un cliente.

Limiti anti-abuso, perché la decisione la prende un modello

Uno strumento richiamato da un modello linguistico ha bisogno di limiti che il modello non può superare. Per gli SMS: in modalità «verso l’azienda», il destinatario viene dalla configurazione, mai dal modello; in modalità «verso il cliente», il numero viene normalizzato e validato. In più, tetto giornaliero per agente, pausa di un minuto verso lo stesso numero e limite di lunghezza del messaggio. Sono recinti scritti nel codice, non istruzioni nel prompt — un prompt si può aggirare, un recinto no.

Filtri in uscita, per i dati che non possono uscire

Quando un’integrazione restituisce più di quanto il cliente debba sapere, filtriamo in uscita, non speriamo che l’agente si trattenga. Un esempio reale: per un cliente del settore dei trasporti, la politica vieta che l’agente detti il numero di telefono dell’autista, ma l’API restituiva quei numeri nella risposta. Abbiamo scritto un filtro che percorre ricorsivamente il risultato dello strumento e rimuove i campi di contatto dell’autista, mantenendo i numeri della centrale operativa. Il filtro è applicato esattamente dove serve, non globalmente, così da non nascondere per errore altro.

Come si presenta

Il percorso, passo dopo passo.

L’inventario: quali sistemi, quali gate, quali diritti

Quali sistemi sono in gioco, cosa espone ciascuno, chi ha il diritto di creare credenziali e chi le ruota. Per ciascuno, la domanda di base: si può leggere senza autenticazione? Se sì, l’integrazione diventa molto più economica e molto più facile da ripetere con il secondo cliente.

Il connettore: strumenti dichiarati, chiavi sul server, termini

Ogni azione diventa uno strumento con un nome, una descrizione scritta per il modello, parametri tipizzati e un termine proprio. Le chiavi restano nell’ambiente del server. Alla fine, l’agente non «sa fare» qualcosa in modo vago: ha un insieme finito di azioni, ciascuna con i propri limiti.

Il test sul caso che fallisce, non solo su quello che funziona

Un connettore si testa sulla richiesta corretta, sulla richiesta incompleta, sul sistema che risponde lentamente e sul sistema che non risponde affatto. Ciò che dice l’agente quando l’integrazione cade è una decisione di progettazione, non un errore che scopre il cliente: preferiamo un messaggio onesto e un passaggio a un operatore umano, invece di un’improvvisazione plausibile.

La resilienza all’instabilità dell’altro sistema

Ritento con pause crescenti, ma solo sugli errori che ha senso ritentare — una limitazione di velocità o un errore del server, non una richiesta sbagliata, che sarà sbagliata anche la seconda volta. E quando il problema è a livello di rete dell’altro, il trattamento è diverso; l’esempio qui sotto è proprio un caso del genere.

Il passaggio di consegne: cosa cambia quando cambia il fornitore

Annotiamo cosa si rompe se l’altro sistema cambia la sua API, quali credenziali scadono e quando, cosa deve essere rinnovato manualmente. Un’integrazione senza questo elenco è un debito nascosto: funziona perfettamente fino al giorno in cui non funziona più e nessuno sa perché.

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.

I dati

Cosa tocchiamo, dove risiedono e quanto rimangono

Le domande che pone chiunque abbia un responsabile della protezione dei dati — poste qui prima che le ponga lui.

Dove stanno le credenziali: Le chiavi di fornitore della piattaforma stanno nell’ambiente del server, non nel database e mai nella pagina del cliente. Le credenziali proprie di un cliente — laddove l’integrazione le richiede — vengono memorizzate criptate. La distinzione conta: una chiave di piattaforma compromessa colpisce tutti, una credenziale di cliente colpisce un account; le trattiamo diversamente perché il rischio è diverso.
Cosa viene memorizzato dai sistemi esterni e cosa no: Il catalogo dei prodotti non viene copiato: viene letto su richiesta e mantenuto in una memoria temporanea di dieci minuti, così che dieci domande consecutive sullo stesso negozio non significhino dieci passaggi completi. Le programmazioni non vengono duplicate da noi — la fonte di verità resta il sistema del salone. Ciò che conserviamo è la traccia della conversazione e il risultato dell’azione, non una replica del database dell’altro sistema.
Ciò che arriva al modello linguistico: Il risultato di uno strumento entra nella conversazione, quindi entra anche nel contesto del modello. Per questo la filtrazione si fa sul risultato, prima che venga dato al modello, non nelle istruzioni. I campi che il cliente non ha il diritto di sentire vengono eliminati alla fonte; ciò che è stato eliminato non può essere dettato, indipendentemente da come venga interrogato l’agente.
Chi può collegare un'integrazione: Il collegamento di un'integrazione è un'operazione autenticata, legata all'account dell'azienda, e gli strumenti risultanti vengono associati a un agente specifico — non a tutti. Un agente ha esattamente gli strumenti di cui ha bisogno per il suo ruolo. È la stessa logica dell'accesso di un dipendente: non gli si danno tutte le chiavi perché è più semplice.
Ciò che resta da sistemare, detto apertamente: Non tutti i moduli di integrazione della nostra piattaforma sono allo stesso livello. Quelli elencati qui sono scritti ed eseguiti. Esistono anche moduli avviati, di poche decine di righe, che non fanno ancora nulla di utile — non li presentiamo come disponibili e non li inseriamo in alcuna offerta. Se ha bisogno di un sistema che da noi è in quello stadio, lo trattiamo come lavoro da costruire, con una verifica di compatibilità prima, non come una casella da spuntare.

Un caso

L'integrazione cadeva a intermittenza, e non era un problema nostro

La situazione

Un connettore CRM funzionava a volte sì e a volte no, senza un modello evidente a prima vista. Le richieste rimanevano in sospeso finché non superavano il limite di esecuzione dell'ambiente server, quindi nei log compariva un timeout — il segnale che porta, erroneamente, a cercare lentezza nel proprio codice.

Cosa abbiamo costruito

La causa era nella rete, dall'altro lato. Il nome di dominio dell'account CRM si risolve in più indirizzi IP, e una parte dei nodi del cluster era malsana. Una normale richiesta HTTP sceglie un indirizzo e, se quello non risponde, non prova gli altri indirizzi restituiti dal DNS — non esiste passaggio automatico alla risposta successiva. La correzione è stata smettere di usare il client HTTP predefinito per quel dominio: risolviamo noi il nome, apriamo connessioni crittografate direttamente verso ciascun indirizzo in parallelo, con un timeout breve per ognuno, e usiamo il primo che risponde; se tutti sono freddi in un giro, si ricomincia.

Cosa è emerso

Le interruzioni intermittenti hanno smesso di essere una lotteria. Più importante per il cliente: la diagnosi è diventata esprimibile in una frase — «i nodi del fornitore sono intermittentemente non disponibili, e noi li aggiriamo» — invece di «a volte non funziona».

Cosa non dice il caso

È una correzione che compensa un problema di qualcun altro, e va detto. Aggiunge complessità al nostro codice per un difetto nell'infrastruttura del fornitore; se questo ripara il proprio cluster, la complessità rimane da noi. La documentiamo come tale, così potrà essere rimossa quando non sarà più necessaria.

Domande

Cosa ci chiedono le persone prima di chiamare

Quali sistemi avete collegato effettivamente, non teoricamente?

Il sistema di prenotazioni Altegio, con sei azioni chiamate dall'agente. amoCRM e Bitrix24, con OAuth completo e aggiornamento del token. Google Sheets, con account di servizio dedicato. Negozi su WooCommerce, tramite l'API pubblica del negozio. Telegram, per le notifiche. Infobip, per gli SMS. Il canale chat di una piattaforma locale di annunci. Inoltre i canali di messaggistica Meta e Telegram per le conversazioni. Per qualsiasi altro sistema — incluse piattaforme di negozio che non abbiamo portato fino in fondo — la risposta onesta è: su richiesta, dopo una verifica di compatibilità, trattata come lavoro, non come impostazione.

Il mio negozio deve generarmi chiavi API?

Per WooCommerce, no. Usiamo l'API pubblica del negozio, che non richiede una chiave consumer — ci si collega con l'indirizzo del sito. È anche più sicuro, non solo più semplice: con questo approccio abbiamo sostituito strumenti più vecchi che tenevano chiavi del negozio scritte in chiaro nel database. Per altre piattaforme, dipende da ciò che espongono; verifichiamo prima di promettere.

L'agente può fare una vera prenotazione, non solo dire che la fa?

Sì, se il sistema di prenotazioni lo consente. Crea la prenotazione, può annullarla e modificarla, e verifica la disponibilità prima. Un dettaglio che si impara solo sul campo: in quel sistema, il servizio e lo specialista viaggiano insieme — se chiede le ore libere di uno specialista per un servizio che non svolge, riceve zero risultati, non un errore. Per questo lo strumento di disponibilità restituisce tutti gli specialisti che svolgono il servizio e le prime ore libere per ciascuno, così l'agente può proporre un'alternativa concreta.

Dove arrivano le mie chiavi?

Le chiavi di piattaforma restano nell'ambiente server, mai nel database e mai nella sua pagina. Le credenziali che sono sue vengono archiviate criptate. La regola che applichiamo: se una chiave può spendere denaro o può leggere dati per tutti i clienti, non ha motivo di trovarsi dove arriva codice eseguito su richiesta di un modello linguistico.

L'agente può inviare SMS a chi vuole?

No, ed è una restrizione deliberata. Nella modalità di notifica all’azienda, il destinatario viene dalla configurazione — il modello non lo può scegliere. Nella modalità verso il cliente, il numero viene normalizzato e convalidato. Oltre a questo esiste un tetto giornaliero per agente, una pausa di un minuto verso lo stesso numero e un limite di lunghezza del messaggio. Sono guardrail nel codice, non istruzioni nel prompt; un prompt si può aggirare con la conversazione, un guardrail no.

Cosa succede quando il sistema dell’altro si blocca o risponde lentamente?

Ogni strumento ha un proprio timeout di esecuzione, così un sistema lento non blocca la conversazione. Ritentiamo con pause crescenti, ma solo sugli errori che meritano di essere ritentati — una limitazione di rate o un errore del server, non una richiesta sbagliata. E il comportamento dell’agente in caso di errore si scrive nello сценарio: dice che non può verificare adesso e passa la conversazione, invece di inventare una risposta plausibile.

Cosa succede se il fornitore modifica la sua API?

Qualcosa si rompe, ed è per questo che preferiamo i gate ufficiali invece della lettura delle pagine. Gli strumenti che estraggono informazioni dall’HTML di un sito si rompono a qualsiasi cambio di tema — li abbiamo sostituiti deliberatamente con un’unica implementazione sull’API ufficiale, proprio per non mantenere decine di varianti fragili. Quando non esiste alternativa, diciamo che è una soluzione fragile e la trattiamo come tale.

Potete fare automazioni senza agente, solo regole programmate?

Sì. La ripresa delle conversazioni rimaste senza risposta, il primo messaggio a un nuovo contatto, l’arresto e la riattivazione dell’agente dopo l’orario di lavoro — sono attività programmate che girano da sole. Ognuna ha contatori propri per esecuzioni, messaggi inviati, messaggi saltati ed errori, così si può rispondere alla domanda «è stata eseguita?» con una cifra, non con un’ipotesi.

Come vi assicurate che l’agente non dica ciò che non deve, da un’integrazione?

Filtriamo il risultato prima che arrivi al modello, non dopo. Il caso concreto che abbiamo risolto: la politica di un cliente vietava che l’agente dettasse il numero di telefono dell’autista, ma l’API restituiva quei numeri. Abbiamo scritto un filtro che percorre ricorsivamente la risposta dello strumento e rimuove i campi di contatto dell’autista, mantenendo i numeri della centrale operativa, applicato esattamente a quello strumento. Ciò che non arriva al modello non può essere pronunciato, indipendentemente da come viene interrogato l’agente.

Su cosa si basano le affermazioni sopra (18 fonti)

18 di esse sono codice e file dei nostri repository. Non ne pubblichiamo il nome né la riga: insieme, in un'unica pagina, descriverebbero con troppa precisione come sono costruiti sistemi che non sono solo nostri. Le esaminiamo con te, nel repository, su richiesta — la verifica resta possibile, solo che avviene in una discussione.

Come lavoriamo Tutti i servizi

Cosa vorresti che funzionasse meglio?

Raccontaci il tuo processo. Insieme stabiliamo cosa vale la pena costruire, cosa possiamo collegare e come verifichiamo il risultato.

Parliamone