Un assistente che risponde a tutto può sembrare efficace durante una demo. Nel lavoro quotidiano è spesso il comportamento più rischioso. Se la fonte è incompleta, la domanda è ambigua o la decisione ha conseguenze importanti, la risposta corretta può essere fermarsi e coinvolgere una persona.
L’affidabilità non dipende soltanto dalla qualità del modello. Dipende soprattutto da come definiamo ciò che può fare, quali informazioni può usare e come gestisce i casi che non rientrano nel perimetro.
Delimitare il compito
“Rispondere ai clienti” è un obiettivo troppo ampio. Un perimetro verificabile può essere: rispondere alle domande su consegne e resi usando il centro assistenza approvato, recuperare lo stato dell’ordine dal gestionale e inoltrare i casi di contestazione.
Per ogni caso definiamo:
- fonti autorizzate;
- azioni consentite;
- dati che possono essere mostrati;
- condizioni che richiedono verifica dell’identità;
- argomenti esclusi;
- persona o coda di escalation.
Più il perimetro è esplicito, più è possibile testare il comportamento.
La confidenza non è un numero magico
Una soglia può aiutare, ma un punteggio elevato non garantisce che la risposta sia vera. I sistemi possono essere molto sicuri anche quando interpretano male una domanda o usano un documento non aggiornato.
La decisione di rispondere dovrebbe combinare più segnali:
- esistenza di una fonte pertinente;
- coerenza tra le fonti recuperate;
- aggiornamento e validità del documento;
- completezza dei dati del caso;
- presenza di termini sensibili o azioni irreversibili;
- regole specifiche del processo.
Se due politiche approvate si contraddicono, la soluzione non è scegliere quella con il punteggio più alto. È segnalare il conflitto.
Mostrare da dove arriva la risposta
In un processo interno, una risposta utile dovrebbe permettere alla persona di aprire il documento o il record usato. Nel customer service la citazione può non essere mostrata al cliente, ma deve rimanere nel log per il controllo.
Registriamo fonte, versione, passaggi recuperati, azione proposta e risultato. Questo rende possibile capire se un errore nasce dal modello, da una regola o da una base informativa non aggiornata.
La tracciabilità ha anche un effetto organizzativo: costringe l’azienda a stabilire quale documento sia davvero autorevole.
Quattro casi in cui fermarsi
L’assistente dovrebbe evitare una risposta definitiva quando:
- non trova una fonte approvata;
- trova informazioni incompatibili;
- mancano dati necessari per identificare il caso;
- la richiesta comporta una decisione riservata a una persona.
La frase “non lo so” da sola, però, non conclude il processo. Il sistema deve spiegare cosa manca e creare il passaggio successivo.
Progettare l’handoff umano
Un’escalation efficace porta con sé conversazione, dati del cliente, fonti consultate, motivo del blocco e bozza eventualmente preparata. La persona non dovrebbe ricominciare da zero né chiedere di nuovo informazioni già fornite.
Occorre definire:
- coda e responsabile;
- priorità;
- tempo atteso di presa in carico;
- messaggio inviato all’utente;
- modalità con cui la decisione torna nel processo.
Se il passaggio umano non viene progettato, l’assistente sposta semplicemente il collo di bottiglia in una casella meno visibile.
Testare anche il rifiuto
I test non devono contenere soltanto domande a cui il sistema dovrebbe rispondere. Servono casi ambigui, documenti scaduti, richieste fuori perimetro, tentativi di ottenere dati non autorizzati e situazioni in cui due fonti divergono.
Misuriamo risposte corrette, risposte errate, escalation corrette ed escalation inutili. Un sistema che inoltra tutto è sicuro ma poco utile; uno che non inoltra mai è apparentemente efficiente ma fragile.
L’obiettivo è trovare un equilibrio controllato e aggiornarlo osservando i casi reali. Un assistente affidabile non dimostra intelligenza parlando sempre. La dimostra riconoscendo quando le condizioni per rispondere non esistono.