Un ticket chiuso da una persona del customer care costa in media 7 dollari, secondo i calcoli di Intercom. Con la nostra nuova live chat, 7 dollari sono il costo di mille messaggi gestiti dall’AI.
In questo articolo racconto come abbiamo costruito tutto da zero in 24 ore: le decisioni, il codice, gli errori e i numeri.
Ecco cosa vedremo:
Da dove partivamo: Open Widget, le API di OpenAI e l’80% dei ticket gestiti dall’AI
Il trigger che ci ha costretti a muoverci in una settimana
L’analisi di 3.131 ticket che ha guidato ogni scelta
L’architettura nuova: interfaccia custom con Claude Code, Flowise come cervello, GPT 5.4 mini come modello
Le basi del system prompt (senza rivelarlo, per ovvie ragioni)
I costi veri, messaggio per messaggio, confrontati con Fin di Intercom
Perché il customer care non sparisce ma cambia mestiere
Cosa costruiamo adesso
NB: questa live chat da sola può essere creata per clienti e venduta a migliaia di euro semplicemente spiegando l’enorme risparmio che possono ottenere al posto di usare tool come Intercom, Zendesk ecc.
Ma prima di iniziare... se non sei ancora iscritto/a puoi farlo da qui o condividerlo ad un tuo/a collega.
PARTE 1: DA DOVE PARTIVAMO
A dicembre 2024 avevo raccontato come, in un weekend, avevo collegato OpenWidget (un tool gratuito per mettere una live chat sul sito) alle API di OpenAI. Un assistente con un system prompt curato, il contesto giusto su Learnn e un fallback verso il form di supporto quando non sapeva rispondere.
Quel sistema ha funzionato molto più di quanto ci aspettassimo. Nel giro di qualche mese abbiamo smesso di usare tool di ticketing tradizionali: la combinazione chat AI più form ha ridotto di circa l’80% i ticket che arrivavano a una persona. Per una startup bootstrap di venti persone, con 286 mila utenti registrati, è stata una delle automazioni con il ritorno più alto che abbiamo mai fatto.
Però aveva limiti strutturali, e col tempo sono diventati sempre più fastidiosi:
Zero export delle conversazioni. Per capire cosa chiedevano gli utenti dovevi leggerti le chat una a una dal pannello di Open Widget.
Accessi fragili: un solo login condiviso, inviti che non funzionavano, il widget che ogni tanto si bloccava e andava riattivato a mano.
Nessun tool. L’assistente poteva solo rispondere, mai agire o cercare informazioni fresche.
L’aggiornamento del prompt avveniva sul pannello di OpenAI, scollegato da tutto il resto.
PARTE 2: IL TRIGGER
Il 15 luglio Carlotta, del nostro team User, scrive su Slack: “mi ricordate quando scade la chat AI?”.
La risposta era: presto. OpenAI sta dismettendo la Assistants API in favore della nuova Responses API, e OpenWidget (che è ancora in beta) si appoggia proprio alla Assistants API, senza nessuna certezza di aggiornamento. Deadline stimata: inizio agosto.
Abbiamo aperto una issue con tre opzioni sul tavolo:
Restare su OpenWidget sperando in una migrazione alle Responses API
Passare a un tool esterno come Intercom con Fin, il suo agente AI
Internalizzare tutto su Flowise, la piattaforma open source che già usiamo self-hosted per orchestrare i nostri agenti AI
Fin è un ottimo prodotto e i loro numeri pubblici sono la miglior validazione del mercato: risolve da solo circa il 70% dei ticket e costa 0,99 dollari per ogni risoluzione. Il loro argomento di vendita è che un ticket chiuso da un umano costa in media 7 dollari, quindi 99 centesimi sono un affare.
Il punto è che noi Flowise ce l’avevamo già in casa, self-hosted, a costo quasi zero. E avevamo già il system prompt rodato da un anno e mezzo di produzione. Il lunedì sera Luca Pirrone, del nostro team tech, fa uno spike: ricrea il chatbot su un flusso Flowise agentflow v2, ci porta dentro il prompt esistente e conclude che la strada è quella. Più controllo, più visibilità sulle conversazioni e la possibilità di collegare tool al flusso.
Giovedì alle 14:35 la nuova chat era in produzione. Dal primo spike al rilascio: quattro giorni di calendario. Il lavoro effettivo sulla parte nuova, l’interfaccia custom e l’integrazione: meno di 24 ore.
PARTE 3: PRIMA DEL CODICE, I DATI
La cosa che mi interessa di più raccontare non è la velocità, è il metodo. Prima di scrivere una riga di codice abbiamo analizzato migliaia di richieste vere: 3.131 ticket arrivati dal form negli ultimi nove mesi, 260 conversazioni della vecchia live chat e oltre 13 mila messaggi mandati a Learnn AI dentro la piattaforma. Avremmo putiti analizzarne molti di più, ma ci sembrava un buon compromesso.
Da lì sono uscite le risposte alle domande che contano:
Cancellazioni, rimborsi e pagamenti
Orientamento in piattaforma e prodotto
Pre-sale: orientamento pre-acquisto (”che corso fa per me?”, “quanto costa?”) e problemi di accesso.
Sta crescendo un cluster nuovo che un anno fa non esisteva: domande su MCP e su come collegare Learnn a Claude.
In generale ci sono molti utenti che non vogliono leggere il sito e solo fare le domande che sono importanti per loro direttamente in chat. La nostra live chat conosce questa esigenza e attraverso il system prompt riconosce la necessità e si trasforma da assistente a consulente di vendita.
Questa analisi ha deciso tutto: quali suggerimenti mostrare nella chat, quali scorciatoie self-service mettere in evidenza, quali casi l’AI deve gestire da sola e quali deve portare a una persona. Se c’è un consiglio operativo che mi sento di dare a chiunque voglia fare una cosa simile è questo: parti dalle domande reali dei tuoi utenti, non dalle feature del tool. Il tool viene dopo.
PARTE 4: L’ARCHITETTURA
La nuova live chat è composta da tre pezzi che parlano tra loro.
1. Il guscio custom, costruito con Claude Code
L’interfaccia che l’utente vede è un widget scritto da zero, prendendo ispirazione da quello che fanno meglio Intercom e Fin: un launcher sempre presente sul sito, una Home con le domande frequenti cliccabili e gli accessi rapidi (gestione abbonamento, fattura), una tab Messaggi con la chat vera e propria.
L’abbiamo costruito iterando su un singolo file HTML con Claude Code: si modificava il file, si apriva nel browser, si vedeva il risultato, si iterava. Niente framework, niente build: CSS e JavaScript dentro un unico file che poi è diventato un tag di Google Tag Manager. Il deploy in produzione è stato letteralmente pubblicare un tag GTM.
Un dettaglio a cui tengo: dopo circa dieci secondi che sei sul sito, il widget ti manda un messaggio proattivo con dei suggerimenti già pronti (”Cosa posso fare con Learnn?”, “Che corso fa per me?”, “Quanto costa Learnn?”). Oggi sono statici, ma l’architettura è pronta per renderli dinamici in base alla pagina in cui ti trovi: suggerimenti diversi sulla pagina prezzi, sulla pagina di un corso, sul checkout. È l’equivalente digitale del commesso che ti chiede se hai bisogno, al momento giusto invece che appena entri.
Qui abbiamo anche inserito tracciamenti utm su ogni click in modo da capire quante conversioni porta la live chat da sola sia dentro al widget che dentro al system prompt di Flowise che vedremo a breve.
2. La chat, embed nativo di Flowise
Dentro la tab Messaggi non abbiamo riscritto la chat: usiamo l’embed ufficiale di Flowise, ritematizzato via CSS per sembrare parte del nostro design system. Questa è stata la decisione architetturale più importante e la scrivo com’è stata formulata internamente: una via di mezzo tra il widget pronto all’uso di Flowise e un widget completamente custom. Flessibilità totale sulla UX del primo contatto, zero reinvenzione delle funzionalità già integrate (streaming delle risposte, storico, feedback).
Qui la parte tecnica divertente, per chi scrive codice. Integrare un embed dentro un guscio custom significa combattere con dettagli che nessun tutorial ti racconta:
La textarea di Flowise calcola la propria altezza come “scrollHeight meno 24” a ogni input, ed è sempre una riga indietro rispetto al testo reale: a due righe scritte mostra l’altezza di una, tagliando il testo. L’abbiamo corretta ricalcolando noi l’altezza con un listener delegato su document, perché il framework interno (Solid.js) ricrea il nodo della textarea e un listener diretto si perde.
Per precompilare l’input quando l’utente clicca un suggerimento non basta impostare il valore e lanciare un evento sintetico: lo stato interno di Solid non si aggiorna e il tasto invio diventa un no-op. La soluzione è
document.execCommand("insertText"), che genera un input event nativo attraversando lo shadow DOM.Flowise intercetta le frecce su e giù per richiamare i messaggi precedenti anche dentro un input multi-riga, senza controllare dove sta il cursore. Disattivato, altrimenti scrivere un messaggio di tre righe diventava impossibile.
Sono dettagli minuscoli, ma sono la differenza tra una chat che “funziona in demo” e una che regge utenti veri. E sono esattamente il tipo di lavoro in cui Claude Code cambia i tempi: ognuno di questi bug è stato diagnosticato e risolto in minuti, documentando il perché direttamente nei commenti del codice.
3. Il cervello: Flowise più GPT 5.4 mini
Dietro l’interfaccia c’è un flusso su Flowise: un agente collegato alle API di OpenAI, modello GPT 5.4 mini. La scelta del modello è una scelta di costo e latenza: per il 90% delle domande di supporto non serve il modello più potente sul mercato, serve un modello veloce, economico e ben istruito. La risposta media arriva in 2-3 secondi.
All’agente sono collegati dei tool. Oggi il principale è un RAG sul catalogo: quando chiedi “che corsi avete per le ads”, l’agente cerca davvero nel catalogo e ti risponde con corsi e link reali, cosa che OpenWidget non poteva fare in nessun modo. Abbiamo anche imparato una lezione di costi qui: la prima versione usava lo stesso tool di ricerca del nostro MCP pubblico, troppo pesante e costoso per una chat di supporto. Ne abbiamo fatto una versione semplificata apposta.
Ma la direzione vera sono i tool che agiscono, non solo che leggono: emettere rimborsi, leggere i dati dell’account, cambiare email, aggiornare informazioni. Su questo la nostra posizione è netta, e ne parlo nella parte 7.
PARTE 5: IL SYSTEM PROMPT
Non pubblicherò il system prompt (tra le sue regole c’è proprio quella di non rivelarsi, sarebbe ironico violarla io per primo), ma posso raccontare le basi, perché sono più interessanti del testo stesso.
Il prompt è costruito su un principio di classificazione: ogni richiesta che arriva ricade in uno di tre tipi, e la prima cosa che l’agente fa è riconoscere quale.
Domande di informazione: “come scarico la fattura”, “come funziona il piano”. L’agente risponde da solo, fondando la risposta sulla knowledge base degli articoli di supporto e citando il link dell’articolo, così l’utente può approfondire.
Richieste di azione sull’account: rimborso, disdetta, cambio email. L’agente non le esegue: porta l’utente al flusso self-service giusto, spiegando in una riga cosa succede dopo. Questo da solo elimina una quota enorme di ticket, perché la maggior parte delle persone apriva un ticket per cose che poteva fare in autonomia.
Casi che richiedono una persona: verifiche sull’account, pagamenti complessi, insoddisfazione delicata. Qui l’agente indirizza al form di supporto, senza girare a vuoto.
Sopra questa struttura ci sono famiglie di regole che vale la pena elencare, perché sono replicabili in qualsiasi business:
Regole di grounding: mai rispondere a memoria quando esiste un articolo dedicato, mai inventare URL o procedure, mai promettere tempi di risposta che non controlliamo.
Regole di tono: empatia prima della soluzione quando l’utente è frustrato, frasi corte, niente aperture piatte. Ci sono perfino regole anti-scrittura-da-AI: niente trattini lunghi, niente triplette ritmiche, niente enfasi vuota. Vogliamo che le risposte sembrino scritte da una persona del team, perché lo standard l’ha fissato una persona del team.
Regole di processo sui casi delicati: per un rimborso l’agente non sgancia subito il link del form. Prima chiede il motivo, poi risponde in modo personalizzato in base alla causa (prezzo, tempo, contenuti, problema tecnico), e solo se l’utente insiste dà la procedura completa con tutte le condizioni trasparenti. Retention fatta con rispetto, senza dark pattern.
Regole di misurazione: ogni link che l’agente inserisce verso una pagina Learnn porta parametri UTM dedicati. Questo significa che ogni visita, iscrizione o upgrade che parte dalla live chat è attribuita. Quando qualcuno mi chiede come si dimostra il ritorno di un progetto AI, la risposta è: lo strumenti dal giorno uno.
Il consiglio operativo qui: il system prompt di un agente di supporto non è un testo creativo, è documentazione operativa. Il nostro nasce dalle procedure reali del team User e viene aggiornato con una procedura scritta: controllo settimanale delle conversazioni, aggiornamento quando emergono risposte poco chiare, check dedicato quando parte una promo e pulizia quando finisce.
PARTE 6: I COSTI VERI
Veniamo ai numeri, che è il motivo per cui molti di voi hanno aperto questo articolo.
Ogni messaggio gestito dalla nostra live chat ci costa in media 0,007 dollari. Non 7 centesimi: 0,7 centesimi. Il tracciamento di Flowise ce lo mostra conversazione per conversazione: una risposta tipica consuma circa 7-8 mila token e costa tra 0,005 e 0,010 dollari a seconda di quanto contesto serve.
Facciamo i conti su scala:
1.000 messaggi: circa 7,2 dollari
10.000 messaggi: circa 72 dollari
Una conversazione media (3-4 messaggi): circa 2,5 centesimi
Ora il confronto con l’alternativa “compra invece di costruire”. Fin di Intercom costa 0,99 dollari per ticket risolto. Una risoluzione può contenere più messaggi, quindi il confronto onesto è per conversazione: la nostra costa circa 2,5 centesimi, la loro 99. Quaranta volte tanto. E rispetto ai 7 dollari del ticket gestito da una persona (la stima è di Intercom stessa), il rapporto diventa di quasi 300 a 1: con il costo di un singolo ticket umano, il nostro agente gestisce mille messaggi.
Sono confronti imperfetti, lo so: Fin include l’infrastruttura, noi ci mettiamo il self-hosting di Flowise e il tempo di manutenzione. Ma anche caricando tutti i costi nascosti, l’ordine di grandezza non cambia. E c’è un vantaggio che non entra in nessun calcolo di costo per ticket: questo agente risponde 24 ore su 24, anche il sabato sera, anche a Ferragosto. Una startup della nostra dimensione non potrà mai permettersi un team di customer care umano su quelle fasce orarie. Non è un risparmio, è una capacità che prima semplicemente non avevamo.
I primi dati di utilizzo confermano il volume: nelle prime 24 ore dalla messa in produzione la chat ha gestito 121 sessioni e 424 messaggi. Costo totale della giornata: circa 3 dollari.
PARTE 7: LE PERSONE NON SPARISCONO
Questa parte mi interessa particolarmente, perché è dove si gioca la differenza tra automazione fatta bene e automazione fatta per tagliare.
La nuova architettura ci permetterà di collegare all’agente tool che eseguono azioni delicate: rimborsi, modifiche all’account, cambi email. La tentazione sarebbe lasciare che l’AI faccia tutto da sola. Non lo faremo. Il modello che stiamo costruendo è human-in-the-loop: l’agente prepara l’azione e chiede l’approvazione a una persona del team, con tutto il contesto già pronto. Un click per approvare, un click per rifiutare.
Il ruolo del customer care passa così da esecutore ad approvatore. La differenza di tempo è enorme: verificare e approvare un rimborso già istruito richiede una frazione del tempo che serve a gestirlo da zero. E ci sono aree che abbiamo deciso esplicitamente di non automatizzare mai del tutto, come la valutazione dei rimborsi e le risposte alle recensioni, dove il giudizio umano è il prodotto.
Il tempo liberato non è tempo tagliato. Una delle persone del team sta diventando di fatto l’orchestratrice di questi sistemi: monitora le conversazioni, ottimizza il prompt, decide cosa automatizzare dopo.
E il resto del tempo va dove la presenza umana rende davvero. Su questo abbiamo un caso interno che spiega il concetto meglio di qualsiasi teoria: il lavoro che Michele sta facendo da mesi con i nostri utenti.
Michele ha iniziato con le user interview classiche: una decina di chiamate a settimana con chi si è appena iscritto, su Calendly, per capire perché le persone arrivano su Learnn e cosa le blocca. In sei mesi ne ha fatte circa 120. E a un certo punto è successa una cosa che non avevamo previsto: a fine intervista gli utenti chiedevano di risentirsi. Le interviste si sono trasformate in chiamate di orientamento, che oggi offriamo gratuitamente soprattutto agli utenti Pro ma anche a chi ha appena creato l’account e non si è ancora attivato.
Da quelle 120 conversazioni è uscito anche un insight che sta riorientando la nostra strategia: solo 3 utenti su 10 sono il classico early adopter che esplora da solo. La maggioranza è pubblico mass market, che non compra “più corsi” ma la sicurezza di non sbagliare e ha bisogno di essere portata in quota prima di volare da sola.
Ecco il punto che tiene insieme questo articolo: rispondere a “quanto costa Learnn?” alle 23:00 di sabato non ha bisogno di un essere umano e da questa settimana non lo occupa più. Aiutare una persona confusa a capire da dove partire per far crescere il proprio lavoro, sì. La sintesi che uso internamente: stiamo togliendo l’umano da dove non serviva e lo stiamo mettendo dove serviva da sempre e non c’era mai tempo di stare.
PARTE 8: COSA COSTRUIAMO ADESSO
Il bello di avere tutto in casa è che ogni miglioramento è a portata di iterazione, senza aspettare la roadmap di un fornitore. Le prossime cose in ordine di priorità:
Analisi automatica settimanale delle conversazioni. Ogni messaggio è tracciato, quindi possiamo costruire una routine che ogni settimana legge tutte le conversazioni, trova le risposte deboli e propone le modifiche al system prompt. Una persona approva, il sistema si migliora da solo. È il pezzo che chiude il cerchio: oggi l’ottimizzazione del prompt è manuale, domani sarà una proposta automatica da approvare, con la stessa logica human-in-the-loop delle azioni.
Suggerimenti dinamici per pagina. Il messaggio proattivo dopo dieci secondi oggi mostra sempre le stesse tre domande. La versione successiva le adatterà alla pagina: sul pricing ti parlerà di piani, su un corso ti proporrà il percorso collegato.
Contesto utente. Per gli utenti loggati, l’agente potrà sapere chi sei e a che punto sei e dare risposte contestuali invece che generiche.
Gli action tool con approvazione, di cui sopra: prima i casi che coprono la maggior parte dei ticket (rinnovi, disdette, accessi, fatture), poi il resto.
Il criterio con cui ordiniamo questa lista è sempre lo stesso ed è il punto di partenza di tutto l’articolo: quali sono le vere esigenze degli utenti e del team. L’AI applicata al supporto non è un progetto di risparmio, è un progetto di servizio. Il risparmio è la conseguenza.
PARTE 9: QUESTA COSA SI PUÒ VENDERE
Fermiamoci un attimo sui numeri di mercato, perché qui dentro c’è un’opportunità di business per chiunque sappia fare quello che ho appena descritto.
Guardate cosa costano i tool di supporto AI là fuori, a listino 2026:
Intercom: da 29 a 132 dollari per postazione al mese, più Fin a 0,99 dollari per ogni risoluzione (con un minimo mensile di 50). Un team di 8 persone sul piano Advanced con 2.100 risoluzioni AI al mese spende circa 2.960 dollari al mese, oltre 35 mila all’anno.
Zendesk: da 55 a 115 dollari per agente al mese, più le risoluzioni automatiche fatturate a parte (circa 1,50-2 dollari l’una oltre la piccola quota inclusa) e il copilot per gli agenti a circa 50 dollari a testa. Un’azienda che automatizza 3.000 risoluzioni al mese aggiunge 3-6 mila dollari al mese solo di AI.
Freshdesk: copilot a 29 dollari per agente al mese, agente AI a 49 dollari ogni 100 sessioni dopo le prime 500.
Anche i tool “economici” come Tidio partono da circa 0,58 dollari a conversazione AI, con piani che salgono fino a 749 dollari al mese.
Ora rileggete i nostri numeri: 7 dollari ogni mille messaggi, su un’infrastruttura open source che possediamo. Per una PMI italiana che riceve qualche migliaio di richieste al mese, la differenza tra un contratto Intercom o Zendesk e una soluzione come la nostra sono decine di migliaia di euro all’anno, ogni anno.
Questo significa che quello che ho descritto in questo articolo è un servizio vendibile.
Se sei un freelance o una piccola agenzia con competenze AI, puoi costruire per un cliente esattamente quello che abbiamo costruito noi per Learnn e fartelo pagare migliaia di euro, esattamente come oggi un sito web custom si vende a migliaia di euro. Con almeno tre modelli di prezzo possibili:
Fisso di implementazione: analisi delle richieste del cliente, system prompt, widget, flusso, deploy. Un progetto chiavi in mano.
Fisso più ricorrente: l’implementazione più un canone mensile per l’ottimizzazione continua del prompt, l’aggiornamento della knowledge base, il cambio modello quando ne esce uno migliore, i report sulle conversazioni. È la parte dove si crea il valore composto, ed è anche la più difficile da fare per il cliente da solo.
Solo ricorrente, per chi preferisce abbassare la barriera d’ingresso e costruire un portafoglio di clienti in abbonamento.
In Italia questa dinamica esiste già in un altro mercato e funziona da quindici anni: moltissime aziende scelgono WooCommerce o Magento con un’agenzia invece di Shopify, proprio per pagare un progetto e un partner invece di un canone SaaS che cresce col volume. Il supporto clienti AI sta seguendo la stessa traiettoria, con una differenza: il bacino è più largo, perché i potenziali clienti sono sia le aziende che oggi pagano un tool di supporto costoso, sia le tantissime che una live chat non ce l’hanno proprio.
E attenzione a non vendere solo il risparmio, perché sarebbe l’argomento sbagliato. Il valore vero è quello che ho raccontato nelle parti precedenti: un agente che risponde al posto tuo 24 ore su 24 fondandosi sulle tue procedure reali, un’interfaccia che è tua e si adatta al tuo brand invece di essere il widget uguale per tutti, la libertà di cambiare modello quando ne esce uno più adatto (noi oggi usiamo GPT 5.4 mini, domani potrebbe essere altro, senza chiedere il permesso a nessuno), i dati delle conversazioni che restano tuoi e diventano intelligenza di prodotto. Il risparmio è quello che fa firmare il preventivo. Il controllo è quello che fa rinnovare il contratto.
DOMANDE E RISPOSTE
Sotto il post LinkedIn collegato a questo articolo sono arrivate parecchie domande. Raccolgo qui le più comuni con le risposte.
1. Senza lo storico di domande avreste avuto la stessa qualità di risposta?
No. Ma il punto è che nemmeno noi siamo partiti con lo storico. Quando abbiamo lanciato la prima chat su OpenWidget l’abbiamo messa live in 7 giorni partendo da un system prompt generale, testato a mano con le domande più frequenti che già conoscevamo. Era un buon 20-80. Da lì in poi, ogni settimana leggevamo domande e risposte e facevamo un ciclo di ottimizzazione del prompt. Lo storico non è un prerequisito, è il risultato: parti imperfetto e ogni settimana il sistema migliora. È sempre un processo, mai un lancio.
2. Quanto è costato lo sviluppo, tool più ore delle persone?
Veramente poco. I tool sono a costo quasi zero: Flowise è open source e self-hosted, il widget è un file HTML dentro Google Tag Manager, l’unico costo variabile sono le API del modello (i famosi 7 dollari ogni mille messaggi). Il costo vero sono le ore delle persone: uno spike di una sera per validare Flowise e meno di 24 ore di lavoro effettivo su interfaccia e integrazione, distribuite su quattro giorni di calendario insieme a tutto il resto. Se dovessi stimarlo come progetto per un cliente, siamo nell’ordine di qualche giornata uomo, non di mesi.
3. L’avete rifatta in 24 ore perché sotto c’era già un sistema chiaro, giusto? Altrimenti ci avreste messo settimane anche con l’AI.
Il sistema chiaro c’era ed è stato decisivo: system prompt rodato da un anno e mezzo, procedure del team User scritte, analisi dei ticket già fatta. Ma onestamente non credo che oggi ci avremmo messo settimane nemmeno partendo da zero o da un sistema imperfetto. La velocity con questi strumenti è aumentata tanto, e la parte che prima costava settimane (interfaccia, integrazione, fix cross-browser) oggi si fa in ore. Quello che l’AI non ti regala è sapere cosa costruire: quella parte viene dai dati e dalle persone, e lì il tempo lo devi investire comunque.
4. Come gestite la diffidenza verso le chat AI e chi chiede subito di parlare con un umano?
Non forziamo nessuno a restare con l’AI. La chat è impostata per portarti all’apertura di un ticket con una persona in due casi: quando non ha un’informazione attendibile e quando lo chiedi esplicitamente. Niente giri a vuoto, niente “sei sicuro di non voler riprovare”. La fiducia si costruisce proprio così: l’AI che conosce i suoi limiti è quella che le persone accettano di usare.
5. Ma un supporto senza AI non sarebbe un vantaggio competitivo, visto che ormai le chat AI stanno ovunque e spesso fanno arrabbiare?
Secondo me il problema nasce quando metti l’AI a fare un lavoro che dovrebbe fare un umano, e vale anche il contrario. Se ho bisogno di un’informazione veloce o di avviare un rimborso alle 23:00, aspettare una persona peggiora la mia esperienza, non la migliora. E attenzione all’obiezione “basta leggere l’help center”: presuppone un utente esperto. Tantissimi ci scrivono in chat solo per avere una conferma, tipo “ma davvero ho tutti i corsi inclusi nell’abbonamento?”. Quel target l’help center non lo aprirà mai. La relazione umana la stiamo concentrando dove cambia davvero le cose, come le chiamate di orientamento di cui ho scritto sopra.
6. Come fa l’agente ad avere contesto sul prodotto e a restare aggiornato quando la piattaforma evolve?
Oggi è tutto mappato nel system prompt, che ha molto spazio di contesto e viene aggiornato con una procedura settimanale. La prossima evoluzione è più strutturale: stiamo migrando il sito marketing (blog, documentazione, landing) a Next.js con i contenuti su Strapi, il nostro CMS headless, creati e verificati via flussi di agenti prima di andare live su GitHub. Una volta lì, vettorializziamo la documentazione pubblica e Flowise risponderà via RAG su quella, invece che su un prompt gigante. Il prompt resta per le regole, la conoscenza si sposta su una base aggiornabile.
7. La soglia di approvazione umana è ancora quella di lancio o si è già allargata? Di solito è la prima cosa che si allarga quando i numeri crescono.
Domanda giusta ma è presto per rispondere: siamo in produzione da giovedì. La filosofia però è fissata: le azioni di scrittura (rimborsi, modifiche account) passano sempre da un’approvazione umana, e allargheremo la soglia solo con l’evidenza delle conversazioni tracciate, non per comodità. Se tra qualche mese la soglia si sarà spostata, lo racconterò qui con i numeri.
8. Avete analizzato migliaia di richieste degli utenti: come avete gestito la privacy?
Le analisi sono state fatte su dati senza alcun identificativo: ci interessavano le domande, non chi le faceva. In più il sistema anonimizza in automatico le informazioni sensibili che passano in chat, come le email, che comunque la chat stessa dice esplicitamente di non inviare. Le domande generali (”come funziona il rimborso?”) non sono dati personali, e tenerle separate dalle identità è quello che rende l’analisi possibile senza rischi.
COSA PORTARSI A CASA
I DATI PRIMA DEL TOOL. Abbiamo analizzato 3.131 ticket prima di scrivere codice. Ogni scelta di prodotto, dai suggerimenti della Home ai tool dell’agente, viene da lì.
COSTRUIRE HA SENSO QUANDO LO STACK CE L’HAI GIÀ. Non partiamo da zero: Flowise era già self-hosted per i nostri agenti interni. Se dovessimo pagare anche l’infrastruttura e le competenze da zero, il confronto con un prodotto pronto sarebbe diverso.
L’INTERFACCIA È METÀ DEL PRODOTTO. La differenza tra la nostra vecchia chat e la nuova, per l’utente, è soprattutto UX: la Home con le scorciatoie, i suggerimenti proattivi, le risposte con i link giusti. Con Claude Code quella metà è costata meno di 24 ore di lavoro.
LE AZIONI DELICATE VOGLIONO UN APPROVATORE, NON UN ESECUTORE AUTONOMO. L’AI prepara, l’umano approva. Vale per i rimborsi come per le modifiche al system prompt.
STRUMENTA TUTTO DAL GIORNO UNO. UTM su ogni link, costo per messaggio tracciato, conversazioni analizzabili. Il ritorno sull’investimento non si racconta, si mostra.
Se tornassi indietro di un anno e mezzo, l’unica cosa che cambierei del primo esperimento con Open Widget è la strumentazione: abbiamo passato mesi a leggere conversazioni una a una quando avremmo potuto esportarle e analizzarle. Tutto il resto, compreso partire con un tool gratuito e imperfetto, lo rifarei identico: è quello che ci ha insegnato cosa serviva davvero.
Chi vuole capire come costruire agenti e automazioni di questo tipo trova su Learnn il percorso AI, agenti e vibe coding, dove questi approcci si vedono applicati passo per passo.
Ci sentiamo nella prossima analisi,
Luca
PS: ti interesserebbe un corso su Learnn su come mettere a terra tutto questo step by step? Commenta per farcelo sapere.
Se questo articolo ti è stato utile, condividilo con qualcuno che ha bisogno di sentirlo.
Se non sei ancora iscritto/a puoi farlo da qui 👇
Si sono interessato, su un caso similie, a capire come si può applicare
Un corso su questo sarebbe bello