Convertire una conversazione in un ticket
Usa un ticket quando il lavoro deve continuare oltre la conversazione dal vivo oppure richiede un tipo, uno stato, un assegnatario o un percorso di risoluzione esplicito. Un ticket integra la cronologia della conversa...
Usa un ticket quando il lavoro deve continuare oltre la conversazione dal vivo oppure richiede un tipo, uno stato, un assegnatario o un percorso di risoluzione esplicito. Un ticket integra la cronologia della conversazione, non deve duplicare ogni messaggio del cliente né sostituire una risposta necessaria.
Questa guida spiega quando creare un ticket, come acquisire un contesto operativo, come il ticket principale appare in Inbox e come le azioni di invio e chiusura o di stato possono influire sia sul ticket sia sullo stato di handoff.
Come si inserisce in Humind
Inbox è il registro operativo delle conversazioni con i clienti. Combina la cronologia dei messaggi, il contesto dell’acquirente e del prodotto, la collaborazione interna, lo stato di handoff umano, i tag e i ticket. Le risposte dei clienti e le note interne hanno volutamente una visibilità diversa.
Una routine di team coerente conta più di qualsiasi singolo filtro. Concordate quando intervenire, quando lasciare una nota interna, quando creare un ticket e quando restituire una conversazione all’IA in modo che la responsabilità rimanga chiara per ogni operatore.
Prima di iniziare
Accesso: Per lavorare da una conversazione è richiesto l’accesso a Inbox. Le azioni di lettura o scrittura dei ticket seguono i permessi di ticketing e la configurazione dell’azienda, le impostazioni del provider sono controllate dagli amministratori.
- Conferma che il ticketing sia abilitato e che esistano il tipo di ticket previsto e gli stati.
- Leggi la conversazione, le note interne, i tag e il ticket principale esistente.
- Verifica se il team usa il ticketing di Humind o un provider esterno testato.
Procedura passo dopo passo
Decidi se è necessario un ticket
Crea un ticket per attività che richiedono follow-up tracciato, un altro team, un ciclo di vita strutturato o una risoluzione dopo che l’acquirente ha lasciato la conversazione. Mantieni una domanda semplice nella conversazione quando l’operatore può rispondere e completarla immediatamente.
Controlla prima se esiste già un ticket cliente principale. Più ticket per lo stesso problema creano stato e responsabilità poco chiari.
Crea un contesto del ticket operativo
Usa l’azione ticket della conversazione e scegli il tipo pertinente o lo stato iniziale offerto dalla configurazione dell’azienda. Riassumi la richiesta, i fatti verificati, il lavoro già svolto, l’aspettativa del cliente e l’azione successiva.
Collega o sfrutta il contesto della conversazione invece di copiare dati personali non necessari nel testo libero. Usa note interne per il ragionamento tra colleghi che non appartiene a un campo del ticket.
Mantieni stato e responsabilità
Rivedi il ticket principale nei dettagli della conversazione. Aggiorna le proprietà man mano che l’indagine cambia e usa in modo coerente le categorie di stato dell’azienda. Humind associa gli stati configurati a categorie come risolto per il flusso di invio.
Un ticket lasciato aperto senza un responsabile o un’azione successiva non è un handoff affidabile. Usa menzioni o il processo di assegnazione del team quando deve intervenire un’altra persona.
Rispondi e chiudi in modo intenzionale
Quando esiste un ticket principale, il menu di invio della risposta può mostrare un’azione di invio e chiusura. Tale azione invia la risposta al cliente, sposta il ticket nello stato configurato della categoria risolto e restituisce la conversazione all’IA. Altre azioni del menu di invio possono aggiornare lo stato di un ticket.
Leggi l’etichetta del menu corrente e lo stato prima di fare clic. Chiudere il ticket e riconsegnare all’IA sono risultati collegati ma distinti che avvengono insieme in questo percorso.
Verifica il risultato per cliente e operatore
Conferma che l’acquirente abbia ricevuto il messaggio previsto, che il ticket mostri lo stato corretto, che la proprietà del thread sia corretta e che le note interne rimangano private. Riapri o aggiorna il ticket secondo la policy se arrivano nuove informazioni.
Per i provider esterni, verifica il record corrispondente nel provider durante il rollout iniziale. Non presumere che un interruttore delle credenziali garantisca una sincronizzazione end-to-end dei ticket.
Permessi e avvertenze importanti
- I tipi di ticket e i nomi degli stati fanno parte della configurazione aziendale, usa le etichette correnti mostrate nello spazio di lavoro.
- L’azione di invio e chiusura può cambiare sia lo stato del ticket sia quello della conversazione in un’unica azione.
- Il comportamento esterno di Gorgias o Zendesk deve essere configurato e testato separatamente.
- Un ticket è lavoro operativo interno e di per sé non notifica all’acquirente l’avanzamento.
Verifica il risultato
Usa questa checklist prima di considerare il lavoro completato:
- Il ticket rappresenta una reale necessità di follow-up e non duplica un ticket principale esistente.
- Riepilogo, tipo, stato, responsabile e azione successiva sono comprensibili a un altro collega.
- La risposta finale al cliente, lo stato del ticket e la responsabilità dell’IA o di una persona corrispondono al risultato previsto.
- I record del provider esterno vengono verificati quando quel provider fa parte del flusso di lavoro.
Risoluzione dei problemi
Le azioni del ticket non sono disponibili
Conferma che il ticketing sia abilitato, che l’azienda disponga di tipi di ticket e stati e che il tuo ruolo abbia l’accesso richiesto. Chiedi a un amministratore di rivedere la configurazione del provider e di Inbox.
L’azione di invio e chiusura ha usato lo stato sbagliato
Controlla quale stato configurato è associato alla categoria risolto. Correggi lo stato del ticket e chiedi a un amministratore di correggere la configurazione degli stati prima che gli operatori usino di nuovo l’azione combinata.
Un provider esterno non ha ricevuto il ticket
Controlla il provider selezionato, le credenziali amministratore, il contesto aziendale e il record del provider stesso. Considera l’integrazione come non verificata finché un test completo non riesce.