Caso studio

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.

Have a nice dayHave a nice day13 min di lettura
Come abbiamo aggiunto un assistente IA a una piattaforma SaaS — senza romperla

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.”
— il nostro capoprogetto, negli appunti di avvio
Uno schizzo su lavagna bianca che divide una sfocata scatola «chatbot IA» in due percorsi chiaramente etichettati — «deviazione del supporto» a sinistra e «attivazione della funzione» a destra — con foglietti adesivi e frecce a pennarello, in un piccolo ufficio di startup
Il primo risultato non è stato codice. È stata la consapevolezza che una richiesta nascondeva due problemi diversi.

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

Un'illustrazione di interfaccia a schermo diviso: a sinistra una risposta di chat contrassegnata da un'icona rossa di avviso che dà una risposta sicura ma inventata, a destra la stessa domanda risposta con un segno di spunta verde, una breve risposta citata e un pulsante di ripiego «Non sono sicuro — parla con il supporto»
La versione uno suonava benissimo e mentiva. La versione due rispondeva meno, citava le sue fonti e ispirava più fiducia.

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.

  1. 1
    Pulita e strutturata la base di conoscenza
    Abbiamo 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.
  2. 2
    Costruito lo strato di recupero
    Prima 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.
  3. 3
    Collegato il contesto del prodotto
    Abbiamo 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.
  4. 4
    Progettato il ripiego onesto
    Abbiamo 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.
  5. 5
    Rilasciato al 10 % degli utenti dietro un flag
    Distribuito 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.

MetricaPrimaDopoVariazione
Ticket di supporto ripetitivi~100/settimana~45/settimanaCirca la metà, deviati
Tempo mediano di prima risposta~5 oreQuasi istantaneo per le domande comuniDa ore a secondi
Focus del team di supportoPer lo più Q&A ripetutePer lo più casi complessi ad alto valoreMiglior uso di due persone
Tasso «impossibile rispondere» dell'assistente—~20 % (passati a persone)Onesto, non nascosto
All'incirca dove sono arrivate le cose dopo tre mesi, rispetto alla base di partenza prima del lancio. I numeri sono arrotondati e illustrativi.

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.”
— dalla revisione dei tre mesi
Un grafico a linee editoriale e pulito sullo schermo di un portatile che mostra i ticket di supporto settimanali calare di circa la metà in tre mesi, con una seconda linea tenue in salita etichettata «scoperta della funzione» che sale sullo sfondo, visto oltre la spalla di un fondatore sollevato
La metrica promessa si è mossa come previsto. La seconda linea tenue — la scoperta della funzione — è quella che nessuno si aspettava.

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 IA

Domande frequenti

Quanto è durato questo progetto?
Dall'avvio al rilascio completo sono stati circa tre mesi, incluso il prototipo che abbiamo scartato e un rilascio a fasi dietro un feature flag. Una prima funzione IA mirata come questa è di solito questione di settimane o pochi mesi, non di un anno — a condizione di mantenere ristretto l'ambito. Ciò che fa esplodere i tempi è cercare di costruire l'«assistente tuttofare» il primo giorno.
Serve un'enorme quantità di dati per aggiungere un assistente IA?
No. Per un assistente di supporto, i «dati» sono per lo più i contenuti di aiuto e i ticket passati che avete già. Il lavoro non è raccoglierne di più — è pulire e strutturare ciò che esiste, così l'assistente può ancorare le sue risposte a qualcosa di accurato e attuale. La maggior parte dei team è sorpresa da quanto materiale utilizzabile abbia già a disposizione.
Un assistente IA non darà risposte sbagliate ai clienti?
Lo farà, a meno che non progettiate contro. La decisione più importante di questo progetto è stata vietare all'assistente di rispondere a qualsiasi cosa non potesse legare a una fonte reale, e dargli un modo pulito per dire «Non sono sicuro, ecco una persona». Costruito così, risponde in modo affidabile alla maggioranza facile e si fa da parte sul resto — che è esattamente ciò che conquista la fiducia dell'utente.
Dovremmo costruirlo da soli o farci aiutare?
Entrambe le strade possono funzionare, ma la modalità di fallimento è la stessa: sottovalutare quanto il risultato dipenda da un lavoro di base poco glamour — pulizia dei contenuti, recupero, protezioni, il ripiego onesto — anziché dal modello in sé. Se il vostro team ha il tempo di farlo con cura, ottimo. Altrimenti, è esattamente la parte in cui un partner esperto vi risparmia un paio di prototipi eliminati.
Qual è una prima funzione IA sensata per un prodotto SaaS?
Scegliete quella in cui una risposta sbagliata costa meno e la metrica è ovvia. La deviazione del supporto si adatta a entrambe: il ripiego è semplicemente ciò che gli utenti facevano prima, e potete misurare direttamente il volume dei ticket. Una volta collaudata e conquistata la fiducia, avrete guadagnato il diritto di affrontare casi d'uso più rischiosi come onboarding, attivazione o guida nel prodotto.
Have a nice day
Have a nice day
Redazione

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.

Servizi correlati