Scegliete tra chatbot IA e live chat in base al compito che il visitatore deve completare. Spiegare una politica pubblicata, verificare l’account di una persona, modificare una prenotazione e parlare con un essere umano richiedono informazioni, permessi e responsabilità differenti. Un assistente sui contenuti pubblici può essere adatto al primo compito. Per gli altri possono essere essenziali una conversazione con personale o un flusso di assistenza verificato separatamente. Scegliete il percorso responsabile prima della finestra di chat.
Autore: Achla AI, organizzazione. Revisione: 14 ottobre 2026. Preparato con l’assistenza dell’IA a partire da indicazioni ufficiali sui servizi, documentazione dei prodotti di supporto e fonti di prodotto Achla. Strumenti decisionali e scenari sono originali e ipotetici. Non si dichiarano riduzioni misurate dei ticket, risultati di clienti o test di assistenza completati.
Confrontare chatbot IA e live chat partendo dall’attività del visitatore
Il Government Digital Service britannico definisce la webchat, chiamata anche live chat, come una conversazione tra un utente e un consulente umano. La distingue dal chatbot che aiuta senza un consulente umano e segnala la necessità di personale formato per la webchat. È una distinzione funzionale utile anche quando i fornitori combinano le due interfacce in un prodotto. Indicazioni su chatbot e webchat.
La prima domanda di acquisto non è quindi «Quale tecnologia è migliore?», ma «Chi o cosa è responsabile di completare il compito di questo visitatore?». Una risposta automatica ben formulata non dimostra che una persona sia disponibile. Una persona nella finestra di chat necessita comunque delle informazioni e dell’autorità corrette.
Scrivete il risultato desiderato in termini semplici: comprendere, verificare, modificare o parlare. Questi verbi aiutano a capire se il canale proposto possa completare davvero il compito.
Separare le domande pubbliche dai casi privati e dalle azioni
Considerate quattro richieste ipotetiche sullo stesso sito aziendale.
«Qual è la vostra politica di cancellazione?» richiede il testo pubblico dell’organizzazione. «La mia cancellazione è stata elaborata?» richiede la pratica del cliente corretto. «Cancellatela per me» domanda un’azione. «Voglio discutere dell’accaduto con qualcuno» chiede una conversazione umana. L’argomento è simile; il servizio richiesto non lo è.
Classificate in base al risultato necessario, non alle parole usate. Una risposta su una politica può spiegare un processo e collegarne la fonte senza conoscere l’identità del visitatore. Uno stato individuale richiede un modo verificato per stabilire a chi appartenga la pratica. Un’azione richiede il permesso di cambiare qualcosa. Una conversazione richiede una persona disponibile o un percorso alternativo descritto onestamente.
Non lasciate che la presenza dell’IA annulli queste distinzioni. La generazione di testo da sola non dimostra accesso agli account, transazioni autorizzate o disponibilità di personale. Chiedete documentazione separata per ogni capacità necessaria.
Distinguete anche una preferenza per una persona da un’eccezione. Un visitatore può desiderare una persona anche quando esiste una risposta pubblica. Un altro può richiedere una valutazione perché le regole pubblicate non chiariscono le sue circostanze. In entrambi i casi, registrate il percorso umano desiderato senza presumere che un’altra spiegazione automatica completi la richiesta.
Sono categorie di acquisto, non una formula per eliminare il personale di assistenza. Lo strumento seguente assegna responsabilità; non stima quante richieste scompariranno.
Usare la matrice decisionale dei percorsi di assistenza
Compilate la matrice con le attività dei vostri visitatori. Le voci seguenti sono illustrative e non sono state collaudate su alcun prodotto.
| Attività del visitatore | Informazioni e azioni necessarie | Requisito umano | Canale da esaminare | Responsabile e prove di disponibilità |
|---|---|---|---|---|
| Comprendere una politica pubblica | Politica approvata; spiegare e collegare | Contatto opzionale per interpretazioni irrisolte | Assistente di risposte sui contenuti pubblici | Il responsabile della politica approva la fonte; quello del sito verifica la disponibilità documentata del prodotto |
| Verificare lo stato di un account personale | Identità verificata e pratica dell’account; recuperare | Persona o flusso verificato consapevole dell’account | Servizio account autenticato o canale di assistenza | Il responsabile del servizio conferma autorizzazione e percorso di supporto |
| Modificare una prenotazione | Pratica, identità e permesso di scrittura | Personale autorizzato o processo transazionale verificato | Servizio di prenotazione o flusso di assistenza | Il responsabile operativo conferma chi possa eseguire modifiche e quando |
| Discutere un’eccezione | Circostanze e valutazione responsabile | Persona che possa decidere o inoltrare la decisione | Canale di assistenza con personale | Team identificato, autorità e disponibilità pubblicata o aspettativa di risposta |
| Richiedere subito una persona | Conversazione con una persona | Esplicito | Live chat con personale o alternativa chiaramente dichiarata | Il responsabile del personale conferma se qualcuno sia realmente raggiungibile ora |
| Trovare un manuale fuori dagli orari presidiati | Manuale pubblico approvato; spiegare o individuare | Alternativa per un compito irrisolto | Assistente di informazioni pubbliche e contatto separato | Restano identificabili i responsabili della documentazione e del contatto |
Un canale non è accettato solo perché il widget può mostrare una risposta. Per ogni riga necessaria, chiedete al fornitore o al team operativo prove degli elementi mancanti. Segnate come sconosciuta la disponibilità non verificata; non trasformatela in «assistenza 24 ore su 24» perché il pulsante resta visibile di notte.
Separate il responsabile dei dati da quello del canale quando necessario. Il team di prodotto può mantenere le politiche, mentre un team di servizio gestisce le eccezioni. La scheda deve indicare chi corregge informazioni errate e chi riceve il visitatore quando le informazioni non bastano.
Cosa distingue un vero passaggio a un operatore da un collegamento di contatto?
Un collegamento di contatto rimanda a un altro percorso: e-mail, modulo, telefono o pagina di assistenza. Può essere del tutto appropriato, ma non dimostra che la conversazione attuale sia stata assegnata a una persona. Il visitatore potrebbe dover iniziare una nuova richiesta e la conversazione originale potrebbe non seguirlo.
Un passaggio nativo è un flusso documentato del prodotto con instradamento configurato e cambiamento della responsabilità di risposta. La documentazione Zendesk su handoff e handback descrive il trasferimento del ruolo di primo risponditore tra agente IA e operatore umano; la notifica all’operatore segue il flusso di instradamento dell’account. È un comportamento specifico di Zendesk, non una capacità automaticamente comune a ogni chatbot. Handoff e handback Zendesk.
Anche Intercom documenta indicazioni, regole e workflow di escalation per Fin. Le indicazioni attuali distinguono l’offerta di escalation dall’escalation immediata e descrivono un esito diverso quando non è configurata una destinazione umana. L’acquirente deve verificare la destinazione configurata, non soltanto la frase del bot che dice di poter aiutare. Indicazioni di escalation Intercom.
Per ogni passaggio dichiarato chiedete dove arrivi la richiesta, chi diventi responsabile, cosa riceva la persona e cosa accada se nessuno è disponibile. Non deducete conservazione del contesto, scadenze di risposta o completamento di azioni senza prove per quel prodotto e quella configurazione esatti.
Il widget Achla di risposte pubbliche supportato da prove non viene presentato qui come live chat con personale o sistema nativo di trasferimento a operatori. Se la continuità nella stessa conversazione è essenziale, valutate un prodotto verificato separatamente che la offra.
Scrivere la scheda di responsabilità e aspettative
Create una scheda per ogni canale che intendete offrire. L’esempio seguente riguarda una piccola impresa di servizi ipotetica che sceglie un assistente di informazioni pubbliche accanto a un percorso e-mail di supporto esistente. È una proposta, non un risultato.
| Campo della scheda | Decisione illustrativa |
|---|---|
| Scopo del canale | Spiegare informazioni pubbliche approvate su servizi e politiche |
| Responsabile dei contenuti | Il responsabile del servizio esamina il testo della fonte pubblica |
| Responsabile del canale | Il manutentore del sito gestisce configurazione e controlli del widget |
| Responsabile del percorso umano | Il team di supporto esistente monitora il canale e-mail separato |
| Orari presidiati | Usare solo gli orari effettivamente confermati dal team di supporto |
| Aspettativa di risposta | Pubblicare un’aspettativa concordata se esiste; altrimenti non inventare una scadenza |
| Percorso per attività non supportate | Mostrare la pagina di supporto o il contatto disponibile indipendentemente |
| Confine dei dati privati | Non chiedere password, dati degli account o dettagli sensibili nella chat di risposte pubbliche |
| Descrizione del passaggio | Solo percorso di contatto; nessuna promessa di trasferimento nativo o continuità della conversazione |
| Decisione di accettazione | Ammesso alla valutazione delle risposte pubbliche; le azioni sugli account restano fuori da questo requisito del prodotto |
Il lavoro importante consiste nel completare i campi delle responsabilità ancora vuoti. Un prodotto può rispondere dai contenuti, ma all’organizzazione serve comunque una persona responsabile di quei contenuti. Un modulo può raccogliere un messaggio, ma qualcuno deve monitorarlo. Un avviso di disponibilità richiede un responsabile che lo mantenga accurato.
Usate schede diverse se proponete anche live chat o servizi sugli account. Devono identificare il responsabile del personale o del flusso autenticato. Non copiate «team di supporto» in ogni campo lasciando poco chiara la destinazione effettiva.
Progettare il percorso chiuso o indisponibile prima di scegliere il software
Specificate il passo successivo del visitatore quando il percorso preferito non può completare l’attività. Il Government Digital Service raccomanda alternative quando chatbot o webchat non forniscono il supporto necessario e di pianificare i vicoli ciechi della conversazione. Le indicazioni sull’assistenza digitale accompagnata descrivono anche supporto telefonico, via webchat o di persona secondo le esigenze degli utenti. Indicazioni sull’assistenza digitale accompagnata.
Un percorso indisponibile non è un problema che il testo del software possa nascondere. Se il visitatore chiede una persona fuori orario, l’interfaccia non deve far credere che un operatore stia arrivando se non è vero. Se l’unica alternativa è asincrona, descrivetela accuratamente. Se una richiesta urgente necessita di un altro canale già stabilito, mantenetelo visibile anziché affidarvi all’assistente perché ne inventi uno.
Evitate di usare una chat automatica come luogo non approvato per raccogliere dettagli degli account. Indirizzate un caso privato al processo verificato dell’organizzazione. Registrate nella scheda collegamento, responsabile e aspettativa onesta.
Le indicazioni Zendesk sulla progettazione dei workflow trattano il percorso dall’assistenza automatica al supporto umano come una decisione progettuale. Usatele per capire perché il percorso operativo vada pianificato; non copiate le funzioni Zendesk nella descrizione delle capacità di un altro fornitore. Progettazione dei workflow conversazionali Zendesk.
Prendere una decisione circoscritta sul prodotto con la scheda completata
Scegliete un assistente sui contenuti pubblici se il compito essenziale è spiegare o trovare informazioni pubbliche approvate e il contatto separato è sufficiente per le necessità residue. Scegliete un canale con personale quando la conversazione umana è essenziale. Esaminate un flusso autenticato o transazionale verificato quando il compito necessita di pratiche personali o azioni.
Un prodotto combinato può essere appropriato se il trasferimento nativo è una parte necessaria del servizio. Valutate destinazione del trasferimento, disponibilità operativa e prove della configurazione specifica. «Include l’IA» non risponde a queste domande.
Usate tre possibili esiti di acquisto: adatto al compito pubblico richiesto, necessita di un’altra capacità verificata oppure non ancora decidibile perché mancano prove. Il terzo è utile: impedisce che una dimostrazione del fornitore riempia implicitamente le lacune della scheda di responsabilità.
Se i requisiti cambiano in seguito, riaprite la decisione. Un assistente di informazioni pubbliche scelto oggi non diventa uno strumento di servizio agli account perché qualcuno aggiunge una domanda al messaggio di benvenuto. Ogni nuova capacità dichiarata resta soggetta a documentazione e revisione del responsabile.
Per una selezione più ampia della categoria, consultate la panoramica sulla ricerca IA nel sito. La scheda resta lo strumento più specifico per decidere quale canale debba gestire ogni attività del visitatore.
Dove valutare Achla per le risposte pubbliche
Achla è un candidato per risposte con collegamenti alle fonti sulle informazioni pubbliche del sito. Consultate la documentazione di installazione attuale, inclusi script generico e percorsi CMS documentati. I responsabili Drupal possono esaminare anche la pagina del connettore Drupal. Il posizionamento non aggiunge accesso agli account, operatori umani, acquisizione di contatti o transazioni.
Leggete le indicazioni di risoluzione dei problemi per le verifiche di installazione successive e i prezzi attuali per le condizioni. Se la scheda completata corrisponde all’ambito delle risposte pubbliche, iniziate l’onboarding; potrebbe essere necessario accedere. Valutate quel compito circoscritto sul vostro sito. Tenete separata la valutazione delle risposte pubbliche dalle decisioni su personale e servizi agli account registrate nella scheda.