Come abbiamo aggiunto un assistente IA a una piattaforma SaaS — senza romperla
Un piccolo team SaaS aveva un arretrato di supporto e una funzione che i suoi utenti non riuscivano a trovare. Questa è la storia sincera di come abbiamo inserito un assistente IA nel loro prodotto: cosa ha funzionato, cosa abbiamo buttato e il numero che alla fine si è mosso.

Ogni team SaaS con cui parliamo prima o poi pronuncia la stessa frase ad alta voce: «Dovremmo mettere un assistente IA qui dentro». A volte è la pressione del consiglio, a volte il lancio di un concorrente, a volte una convinzione autentica. La parte interessante non è mai l'idea: quasi tutti ce l'hanno. La parte interessante è la distanza tra quella frase e una funzione su cui gli utenti reali fanno davvero affidamento. Questa è la storia di un team che l'ha colmata, e delle decisioni poco glamour che ce l'hanno portato.
Una breve nota prima di iniziare: abbiamo reso anonimo il cliente e arrotondato i numeri. È una piccola azienda SaaS B2B redditizia — meno di venti persone — che vende uno strumento di workflow a team operativi. Abbiamo cambiato abbastanza dettagli perché non la riconosciate, ma la forma del progetto è esattamente come è andata. I numeri sono illustrativi, non certificati; preferiamo mostrarvi lo schema piuttosto che abbellire un grafico.
Lo scriviamo perché il progetto è un esempio quasi perfetto di come vanno realmente queste cose. Non è andato come diceva la presentazione di avvio. È andato meglio, ma solo perché eravamo disposti a cancellare la prima versione.
La situazione: due problemi con un solo costume
Quando il fondatore ci ha contattato la prima volta, la richiesta era semplice: «Vogliamo un chatbot IA nell'app». È da lì che partono la maggior parte dei progetti, ed è anche lì che la maggior parte deraglia in silenzio. «Chatbot IA» non è un obiettivo, è una forma. Il nostro primo compito è stato quindi capire quale problema il chatbot dovesse risolvere — e se fosse davvero un solo problema.
Non lo era. Sotto quell'unica richiesta si nascondevano due dolori completamente diversi. Il primo era il carico di supporto: un team di customer success di due persone annegava in ticket ripetitivi — «come esporto questo», «dov'è l'impostazione per quello», «perché il mio report non è partito». Circa il 60 % dei ticket in arrivo erano domande già risposte da qualche parte nella loro documentazione di aiuto. Il secondo dolore era più silenzioso e più costoso: l'attivazione. Il loro prodotto aveva una funzione davvero potente sepolta a tre clic di profondità che quasi nessuno scopriva da solo. Gli utenti che la trovavano restavano per anni. Quelli che non la trovavano abbandonavano nei primi due mesi.
Stesso costume, due problemi. E tiravano in direzioni diverse. Un bot di supporto vuole deviare le domande e togliersi di mezzo. Un assistente di attivazione vuole avviare conversazioni e spingere le persone verso cose che non hanno chiesto. Se avessimo costruito «un chatbot IA» senza separarli, avremmo costruito qualcosa che faceva male entrambi i lavori.
“«Chatbot IA» è una forma, non un obiettivo. La prima settimana del progetto è servita a scoprire quale problema ci stavano davvero pagando per risolvere.”

Ridurre l'ambito a qualcosa che potessimo completare
Di fronte a due problemi, la tentazione è costruire un grande assistente che li gestisca entrambi dal primo giorno. Abbiamo dissuaso il team. Non perché la visione fosse sbagliata, ma perché un «assistente tuttofare» da sei mesi è esattamente il tipo di progetto che viene consegnato in ritardo, cade a vuoto e rende tutti nervosi riguardo all'IA per i due anni successivi.
Così ne abbiamo scelto uno. Abbiamo optato prima per la deviazione del supporto, per tre ragioni noiose ma decisive. Aveva un obiettivo chiaro e misurabile — il volume dei ticket. Usava contenuti già esistenti — la loro documentazione di aiuto e i ticket passati. E se avesse reso poco, lo svantaggio era piccolo: un utente che non otteneva una buona risposta faceva semplicemente ciò che già faceva e apriva un ticket. Basso rischio, feedback rapido, metrica onesta. È una buona prima funzione IA, ogni volta.
L'assistente di attivazione non è scomparso — l'abbiamo parcheggiato, sulla carta, con una nota chiara: fase due, una volta collaudato lo strato di recupero. Quella singola decisione ha probabilmente salvato il progetto. Ha dato al team un traguardo davvero raggiungibile in settimane anziché in trimestri.
Il primo prototipo che abbiamo costruito — ed eliminato
Ecco la parte che la maggior parte dei casi studio omette. Il nostro primo prototipo funzionante era, a essere gentili, non buono. Abbiamo fatto la cosa ovvia: collegato gli articoli di aiuto del prodotto a un grande modello linguistico, aggiunto una casella di chat e lasciato che gli utenti facessero domande. Nella demo sembrava magico. Nei test reali è crollato in un modo molto specifico e molto istruttivo.
Il modello sbagliava con sicurezza. Interrogato su un'impostazione rinominata sei mesi prima, inventava allegramente il vecchio percorso di menu. Interrogato su una funzione di un piano superiore, spiegava come usarla — a un cliente che non poteva accedervi. Ogni risposta suonava autorevole, il che rendeva quelle sbagliate peggiori di nessuna risposta. Un bot di supporto che mente cortesemente non riduce i ticket; ne genera di più arrabbiati.
Avremmo potuto mascherarlo con aggiustamenti del prompt. Invece abbiamo fatto qualcosa che sembrava un passo indietro e si è rivelato l'intera partita: abbiamo buttato il primo prototipo e l'abbiamo ricostruito attorno a una regola rigida — l'assistente può rispondere solo da fonti che può citare, e altrimenti deve dire «Non lo so».

Cosa abbiamo davvero costruito
La versione andata in produzione era volutamente modesta in ciò che tentava e rigorosa nel modo in cui si comportava. Sotto il cofano era un assistente ancorato al recupero: quando un utente chiedeva qualcosa, il sistema prima cercava in una base di conoscenza curata e aggiornata, poi chiedeva al modello di rispondere solo da ciò che trovava, con un link alla fonte. Nessuna fonte, nessuna risposta sicura — solo un passaggio pulito a una persona.
Tre scelte di progettazione hanno fatto la maggior parte del lavoro, e nessuna è entusiasmante. È proprio questo il punto — le scelte noiose sono di solito quelle che decidono se ci si fida di una funzione IA o se viene spenta in silenzio.
Ancoraggio invece di astuzia
Ogni risposta era legata a un documento reale e attuale. Abbiamo passato più tempo a pulire e strutturare la base di conoscenza che a mettere a punto il modello. Poco glamour, e di gran lunga il lavoro con la leva più alta del progetto. Un modello mediocre su contenuti eccellenti e ben mantenuti batte un modello brillante su un ammasso obsoleto.
Un passaggio elegante
Quando l'assistente non era sicuro, non indovinava. Lo diceva e offriva un percorso a un clic verso una persona — portandosi dietro il contesto della conversazione, così l'utente non doveva mai ripetersi. Contro ogni intuizione, questo faceva fidare di più le persone del bot: un assistente che ammette i propri limiti sembra onesto, e vi si appoggiavano per il 60 % facile proprio perché si faceva da parte sul 40 % difficile.
Consapevole di chi sta chiedendo
Poiché viveva dentro il prodotto, l'assistente conosceva il piano, il ruolo dell'utente e dove si trovava nell'app. Quindi non spiegava mai una funzione inaccessibile, e poteva dire: «Il pulsante che cerchi è sulla schermata in cui sei già». Questa consapevolezza del prodotto è il vero vantaggio di un assistente integrato nell'app rispetto a un chatbot generico avvitato su un sito di marketing.
- 1Pulita e strutturata la base di conoscenzaAbbiamo verificato ogni documento di aiuto, eliminato quelli obsoleti e taggato il resto per piano e funzione. Era la settimana uno, ed è stata la settimana più importante.
- 2Costruito lo strato di recuperoPrima cercare, poi rispondere. Il modello vedeva solo contenuti verificati e attuali — e aveva istruzione di rifiutare tutto ciò che non poteva ancorare a una fonte.
- 3Collegato il contesto del prodottoAbbiamo connesso l'assistente al piano, al ruolo e alla schermata corrente dell'utente, così le risposte erano su misura e non puntavano mai a funzioni inaccessibili.
- 4Progettato il ripiego onestoAbbiamo costruito il percorso «Non sono sicuro — ecco una persona» come funzione di prima classe, con l'intero contesto della conversazione consegnato al team di supporto.
- 5Rilasciato al 10 % degli utenti dietro un flagDistribuito in silenzio a una parte degli account, osservate conversazioni reali per due settimane, corretto ciò che si rompeva, poi ampliato il rilascio.
I risultati — e quello che ci ha sorpreso
Dopo circa tre mesi di attività per tutti, il quadro era chiaro. Vi diamo numeri arrotondati e illustrativi — la direzione conta più dei decimali.
| Metrica | Prima | Dopo | Variazione |
|---|---|---|---|
| Ticket di supporto ripetitivi | ~100/settimana | ~45/settimana | Circa la metà, deviati |
| Tempo mediano di prima risposta | ~5 ore | Quasi istantaneo per le domande comuni | Da ore a secondi |
| Focus del team di supporto | Per lo più Q&A ripetute | Per lo più casi complessi ad alto valore | Miglior uso di due persone |
| Tasso «impossibile rispondere» dell'assistente | — | ~20 % (passati a persone) | Onesto, non nascosto |
Il numero del supporto era quello che avevamo promesso, e ha mantenuto: poco più della metà dei ticket ripetitivi ha semplicemente smesso di arrivare, e il team di due persone ha riavuto la propria settimana per gestire i casi che avevano davvero bisogno di una persona. Buon risultato, esattamente come definito.
Ma il risultato che ha davvero sorpreso il fondatore era uno per cui non avevamo affatto ottimizzato. Poiché l'assistente rispondeva tutto il giorno a domande «come faccio X», indirizzava naturalmente gli utenti verso quella funzione sepolta e fidelizzante — quella legata alla retention. Non avevamo ancora costruito l'assistente di attivazione. Il bot di supporto svolgeva in silenzio una parte del suo lavoro come effetto collaterale, semplicemente essendo utile e consapevole del prodotto. I nuovi utenti trovavano la funzione settimane prima di quanto avveniva in passato.
“Abbiamo rilasciato uno strumento di supporto. Si è rivelato uno strumento di onboarding travestito da strumento di supporto — ed è esattamente per questo che la fase due ha avuto il via libera.”

Cosa diremmo al prossimo team
Se siete un team SaaS che fissa la stessa frase «dovremmo aggiungere un assistente IA», alcune cose di questo progetto si generalizzano ben oltre di esso.
- Separate i problemi prima di costruire. «Chatbot IA» quasi sempre nasconde due o tre lavori distinti che vogliono progettazioni diverse.
- Iniziate dal caso d'uso in cui una risposta sbagliata costa meno. La deviazione del supporto è un primo passo quasi perfetto; il ripiego è lo status quo.
- Destinate la maggior parte dello sforzo ai contenuti, non al modello. Ancorare a dati puliti e attuali è ciò che rende affidabile un assistente.
- Rendete «Non lo so» una funzione, non un fallimento. Un passaggio onesto costruisce la fiducia che fa affidare gli utenti alle parti che il bot fa bene.
- Rilasciate prima dietro un flag a una piccola parte. Le conversazioni reali vi insegneranno cose che nessuna demo insegnerà mai.
State pensando a una funzione IA nel vostro prodotto?
La parte più difficile raramente è il modello — è definire la cosa in modo che venga rilasciata e conquisti fiducia. Aiutiamo i team SaaS e software a capire cosa vale davvero la pena costruire, poi lo costruiamo. Una prima conversazione non vi costa altro che il tempo.
Scopri come costruiamo funzioni IADomande frequenti
Quanto è durato questo progetto?
Serve un'enorme quantità di dati per aggiungere un assistente IA?
Un assistente IA non darà risposte sbagliate ai clienti?
Dovremmo costruirlo da soli o farci aiutare?
Qual è una prima funzione IA sensata per un prodotto SaaS?

Have a nice day è uno studio software che aiuta le piccole e medie imprese a digitalizzarsi — automazione, IA e software su misura che funziona nelle operazioni quotidiane, non solo sulle slide.