Un cliente chiede di parlare con una persona. Il bot dice che qualcuno sta per entrare nella chat, ma non arriva nessuno. Per correggere questa esperienza, occorre prima decidere dove inviare la richiesta e chi risponderà.
Questa guida distingue un trasferimento in diretta da un ticket di supporto. Usa il funzionamento attuale dell'escalation di Agentkit per spiegare i limiti della configurazione. Propone poi una politica e verifiche di accettazione da adattare al tuo team di supporto. I dettagli del prodotto sono stati verificati il 6 ottobre 2026. Gli esempi sono illustrativi e non sono risultati di clienti.
Come definire le condizioni per il passaggio dal bot a un operatore umano nel supporto?
Definisci le condizioni per le richieste esplicite di parlare con una persona, le risposte ripetute che non aiutano e le attività fuori dall'ambito del bot, e verifica ciascuna condizione prima del lancio. Agentkit può creare una pratica di supporto tramite sei sistemi esterni di helpdesk o CRM collegati, ma la sua azione generica Escalate to Human non collega una persona in diretta alla chat.
Scegli una destinazione, raccogli i recapiti necessari e spiega al cliente cosa succederà dopo. La creazione riuscita di un ticket conferma che la richiesta è stata registrata. Non conferma che una persona l'abbia letta o che risponderà entro un tempo preciso.
Scegli il passaggio che il tuo team può gestire
Un trasferimento in diretta richiede un canale presidiato e un'integrazione che consenta a una persona di proseguire la conversazione. Un passaggio tramite ticket registra la richiesta per un ricontatto successivo. I clienti devono sapere quale riceveranno.
L'azione generica Escalate to Human di Agentkit supporta Zendesk, Freshdesk, Help Scout, Intercom, HubSpot e Salesforce. La destinazione riceve un ticket, un caso o una conversazione, a seconda del fornitore. Salesforce Live Chat è un'azione separata. Scegliere Salesforce come destinazione dell'escalation generica crea un caso, non una sessione di chat in diretta.
Agentkit Help Desk è un'altra destinazione, nativa. Richiede una conversazione salvata, un piano con accesso a Help Desk e Help Desk abilitato per quell'agente. Serve anche un indirizzo e-mail valido del richiedente. I ticket della chat del sito non hanno un campo per comporre risposte nella casella di Help Desk e non aggiungono al widget un canale di risposta umana in diretta. Prima di abilitare il flusso, il team deve predisporre un altro percorso di ricontatto, come la propria e-mail di supporto.
Per una destinazione esterna, collega il fornitore e conferma che il tuo piano supporti l'azione. Quindi aggiungi e abilita l'azione per l'agente. Verifica le autorizzazioni e la casella del team destinatario con una richiesta di prova innocua.
Definisci le condizioni in base alle decisioni di supporto
Parti da decisioni che il tuo team sappia spiegare. Non trattare ogni riferimento a un "essere umano" o ogni frase negativa come la stessa richiesta.
| Condizione | Esempio | Politica da verificare |
|---|---|---|
| Richiesta esplicita | "Per favore, fammi parlare con una persona." | Offri il percorso di supporto disponibile e raccogli i recapiti necessari. |
| Insuccesso ripetuto | "Questa risposta non risolve ancora il mio problema." | Smetti di ripetere lo stesso consiglio e proponi un'escalation. |
| Fuori dall'autorità del bot | Un addebito contestato o una richiesta di modifica dell'accesso all'account | Invia al team responsabile invece di inventare una decisione o confermare una modifica non autorizzata. |
| Urgenza o frustrazione | "Il mio account è bloccato e non posso lavorare." | Offri aiuto prontamente, descrivendo il canale effettivo di ricontatto. Non promettere una risposta di emergenza senza personale disponibile. |
| Regola cliente verificata | Un account noto ha diritto a un percorso di supporto diverso | Usa dati del cliente attendibili e un percorso configurato. Un visitatore che si dichiara VIP non ha verificato la propria identità. |
Queste sono politiche consigliate, non interruttori integrati per condizioni deterministiche. L'azione di Agentkit ha istruzioni When to use che guidano il modello. Le istruzioni in linguaggio naturale devono essere verificate con formulazioni diverse e nelle lingue supportate. Da sole non forniscono una valutazione affidabile del sentiment, una verifica dello stato VIP o un contatore fisso di risposte rifiutate.
La documentazione di Intercom sull'escalation distingue le istruzioni in linguaggio naturale, le regole basate sui dati e l'instradamento dopo l'escalation. Sono distinzioni utili per valutare un flusso, ma non significano che Agentkit implementi il sistema di regole di Intercom.
Fornisci alla persona informazioni utili
Per un fornitore esterno collegato, l'escalation di Agentkit raccoglie un oggetto, un riepilogo del problema, un indirizzo e-mail valido e un nome quando disponibile. Il contesto del ticket include fino agli ultimi 50 messaggi salvati che non sono messaggi degli strumenti. Ogni messaggio visualizzato è limitato a 2.000 caratteri. La richiesta attuale viene inclusa quando disponibile.
Si tratta di un contesto limitato, non della promessa di una trascrizione completa. Il riepilogo è limitato a 2.000 caratteri e l'oggetto a 150 caratteri. La trascrizione visualizzata contiene il testo dei messaggi, non i file allegati. Il fornitore destinatario può imporre altri limiti. In una chat lunga, un numero d'ordine citato all'inizio potrebbe dover essere riportato nel riepilogo. Verifica cosa mostra effettivamente la destinazione scelta. Il ticket nativo di Help Desk rimanda alla conversazione salvata. Non presumere che la sua visualizzazione sia identica al corpo del ticket di un fornitore esterno.
Chiedi solo ciò che serve al team. Un indirizzo e-mail digitato è un recapito per il ricontatto, non la prova che il cliente sia proprietario di un account. Non chiedere ai visitatori di incollare password, dati delle carte di pagamento o credenziali private nella chat.
Un riepilogo utile indica cosa serve al cliente, cosa ha già tentato il bot e cosa resta irrisolto. Se il team ha bisogno di un motivo di escalation etichettato o di una coda specifica, configura e verifica quel flusso. Non presumere che l'azione generica lo fornisca automaticamente.
Definisci le aspettative senza inventare disponibilità
In un flusso tramite ticket, spiega al cliente che il supporto lo ricontatterà tramite il canale concordato. Includi un impegno sui tempi di risposta solo quando il team destinatario ne è responsabile e può rispettarlo. Non dire "un operatore sta entrando nella chat" solo perché è stato creato un ticket.
Per le richieste fuori orario, raccogli l'e-mail necessaria e il riepilogo del problema, poi comunica l'esito effettivo della creazione. Se la connessione è scaduta o la creazione del ticket fallisce, fornisci al cliente un'alternativa di contatto funzionante. Un messaggio rassicurante non sostituisce una pratica di supporto mancante.
L'annuncio dell'integrazione Zendesk di Chatbase esplicita la stessa distinzione tra canali. Il flusso tramite ticket usa il ricontatto via e-mail. L'integrazione Sunshine è un percorso separato di chat in tempo reale. Verifica l'integrazione effettiva prima di promettere un passaggio in diretta.
Un esempio di istruzione da adattare
Il seguente modello in inglese è una politica iniziale per un flusso tramite ticket. Non è un classificatore verificato né una regola di instradamento eseguibile.
Use the support-ticket action when the visitor clearly asks for a person, says the suggested answer did not help, or needs a decision outside your authority. Before calling it, collect or confirm a valid follow-up email and summarize the unresolved issue. Do not ask for passwords or payment-card details. After a successful result, explain that the request was recorded for follow-up. Do not claim a human has joined or promise a reply time unless the business has supplied a supported commitment. If creation fails, explain the problem and provide the business's alternative support contact. Do not say a ticket was created when the action failed.
Inserisci le indicazioni sulle condizioni nelle istruzioni When to use dell'azione e mantieni le aspettative del cliente coerenti con le istruzioni dell'agente. Verifica il flusso completo, compresa la casella destinataria, invece di controllare solo le parole del bot.
Verifica il flusso prima del lancio
Usa richieste simulate e un indirizzo di supporto che controlli. I casi seguenti sono una scheda di accettazione, non risultati di test già eseguiti.
| Caso di test | Cosa verificare |
|---|---|
| Richiesta chiara di una persona | L'azione abilitata corretta viene proposta o chiamata dopo aver raccolto i dettagli necessari. |
| Due risposte senza successo | Il bot propone un'escalation invece di ripetere lo stesso consiglio. Questa soglia è la tua politica di test, non un contatore integrato. |
| Nessuna e-mail nota dalla conversazione o dal record del contatto | Il bot chiede un indirizzo e-mail valido prima di tentare la creazione. |
| Conversazione lunga | La pratica ricevuta contiene un contesto recente utile. I dettagli importanti precedenti restano nel riepilogo. |
| Fornitore scollegato | Il bot segnala il fallimento e indica il percorso di supporto alternativo configurato. |
| Help Desk disabilitato | Non viene dichiarata la creazione riuscita di un ticket nativo. |
| Richiesta fuori orario | Il bot descrive correttamente il ricontatto senza inventare una coda in diretta o un tempo di risposta. |
| Richiesta di escalation ripetuta | Verifica se la pratica esistente viene riutilizzata e se il cliente riceve uno stato preciso. |
Annota l'identificativo della pratica ricevuta e verifica che un team designato riesca a trovarla. Ripeti i casi delle condizioni in ogni lingua che offri. Un messaggio corretto nella chat è solo una parte dell'accettazione.
Misura separatamente creazione e risposta
Monitora i tentativi di escalation, la creazione riuscita delle pratiche, gli errori di consegna e il tempo fino alla prima risposta umana. Per il tempo di risposta, usa i timestamp dell'helpdesk destinatario o la tua strumentazione. I soli log delle conversazioni di Agentkit non costituiscono un dashboard completo dei tempi di passaggio o della soddisfazione dopo il passaggio.
Esamina un campione di casi inoltrati per individuare informazioni mancanti e domande ripetute. Se raccogli valutazioni di soddisfazione, conserva il numero di risposte e il canale accanto al punteggio. La guida ai KPI dei chatbot spiega perché la gestione senza escalation e la risoluzione richiedono definizioni separate.
Parti da una destinazione supportata e da un team responsabile del ricontatto. Configura l'azione di escalation, esegui i casi di accettazione e conferma la ricezione prima di invitare i clienti a usarla.
Letture correlate:
