← Back to desktop ← Return to Blog

Agenti AI assistenza clienti: progettare il passaggio umano

Un agente AI per l’assistenza clienti può rispondere in pochi secondi a domande su ordini, spedizioni, fatture e configurazioni. Per una PMI però il valore non sta nell’automatizzare tutto. Sta nel decidere con precisione cosa gestisce l’agente, cosa fa solo con un’approvazione e quando passa il cliente a una persona, senza costringerlo a ripetere tutto da capo. Questo articolo parla di questo: come progettare un agente di supporto che riduce il carico sul team e intanto non fa arrabbiare i clienti.

Cosa dicono i dati, e chi li pubblica

Secondo un’indagine ripresa da Tom’s Hardware, due team di assistenza su tre usano già agenti AI e i tempi di gestione dei casi si accorciano. Lo stesso studio riporta però che l’87% dei clienti vuole poter parlare con una persona. C’è un dettaglio importante: i dati vengono da un fornitore che vende proprio questi agenti, quindi vanno letti con cautela.

Il messaggio di fondo resta utile anche facendo la tara alla fonte. L’adozione cresce, ma il cliente non accetta di restare chiuso in una conversazione con una macchina. In un agente di supporto ben fatto il passaggio a una persona non è un ripiego. È una funzione progettata come le altre.

Cosa delegare all’agente AI (e cosa no)

Il primo lavoro non è tecnico. Si prendono gli ultimi mesi di ticket, email e chat e si classificano le richieste. In molte PMI emergono tre gruppi.

  • Richieste informative ripetitive: orari, tempi di consegna, compatibilità di un prodotto, procedura di reso, dove trovare una fattura. Sono il terreno ideale per l’agente.
  • Richieste operative a basso rischio: stato di un ordine, modifica di un indirizzo prima della spedizione, apertura di una pratica di reso, prenotazione di un intervento. L’agente può eseguirle tramite integrazioni, con regole chiare.
  • Richieste delicate: reclami, contestazioni, rimborsi fuori policy, clienti strategici, problemi di sicurezza o di salute, questioni legali. Qui l’agente raccoglie le informazioni e passa la pratica. Non decide.

Se vendete online, la qualità delle risposte dipende molto da come sono strutturati i dati di prodotto. Ne ho parlato a proposito del catalogo e-commerce leggibile dagli agenti AI: le stesse schede pulite servono anche al vostro agente di supporto.

Progettare il passaggio a una persona

La maggior parte dei chatbot deludenti fallisce proprio qui. Il cliente scrive “voglio parlare con qualcuno” e riceve l’ennesima risposta generica. Un buon handoff si basa su quattro elementi.

1. Trigger espliciti e impliciti

L’agente deve passare la conversazione a una persona quando:

  • il cliente lo chiede, in qualunque forma (“operatore”, “una persona”, “non mi state aiutando”);
  • la richiesta rientra in una categoria delicata definita in partenza;
  • l’agente non trova la risposta nella knowledge base, oppure la sua confidenza è bassa;
  • la conversazione gira a vuoto: stessa domanda ripetuta più volte, tono sempre più frustrato;
  • serve un’azione oltre i permessi dell’agente, per esempio un rimborso sopra una certa soglia.

2. Contesto completo per l’operatore

Al momento del passaggio l’operatore deve ricevere nel suo strumento (Zendesk, Freshdesk, HubSpot, un helpdesk interno o anche una casella condivisa) un riepilogo strutturato. Dentro ci vanno chi è il cliente, numero d’ordine, problema, cosa è già stato verificato, cosa ha risposto l’agente e perché ha passato la pratica. Il cliente non deve ripetere nulla.

3. Aspettative realistiche

Se è domenica sera e il team rientra lunedì, l’agente deve dirlo chiaramente: “Ho inoltrato la richiesta a un collega, riceverà risposta entro lunedì mattina”. Promettere “un operatore arriva subito” quando nessuno è online è il modo più rapido per perdere fiducia.

4. Trasparenza

Il cliente deve sapere fin dall’inizio che sta parlando con un sistema automatico. Non è solo una buona pratica. Con l’AI Act diventa un obbligo, come spiego nell’articolo sull’articolo 50 e la trasparenza di chatbot e agenti AI.

Permessi, approvazioni e log: i guardrail minimi

Un agente che risponde e basta è una cosa. Un agente con accesso agli strumenti (gestionale, CRM, e-commerce, sistema di spedizioni) è un’altra, perché può agire. Nell’ultimo periodo si è parlato molto di sicurezza degli agenti. Un esempio è la piattaforma presentata da NVIDIA e raccontata da Rivista AI, che parte da un principio condivisibile: un agente non è sicuro solo perché il modello è stato addestrato bene. La sicurezza va costruita attorno al modello.

In pratica, per una PMI:

  1. Permessi minimi. L’agente legge lo stato dell’ordine ma non modifica i prezzi. Apre una pratica di reso ma non emette il rimborso. Ogni integrazione usa credenziali dedicate e limitate.
  2. Approvazione umana sulle azioni sensibili. Rimborsi, sconti, cancellazioni e modifiche a dati anagrafici o bancari passano da una conferma. In un workflow n8n o Make basta un nodo di approvazione, per esempio un messaggio su Slack o Teams con i pulsanti approva e rifiuta.
  3. Log di tutto. Ogni conversazione, ogni chiamata a uno strumento, ogni decisione di handoff va registrata. Servono a correggere gli errori, a rispondere alle contestazioni e a migliorare l’agente.
  4. Limiti di spesa e di frequenza. Un tetto al numero di azioni e al consumo di token per conversazione evita loop costosi.

Sul fronte privacy valgono le regole del GDPR: informativa aggiornata, base giuridica, fornitori nominati responsabili del trattamento, attenzione ai trasferimenti di dati fuori dall’UE. Conviene anche evitare che l’agente prenda da solo decisioni con effetti significativi sul cliente. Prima di andare in produzione, fate validare questa parte dal vostro DPO o consulente privacy.

Knowledge base e RAG: l’agente sa solo quello che gli date

Quasi sempre un agente di supporto affidabile si appoggia alla RAG (retrieval-augmented generation). Prima di rispondere, recupera i passaggi pertinenti dai vostri documenti: condizioni di vendita, FAQ, manuali, policy di reso, listini. Poi risponde basandosi su quelli. Così si riducono le risposte inventate.

Gli errori più comuni:

  • documenti vecchi o in contraddizione tra loro (due versioni della policy di reso);
  • informazioni importanti che esistono solo nella testa di un collega;
  • PDF scansionati o tabelle illeggibili;
  • nessun proprietario della knowledge base, che quindi non viene aggiornata.

Una regola pratica: se una risposta non sta nei documenti, l’agente non improvvisa. Dice che non lo sa e passa la richiesta. Ogni passaggio di questo tipo segnala una lacuna da colmare nella documentazione.

Un’architettura tipica per una PMI

Senza piattaforme enterprise, uno schema che funziona bene ha questi componenti.

  • Canali: widget sul sito, email, WhatsApp Business. Si parte da uno solo.
  • Orchestrazione: n8n (anche self-hosted, utile per tenere i dati sotto controllo) o Make, che riceve i messaggi, chiama il modello e gestisce le regole.
  • Modello LLM con tool use: può chiamare funzioni definite da voi, per esempio “cerca ordine”, “apri reso” o “crea ticket”.
  • Knowledge base indicizzata per la RAG.
  • Helpdesk o CRM dove arrivano i passaggi agli operatori con il contesto.
  • Logging e dashboard per controllare costi, risposte e motivi di handoff.

Questi progetti possono rientrare negli investimenti in software agevolabili. Ho approfondito il tema nell’articolo sull’iperammortamento 2026 per software, agenti AI e automazioni.

Come misurare se funziona

Lasciate perdere metriche di vanità come il numero di conversazioni. Guardate queste:

  • tasso di risoluzione senza persona sulle categorie delegate, non sul totale;
  • tasso di handoff e relativi motivi: se è alto su un tema, manca documentazione o un’integrazione;
  • tempo di prima risposta e di risoluzione, confrontati con lo storico;
  • riaperture: richieste “risolte” che il cliente riapre;
  • costo per conversazione, tra token, piattaforme e tempo di supervisione;
  • revisione a campione delle conversazioni, ogni settimana nelle prime fasi.

Conviene partire con un pilota di qualche settimana su una o due categorie di richieste, con l’agente che propone le risposte e un operatore che le approva. Poi si passa all’invio automatico solo dove la qualità è dimostrata.

Domande frequenti

Un agente AI può sostituire il team di assistenza?

In una PMI l’obiettivo realistico è un altro: togliere al team le richieste ripetitive e dargli pratiche già istruite. Reclami, casi complessi e clienti importanti restano alle persone.

Meglio un chatbot pronto o un agente su misura?

I chatbot integrati negli helpdesk vanno bene per le FAQ. Se servono integrazioni con gestionale, e-commerce o CRM, regole di handoff specifiche e controllo sui dati, un agente orchestrato su misura dà più flessibilità.

Quanto tempo serve per partire?

Dipende soprattutto dallo stato della documentazione e dalle integrazioni disponibili. Un pilota su un solo canale e poche categorie di richieste è il modo più rapido per avere dati reali su cui decidere.

Come evito che l’agente dia risposte sbagliate?

Usate la RAG su documenti aggiornati e date all’agente l’istruzione di non rispondere fuori dalle fonti. Prevedete il passaggio a una persona quando la confidenza è bassa e fate revisioni a campione. Nella fase iniziale, fate approvare le risposte prima dell’invio.

Il prossimo passo

Un agente AI per l’assistenza clienti funziona quando è progettato come un processo: categorie chiare, permessi limitati, passaggio a una persona senza attriti, knowledge base curata e metriche controllate. Se volete capire quali richieste della vostra azienda si possono automatizzare e come collegare l’agente ai vostri sistemi, contattatemi. Partiamo dai vostri ticket reali e costruiamo un pilota misurabile.

Cornel Caba — signature