Chatbot basati su regole vs LLM per l’automazione dell’assistenza clienti

Che problema risolviamo nell’assistenza clienti?

L’automazione dell’assistenza clienti ha un obiettivo pratico: rispondere correttamente a più clienti, più velocemente, senza sfiancare il tuo team. Questo significa decidere quali richieste il software può gestire in sicurezza e quali devono andare a una persona.

I chatbot funzionano meglio quando l’obiettivo del cliente è chiaro e i passaggi sono standard: stato dell’ordine, orari di apertura, reset password, aggiornare un indirizzo di consegna prima della spedizione o spiegare le regole di reso. Sono conversazioni ripetitive ad alto volume in cui la velocità conta più di un tocco umano unico.

Creano problemi quando il cliente è in un caso limite, quando le policy hanno eccezioni o quando la situazione richiede giudizio. Un bot che fornisce con sicurezza una risposta sbagliata può costarti denaro (rimborsi, chargeback), fiducia (reclami pubblici) e tempo (agenti che riparano i danni). Ecco perché il dibattito tra rule-based vs LLM è importante: riguarda risultati prevedibili, non frasi eleganti.

La coerenza conta più delle risposte spiritose perché il supporto è parte del tuo prodotto. I clienti vogliono la stessa risposta indipendentemente da chi contattano, e gli agenti hanno bisogno che il bot segua le stesse regole. Una risposta “utile” che viola la policy non è utile.

Un modo pratico per inquadrare il problema è decidere cosa vuoi che il bot faccia ogni giorno. Per la maggior parte dei team è una combinazione di: risolvere end-to-end le richieste ripetitive principali, raccogliere i dettagli giusti prima del trasferimento, ridurre i tempi di attesa senza abbassare la qualità della risposta e rimanere allineati con la policy e le informazioni di prodotto aggiornate.

Considera il chatbot come un passaggio nel processo di supporto, non come l’intero processo. Il risultato che vuoi è meno ticket e meno errori, non più conversazioni.

Chatbot basati su regole e LLM in parole semplici

Quando si confrontano rule-based vs LLM chatbot, si parlano di due modi diversi di decidere cosa rispondere.

Un chatbot basato su regole segue uno script. Definisci intenti (ciò che il cliente vuole, come “reset password” o “stato rimborso”) e mappi ogni intento in un albero decisionale. Il bot fa una domanda, verifica la risposta e passa al passo successivo. È prevedibile perché dice solo quello che hai scritto.

Un chatbot LLM funziona più come uno scrittore flessibile. Legge il messaggio del cliente, usa il contesto della conversazione e genera una risposta in linguaggio naturale. Gestisce meglio il linguaggio disordinato e le domande multi‑parte, ma può anche indovinare, sovra‑spiegare o allontanarsi dalla policy a meno che non lo limiti.

Le configurazioni ibride sono comuni perché il supporto ha bisogno sia di sicurezza sia di linguaggio naturale. Una divisione utile è:

• Le regole decidono cosa è permesso (idoneità, rimborsi, passaggi di verifica, formulazioni richieste).
• Un LLM aiuta sul come dirlo (tono, spiegazioni brevi, riassumere un caso prima del trasferimento).

Per esempio, le regole confermano che un ordine è nel periodo di reso, poi l’LLM redige un messaggio amichevole che corrisponde alla voce del tuo brand.

Un modo rapido per scegliere:

• Principalmente regole quando le policy sono rigide, gli errori costano e le domande sono ripetitive.
• Principalmente LLM quando le domande variano, i clienti usano linguaggio imprevedibile e l’escalation è chiara.
• Sia che usi entrambi quando vuoi risposte di policy coerenti ma anche una conversazione più naturale.

Accuratezza: cosa va storto e come si manifesta

Nel supporto, “accuratezza” non significa solo avere un fatto corretto. Vuol dire tre cose insieme: la risposta è corretta, copre ciò di cui il cliente ha realmente bisogno (non una risposta a metà) e rimane entro la policy (regole di rimborso, limiti di sicurezza, conformità).

Rule-based e LLM tendono a fallire in modi diversi e prevedibili.

I bot basati su regole di solito falliscono quando la realtà non corrisponde all’albero decisionale. Appare una nuova domanda senza un ramo, il cliente usa parole inaspettate o il bot sceglie l’intento sbagliato. L’esperienza sembra risposte preconfezionate irrilevanti, menu ripetitivi o “Scegli una di queste opzioni” anche se il cliente ha già spiegato il problema.

I bot LLM tendono a fallire per eccesso di fiducia. Possono indovinare una policy, inventare passaggi o confondere dettagli di prodotto. L’esperienza è peggiore perché suona utile ma è sbagliata. Un altro problema è la deriva della policy: il bot risponde in modo diverso da una chat all’altra, specialmente quando cerca di essere “carino” e piega le regole (per esempio offrendo rimborsi fuori dalla finestra prevista).

Per misurare l’accuratezza, usa ticket reali e valuta i risultati, non le impressioni. Etichetta un campione di chat e traccia:

• Risoluzione corretta (ha risolto il problema del cliente?)
• Conformità alla policy (ha promesso qualcosa che non dovrebbe?)
• Tasso di escalation (ha passato la conversazione quando doveva?)
• Tasso di ricontatto entro 24–72 ore (il cliente è tornato?)

A volte la risposta più accurata è un sicuro “Non lo so.” Se la domanda riguarda accesso account, eccezioni di fatturazione o qualcosa che richiede verifica, un trasferimento chiaro batte un’ipotesi rischiosa. Un buon bot guadagna fiducia sapendo i propri limiti e indirizzando il cliente alla persona giusta con tutto il contesto.

Costo di manutenzione: tempo di costruzione vs sforzo continuo

La differenza di costo principale tra rule-based e LLM non è la prima costruzione. È cosa succede dopo che il tuo prodotto, i prezzi e le policy iniziano a cambiare.

I bot basati su regole costano di più all’inizio perché devi mappare i flussi: intenti, alberi decisionali, casi limite e i trigger esatti che fanno prendere a una conversazione ogni percorso. È lavoro accurato, ma produce comportamenti prevedibili.

I bot LLM spesso sembrano più rapidi da avviare perché puoi puntarli a un help center o a documenti interni e scrivere istruzioni, poi affinare dalle chat reali. Il compromesso è il controllo continuo.

Col tempo, il lavoro si sposta:

• I bot basati su regole necessitano di modifiche quando qualcosa cambia (un nuovo livello di spedizione, un piano rinominato, una nuova eccezione nella policy di rimborso).
• I bot LLM necessitano di mantenere fonti aggiornate (documenti, macro, note di prodotto) e vincoli (istruzioni, guardrail), più controlli regolari che le risposte siano ancora conformi alla policy.

Chi lo mantiene conta. I sistemi a regole generalmente costringono allineamento tra support ops e prodotto su regole esatte, poi qualcuno implementa e testa le modifiche. I sistemi LLM possono essere aggiornati più facilmente da support ops se la knowledge base è ben gestita, ma serve comunque ingegneria per retrieval più sicuro, logging e gestione delle escalation.

I costi che i team spesso sottovalutano fino al lancio includono test di regressione dopo cambi di policy, monitoraggio per risposte rischiose, revisione delle conversazioni per tono e conformità e aggiornamento delle fonti quando emergono nuovi gap.

La frequenza dei cambiamenti guida il costo totale. Se le tue policy cambiano settimanalmente, un albero rigido diventa rapidamente costoso. Se le policy cambiano raramente ma devono essere esatte (come regole di garanzia), un bot basato su regole può essere più economico nel tempo.

Mantenere le risposte coerenti con la policy

Un bot di supporto è “buono” solo se segue le stesse regole che usano i tuoi agenti. Il modo più veloce per perdere fiducia è quando il bot promette un rimborso, modifica un indirizzo o condivide dettagli di account in modo non consentito dalla policy.

Inizia scrivendo cosa il bot è autorizzato a fare senza un umano. Concentrati sulle azioni, non sui temi. “Può spiegare come funzionano i rimborsi” è diverso da “può emettere un rimborso” o “può cancellare un abbonamento”. Più il bot può cambiare (soldi, accesso, dati personali), più le regole devono essere rigide.

Usa una sola fonte di verità per i testi di policy e le macro. Se la tua policy di rimborso è sparsa su più documenti e note agenti, otterrai risposte incoerenti. Metti la formulazione approvata in un unico posto e riusala ovunque (chat, email, canali di messaggistica). Qui è dove rule-based e LLM spesso divergono: le regole fanno rispettare la formulazione esatta, mentre gli LLM hanno bisogno di forti vincoli per evitare la deriva.

Guardrail che mantengono le risposte nella policy

Buoni guardrail sono semplici, visibili e facili da testare:

• Snippets approvati per argomenti sensibili (rimborsi, garanzie, chargeback, accesso account)
• Dichiarazioni proibite (come “data di consegna garantita” o “rimborso istantaneo”)
• Disclaimer obbligatori (verifiche d’identità, tempi di lavorazione, idoneità)
• Campi strutturati che il bot deve raccogliere prima di qualsiasi azione (ID ordine, email, ultime 4 cifre)
• Una regola “se incerto, escala” che si attiva presto

Versioning e tracciabilità

Le policy cambiano. Trattale come software: versione i testi e registra quale versione è stata usata per ogni risposta. Se un cliente contesta qualcosa che il bot ha detto la settimana scorsa, puoi vedere il testo esatto di policy che il bot stava seguendo.

Esempio: un ecommerce aggiorna la finestra di reso da 30 a 14 giorni. Con il versioning, il bot può rispondere in base alla data e tu puoi successivamente verificare i casi limite.

Flussi di escalation che non frustrano i clienti

Un chatbot è buono quanto il suo trasferimento a un umano. Quando le persone si sentono intrappolate in un loop, smettono di fidarsi del canale. Sia che tu scelga rule-based o LLM, progetta l’escalation come parte normale dell’esperienza, non come un fallimento.

Inizia con trigger chiari che spostano la chat a una persona senza costringere l’utente a implorare. Trigger comuni includono bassa confidenza, parole chiave come “rimborso”, “chargeback”, “legale” o “cancella”, sentiment fortemente negativo, limiti di tempo senza progresso o tentativi falliti multipli sullo stesso passaggio.

Quando avviene l’escalation, non far ripetere il cliente. Passa un pacchetto di contesto breve all’agente:

• Un riassunto conciso del problema in linguaggio semplice
• Dati cliente già noti (nome, account, ID ordine)
• Cosa il bot ha chiesto e cosa ha risposto l’utente
• Passaggi già tentati e i loro esiti
• Eventuali file, screenshot o messaggi di errore condivisi

Imposta le aspettative in una frase: cosa succede dopo e quanto tempo potrebbe richiedere. Per esempio: “Sto inviando questo a uno specialista del supporto ora. Il tempo di attesa tipico è di circa 5 minuti. Puoi continuare a scrivere qui.”

Rendi il trasferimento reversibile. Gli agenti spesso vogliono che il bot esegua passaggi di routine (raccolta log, troubleshooting di base, recupero dettagli mancanti) mentre loro si concentrano sulle eccezioni. Un semplice “invia al cliente una checklist guidata dal bot” risparmia tempo e mantiene il servizio coerente.

Infine, traccia perché avvengono le escalation. Tagga ogni motivo di handoff (bassa confidenza, richiesta di policy, cliente arrabbiato, dati mancanti) e rivedi i principali settimanalmente. Quel loop di feedback è il modo in cui il bot migliora senza diventare rischioso.

Passo dopo passo: scegliere e distribuire il chatbot giusto

Inizia piccolo di proposito. Automatizza poche domande ripetitive per prime, poi migliora dalle trascrizioni reali. Questo approccio funziona sia con bot basati su regole sia con LLM, perché la parte difficile non è il modello: sono le decisioni su policy, handoff e misurazione.

Un piano di rollout pratico

1. Scegli 3–5 tipi di ticket ad alto volume e basso rischio. Buoni esempi: stato ordine, reset password, orari del negozio e riepiloghi della policy di rimborso. Evita tutto ciò che può causare perdita di denaro o modifiche all’account finché non ti fidi del flusso.

2. Definisci il successo prima di costruire. Scegli 2–3 metriche settimanali come tasso di risoluzione senza intervento umano, CSAT dopo la chat e minuti risparmiati per turno agente.

3. Scrivi regole di policy e una breve lista del “mai fare”. Esempi: mai confermare identità senza un passo verificato, mai promettere date di consegna non visibili, mai chiedere numeri di carta completi.

4. Costruisci i percorsi principali e un fallback reale. Redigi risposte ideali, poi aggiungi una modalità educata di errore quando il bot è incerto: ripeti ciò che ha capito, fai una domanda chiarificatrice o offri un trasferimento. Se usi un LLM, mantieni gli argomenti sensibili ancorati a snippet approvati.

5. Esegui un pilot con clienti reali, poi espandi. Mantienilo limitato (un canale, un team, una settimana). Rivedi le trascrizioni giornalmente, tagga i fallimenti (intento sbagliato, dati mancanti, rischio di policy), aggiorna il flusso e solo allora aggiungi più argomenti.

Errori comuni e trappole da evitare

Il modo più rapido per restare delusi è trattare rule-based e LLM come lo stesso strumento. Falliscono in modi diversi, quindi le trappole cambiano.

Un errore comune è mescolare “ciò che il bot deve fare” (policy) con “come dovrebbe suonare” (tono) in un unico insieme di istruzioni. Il tono è flessibile. La policy no. Mantieni la policy come regole chiare e verificabili (finestre di rimborso, controlli di identità, cosa non promettere), poi lascia che il bot applichi una voce amichevole sopra.

Un’altra trappola ad alto rischio è permettere al bot di rispondere a domande specifiche sull’account senza una barriera netta. Se un utente chiede “Dov’è il mio ordine?”, il bot non dovrebbe indovinare. Deve richiedere una verifica o passare a un sistema sicuro che recuperi i dati corretti.

Controlla questi pattern prima del lancio:

• Nessun fallback reale, quindi il bot continua a indovinare quando è incerto
• Testare solo domande educate e chiare, saltando messaggi arrabbiati o vaghi
• Permettere al bot di inventare eccezioni e offerte speciali
• Assenza di un loop di revisione umano, così gli stessi errori si ripetono
• Non passare la trascrizione completa agli agenti, costringendo i clienti a ripetere

Un esempio semplice: un cliente scrive “La vostra app mi ha addebitato due volte. Sistemalo ora.” Se il bot non è preparato alla frustrazione e all’urgenza, può rispondere con una FAQ generica sulla fatturazione. Meglio una breve scusa, una domanda chiarificatrice (metodo di pagamento e ora) e un passo successivo chiaro: avviare il workflow corretto o escallare.

Checklist veloce prima del go live

Prima di attivare l’automazione per tutti, tratta il bot come un nuovo agente di supporto: ha bisogno di addestramento, confini e supervisione. Questo è il modo più veloce per evitare escalation prevenibili e errori di policy, sia che tu scelga rule-based o LLM.

• Le fonti delle risposte sono bloccate. Il bot risponde solo da contenuti di policy approvati (regole di rimborso, tempistiche di spedizione, termini di garanzia, regole di sicurezza). Se non trova una corrispondenza, lo dice e offre un trasferimento.
• L’escalation è chiara e sempre disponibile. Definisci i trigger (linguaggio arrabbiato, problemi di accesso account, controversie di pagamento, richieste legali, ripetuto “non è stato utile”). Assicurati che “parla con un umano” funzioni in qualsiasi momento.
• Puoi verificare ogni conversazione. Memorizza la domanda utente, la risposta del bot, quali fonti sono state usate (o “nessuna”) e l’esito (risolto, escalato, abbandonato).
• Hai un’abitudine di revisione settimanale. Per il primo mese, rivedi i maggiori bucket di fallimento (policy sbagliata, risposta incompleta, linguaggio poco chiaro, instradamento errato) e trasformali in correzioni testabili.
• Gli aggiornamenti di policy hanno un piano di test. Quando la policy cambia, aggiorna il contenuto sorgente e riesegui un piccolo set di chat obbligatorie (richiesta di rimborso, cambio indirizzo, ritardo consegna, reset password, cliente arrabbiato).

Un esempio realistico: chat di supporto per un ecommerce

Immagina un piccolo brand ecommerce con tre richieste top: “Dov’è il mio ordine?”, “Devo cambiare l’indirizzo di spedizione” e “Voglio un rimborso.” Qui rule-based vs LLM diventa molto pratico.

Per lo stato ordine, un bot basato su regole è di solito la prima linea più sicura. Chiede il numero d’ordine e l’email, verifica lo stato con il corriere e poi risponde con un messaggio coerente: posizione attuale, finestra di consegna prevista e cosa fare se il pacco è in ritardo. Niente supposizioni.

Il cambio indirizzo è anche un buon percorso basato su regole perché le regole sono chiare. Il bot verifica se l’ordine è ancora non evaso, conferma il nuovo indirizzo e lo aggiorna. Se l’ordine è già spedito, si ferma e offre il passo successivo giusto (contattare il corriere o creare un reso dopo la consegna).

Un bot LLM aiuta soprattutto quando il messaggio del cliente è confuso o emotivo. Può riformulare ciò che il cliente vuole, raccogliere dettagli mancanti e riassumere il caso per un agente. L’obiettivo non è una conversazione lunga, ma un trasferimento più pulito.

I rimborsi sono il punto in cui escalation e formulazioni controllate contano. Un bot dovrebbe escalare quando la decisione dipende da eccezioni o prove: articoli danneggiati (servono foto), pacchi mancanti dopo una scansione “consegnato”, richieste fuori dalla finestra di policy, segnali di chargeback o ordini di alto valore.

Per mantenere le risposte coerenti con la policy, tratta il messaggio finale del rimborso come un template controllato, non testo libero. Lascia che l’LLM compili solo campi approvati (date, ID ordine, passi successivi) mentre la formulazione della policy resta fissa.

Passi successivi: costruire un setup di automazione che duri

Scegli una fetta di supporto ad alto volume e basso rischio (stato ordine, reset password, cambio indirizzo) e automatizza solo quella. Espandi basandoti su ciò che riduce davvero i ticket e fa risparmiare tempo agli agenti.

Scegli il pattern in base al livello di rischio, non alla preferenza. Per risposte fattuali e ricche di policy, regole o flussi strutturati di solito vincono. Per domande disordinate (“cosa dovrei fare ora?”), un LLM può essere d’aiuto, ma solo con guardrail. Molti team optano per un ibrido: regole per le parti che devono essere esatte e un LLM per redigere, riassumere e instradare.

Un piano di costruzione semplice riutilizzabile su più canali:

• Un intake chiaro in chat (cosa è successo, numero ordine, email)
• Regole di instradamento (fatturazione, spedizione, tecnico) con opzione di handoff umano
• Controlli di autenticazione per richieste specifiche dell’account
• Log di audit su cosa ha detto il bot e quali dati ha usato
• Template approvati per argomenti sensibili (rimborsi, privacy, cancellazioni)

Se vuoi implementare questi flussi senza costruire tutto da zero, AppMaster (appmaster.io) può essere usato per modellare i dati, costruire processi di supporto con logica aziendale visuale e collegare i trasferimenti di chat ai sistemi backend che tracciano richieste e versioni di policy.