Ciclo di vita del ticket e comunicazione con i clienti nell'Helpdesk
Introduzione
In questo articolo, esamineremo il processo di emissione dei ticket in base al modo in cui viene creato un ticket nell'Help Desk e in base all'accesso del cliente al tuo sistema. Troverai suggerimenti su cosa cercare nelle varie configurazioni del processo di ticket.
Questo articolo contiene suggerimenti e suggerimenti per varie configurazioni, ma non direttamente su come vengono eseguite le configurazioni. Ecco gli articoli rilevanti:
- Documentazione dell'Help Desk
- Manuale del proprietario (flusso di lavoro, impostazioni di notifica)
Tre principali vie di comunicazione
A partire da uno schema del ciclo di vita del ticket in situazioni semplici, quando il ticket segue solo un tipo di flusso dall'inizio alla fine.
- Utente completo nell'applicazione
- Utente dell'help desk nell'applicazione
Creazione e ulteriore comunicazione all'interno di un ticket
La creazione del ticket e l'ulteriore comunicazione possono combinare gli approcci di cui sopra.
È possibile creare un ticket via email e poi dargli seguito nell'applicazione (sia da parte dell'utente completo che dell'utente dell'help desk). È anche possibile creare un ticket tramite il sistema e poi seguire solo le email.
esempio 1
- I ticket vengono creati tramite e-mail: il cliente invia una nuova e-mail all'indirizzo dell'helpdesk.
- Il cliente accede al sistema e lì può vedere il ticket, poiché è l'autore del ticket.
- I clienti possono modificare gli stati e altri campi nonché lasciare commenti, in base alle loro autorizzazioni.
esempio 2
- Il client accede al sistema e crea un nuovo ticket.
- Il cliente riceve gli aggiornamenti via e-mail e guarda solo questi aggiornamenti e non sente più la necessità di accedere al sistema.
esempio 3
- Il cliente crea un ticket tramite il portale dell'helpdesk
- Il cliente decide di voler seguire solo le e-mail e di non accedere più al portale
- Il cliente quindi decide che vuole seguire tramite il portale, effettua il log in e inserisce alcune risposte tramite il portale.
Per comodità dei tuoi Clienti, puoi decidere con quali metodi desideri consentire loro di creare e/o aggiornare i ticket. Ma soprattutto, devi coprire ogni possibile situazione, in modo che i biglietti non vadano persi in un vicolo cieco. Il flusso di lavoro e altre configurazioni forniscono tutte le opzioni necessarie.
Problemi comuni
Il client risponde alla normale notifica dell'attività, ma la risposta non viene elaborata correttamente.
Questa storia riguarda l'Esempio 2. I clienti pensano di rispondere a un ticket via e-mail, ma l'e-mail non viene abbinata al ticket esistente e ne viene invece creato uno nuovo, oppure l'e-mail non raggiunge affatto il sistema. Il cliente risponde a una notifica o per errore crea una nuova email.
La causa: le impostazioni di notifica e-mail non prevedono risposte all'indirizzo di notifica.
Soluzione: la risposta del cliente deve essere inviata all'indirizzo specificato dall'helpdesk e deve contenere il numero del ticket. L'indirizzo e-mail di notifica (Amministrazione >> Impostazioni >> Notifiche e-mail >> Indirizzo e-mail di notifica (FROM)) potrebbe essere uguale a un indirizzo e-mail dell'helpdesk per acquisire eventuali risposte dai clienti e associarle al ticket da cui è stata inizialmente inviata la notifica.
Un'altra opzione è semplicemente disabilitare le normali notifiche e-mail agli utenti client. Le uniche e-mail relative ai biglietti che riceverebbero verrebbero inviate attivamente dagli operatori tramite modelli di e-mail dell'help desk.
Punto chiave: i tuoi clienti saranno naturalmente tentati di rispondere a tutti i messaggi e-mail che ricevono. Assicurati che ricevano solo messaggi le cui risposte possono essere elaborate correttamente.
Il cliente ha cambiato il biglietto nello stato "errato".
Ciò si verifica soprattutto in situazioni in cui il client dispone di un utente completo nell'applicazione (invece che di un utente dell'Help desk). Il cliente potrebbe avere la possibilità di modificare molti campi, incluso lo stato, e potrebbe interpretare erroneamente il significato dei vari stati. O d'altra parte potrebbe non cambiare lo stato, quando ti aspetti che venga cambiato.
La causa: il client è responsabile dell'impostazione dello stato corretto.
Soluzione: questo è un chiaro anti-modello, il cliente non dovrebbe dover ricordare alcuna regola per gli stati delle attività.
Una soluzione è trasferire gli account dei clienti agli utenti dell'Help desk, anziché agli utenti completi. Gli utenti dell'help desk possono creare ticket e inserire commenti nei ticket esistenti, i cambiamenti di stato si basano sulle configurazioni dell'help desk, quindi non c'è alcuna possibilità che il cliente "interrompa" qualche processo corretto. Gli aggiornamenti dei ticket degli utenti dell'help desk sono praticamente progettati per seguire la logica e le impostazioni di comunicazione e-mail dell'help desk. L'unica differenza è che l'utente può effettivamente vedere e lavorare con la forma fisica del biglietto.
Se hai bisogno di mantenere tutti gli utenti per i tuoi clienti, il nostro suggerimento è di disabilitare completamente qualsiasi modifica di stato (o modifica di altri campi), che potrebbe interrompere alcuni dei tuoi processi interni. Utilizza altri modi per tenere traccia dei ticket che devono essere aggiornati, ad esempio per campo Ultimo aggiornamento dell'attività (data dell'ultimo aggiornamento), Ultimo aggiornamento da (chi ha effettuato l'ultimo aggiornamento), puoi mostrare l'ultimo commento su un ticket nell'elenco, in modo che sia chiaro che un cliente ha effettuato l'aggiornamento.
Uno scenario leggermente più complicato è quello dell'Esempio 1, quando si consente la comunicazione dei ticket tramite e-mail, ma si consente anche ai client di accedere come utente completo. Ecco a cosa prestare attenzione:
- La modifica dello stato dopo le risposte del cliente via e-mail è impostata nelle impostazioni globali dell'help desk
- Non è prevista alcuna modifica dello stato per gli utenti che hanno effettuato l'accesso: è sempre disponibile l'opzione di mantenere lo stato così com'è
In questo caso, dovresti assicurarti che le tue code di risposta contengano entrambi i tipi di situazione, aggiornata via email (ad esempio filtro per uno stato specifico), e ticket aggiornati dai client dall'interno dell'applicazione (ad esempio elenco dei ticket con colonna Ultimo commento).
Punti chiave: il cliente non dovrebbe mai preoccuparsi dei tuoi processi interni, ha solo bisogno di un posto dove presentare i suoi problemi e comunicare con te, i processi sono a carico tuo e l'applicazione ha varie opzioni per impostarli in modo serrato.
Combinazione di utenti completi e utenti dell'help desk
Questo è solo un forte avvertimento a non combinare soluzioni che non avrebbero mai dovuto essere combinate. Puoi decidere se utilizzare
- Utenti dell'help desk: gratuito, con accesso limitato codificato o
- Utenti completi: utenti con licenza regolare, a cui decidi a cosa hanno accesso
, ma non dovresti usarli entrambi contemporaneamente, soprattutto per gli stessi client. Tecnicamente gli utenti full user e quelli dell'Help desk non sono in alcun modo collegati. Hanno anche una pagina di accesso diversa. Rappresentano un campo diverso nelle attività (autore o autore dell'help desk). Quindi non c'è motivo di confondere il tuo cliente fornendogli entrambe le opzioni di accesso.
Per quanto riguarda i processi interni, è tecnicamente possibile fornire ad alcuni clienti utenti completi e ad altri solo utenti dell'help desk. Tuttavia, ciò richiede descrizioni precise del processo e formazione per i tuoi agenti per garantire che non confondano l'elaborazione dei ticket provenienti da questi canali molto diversi. A causa della sua difficoltà organizzativa, consigliamo vivamente di scegliere una sola opzione per l'accesso del cliente.
Sommario
Riportiamo le informazioni precedenti in una forma digeribile. Di seguito è riportata una tabella delle situazioni che possono verificarsi in base al tipo di accesso dei client al sistema.
| Accesso del client all'applicazione | Opzioni per inviare ticket (cliente) |
Notifiche dal ticket (agente) |
Opzioni per aggiornare il ticket (cliente) |
Le nostre raccomandazioni |
| Senza accesso | Invia un'e-mail a un indirizzo e-mail dell'helpdesk. | L'agente invia un'e-mail tramite il modello dal ticket. |
|
|
| Utente completo |
|
|
|
|
| Utente dell'help desk |
|
L'agente invia un'e-mail tramite il modello dal ticket. |
|
|
