Nel customer service B2B il problema raramente è la mancanza assoluta di informazioni. Più spesso, le informazioni esistono ma sono sparse tra manuali tecnici, email, ticket precedenti, CRM, procedure interne e persone che hanno accumulato esperienza negli anni.
Quando arriva una richiesta, l’operatore deve ricostruire il contesto, capire quale documentazione sia ancora valida, controllare il contratto del cliente e decidere se può rispondere o deve coinvolgere un collega. È in questo passaggio che l’intelligenza artificiale può produrre un beneficio concreto.
Non affidandole alla cieca la conversazione con il cliente, ma usandola come copilota interno: uno strumento che cerca informazioni autorizzate, riassume il caso, prepara una risposta e segnala eventuali condizioni di escalation. La decisione finale rimane all’operatore, almeno finché dati, procedure e metriche non dimostrano che una specifica attività può essere automatizzata con un rischio accettabile.
Che cosa fa davvero un copilota per l’assistenza B2B
Un copilota non è semplicemente una finestra di chat collegata a un modello linguistico. Per essere utile deve lavorare nel contesto reale dell’assistenza: sapere quale cliente ha aperto il ticket, quale prodotto utilizza, quali verifiche sono già state effettuate e quali procedure aziendali si applicano.
Di fronte a una richiesta tecnica, per esempio, potrebbe:
- riassumere la conversazione e le attività già svolte;
- identificare prodotto, configurazione, versione e anomalia segnalata;
- recuperare i passaggi pertinenti da manuali e procedure approvate;
- cercare ticket simili già risolti;
- proporre le domande necessarie per completare la diagnosi;
- preparare una bozza di risposta con le fonti utilizzate;
- suggerire il team a cui inoltrare il caso quando emergono determinate condizioni.
La differenza rispetto a un chatbot autonomo è sostanziale. Il copilota assiste chi conosce il processo e può riconoscere un suggerimento sbagliato. Non trasforma automaticamente una probabilità linguistica in una decisione tecnica, contrattuale o commerciale.
Questa impostazione è coerente anche con le funzionalità introdotte nelle principali piattaforme enterprise: riepilogo dei casi, ricerca nella knowledge base, preparazione delle risposte, piani di risoluzione e note di chiusura. La documentazione di Microsoft Dynamics 365, per esempio, invita gli operatori a verificare i contenuti suggeriti prima di utilizzarli.
Le fonti da collegare, in ordine di affidabilità
Il modello AI è solo una parte del progetto. La qualità del risultato dipende soprattutto dalla conoscenza che il sistema può consultare e dalle regole con cui la recupera.
Manuali, procedure e articoli approvati dovrebbero costituire la fonte normativa principale. Ogni contenuto dovrebbe avere almeno un prodotto associato, una versione, una lingua, una data di validità e un responsabile. Se due documenti danno istruzioni differenti, il copilota deve sapere quale prevale oppure dichiarare il conflitto.
Il ticket corrente fornisce invece il contesto immediato: descrizione, email, allegati, note interne, verifiche effettuate e stato della richiesta. A questo si possono aggiungere i dati del CRM, come prodotto installato, configurazione, garanzia, contratto, livello di servizio e precedenti contatti.
I ticket storici sono preziosi, ma richiedono maggiore cautela. Una soluzione adottata tre anni prima potrebbe riguardare una versione diversa del prodotto oppure contenere una deroga concessa a uno specifico cliente. I casi passati sono quindi precedenti operativi da valutare, non verità da applicare automaticamente.
Infine, il sistema dovrebbe conoscere le matrici di competenza e le regole di escalation: quando coinvolgere il secondo livello, il commerciale, la qualità, l’amministrazione o un responsabile tecnico.
Questo lavoro sulla conoscenza viene spesso sottovalutato. Collegare una cartella piena di PDF non equivale a costruire una knowledge base affidabile. Prima dell’integrazione è utile definire titolarità, versioni e criteri di aggiornamento dei contenuti. Ho approfondito il tema nella guida su come preparare documenti e knowledge base per un sistema RAG.
Come funziona l’architettura RAG
Per questo tipo di applicazione si utilizza spesso un’architettura RAG, acronimo di Retrieval-Augmented Generation. In termini semplici, il sistema non chiede al modello di rispondere affidandosi soltanto a ciò che ha appreso in fase di addestramento. Prima cerca le informazioni rilevanti nelle fonti aziendali e poi le inserisce nel contesto usato per generare la proposta.
Una pipeline tipica comprende la classificazione della richiesta, il recupero dei documenti, i filtri per cliente e prodotto, la generazione della bozza, la citazione delle fonti e la registrazione del feedback dell’operatore. Nell’articolo dedicato alla RAG aziendale per le PMI spiego più nel dettaglio quando questa architettura può essere utile e quali condizioni servono per partire.
C’è però un requisito che non può essere delegato a un prompt: i permessi. Se un operatore non può vedere un contratto, una pratica riservata o i dati di un’altra business unit, quei contenuti devono essere esclusi prima del recupero. Non basta istruire il modello dicendogli di non mostrarli. Il controllo degli accessi deve essere applicato a livello di sistema e, quando necessario, di singolo documento.
È altrettanto importante mostrare all’operatore le fonti utilizzate. Una risposta senza riferimenti può sembrare plausibile ma richiede una verifica lenta. Se invece il suggerimento rimanda al manuale, alla procedura e al punto esatto da cui deriva, il controllo umano diventa più rapido e concreto.
Che cosa affidare all’AI e che cosa no
Non tutte le attività di assistenza hanno lo stesso rischio. Un riepilogo errato può far perdere qualche minuto; una chiusura impropria del ticket o un’interpretazione sbagliata della garanzia può avere conseguenze operative ed economiche.
| Attività | Uso consigliato dell’AI | Controllo necessario |
|---|---|---|
| Riassunto del ticket | Generazione automatica | Verifica rapida dell’operatore |
| Ricerca di manuali e procedure | Suggerimento con collegamento alle fonti | Controllo di versione e pertinenza |
| Bozza della risposta | Preparazione automatica | Approvazione prima dell’invio |
| Classificazione e priorità | Suggerimento motivato | Conferma dell’operatore |
| Modifica di stato o SLA | Solo proposta | Autorizzazione esplicita |
| Rimborsi, deroghe e sostituzioni | Supporto informativo | Decisione della persona responsabile |
| Comandi su sistemi tecnici | Eventuale preparazione dell’azione | Controlli tecnici e approvazione forte |
Una regola utile è distinguere tra suggerire, modificare e agire. Il copilota può avere una certa autonomia nel suggerire. Per modificare un record dovrebbe chiedere conferma. Per compiere azioni con impatto tecnico, economico o contrattuale servono permessi specifici, registrazione delle operazioni e possibilità di blocco.
Questo è il principio del Human in the Loop: la supervisione umana non viene aggiunta in modo generico, ma collocata nei punti in cui errore, ambiguità o responsabilità richiedono una decisione consapevole.
Un esempio di flusso operativo
Immaginiamo che un cliente segnali un fermo macchina dopo un aggiornamento. Il copilota legge il ticket e ricava modello, numero di versione, codice dell’errore e prove già effettuate. Dal CRM verifica la configurazione installata e il livello di assistenza previsto dal contratto.
Cerca quindi nei manuali validi per quella versione e trova una procedura pertinente. Tra i ticket storici individua casi simili, ma uno riguarda una versione precedente: lo segnala come precedente non pienamente applicabile invece di copiarne la soluzione.
La risposta proposta può indicare una verifica preliminare, citare il paragrafo del manuale e chiedere al cliente un dato mancante. Se dal ticket emerge una condizione critica, il sistema suggerisce l’escalation al secondo livello senza chiudere il caso.
Questo esempio mostra dove si produce il valore: non tanto nella scrittura più veloce dell’email, quanto nella riduzione del tempo speso a ricostruire il contesto e nel rendere più coerente l’applicazione delle procedure.
Come misurare se il progetto funziona
Il numero di risposte generate è una metrica di utilizzo, non una prova di efficacia. Prima di introdurre il copilota è opportuno rilevare una baseline e separare almeno tre dimensioni: prestazioni operative, qualità delle risposte e utilità per gli operatori.
Dal punto di vista operativo si possono misurare il tempo alla prima risposta, il tempo effettivo di lavorazione, il tempo di risoluzione, il numero di interventi per ticket, le riaperture, le escalation e il rispetto degli SLA. I risultati vanno però segmentati per prodotto, complessità, canale e tipologia di caso. Una media generale potrebbe nascondere un miglioramento sui ticket ripetitivi e un peggioramento su quelli tecnici.
La qualità richiede una valutazione distinta. Una risposta è fondata quando le sue affermazioni derivano dalle fonti citate, ma questo non significa necessariamente che sia corretta. Il documento recuperato potrebbe essere obsoleto oppure il modello potrebbe averlo interpretato male. Conviene quindi valutare separatamente:
- aderenza alle fonti;
- correttezza tecnica;
- completezza dei passaggi;
- pertinenza rispetto alla richiesta;
- validità delle citazioni;
- rispetto delle procedure;
- capacità di astenersi quando mancano informazioni.
Infine ci sono le metriche di adozione: percentuale di suggerimenti accettati, risposte riscritte, entità delle modifiche e motivazioni degli scarti. Se gli operatori ignorano sistematicamente le bozze, non è necessariamente un problema di formazione: potrebbe essere il segnale che il recupero dei documenti è debole, che le procedure non sono aggiornate o che l’interfaccia rallenta il lavoro.
Partire da un pilota controllato
Il punto di partenza più prudente è la sola lettura: ricerca dei documenti e riepilogo del caso, senza modifiche al CRM e senza invio di messaggi. Il passaggio successivo può introdurre le bozze di risposta con fonti visibili. Solo dopo aver raccolto evidenze sufficienti ha senso aggiungere suggerimenti di classificazione, aggiornamenti sottoposti a conferma ed eventuali automazioni limitate.
Prima del rilascio serve un set di ticket rappresentativi. Non solo casi semplici e ben documentati, ma anche richieste ambigue, allegati incompleti, procedure in conflitto, versioni obsolete e situazioni nelle quali il sistema dovrebbe dichiarare di non avere elementi sufficienti.
Il confronto dovrebbe avvenire tra gruppi di casi omogenei, osservando sia il tempo sia la qualità. Se il copilota riduce il tempo medio ma aumenta riaperture ed escalation, il risultato non è positivo. Allo stesso modo, una buona precisione durante il test iniziale non elimina la necessità di monitorare il sistema dopo il rilascio: documenti, prodotti e procedure cambiano.
Sicurezza, privacy e responsabilità
Ticket, email e CRM possono contenere dati personali, informazioni contrattuali e dettagli tecnici riservati. Occorre quindi chiarire quali dati vengono trattati, per quale finalità, per quanto tempo vengono conservati e chi può accedervi. Devono essere valutati anche i flussi verso fornitori esterni e le impostazioni con cui i dati vengono utilizzati dal servizio scelto.
Il RAG migliora l’ancoraggio alle fonti, ma non rende il sistema immune dagli attacchi. Come ricorda OWASP, istruzioni malevole possono essere inserite anche indirettamente nei file o nei contenuti recuperati. Per questo sono necessari privilegi minimi, separazione tra dati e istruzioni, controlli sugli allegati e approvazione umana per le azioni ad alto impatto.
Nel quadro europeo, gli obblighi di alfabetizzazione in materia di AI sono applicabili dal 2 febbraio 2025. Le regole di trasparenza previste per i sistemi AI che interagiscono direttamente con le persone si applicano dal 2 agosto 2026. Un copilota usato soltanto dall’operatore è diverso da un chatbot che risponde autonomamente al cliente; se il perimetro cambia, devono essere rivalutati anche gli obblighi applicabili.
Al di là della conformità formale, la formazione ha un valore operativo. Gli addetti devono sapere che una risposta fluida può essere sbagliata, come controllare una citazione, quando rifiutare un suggerimento e come segnalare un problema.
La scelta decisiva non riguarda il modello
Nella valutazione di un progetto simile è facile concentrarsi sul modello linguistico o sulla piattaforma. Sono scelte importanti, ma raramente determinano da sole il successo dell’iniziativa.
Le domande decisive sono altre: la documentazione è affidabile? I permessi sono coerenti con quelli già applicati nei sistemi aziendali? Il copilota mostra le fonti? Esistono regole chiare per approvazioni ed escalation? È possibile misurare che cosa è cambiato rispetto alla situazione precedente?
Un buon copilota per il customer service B2B non elimina l’operatore. Riduce il tempo necessario per cercare informazioni, rende più coerenti le risposte e aiuta a riconoscere prima i casi che richiedono una competenza diversa. L’automazione può arrivare in seguito, ma solo sulle attività ripetitive, reversibili e sufficientemente misurate.
Per una PMI, partire in questo modo è meno spettacolare di un chatbot che promette di risolvere tutto. È però molto più utile per capire se l’AI sta davvero migliorando l’assistenza o sta soltanto aggiungendo un nuovo livello di complessità.