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à costruitoIntegrazioni proprie, scritte ed eseguite, misurate oggi nel codice: il connettore per il sistema di programmazione Altegio (946 righe, con sei strumenti esposti all’agente), il connettore CRM amoCRM (2.888 righe nella piattaforma di messaggistica, più 12 funzioni server nella piattaforma vocale), Bitrix24 (903 righe, più 4 funzioni), Google Sheets (615 righe, più 10 funzioni e un account di servizio dedicato), il catalogo vivo sopra il negozio (servizio di piattaforma, 318 righe), notifiche lead su Telegram (1.776 righe), SMS tramite Infobip con limiti anti-abuso, automazioni programmate (1.088 righe) e il canale chat di una piattaforma locale di annunci (2.459 righe). In esecuzione, l’agente può chiamare 15 tipi di strumenti interni, oltre a strumenti tramite webhook e strumenti con codice proprio eseguito in isolamento.

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.

Automazione trasparente — integrazioni verificabili · video in rumeno, con sottotitoli e trascrizione in italiano

La trascrizione completa

Entriamo direttamente nel vivo. Oggi analizzeremo le realtà tecniche e, sinceramente, spesso ignorate, dell’automazione tramite assistenti basati sull’intelligenza artificiale. Ci concentreremo su un approccio super pragmatico della piattaforma iCat.md sviluppata da Mega Promoting. Oggi non abbiamo promesse di marketing e, certamente, non abbiamo concetti vaghi. Parliamo di una piattaforma già in produzione, con funzionalità spiegate direttamente dall’architettura del database. Quindi vediamo com’è, in realtà, un’automazione completamente trasparente. L’agenda di questa analisi è semplice e diretta. Passiamo dal problema del tempo, alla meccanica della tecnologia, a un caso reale, ai limiti chiari del sistema, alla gestione dei dati e ai passi successivi. Iniziamo con la prima sezione, il problema del tempo. Conoscete tutti quella domanda estremamente frustrante? Perché un intero team di supporto perde ore buone, giorno dopo giorno, scrivendo a mano risposte alle stesse identiche cinque domande?

L’informazione esiste già sul sito dell’azienda, ma, nonostante ciò, i clienti continuano a chiedere ripetutamente i dettagli. Ed è proprio questo il punto del nostro problema. Senza una soluzione tecnica adatta, tutte queste richieste ripetitive intasano semplicemente la messaggistica diretta, non importa se sia Instagram o Messenger. Di conseguenza, le risposte arrivano in forte ritardo per i clienti che hanno davvero un problema complesso, le richieste si perdono nel mare dei messaggi, e l’intero processo di supporto diventa praticamente una scatola nera che non si può né verificare né misurare. Parte due. Come funziona, in realtà, la tecnologia sotto il cofano? Ecco come stanno le cose. La configurazione della piattaforma si basa su quattro passaggi molto logici. Per prima cosa colleghiamo i canali di comunicazione usando codice proprio.

Poi si indicizza tutta la base di conoscenza. Segue il collegamento degli strumenti che possono eseguire azioni nei vostri sistemi esistenti. E infine, e questo dettaglio è vitale, si configura un percorso chiaro registrato direttamente nel database, attraverso il quale il bot passa la conversazione a un operatore umano. Tutto è un sistema visibile e perfettamente configurabile. Ora, un aspetto assolutamente affascinante. Non stiamo parlando a caso da qui. Queste sono impostazioni estratte direttamente dallo schema del database. Quando l’assistente ha bisogno di una risposta, usa la cosiddetta ricerca ibrida. Per impostazione predefinita, l’algoritmo estrae 5 frammenti di testo, applica una soglia rigorosa di similarità di 0-70 e assegna un’importanza del 30% alla corrispondenza esatta delle parole. Tutto viene elaborato tramite il modello Text Embedding 3 Small.

In pratica, il sistema trasforma le parole in concetti matematici per cogliere il contesto esatto. Le risposte non sono indovinelli, ma matematica pura. Ricordatevi questo numero. 15. È un limite tecnico assoluto nel sistema. Rappresenta il tempo massimo, in secondi, assegnato per eseguire qualsiasi strumento o ricerca. Se un’integrazione esterna richiede più tempo di così, diciamo che ha bisogno di 40 secondi, non possiamo lasciarla nel flusso live della conversazione. Deve essere elaborata in asincrono, altrimenti si romperebbe completamente il ritmo naturale del dialogo. E c’è anche altro. Le persone scrivono in chat a raffica, no? 2, 3, 4 messaggi brevi inviati uno dopo l’altro. Per non mandare il sistema in tilt, esiste un buffer di concatenazione di 15 secondi.

Tutto ciò che entra in questa finestra viene unito e diventa una sola richiesta chiara. Inoltre, su piattaforme come Meta, dove a volte si incontrano messaggi duplicati inviati per errore, il sistema applica un filtro di memoria di 120 secondi sull’ID del messaggio. Così il cliente riceve una sola risposta coerente, non 3 falsi allarmi. Terza sezione. Vediamo un caso reale. Abbiamo questo classico scenario e-commerce. Abbiamo un negozio online, con un catalogo impeccabile sul sito, ma che riceve una valanga di messaggi privati su Instagram e Messenger? È ancora in stock? Quanto costa? Qui l’integrazione è stata fatta in modo elegante, collegando l’assistente direttamente all’interfaccia pubblica Store API di WooCommerce. Senza complicazioni di sicurezza, il catalogo vivo del negozio è stato semplicemente messo nelle mani dell’assistente.

Solo qui entra in gioco la realtà tecnica di ogni piattaforma, anche sotto l’ombrello della stessa azienda, come Meta. Su Messenger, l’assistente può mostrarvi splendidi caroselli di prodotti. Su Instagram, il bot vi risponderà solo con testo e al massimo un’immagine semplice. Perché? Semplicemente perché Meta non supporta quei template generici su Instagram. L’assistente deve giocare esattamente secondo le regole del canale in cui si trova. Qui è il punto critico. Cosa succede quando il bot viene superato dalla situazione? Ebbene, nel database la conversazione ha stati espliciti. Quando una domanda esce dalla zona di comfort del catalogo, il filo della discussione passa immediatamente dallo stato bot allo stato umano. E la parte geniale è che il sistema contabilizza il tempo in cui risponde l’operatore umano, segnando tutto chiaramente, status OK, avvertimento o termine superato.

Tutto il contesto viene passato all’uomo, senza che si perda assolutamente nulla per strada. Sezione A4 Limiti del sistema Perché la trasparenza significa sapere cosa non può fare. Ci sono alcuni limiti fermi che dobbiamo accettare. Non potete inviare messaggi proattivi su WhatsApp se sono passate più di 24 ore dal messaggio del cliente. Meta restituirà un errore, più precisamente l’errore 131047, e l’azione fallirà. Il sistema non fa file RPDF, non legge gli allegati. Per quanto riguarda le lingue straniere, le traduzioni funzionano solo in un’unica direzione. Il cliente riceve la risposta tradotta, ma l’operatore vede l’originale. E, sebbene l’integrazione con 999.md funzioni, è non ufficiale e si basa sui cookie del browser. Se la piattaforma modifica i propri meccanismi, la connessione cade e richiede riparazioni.

E ricordatevi assolutamente questo. L’assistente è lo specchio dei vostri dati. Un prezzo sbagliato sul sito diventerà garantitamente un prezzo sbagliato nella conversazione. Funziona come un lettore, non come un gestore del negozio. Non correggerà di propria iniziativa gli errori umani nei cataloghi. L’infrastruttura tecnica qui non è uno scherzo. Tutto è ospitato su un server privato Microsoft Azure. Stiamo discutendo di un database MySQL estremamente strutturato, con oltre 80 tabelle modellate chiaramente per separare i canali e per l’audit. Le chiavi di accesso per WhatsApp, che sono super sensibili, usano la crittografia fernet. Oltre a questo, a livello web, i domini per il widget di chat vengono aggiunti manualmente in una whitelist. Nessuno si connette senza permesso esplicito. Però dobbiamo affrontare una realtà evidente.

Le persone scriveranno ogni genere di dati personali in quelle finestre di chat, numeri di telefono, indirizzi. Tecnicamente, non si può bloccare un campo di testo libero. Quindi la soluzione è amministrativa. Quando implementate un tale sistema, avete bisogno, fin dal secondo 1, di politiche chiare di retention che indichino esattamente chi ha il diritto di vedere quei dati e per quanto tempo vengono conservati. E siamo arrivati al punto 6. I passi successivi. La filosofia centrale dell’intero sistema può essere riassunta da questa citazione. Un assistente utile non è quello che compone poesie o scrive bene, ma quello che è connesso a informazioni reali e, cosa molto importante, sa esattamente dove deve fermarsi. L’automazione efficace nel business significa prendere correttamente i dati e la sicurezza con cui cede il controllo a un operatore umano nel momento opportuno.

Di conseguenza, il passo successivo non è comprare un software, ma analizzare con attenzione i vostri processi attuali. Valutate quali flussi di lavoro meritano davvero di essere costruiti e automatizzati, come si possono collegare in sicurezza e, cosa più importante, stabilite come misurerete i risultati con dati reali, non con illusioni di marketing. E vi lascio con questo spunto di riflessione. Tra tutti i processi di comunicazione in un’azienda, quali sono quelli che richiedono davvero l’empatia e il tatto di una persona e quali sono, in realtà, solo compiti ripetitivi che aspettano semplicemente di essere collegati con precisione al database giusto? Qualsiasi piano di automazione dovrebbe partire da questa domanda. Grazie per essere stati con noi in questa analisi!

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

I sistemi esterni attorno alla conversazione: prenotazioni, il catalogo del negozio, CRM, fogli di calcolo, SMS e canali di messaggistica — ciascuno letto su richiesta, con le chiavi rimaste sul 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