Questa guida propone un modo pratico per delimitare il servizio, scegliere il grado di autonomia, testarlo e misurarlo. È pensata per chat sul sito, messaggistica o ticket; non sostituisce la valutazione di obblighi contrattuali, privacy o di settore che possono applicarsi al singolo caso.
Prima domanda: quale risultato vuoi automatizzare?
Parti da un elenco di richieste realmente ricevute, non da una lista di funzioni offerte da uno strumento. Per due settimane, raccogli un campione dei messaggi in arrivo e annota per ciascuno: argomento, informazione necessaria, fonte aziendale da cui deriva la risposta, eventuale dato personale richiesto, tempo dell’operatore e conseguenza di una risposta sbagliata. Anche 40 o 50 richieste diverse possono mostrare dove si concentrano le ripetizioni.
Di solito sono candidati ragionevoli le FAQ su orari, consegne, documenti da preparare, disponibilità di un servizio e istruzioni che cambiano raramente. Una richiesta di stato ordine, invece, può avere bisogno di identificare il cliente e di leggere dati aggiornati: l’AI può raccogliere il motivo del contatto o predisporre una risposta, ma la regola di accesso e la verifica del dato diventano parte del progetto.
Non assegnare in autonomia decisioni che modificano diritti, prezzo, rimborso, contratto, priorità di un reclamo o condizioni di sicurezza. Lo stesso vale per situazioni emotivamente tese, richieste mediche o legali e casi in cui l’operatore deve interpretare eccezioni. In questi casi la funzione più utile dell’AI è classificare il messaggio, spiegare il prossimo passo e avvisare la persona giusta; non emettere il verdetto.
Tre livelli di autonomia, invece di un sì o no
Separare i compiti in livelli evita sia il chatbot che si limita a dire che non capisce, sia quello che improvvisa oltre il suo perimetro.
| Livello | Cosa può fare | Quando usarlo |
|---|---|---|
| Risposta diretta | Risponde a una domanda frequente con una fonte aziendale indicata. | Informazione stabile, conseguenza bassa, testo approvato. |
| Bozza con controllo | Classifica, recupera elementi utili e propone una risposta all’operatore. | Servono dati aggiornati, tono adeguato o una verifica del caso. |
| Solo instradamento | Riconosce tema, urgenza e dati minimi per aprire o assegnare il ticket. | Reclami, eccezioni, pagamenti, cambi di condizioni o impatto elevato. |
Il confine deve essere visibile anche a chi lavora nel team. Scrivi una pagina operativa con le attività permesse, quelle vietate e il nome o ruolo che riceve l’escalation. Il profilo del NIST per l’AI generativa raccomanda, tra le altre cose, politiche di uso accettabile per interfacce e configurazioni umano-AI, criteri per le domande da rifiutare e meccanismi di feedback e ricorso. Per una PMI, quella raccomandazione diventa una regola semplice: il sistema non deve indovinare quando fermarsi.
La griglia RIC per scegliere cosa delegare
Per non scegliere in base alla sola frequenza, usa questa griglia originale su ogni tipologia di richiesta. Assegna un punteggio da 0 a 3 a tre fattori: Ripetizione, cioè quante richieste seguono davvero lo stesso schema; Istruttura della risposta, cioè quanto è completa e aggiornata la fonte approvata; Conseguenza dell’errore, cioè quanto è difficile o costoso rimediare a una risposta non corretta.
- Calcola RIC = Ripetizione + Istruttura − Conseguenza.
- Con punteggio 4 o più e conseguenza pari a 0 o 1, prova una risposta diretta.
- Con punteggio 2 o 3, oppure conseguenza pari a 2, mantieni la bozza con controllo umano.
- Con punteggio 1 o meno, oppure conseguenza pari a 3, limita il sistema al solo instradamento.
La soglia non è una norma né una certificazione: è un criterio interno da correggere con i test. Per esempio, una domanda su un orario può avere 3 per ripetizione, 3 per struttura e 0 per conseguenza: punteggio 6, quindi candidata a risposta diretta. Lo stato di una spedizione può fare 3 + 2 − 2 = 3: utile per una bozza o per raccogliere un codice, non per promettere una data. Un rimborso con eccezione può fare 2 + 2 − 3 = 1: instradamento a una persona.
Questa distinzione rende la conversazione più onesta. Invece di una risposta generica, il sistema può dire cosa può verificare, quale informazione gli manca e quando passa il caso. Quando una fonte non esiste, è contraddittoria o non aggiornata, la risposta corretta è dichiarare il limite e aprire l’escalation, non completare il vuoto con un testo plausibile.
Il flusso minimo: risposta, prova, passaggio di mano
Un flusso sicuro non richiede un progetto enorme, ma richiede alcuni passaggi espliciti. All’avvio, chiarisci che la persona sta parlando con un sistema AI e mostra una via semplice per il contatto umano. L’articolo 50 dell’AI Act stabilisce che i sistemi destinati a interagire direttamente con persone siano progettati affinché esse siano informate dell’interazione con l’AI, salvo che ciò sia ovvio nel contesto; l’informazione deve essere chiara, distinguibile e accessibile. Per chi configura il canale, significa verificare come tale avviso sia reso nell’interfaccia e quale ruolo abbia il fornitore nel rispettare questo requisito.
- Accogli e limita il campo. Spiega in una frase gli argomenti gestiti e invita a non inserire dettagli non necessari. Offri subito il canale umano per reclami, urgenze o temi fuori perimetro.
- Classifica prima di rispondere. Il sistema riconosce il tema e valuta se la domanda corrisponde a una categoria ammessa. Se il messaggio è ambiguo, chiede una sola precisazione utile oppure instrada.
- Rispondi solo da contenuti approvati. Associa a ogni FAQ una fonte, un proprietario e una data di revisione interna. Nella risposta, indica il titolo o il link della pagina, politica o procedura che la sostiene. Il NIST suggerisce di rivedere e verificare fonti e citazioni nelle risposte generative sia prima del rilascio sia nel monitoraggio continuativo.
- Trasferisci il contesto essenziale. Il ticket verso l’operatore contiene categoria, sintesi del problema, eventuali riferimenti già forniti e motivo dell’escalation. Evita di copiare conversazioni intere quando non servono a risolvere il caso.
- Chiudi con una scelta verificabile. La persona deve capire se ha ricevuto una risposta, se un caso è stato preso in carico o dove proseguire. Un messaggio che rimanda più volte alla stessa domanda è un errore di flusso, non un successo di automazione.
Se il perimetro riguarda le domande ricevute sul sito, la pagina del servizio Chatbot per siti web presenta un possibile canale da valutare. Qui il criterio resta indipendente dalla tecnologia: definire prima quali richieste possono ottenere una risposta, quali solo una bozza e quali devono arrivare a una persona.
Il pilota: test prima, monitoraggio dopo
Inizia con una sola famiglia di FAQ e una sola via di escalation. Prepara un set di prova con domande formulate in modi diversi, refusi, richieste fuori ambito e casi che devono essere trasferiti. Inserisci anche contenuti non presenti nella base approvata: il comportamento atteso non è una risposta creativa, ma un limite chiaro e l’invio al team.
Fai provare il flusso a chi lavora davvero sui ticket. Per ogni prova, segna se la categoria è corretta, se la fonte indicata è pertinente, se il tono è comprensibile, se l’uscita umana è visibile e se il dato passato all’operatore è sufficiente ma non eccessivo. Il NIST raccomanda di misurare le prestazioni in condizioni simili a quelle di impiego, documentare le misure e condividere i risultati dei test prima del rilascio con chi può approvare il sistema.
Dopo l’avvio non misurare soltanto quante chat restano al sistema. Tieni almeno cinque indicatori, con definizioni scritte prima del pilota:
- Risoluzione autonoma verificata: richiesta chiusa senza intervento umano e senza riapertura entro un periodo scelto dall’azienda.
- Instradamento corretto: ticket arrivato al team giusto al primo passaggio.
- Tasso di correzione: risposte che un operatore deve modificare per contenuto, fonte o tono.
- Tempo fino alla presa in carico: dal messaggio dell’utente alla prima azione della persona responsabile nei casi escalati.
- Cause di abbandono: uscita dalla conversazione, ripetizione della domanda o richiesta di operatore, lette insieme ai messaggi e non come un numero isolato.
Definisci una soglia di stop prima dell’avvio: per esempio, se compaiono risposte senza fonte, classificazioni ripetutamente errate su un tema delicato o escalation non ricevute, disattiva quel percorso e correggi la causa. Il piano di monitoraggio post-impiego del NIST include raccolta dei riscontri degli utenti, possibilità di override, risposta agli incidenti e gestione delle modifiche: elementi utili anche in una configurazione piccola.
Misurare il costo per richiesta senza trucchi nel denominatore
Un costo mensile dello strumento non dice da solo se il flusso conviene. Scegli prima quale denominatore vuoi osservare e non confrontare numeri diversi. Una formula trasparente è: costo del flusso = canone del periodo + quota di configurazione + tempo di revisione × costo orario interno. Poi dividi il totale per le richieste in arrivo, per quelle a cui il flusso ha dato almeno una risposta utile o per le sole risoluzioni autonome. I tre risultati rispondono a domande diverse.
Esempio puramente ipotetico, non è un prezzo né un benchmark: in un mese arrivano 480 richieste. Il canone ipotizzato è 180 €, la configurazione ipotizzata è 1.200 € ripartita su 12 mesi, e 168 bozze richiedono 4 minuti di controllo ciascuna a un costo interno ipotizzato di 30 €/ora. Il controllo costa 336 €; il costo mensile del flusso è quindi 180 + 100 + 336 = 616 €. Con 216 risoluzioni dirette e 168 bozze revisionate, il risultato è 1,28 € per tutte le 480 richieste entranti, 1,60 € per le 384 richieste assistite dal flusso e 2,85 € per le 216 sole risoluzioni autonome. I casi instradati non spariscono dal lavoro umano: vanno osservati a parte.
Questo esempio mostra perché un tasso alto di contenimento non basta. Un flusso può essere economico ma trasferire male i casi, oppure chiudere molte conversazioni a costo di risposte inesatte. Affianca quindi il costo alla qualità delle fonti, al tasso di correzione e al tempo di presa in carico.
Trasparenza e dati: progettare il limite prima del dialogo
Le conversazioni di assistenza contengono spesso dati personali anche quando il cliente non li etichetta come tali. La pagina della Commissione europea sui principi GDPR ricorda che il trattamento deve essere lecito, corretto e trasparente, legato a una finalità specifica e limitato ai dati necessari; indica inoltre limiti di conservazione, sicurezza e responsabilità dimostrabile. Non è una questione da aggiungere alla fine: determina quali campi chiedere, chi può vedere il ticket e per quanto tempo conservarlo.
Traduci i principi in scelte concrete: chiedi un identificativo ordine solo quando serve al caso; separa le FAQ pubbliche dal profilo del cliente; evita di usare conversazioni complete come materiale di miglioramento senza aver definito finalità, basi e tutele; assegna accessi per ruolo; registra le modifiche alle fonti; stabilisci una scadenza di revisione o cancellazione delle conversazioni. Se il servizio tratta categorie particolari di dati, profili complessi o decisioni con effetti rilevanti, coinvolgi chi segue privacy e aspetti legali prima del pilota. Nessuna checklist sostituisce tale valutazione.
Checklist prima del via
- Abbiamo scelto una sola famiglia di richieste e abbiamo esempi reali, privati dei dettagli non necessari?
- Ogni risposta automatica ha una fonte, un proprietario e una regola di aggiornamento?
- Il sistema dichiara l’interazione con l’AI e mostra fin dall’inizio come parlare con una persona?
- Sono scritti i casi vietati, le parole o categorie che attivano escalation e il team che li riceve?
- Il passaggio all’operatore porta solo le informazioni necessarie per lavorare il caso?
- Abbiamo eseguito test su domande ambigue, dati mancanti, fonti superate e richieste fuori perimetro?
- Qualità, correzioni, instradamento e costo saranno letti insieme a una frequenza stabilita?
Domande frequenti
Un chatbot può gestire lo stato di un ordine?
Può essere utile per orientare il cliente o raccogliere il riferimento necessario. Prima di mostrare informazioni specifiche, però, definisci come avviene l’identificazione, quali dati sono necessari e quando l’operatore deve controllare eccezioni, ritardi o modifiche. Non trasformare una risposta informativa in un impegno non verificato.
Serve una base di contenuti perfetta prima di iniziare?
Serve una base sufficientemente affidabile per il perimetro scelto, non un archivio infinito. Inizia dalle FAQ stabili, assegna un responsabile ai contenuti e inserisci un comportamento esplicito per le domande senza fonte. Ampliare il campo prima di mantenere aggiornati i contenuti aumenta il rischio di risposte imprecise.
Come evitare che il cliente resti bloccato con l’AI?
Offri un’uscita umana visibile all’inizio e dopo un’incomprensione significativa. Fai arrivare l’escalation a un team, casella o ticketing realmente presidiato; altrimenti la conversazione automatica aggiunge un passaggio invece di ridurre l’attesa.
Se vuoi valutare il perimetro partendo dalle richieste che ricevi, puoi descrivere volontariamente il tuo caso all’assistente disponibile in basso nella pagina. Per leggere questa guida o usare il flusso informativo non è necessario lasciare recapiti.
