La differenza tra una chat dimostrativa e un canale di assistenza
In una dimostrazione è sufficiente ottenere qualche risposta convincente. In esercizio servono continuità, controllo e una qualità misurabile. Le informazioni cambiano, gli utenti formulano domande ambigue e alcune richieste richiedono accesso a dati personali o decisioni che non possono essere delegate.
Un sistema destinato all'assistenza deve quindi gestire l'intero ciclo della conversazione.
CICLO CONVERSAZIONE
01 – identificare l’argomento e chiedere le informazioni mancanti;
02 – recuperare contenuti soltanto dalle fonti autorizzate;
03 – distinguere informazioni generali e dati riferiti al singolo cliente;
04 – citare o rendere riconoscibile la fonte quando è importante verificarla;
05 – evitare risposte quando le evidenze non sono sufficienti;
06 – trasferire il caso al reparto corretto senza costringere l’utente a ricominciare;
07 – registrare esito, tempi ed eventuali errori per migliorare il servizio.
Questi comportamenti non derivano automaticamente dal modello. Vanno progettati nel flusso applicativo, verificati con casi reali e monitorati dopo la pubblicazione.
Come progettiamo un
assistente AI affidabile
Un assistente AI aziendale non è semplicemente una chat collegata a un modello linguistico. È un sistema composto da conoscenza, integrazioni, regole operative e meccanismi di controllo che determinano cosa può sapere, quali azioni può eseguire e quando deve coinvolgere una persona.
CONOSCENZA CONTROLLATA
Le fonti determinano ciò che il chatbot può davvero sapere
FAQ, manuali, schede prodotto, condizioni commerciali e procedure interne hanno strutture e frequenze di aggiornamento differenti. Prima di collegarli analizziamo qualità, duplicazioni, versioni e permessi. Un documento superato ma ancora presente nell’archivio può produrre una risposta formalmente corretta e operativamente sbagliata.
Quando il caso lo richiede, utilizziamo un’architettura RAG: il sistema cerca i passaggi pertinenti nelle fonti aziendali e li usa per costruire la risposta. Questo approccio permette di aggiornare la conoscenza intervenendo sui contenuti, senza affidare al modello informazioni che dovrebbe ricordare in modo implicito.
Definiamo inoltre chi può pubblicare o sostituire una fonte, come vengono gestite le versioni e quali contenuti sono visibili a utenti, clienti, operatori o reparti diversi. La conoscenza non è un archivio indistinto: è parte delle autorizzazioni aziendali.
intelligenza adattata a ogni canale
Un'unica logica, canali con comportamenti diversi
La chat sul sito, WhatsApp e Telegram non sono contenitori equivalenti. Cambiano identità dell’utente, formato dei messaggi, durata della sessione, disponibilità di pulsanti e regole del canale. Anche le aspettative sono diverse: sul sito può essere naturale guidare la navigazione; nella messaggistica l’utente si aspetta una conversazione che prosegua nel tempo.
Possiamo condividere fonti, servizi applicativi e criteri di risposta, mantenendo un adattamento specifico per ciascun canale. Il sistema può, per esempio:
- rispondere a domande su prodotti e servizi nella chat web;
- raccogliere codice cliente e motivo del contatto su WhatsApp;
- inviare su Telegram aggiornamenti legati a un processo autorizzato;
- aprire una richiesta di assistenza e restituire il relativo riferimento;
- riconoscere un utente autenticato nell’area riservata e consultare i soli dati consentiti.
Le credenziali dei sistemi interni restano nella parte protetta dell’applicazione e non vengono affidate al modello. Il modello interpreta la richiesta e prepara i parametri, mentre l’applicazione verifica identità, permessi e validità prima di leggere o modificare un dato.
Quando serve interviene una persona
Il passaggio all'operatore è una funzione centrale
Automatizzare non significa trattenere a ogni costo l’utente nella conversazione. Il chatbot deve riconoscere condizioni di trasferimento esplicite: richiesta dell’utente, bassa affidabilità della risposta, argomento sensibile, reclamo, eccezione non gestita o necessità di una decisione umana.
Quando avviene il passaggio, l’operatore deve ricevere tutto ciò che è già stato raccolto: un riepilogo, la cronologia utile, i dati identificativi consentiti e il motivo del trasferimento. Così può intervenire subito, senza chiedere di nuovo le stesse informazioni.
Il sistema tiene conto anche degli orari e della disponibilità. Se nessun operatore è presente, il sistema può aprire una richiesta, indicare i tempi previsti e consentire un contatto successivo. Non promette una risposta immediata se l’organizzazione non può garantirla.
Regole, permessi e sicurezza prima delle risposte
Definire con chiarezza ciò che non deve fare
Le restrizioni efficaci non si limitano a un’istruzione generica scritta nel prompt. Per ogni ambito valutiamo le azioni ammesse, le fonti utilizzabili e le condizioni che impongono un rifiuto o una conferma.
Un assistente commerciale può spiegare le caratteristiche pubbliche, ma non inventare disponibilità o condizioni. Un chatbot interno può aiutare a trovare una procedura, ma non approvare un’eccezione. Un canale di assistenza può consultare lo stato di una pratica solo dopo aver verificato l’identità prevista dal processo.
Per ridurre i rischi applichiamo più livelli di controllo:
- istruzioni contestuali,
- recupero controllato delle fonti,
- validazione lato server,
- filtri per dati sensibili,
- registrazione delle operazioni.
Le decisioni importanti rimangono nel software e nelle regole aziendali, non nella sola risposta del modello.
Qualità, verifiche
ed estensioni
Come valutiamo la qualità
Il test non consiste nel porre qualche domanda durante una riunione. Prepariamo un insieme rappresentativo di conversazioni: richieste frequenti, formulazioni incomplete, contenuti simili tra loro, domande fuori ambito, informazioni non presenti e casi da trasferire ad un operatore.
Osserviamo aspetti distinti:
- correttezza delle risposte rispetto alle fonti;
- capacità del sistema di recuperare il contenuto pertinente;
- rispetto dei limiti e delle autorizzazioni;
- qualità delle domande di chiarimento poste all’utente;
- precisione nell’attivare il passaggio all’operatore;
- tempo di risposta percepito e stabilità del canale;
- costo per conversazione e utilizzo dei modelli.
Dopo il rilascio, i dati delle conversazioni vengono analizzati con criteri compatibili con privacy e sicurezza. Le domande rimaste senza risposta aiutano a individuare contenuti mancanti; i trasferimenti errati mostrano dove modificare il flusso; le richieste ricorrenti possono suggerire un’integrazione aggiuntiva.
Un progetto progressivo, con verifiche prima dell'estensione
Iniziamo delimitando utenti, canali e casi d'uso.
Selezioniamo poi un gruppo di richieste che abbia valore operativo concreto e fonti sufficientemente affidabili. Su questo perimetro realizziamo una prima versione verificabile, integrando almeno un passaggio reale, come la ricerca documentale o l'apertura di una richiesta.
Solo dopo aver misurato comportamento e limiti conviene ampliare fonti, canali e azioni. Questo evita di costruire un assistente molto esteso ma difficile da governare.
Prevediamo inoltre: manutenzione dei contenuti, controllo delle integrazioni, rivalutazione dei modelli quando cambiano costi o requisiti.