Ticketing Escalation

Il processo di esclation si innesca quando i risolutori al livello a cui è assegnato il ticket, normalmente il primo, non sono in grado di risolvere il ticket. Il processo di escalation è il meccanismo grazie al quale il ticket passa ad un livello di competenza superiore (ad esempio livello 2, 3 o 4). Questo meccanismo può essere avviato dall'agente risolutore responsabile del ticket oppure d'ufficio dagli utenti responsabili dei risolutori o dai profili amministratori.

Per ogni servizio di assistenza e supporto è possibile configurare in autonomia il routing dedicato per il primo livello ed il relativo processo di escalation per il livello successivo. In questo modo sarà assicurata la massima flessbilità ed efficienza. Significa quindi ottenere un grande risparmio di costi e di tempo evitando di cercare di gestire manualmente il processo di escalation dei ticket.

T-HelpDesk è un sistema di ticketing multi-canale e multi-dipartimentale. Ciò significa che è possible creare dei servizi dedicati ai propri Clienti e dei servizi dedicati ad utenti interni e collaboratori. I servizi sono inoltre definibili per dipartimento, ognuno con le proprie caratteristiche e logiche di gestione. In questo modo il sistema di ticketing di TeraNet può essere adottato tanto dai Sistemi Informativi, quanto dai Servizi Tecnici, come pure dal Customer Care. Ma anche da servizi di Amministrazione, Produzione e Qualità, etc.

All'aumentare dei team degli agenti risolutori, con diverse competenze specifiche, è fondamentale automatizzatare il routing ed instradamento e soprattutto l'escalation garantendo una gestione efficace e flessibile.

T-HelpDesk permette di definire dei comportamenti diversi per ogni servizio di supporto o assistenza richiesto dagli utenti. Durante la fase di creazione dei ticket la scelta del servizio richiesto influirà sulle SLA di riferimento, sul livello assegnato ai ticket, sull' eventuale instradamento e quindi assegnazione automatica dei ticket ai risolutori di pertinenza.

Il routing e instradamento sono quindi le fasi del processo, da parte del sistema T-HelpDesk, per determinare il livello da assegnare al ticket e quale risolutore di pertinenza coinvolgere per l'avvio della risoluzione del ticket stesso. In T-HelpDesk il livello di assegnazione, in fase di creazione del ticket, può essere il livello 1 o il livello 2. Il livello 3 o successivi sono disponibili solo in fase di escalation. Il risolutore scelto o il gruppo di risolutori coinvolti dipende dall'algoritmo assegnato.

Nel sistema di ticketing T-HelpDesk è presente un pannello di amministrazione dove ogni servizio può essere configurato in autonomia. Da questo pannello per ogni servizio si vanno a definire varie logiche, tra cui il routing ed instradamento. Per il livello 1 è possibile definire una delle seguenti modalità di routing ed instradamento alla nascita del ticket:

• assegnare i ticket in modo automatico al risolutore di 1° livello più scarico tra tutti i risolutori di 1° livello di sistema
• assegnare i ticket in modo automatico al risolutore di 1° livello più scarico tra gli utenti di un gruppo predefinito di risolutori
• assegnare i ticket in modalità circolare tra tutti i risolutori di 1° livello ruotando tra tutti i risolutori di 1° livello di sistema
• assegnare i ticket in modalità circolare tra tutti i risolutori di 1° livello ruotando tra tutti i risolutori del gruppo di utenti specificato per quel servizio
• assegnare d'ufficio uno specifico utente risolutore (indicato dall'amministratore)
• suggerire ad uno specifico gruppo di risolutori di 1° livello i ticket (in questo caso i ticket non verranno assegnati, ma il primo risolutore libero tra quelli del gruppo prenderà in carico in autonomia il ticket)
• suggerire a tutti i risolutori di 1° livello a sistema i ticket (in questo caso i ticket non verranno assegnati, ma il primo risolutore libero tra tutti i risolutori di 1° livello di sistema prenderà in carico in autonomia il ticket)
• suggerire ad utenti, esplicitamente indicati dall'amministratore, il ticket (in questo caso i ticket non verranno assegnati, ma il primo risolutore libero tra quelli indicati prenderà in carico in autonomia il ticket)
• saltare il primo livello e assegnare il ticket al livello 2 (seguendo le regole di routing/intradamento del 2° livello)
• non assegnare a nessuno i ticket (i ticket verranno necessariamente gestiti manualmente dal manager degli agenti risolutori)

Quando il risolutore a cui è stato assegnato il ticket non è in grado di risolvere in autonomia il ticket ha tre strade percorribili.

• Coinvolgere altri agenti risolutori suddividendo il ticket in più task. In questo caso il ticket rimane allo stesso livello e può essere risolto in modalità collaborativa e la responsabilità rimane al primo risolutore assegnatario.
• Rimettersi dall'incarico scegliendo di riavviare la procedura di routing/inoltro applicata in fase di creazione del ticket. In questo caso l'utente sarà scartato dalla procedura; questa opzione è disponibile solo per alcuni algoritmi.
• Avviare la procedura di escalation ad un livello superiore. Questo se il servizio associato al ticket permette l'esclation a livello successivo.

Di fatto l'esclation dal 1° al 2° livello non è sempre percorribile in quanto dipende dalla configurazione del singolo servizio. Questo per dare massima flessibilità al sistema e permettere di decidere ad ogni azienda, servizio per servizio, qual'è la modalità più corretta.

In ogni caso i responsabili degli agenti risolutori, possono forzare d'ufficio l'escalation ad un livello successivo, a prescindere dalla configurazione del servizio stesso, scegliendo puntualmente il risolutore più corretto o suggerendo ad uno o più risolutori il ticket.

Per ogni servizio può essere abilitata e scelta la modalità di routing e instradamento più corretta, in fase di escalation, per il livello 2:

• 2° livello disabilitato
• 2° livello disabilitato e abilitato il 3° (via t-kanban)
• assegnare i ticket in modo automatico al risolutore di 2° livello più scarico tra tutti i risolutori di 2° livello di sistema
• assegnare i ticket in modo automatico al risolutore di 2° livello più scarico tra gli utenti di un gruppo predefinito di risolutori
• assegnare i ticket in modalità circolare tra tutti i risolutori di 2° livello ruotando tra tutti i risolutori di 2° livello di sistema
• assegnare i ticket in modalità circolare tra tutti i risolutori di 2° livello ruotando tra tutti i risolutori del gruppo di utenti specificato per quel servizio
• assegnare d'ufficio uno specifico utente risolutore (indicato dall'amministratore)
• suggerire ad uno specifico gruppo di risolutori di 2° livello i ticket (in questo caso i ticket non verranno assegnati, ma il primo risolutore libero tra quelli del gruppo prenderà in carico in autonomia il ticket)
• suggerire a tutti i risolutori di 2° livello a sistema i ticket (in questo caso i ticket non verranno assegnati, ma il primo risolutore libero tra tutti i risolutori di 2° livello di sistema prenderà in carico in autonomia il ticket)
• suggerire ad utenti, esplicitamente indicati dall'amministratore, il ticket (in questo caso i ticket non verranno assegnati, ma il primo risolutore libero tra quelli indicati prenderà in carico in autonomia il ticket)
• non assegnare a nessuno i ticket (i ticket verranno necessariamente gestiti manualmente dal manager degli agenti risolutori)

Come per il livello 1, quando un risolutore di 2° livello non è in grado di portare a termine la risoluzione di un ticket può decidere di rimettersi dall'incarico e avviare o meno l'escalation. Sulla base della configurazione del servizio decisa dal'azienda e dalla configurazione di T-HelpDesk, il risolutore di 2° livello potrebbe avere diverse strade percorribili.

• Coinvolgere altri agenti risolutori suddividendo il ticket in più task. In questo caso il ticket rimane allo stesso livello e può essere risolto in modalità collaborativa e la responsabilità rimane al primo risolutore assegnatario.
• Rimettersi dall'incarico scegliendo di riavviare la procedura di routing/inoltro applicata in fase di creazione del ticket. In questo caso l'utente sarà scartato dalla procedura; questa opzione è disponibile solo per alcuni algoritmi.
• Rimettersi dall'incarico forzando il responsabile dei risolutori l'assegnazione manuale del ticket.
• Rimandare il ticket al livello precedente (de-escalation).
• Mettere in sospesione il ticket e avviare la procedura di escalation ad un livello superiore (3° livello) attivando l'opportuno kanban (solo se il modulo applicativo t-kanban è abilitato). In questo caso il ticket potrà essere risolto solo al termine dei task associati al kanban.
• Avviare la procedura di escalation ad un livello superiore (3° livello) attivando l'opportuno kanban e chiudere il ticket (solo se il modulo applicativo t-kanban è abilitato). In questo caso il ticket verrà marcato eseguito e l'esecuzione dei task legati al kanban seguiranno la loro strada.

Di fatto l'esclation dal 2° al 3° livello non è sempre percorribile in quanto dipende dalla configurazione del singolo servizio e del software di T-HelpDesk.

In ogni caso i responsabili degli agenti risolutori, possono forzare d'ufficio l'escalation al terzo livello (se abiltiato T-Kanban) oppure, a prescindere dalla configurazione del servizio stesso, riassegnare puntualmente il risolutore più corretto o suggerendo ad uno o più risolutori il ticket allo stesso livello.

T-HelpDesk Ticketing permette di proprorre in modo strutturato ed efficace i servizi di supporto e assistenza ai propri dipendenti, clienti o collaboratori con la capacità di coinvolgeere in maniera flessibile più dipartimenti. L'utente è guidato dal Catalogo Servizi che permette di individuare facilmente le aree di supporto. La Knowledge Base integrata permette di aiutare gli utenti in modalità self-service in modo da ridurre il numero di ticket.

La scelta di far indicare il servizio in fase di apertura del ticket da parte degli utenti, nasce per masssimizzare le performance del sistema e perseguire la conseguente soddisfazione finale degli utenti dei servizi nonchè del corretto routing ed instradamento e corretta gestione dell'escalation. T-HelpDesk, nella confirugrazione base, propone la creazione del ticket in modalità self-service, ossia via accesso al portale web, da parte degli utenti in modo che le potenziali risposte possano arrivare già dal sistema di knowledge base (livello 0) che mostrerà in tempo reale le potenziali risposte pertinenti alla richiesta.

Le aperture via mail non permettono infatti in nessun modo la corretta gestione del livello 0 e il corretto inquadramento del servizio richiesto, se non tramite sofisitcati algoritmi che possono variare da azienda ad azienda. Avendo ben chiaro i pro ed i contro, le aperture dei ticket via mail e i relativi algoritmi di inoltro al corretto servizio sono comunque abilitabili in T-HelpDesk via API standard.

Senza un opportuno sistema di inoltro delle mail al corretto servizio, tarato, studiato e manutenuto nel tempo, il rischio che i ticket siano assegnati alla categoria di risolutori errati è molto alto. In questi casi il cambio risolutore allo stesso livello è una sorta di escalation orizzontale che per aziende piccole può essere accettabile, ma per aziende strutturate e di una certa dimensione significa un enorme dispendio di energie e quindi di maggiori costi di gestione.