Il template dei dati per il servizio clienti
Il template dei dati per il servizio clienti
- Attributi consigliati da raccogliere
- Attività principali da monitorare
- Istruzioni per l’estrazione
Attributi del servizio clienti
| Nome | Descrizione | ||
|---|---|---|---|
|
Attività
Activity
|
Nome di uno specifico evento o passaggio aziendale che si è verificato nel processo di servizio clienti. | ||
|
Descrizione
L’attributo Attività rappresenta un’azione distinta o una modifica di stato nel ciclo di vita di una richiesta di assistenza. Registra eventi aziendali chiave come «Ticket creato», «Ticket assegnato», «Prima risposta inviata» e «Ticket risolto». Queste attività costituiscono i nodi della mappa di processo. Analizzare la sequenza e la frequenza di queste attività è il fulcro del Process Mining. Consente di visualizzare i flussi di processo, individuare i percorsi comuni e quelli rari e rilevare le deviazioni dalla procedura operativa standard. Comprendere le attività è fondamentale per individuare le inefficienze, i cicli di lavoro ripetuto come «Ticket riaperto» e i problemi di conformità.
Perché è importante
Definisce i passaggi della mappa di processo e consente di visualizzare e analizzare il flusso del processo dall’inizio alla fine.
Dove reperirli
Ricavato dai tipi di evento in Freshdesk. Può combinare le modifiche di stato provenienti dall’endpoint API «Tickets» con eventi specifici, come note o risposte, provenienti dall’endpoint «Conversations».
Esempi
Ticket creatoPrima risposta inviataStato modificato in «Pending»Ticket risoltoTicket chiuso
|
|||
|
Ora dell’evento
EventTime
|
Timestamp che indica quando si è verificata una specifica attività o un evento. | ||
|
Descrizione
L’ora dell’evento, o timestamp, registra la data e l’ora esatte in cui si è svolta un’attività. È fondamentale per ordinare cronologicamente gli eventi e calcolare la durata tra i diversi passaggi del processo. Ogni attività registrata deve avere il relativo timestamp. Nell’analisi, questo attributo serve a ricostruire la cronologia di ogni richiesta di assistenza. È la base per calcolare tutti gli indicatori legati al tempo, come il tempo di risoluzione, il tempo della prima risposta e la durata dei colli di bottiglia. Timestamp accurati sono essenziali per comprendere le prestazioni del processo e individuare i ritardi.
Perché è importante
Questo timestamp è essenziale per ordinare cronologicamente gli eventi e calcolare tutte le metriche basate sulla durata, come i tempi di ciclo e il rispetto degli SLA.
Dove reperirli
Corrisponde ai campi «created_at» o «updated_at» associati agli eventi del ticket, alle risposte o alle modifiche di stato nell’API di Freshdesk.
Esempi
2023-10-25T10:00:00Z2023-10-25T10:05:14Z2023-10-26T14:30:00Z
|
|||
|
Richiesta di assistenza
ServiceRequest
|
Identificativo univoco di una singola richiesta o segnalazione del cliente, comunemente chiamata ticket o caso. | ||
|
Descrizione
La richiesta di assistenza è l’identificativo principale del caso e collega tutte le attività relative a una singola interazione con il cliente. Ogni nuova richiesta, segnalazione di un problema o domanda del cliente genera un ID univoco. Questo ID rimane invariato per tutto il ciclo di vita del ticket, dalla creazione e assegnazione fino alla risoluzione e alla chiusura. Nel Process Mining, questo attributo è fondamentale per ricostruire il percorso completo di ogni caso di assistenza. Raggruppando tutti gli eventi correlati sotto un unico ID della richiesta, gli analisti possono visualizzare i flussi di processo, misurare i tempi di ciclo e individuare le variazioni o i colli di bottiglia che interessano i singoli casi.
Perché è importante
È l’ID caso essenziale che collega tutti gli eventi correlati in un’unica istanza del processo, offrendo una visione completa del percorso di ogni richiesta di assistenza.
Dove reperirli
È l’ID principale del ticket in Freshdesk, in genere disponibile nel campo «id» dell’endpoint API «Tickets».
Esempi
SR-2023-10-4831SR-2023-11-0192SR-2023-11-5210
|
|||
|
Operatore assegnato
AssignedAgent
|
Nome o ID dell’operatore del servizio clienti responsabile del ticket al momento dell’evento. | ||
|
Descrizione
Questo attributo identifica l’operatore specifico a cui è assegnata la gestione della richiesta di assistenza. L’operatore assegnato può cambiare durante il ciclo di vita del ticket a seguito di riassegnazioni o escalation. Analizzare i dati per operatore assegnato è fondamentale per le Dashboard di gestione delle prestazioni. Consente di misurare indicatori specifici per operatore, come il tempo medio di risoluzione, il volume dei ticket e la frequenza di riapertura. Aiuta a individuare gli operatori con i risultati migliori, le esigenze di formazione e l’impatto dei trasferimenti sui tempi complessivi di risoluzione.
Perché è importante
Consente di analizzare le prestazioni dei singoli operatori, individuare quelli con i risultati migliori e le opportunità di formazione, nonché valutare l’impatto delle riassegnazioni.
Dove reperirli
Corrisponde al campo «responder_id» dell’oggetto «Tickets» di Freshdesk, che può essere collegato ai dettagli degli operatori.
Esempi
Alice JohnsonRobert SmithMaria Garcia
|
|||
|
Priorità
Priority
|
Il livello di priorità assegnato alla richiesta di assistenza, ad esempio 'Bassa', 'Media', 'Alta' o 'Urgente'. | ||
|
Descrizione
L’attributo Priorità indica l’urgenza di una richiesta di assistenza e spesso determina i tempi previsti per la risposta e la risoluzione. La priorità può essere impostata automaticamente in base a regole oppure manualmente da un operatore durante la classificazione iniziale. Questo attributo è essenziale per analizzare il rispetto degli SLA e l’allocazione delle risorse. Filtrando la mappa del processo in base alla priorità, gli analisti possono verificare se i ticket ad alta priorità vengono effettivamente gestiti più rapidamente di quelli a bassa priorità. È inoltre possibile capire se i cambiamenti di priorità, che costituiscono una forma di rilavorazione, sono frequenti e quale impatto hanno sul processo.
Perché è importante
Essenziale per analizzare gli SLA e verificare se le risorse sono assegnate correttamente, così da gestire i problemi ad alta priorità più rapidamente di quelli a bassa priorità.
Dove reperirli
Corrisponde al campo 'priority' dell’oggetto 'Tickets' di Freshdesk.
Esempi
BassaMediaAltaUrgente
|
|||
|
Stato
Status
|
Lo stato attuale o storico della richiesta di assistenza, ad esempio 'Aperta', 'In attesa', 'Risolta' o 'Chiusa'. | ||
|
Descrizione
L’attributo Stato indica lo stato di una richiesta di assistenza in un determinato momento. I cambiamenti di stato rappresentano spesso tappe importanti del processo, ad esempio il passaggio da 'Aperta' a 'In attesa' quando si attende una risposta del cliente, oppure da 'In attesa' ad 'Aperta' quando il cliente risponde. Monitorare i cambiamenti di stato è fondamentale per comprendere il ciclo di vita dei ticket. Consente di individuare quanto tempo i ticket trascorrono in determinati stati, un dato utile per identificare i colli di bottiglia. Ad esempio, una lunga permanenza nello stato 'In attesa' potrebbe indicare ritardi nella ricezione di informazioni dai clienti.
Perché è importante
Monitorare i cambiamenti di stato è essenziale per comprendere il ciclo di vita dei ticket e individuare quanto tempo le richieste rimangono in stati specifici, come 'In attesa' o 'In sospeso'.
Dove reperirli
Corrisponde al campo 'status' dell’oggetto 'Tickets' di Freshdesk. Gli stati storici devono essere ricavati dai registri delle attività.
Esempi
ApertaIn attesaRisoltaChiusa
|
|||
|
Tipo di richiesta di assistenza
ServiceRequestType
|
Classificazione della richiesta di assistenza, ad esempio «Domanda», «Incidente», «Problema» o «Richiesta di funzionalità». | ||
|
Descrizione
Il tipo di richiesta di assistenza è un campo di classificazione fondamentale, che definisce la natura della richiesta del cliente. In genere viene impostato quando si crea il ticket o durante una prima fase di valutazione e aiuta a indirizzare la richiesta al team o all’operatore più adatto. Nell’analisi, questo attributo consente di segmentare il processo per capire come vengono gestiti i diversi tipi di richiesta. Aiuta a rispondere a domande come «Gli incidenti richiedono più tempo per essere risolti rispetto alle domande?» e «Quali tipi di richiesta vengono riaperti più spesso?». Questa segmentazione è essenziale per individuare i colli di bottiglia specifici per ciascun tipo e ottimizzare di conseguenza i flussi di lavoro.
Perché è importante
Consente di segmentare il processo per confrontare le prestazioni e i flussi di lavoro relativi a diversi tipi di problemi dei clienti, come gli incidenti e le domande.
Dove reperirli
Probabilmente corrisponde al campo «type» disponibile nell’oggetto «Tickets» di Freshdesk.
Esempi
DomandaIncidenteProblemaRichiesta di funzionalità
|
|||
|
Canale di comunicazione
CommunicationChannel
|
Il canale attraverso cui è stata inviata la richiesta di assistenza, ad esempio 'E-mail', 'Telefono', 'Chat' o 'Portale web'. | ||
|
Descrizione
Questo attributo identifica l’origine o il canale della comunicazione con il cliente. I diversi canali possono avere flussi di processo e tempi di risoluzione distinti. Ad esempio, una richiesta inviata tramite chat potrebbe avere un tempo di risoluzione previsto inferiore rispetto a una richiesta inviata per e-mail. Analizzare il processo in base al canale di comunicazione aiuta a ottimizzare l’allocazione delle risorse e a comprendere l’efficienza dei singoli canali. L’analisi può rivelare quali canali sono associati a risoluzioni più rapide o a una maggiore soddisfazione dei clienti, fornendo elementi utili per decidere su quali canali puntare o investire.
Perché è importante
Consente di analizzare le prestazioni e l’efficienza del processo nei diversi canali di contatto con i clienti, come e-mail, telefono o chat.
Dove reperirli
Corrisponde al campo 'source' dell’oggetto 'Tickets' di Freshdesk.
Esempi
E-mailTelefonoPortale webChat
|
|||
|
Gruppo assegnato
AssignedGroup
|
Il team o il reparto a cui è assegnata la richiesta di assistenza. | ||
|
Descrizione
Il gruppo assegnato identifica il team di operatori responsabile della gestione di una specifica richiesta di assistenza. Spesso i ticket vengono indirizzati a gruppi specializzati in base alla tipologia o alla complessità, ad esempio 'Supporto tecnico' o 'Ufficio fatturazione'. Questo attributo è utile per analizzare i passaggi tra reparti e le prestazioni dei singoli team. Consente di individuare quali gruppi gestiscono più ticket, quali registrano i tempi di risoluzione più lunghi e con quale frequenza i ticket vengono trasferiti da un gruppo all’altro. Queste informazioni sono fondamentali per ottimizzare la struttura dei team e i flussi di lavoro.
Perché è importante
Consente di analizzare le prestazioni a livello di team o reparto, mettendo in evidenza i passaggi di consegne e i colli di bottiglia specifici dei gruppi.
Dove reperirli
Corrisponde al campo 'group_id' dell’oggetto 'Tickets' di Freshdesk.
Esempi
Supporto di primo livelloSupporto tecnico di secondo livelloFatturazioneCustomer Success
|
|||
|
Nome cliente
CustomerName
|
Il nome o l’ID del cliente che ha inviato la richiesta di assistenza. | ||
|
Descrizione
Questo attributo identifica il cliente associato alla richiesta di assistenza. Permette di analizzare il processo dal punto di vista del cliente e di monitorare nel tempo tutte le interazioni che lo riguardano. L’analisi per cliente può rivelare, ad esempio, quali clienti inviano più ticket o quali riscontrano più spesso problemi che vengono riaperti. Queste informazioni possono orientare le iniziative di Customer Success e aiutare a individuare i clienti a rischio di abbandono a causa di esperienze di assistenza insoddisfacenti. Sono inoltre fondamentali per comprendere il percorso completo del cliente attraverso più richieste di assistenza.
Perché è importante
Offre una visione del processo incentrata sul cliente e aiuta a individuare chi invia spesso richieste o riscontra problemi ricorrenti.
Dove reperirli
Questa informazione è collegata tramite 'requester_id' nell’oggetto 'Tickets', che rimanda all’oggetto 'Contacts' o 'Users' di Freshdesk.
Esempi
Mario RossiMaria BianchiGlobal Tech Inc.
|
|||
|
Numero di trasferimenti tra operatori
AgentTransferCount
|
Il numero totale di volte in cui una richiesta di assistenza è stata riassegnata da un operatore a un altro. | ||
|
Descrizione
Questa metrica a livello di caso conta quante volte è cambiato l’operatore assegnato a un ticket. Si calcola contando le occorrenze dell’attività 'Ticket Reassigned' per ogni richiesta di assistenza. I trasferimenti frequenti, talvolta definiti 'ping-pong', possono causare ritardi significativi e un’esperienza frustrante per il cliente, poiché a ogni passaggio si rischia di perdere il contesto. Analizzare il numero di trasferimenti aiuta a individuare problemi nell’instradamento iniziale, lacune nelle competenze degli operatori o complessità del processo. Spesso l’obiettivo è ridurre i trasferimenti non necessari per migliorare l’efficienza e la soddisfazione dei clienti.
Perché è importante
Misura la frequenza dei passaggi interni, che possono causare ritardi e insoddisfazione dei clienti, e aiuta a migliorare la risoluzione al primo livello.
Dove reperirli
Campo calcolato. Corrisponde al numero di attività 'Ticket Reassigned' per ogni richiesta di assistenza.
Esempi
0132
|
|||
|
Prodotto
Product
|
Il prodotto o servizio a cui si riferisce la richiesta del cliente. | ||
|
Descrizione
Questo attributo specifica la linea di prodotti o servizi a cui si riferisce la richiesta di assistenza. Spesso si tratta di un campo personalizzato configurato in Freshdesk per classificare i ticket ai fini dell’instradamento e della reportistica. Filtrando il processo per prodotto, le organizzazioni possono individuare problemi specifici di un prodotto. Ad esempio, l’analisi può mostrare se un determinato prodotto genera un numero sproporzionato di richieste di assistenza o se il lancio di un nuovo prodotto provoca un aumento delle richieste di informazioni. Questi dati forniscono indicazioni utili ai team di sviluppo e gestione dei prodotti.
Perché è importante
Consente di filtrare il processo per area di prodotto e di capire quali prodotti generano più richieste di assistenza o presentano tempi di risoluzione più lunghi.
Dove reperirli
In genere si tratta di un campo personalizzato. La posizione esatta dipende dalla configurazione di Freshdesk; è probabile che si trovi nella sezione 'custom_fields' della risposta dell’API 'Tickets'.
Esempi
Piattaforma AlphaApp mobile BetaAbbonamento Gamma
|
|||
|
Riaperta
IsReopened
|
Indicatore booleano che segnala se una richiesta di assistenza risolta è stata riaperta. | ||
|
Descrizione
Questo attributo a livello di caso viene impostato su true se, in qualsiasi momento del ciclo di vita della richiesta di assistenza, si verifica l’attività 'Ticket Reopened'. Permette di individuare e analizzare facilmente i casi che hanno richiesto una rilavorazione. Un’elevata percentuale di ticket riaperti suggerisce che la risoluzione iniziale non è stata efficace o completa, con conseguenti inefficienze e insoddisfazione dei clienti. Filtrando i ticket riaperti, gli analisti possono indagare sulle cause profonde, ad esempio i motivi più frequenti della riapertura, gli operatori o i team con percentuali più alte e le tipologie di ticket più soggette a riapertura.
Perché è importante
Individua i casi che hanno richiesto una rilavorazione, un indicatore chiave della qualità della risoluzione e dell’inefficienza del processo. Analizzarli aiuta a migliorare la risoluzione al primo contatto.
Dove reperirli
Campo calcolato. Impostato su true per una richiesta di assistenza se per il caso esiste un evento con Activity = 'Ticket Reopened'.
Esempi
truefalse
|
|||
|
Sistema di origine
SourceSystem
|
Il sistema da cui sono stati estratti i dati, in questo caso Freshdesk. | ||
|
Descrizione
Questo attributo identifica l’applicazione di origine dei dati di processo. In questa analisi, il valore è statico, ad esempio «Freshdesk», a indicare che tutti gli eventi provengono dalla piattaforma di servizio clienti Freshdesk. Anche se può sembrare un dato semplice, questo attributo è importante per la governance dei dati e negli scenari in cui si combinano dati provenienti da più sistemi. Fornisce informazioni chiare sulla provenienza e sul contesto, così che gli analisti sappiano da dove provengono i dati che stanno esaminando. È fondamentale per preservare l’integrità dei dati e garantire l’affidabilità dell’analisi.
Perché è importante
Fornisce informazioni essenziali sulla provenienza dei dati, fondamentali per la governance dei dati e per combinare dati provenienti da più sistemi di origine.
Dove reperirli
È un valore statico, «Freshdesk», aggiunto durante la trasformazione dei dati per identificarne l’origine.
Esempi
Freshdesk
|
|||
|
SLA non rispettato
IsSlaBreached
|
Indicatore booleano che segnala se il tempo di risoluzione della richiesta di assistenza ha superato l’obiettivo SLA. | ||
|
Descrizione
Questo attributo calcolato indica in modo chiaro e binario se ogni richiesta di assistenza rispetta l’SLA. Si ottiene confrontando il valore effettivo di 'ResolutionTime' con 'SlaTargetResolutionTime'. Se il tempo effettivo supera quello previsto, l’indicatore è impostato su true. Questo attributo semplifica l’analisi e la visualizzazione dei dati relativi al rispetto degli SLA. Permette di contare e filtrare facilmente i ticket per cui l’SLA non è stato rispettato, così gli analisti possono valutarne rapidamente la portata e scendere di livello per individuare le cause profonde negli andamenti del processo. Supporta direttamente la Dashboard e il KPI SLA Compliance Overview.
Perché è importante
Semplifica l’analisi del rispetto degli SLA indicando chiaramente, per ogni caso, se l’obiettivo non è stato raggiunto e consentendo di analizzare le cause profonde delle violazioni.
Dove reperirli
Campo calcolato, ottenuto confrontando la data e l’ora effettive di risoluzione con 'SlaTargetResolutionTime' o con il campo 'due_by' di Freshdesk.
Esempi
truefalse
|
|||
|
Tempo di prima risposta
FirstResponseTime
|
Il tempo trascorso dalla creazione del ticket alla prima risposta dell’operatore al cliente. | ||
|
Descrizione
Il tempo di prima risposta misura la rapidità con cui il cliente riceve una prima risposta non automatica da un operatore dell’assistenza. Si calcola come differenza tra la data e l’ora dell’attività 'First Response Sent' e quelle dell’attività 'Ticket Created'. Questo KPI è un indicatore chiave della tempestività del servizio e incide in modo significativo sulla soddisfazione dei clienti. Una prima risposta rapida rassicura il cliente, confermandogli che il problema è stato preso in carico e che si sta intervenendo. Analizzare questa metrica aiuta le organizzazioni a verificare il rispetto degli SLA di prima risposta e a offrire un’esperienza di assistenza tempestiva.
Perché è importante
Misura la tempestività del servizio, un fattore determinante per la soddisfazione dei clienti e un elemento centrale per offrire un’assistenza proattiva.
Dove reperirli
Campo calcolato. Indica il tempo trascorso tra la data e l’ora dell’evento 'Ticket Created' e quelle dell’evento 'First Response Sent'.
Esempi
3000009000001800000
|
|||
|
Tempo obiettivo di risoluzione SLA
SlaTargetResolutionTime
|
Il tempo concordato contrattualmente o previsto per risolvere la richiesta di assistenza. | ||
|
Descrizione
Questo attributo definisce il tempo entro cui una richiesta di assistenza dovrebbe essere risolta in base all’accordo sul livello del servizio (SLA). Il valore previsto dipende spesso dalla priorità o dalla tipologia del ticket. È un dato fondamentale per calcolare il rispetto degli SLA. Confrontando il tempo effettivo di risoluzione con quello previsto, è possibile stabilire se l’obiettivo è stato 'Raggiunto' o 'Non rispettato'. Analizzare le prestazioni SLA per tipologia di richiesta, team o operatore è una parte essenziale della gestione dei servizi.
Perché è importante
Fornisce il valore di riferimento per misurare il rispetto degli SLA, un indicatore chiave per qualsiasi organizzazione che offre assistenza ai clienti.
Dove reperirli
Potrebbe essere disponibile in Freshdesk nell’oggetto 'Tickets' come campo 'fr_due_by' (prima risposta) o 'due_by' (risoluzione); in alternativa, potrebbe essere necessario ricavarlo dalle regole delle politiche SLA.
Esempi
2023-10-25T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
|
|||
|
Ultimo aggiornamento dei dati
LastDataUpdate
|
Timestamp che indica l’ultima volta in cui i dati sono stati aggiornati dal sistema di origine. | ||
|
Descrizione
Questo attributo registra la data e l’ora dell’ultima estrazione o dell’ultimo aggiornamento dei dati da Freshdesk. Indica quanto sono aggiornati i dati analizzati, un’informazione fondamentale per prendere decisioni aziendali tempestive e pertinenti. Gli analisti utilizzano questo dato per capire quale intervallo temporale copre il dataset e verificare di lavorare con le informazioni più aggiornate disponibili. È un metadato essenziale per ogni Dashboard o report di Process Mining, perché permette alle parti interessate di sapere quanto sono recenti i dati.
Perché è importante
Indica quanto sono aggiornati i dati, così che analisi e decisioni si basino su informazioni recenti.
Dove reperirli
È un campo di metadati generato durante l’estrazione dei dati, che registra il timestamp dell’estrazione.
Esempi
2023-12-01T08:00:00Z
|
|||
|
Valutazione della soddisfazione
SatisfactionRating
|
Il punteggio di soddisfazione fornito dal cliente dopo la risoluzione del ticket. | ||
|
Descrizione
La valutazione della soddisfazione è un indicatore chiave dei risultati e viene in genere raccolta tramite un sondaggio inviato dopo la risoluzione di un ticket. Di solito consiste in un punteggio numerico o in una valutazione categoriale, come 'Soddisfatto', 'Neutrale' o 'Insoddisfatto'. Questo attributo permette di mettere in relazione gli andamenti del processo con i risultati per i clienti. Analizzando le varianti del processo associate a punteggi di soddisfazione bassi, le organizzazioni possono individuare comportamenti o ritardi specifici che incidono negativamente sull’esperienza del cliente. In questo modo emerge il legame diretto tra efficienza del processo e soddisfazione dei clienti.
Perché è importante
Collega l’esecuzione del processo ai risultati per i clienti e aiuta a individuare i comportamenti che portano a livelli di soddisfazione alti o bassi.
Dove reperirli
Questi dati fanno parte della funzionalità di valutazione della soddisfazione di Freshdesk e possono essere recuperati tramite l’endpoint API 'Surveys' o 'Satisfaction Ratings'.
Esempi
5314
|
|||
Attività del servizio clienti
| Attività | Descrizione | ||
|---|---|---|---|
|
Prima risposta inviata
|
Indica la prima risposta pubblica inviata da un operatore al cliente dopo la creazione del ticket. Freshdesk registra esplicitamente questo evento per misurare il «First Response Time» ai fini del monitoraggio degli SLA. | ||
|
Perché è importante
È una tappa fondamentale per misurare la tempestività delle risposte ai clienti e il rispetto degli SLA. Analizzare il tempo che intercorre prima di questa attività aiuta a individuare i ritardi nel primo contatto con i clienti.
Dove reperirli
È un evento specifico che Freshdesk monitora ai fini degli SLA. Corrisponde al timestamp del primo commento pubblico aggiunto da un operatore.
Acquisizione
Individuato nella prima risposta pubblica dell’operatore nella cronologia della conversazione del ticket.
Tipo di evento
explicit
|
|||
|
Ticket assegnato
|
Indica l’assegnazione di un ticket a un operatore o a un gruppo specifico. L’evento viene registrato esplicitamente nella cronologia del ticket ogni volta che il campo dell’operatore o del gruppo assegnato viene compilato o modificato. | ||
|
Perché è importante
Monitorare le assegnazioni è fondamentale per analizzare il carico di lavoro degli operatori, individuare inefficienze nell’instradamento e misurare gli indicatori relativi ai tempi di assegnazione. Aiuta a capire come viene distribuito il lavoro e dove si verificano ritardi prima che inizi la gestione del ticket.
Dove reperirli
Rilevato nel registro «Ticket Activities», che riporta con un timestamp le modifiche ai campi «Agent» o «Group».
Acquisizione
Evento registrato quando viene aggiornato il campo «Assigned to» di un operatore o di un gruppo.
Tipo di evento
explicit
|
|||
|
Ticket chiuso
|
È l’attività finale e indica la chiusura definitiva del ticket. Spesso il sistema la esegue automaticamente dopo che il ticket è rimasto nello stato «Resolved» per un periodo prestabilito senza nuove risposte del cliente. | ||
|
Perché è importante
Questa attività segna la conclusione definitiva del ciclo di vita della richiesta di assistenza e costituisce il punto finale per calcolare con precisione il tempo di ciclo da un’estremità all’altra.
Dove reperirli
Rilevato nel registro «Ticket Activities», che riporta la modifica finale di stato a «Closed». Spesso viene attivato da un’automazione di sistema.
Acquisizione
Evento registrato quando il campo «Status» del ticket viene impostato su «Closed».
Tipo di evento
explicit
|
|||
|
Ticket creato
|
È il primo evento nel ciclo di vita del servizio clienti e corrisponde al momento in cui la richiesta del cliente viene registrata ufficialmente in Freshdesk. L’attività viene rilevata esplicitamente quando si crea un nuovo ticket, tramite e-mail, portale, telefono o integrazione API. | ||
|
Perché è importante
Questa attività segna l’inizio di ogni caso ed è quindi essenziale per calcolare i tempi complessivi di risoluzione e analizzare l’andamento dei volumi di ticket per canale o tipologia.
Dove reperirli
È un evento esplicito nel registro «Ticket Activities» di Freshdesk. Viene generato automaticamente quando si crea un nuovo ticket.
Acquisizione
Registrato direttamente nel flusso delle attività del ticket al momento della creazione.
Tipo di evento
explicit
|
|||
|
Ticket risolto
|
Indica il momento in cui l’operatore ha fornito una soluzione e ha impostato lo stato del ticket su «Resolved». La modifica di stato viene registrata esplicitamente nella cronologia del ticket. | ||
|
Perché è importante
Questa attività segna la fine del lavoro attivo sul ticket e costituisce la base per misurare il tempo di risoluzione. È un evento fondamentale per analizzare le prestazioni degli operatori e l’efficienza complessiva del processo.
Dove reperirli
Rilevato nel registro «Ticket Activities», che riporta con un timestamp la modifica di stato specifica a «Resolved».
Acquisizione
Evento registrato quando il campo «Status» del ticket viene impostato su «Resolved».
Tipo di evento
explicit
|
|||
|
Nota interna aggiunta
|
Un operatore aggiunge al ticket una nota privata, destinata alla collaborazione interna con gli altri operatori. È un evento esplicito registrato nel flusso delle attività del ticket e visibile solo agli operatori. | ||
|
Perché è importante
Monitorare le note interne aiuta ad analizzare le modalità di collaborazione e a individuare i casi che richiedono un confronto interno approfondito. Un numero elevato di note interne prima della risoluzione può indicare problemi complessi o lacune nelle conoscenze.
Dove reperirli
Registrato come «Private Note» nella cronologia della conversazione del ticket, dove è distinguibile dalle risposte pubbliche al cliente.
Acquisizione
Evento registrato quando un operatore aggiunge una nota contrassegnata come «Private».
Tipo di evento
explicit
|
|||
|
Priorità del ticket modificata
|
L’evento si verifica quando un operatore o una regola di automazione modifica il livello di priorità di un ticket, ad esempio da «Low» a «High». La modifica viene registrata esplicitamente nel registro delle attività del ticket. | ||
|
Perché è importante
Le modifiche alla priorità possono segnalare un’escalation o una nuova valutazione dell’urgenza del problema. Analizzarle aiuta a comprendere i fattori che determinano le escalation e il loro impatto sui tempi di risoluzione.
Dove reperirli
Rilevato nel registro «Ticket Activities», che registra tutte le modifiche alle proprietà del ticket, compreso il campo «Priority».
Acquisizione
Evento registrato quando viene aggiornato il valore del campo «Priority».
Tipo di evento
explicit
|
|||
|
Risposta del cliente ricevuta
|
Indica una nuova risposta o comunicazione ricevuta dal cliente. È un evento esplicito nella conversazione del ticket e in genere riporta lo stato da «Pending» a «Open». | ||
|
Perché è importante
Questa attività è fondamentale per comprendere gli scambi tra clienti e operatori e misurare i tempi di risposta dei clienti. Riavvia inoltre gli eventuali timer SLA sospesi, incidendo sugli indicatori di conformità.
Dove reperirli
Registrato come nuova voce nella conversazione del ticket. L’evento è associato al record del contatto del cliente.
Acquisizione
Nuova nota pubblica aggiunta al ticket dal contatto del cliente.
Tipo di evento
explicit
|
|||
|
SLA non rispettato
|
Evento calcolato che si verifica quando il tempo impiegato per rispondere a un ticket o risolverlo supera l’obiettivo definito dalla policy SLA. Freshdesk monitora lo stato degli SLA e contrassegna i ticket come «violated»; da questo dato è possibile ricavare l’attività. | ||
|
Perché è importante
Questa attività supporta direttamente l’analisi del rispetto degli SLA, indicando esattamente quando e dove non vengono rispettati gli impegni sui livelli di servizio. È fondamentale per individuare le cause sistemiche dei ritardi.
Dove reperirli
L’evento viene dedotto o calcolato osservando lo stato «SLA» del ticket. L’attività può essere generata quando lo stato SLA del ticket passa a «Violated» oppure confrontando i timestamp di risposta e risoluzione con gli obiettivi SLA.
Acquisizione
Ricavato dai dati del ticket quando «Time to Resolve» supera «SLA Target Resolution Time».
Tipo di evento
calculated
|
|||
|
Sondaggio sulla soddisfazione inviato
|
Indica l’invio di un sondaggio sulla soddisfazione del cliente, in genere attivato da una regola di automazione dopo la risoluzione di un ticket. L’evento può essere rilevato se l’azione automatica viene registrata nella cronologia del ticket. | ||
|
Perché è importante
Segna l’inizio della raccolta dei feedback. Correlare le risposte ai sondaggi con le varianti del processo può fornire indicazioni approfondite su come le prestazioni del processo incidono sulla soddisfazione dei clienti.
Dove reperirli
In genere viene attivato da una «Automation Rule». La possibilità di visualizzarlo come evento distinto nel registro delle attività del ticket dipende dalla configurazione della registrazione delle automazioni in Freshdesk.
Acquisizione
Evento registrato dall’esecuzione di una regola di automazione dopo la risoluzione del ticket.
Tipo di evento
explicit
|
|||
|
Stato modificato in «Pending»
|
Questa attività si verifica quando un operatore attende informazioni dal cliente e imposta lo stato del ticket su «Pending». L’evento viene registrato esplicitamente come modifica di stato nella cronologia delle attività del ticket. | ||
|
Perché è importante
Individua i periodi in cui il processo è in pausa in attesa di informazioni esterne. Analizzare il tempo trascorso in questo stato aiuta a quantificare i ritardi imputabili al cliente e a valutare il rispetto degli SLA, poiché in genere i relativi timer vengono sospesi.
Dove reperirli
Rilevato nel registro «Ticket Activities», che registra tutte le modifiche di stato, compreso il passaggio a «Pending».
Acquisizione
Evento registrato quando il campo «Status» del ticket viene impostato su «Pending».
Tipo di evento
explicit
|
|||
|
Ticket riaperto
|
Questa attività si verifica quando un cliente risponde a un ticket già nello stato «Resolved», riportandolo automaticamente allo stato «Open». È un evento esplicito registrato dal sistema. | ||
|
Perché è importante
Un’elevata frequenza di riapertura indica che le soluzioni iniziali non sono efficaci e comporta lavoro ripetuto e insoddisfazione dei clienti. Analizzare questa attività è essenziale per l’«Ticket Re-opening Analysis» e per migliorare la risoluzione al primo contatto.
Dove reperirli
L’evento viene rilevato quando una risposta del cliente attiva il passaggio automatico dello stato da «Resolved» a «Open». La modifica viene registrata nel registro «Ticket Activities».
Acquisizione
Modifica di stato da «Resolved» a «Open» attivata da un’interazione con il cliente.
Tipo di evento
explicit
|
|||
|
Ticket riassegnato
|
Si verifica quando, dopo l’assegnazione iniziale, un ticket viene trasferito da un operatore o gruppo a un altro. È un evento esplicito registrato nel registro delle attività del ticket come modifica del responsabile. | ||
|
Perché è importante
Le riassegnazioni frequenti o un elevato numero di trasferimenti tra operatori indicano spesso un instradamento iniziale errato o conoscenze frammentate. Questa analisi aiuta a individuare le opportunità per migliorare la risoluzione al primo contatto.
Dove reperirli
Monitorato tramite le modifiche ai campi «Agent» o «Group» nel registro «Ticket Activities» successive alla prima assegnazione.
Acquisizione
Aggiornamento successivo del campo «Assigned to» dopo l’assegnazione iniziale.
Tipo di evento
explicit
|
|||
Guide all’estrazione
È pronto a iniziare?
Inizi a trasformare le attività di assistenza clienti partendo da una visione chiara dei processi. Questo template è il primo passo verso un’ottimizzazione basata sui dati.
Ottimizzi subito il servizio clienti con Freshdesk
Raggiunga l’80% di risoluzioni al primo contatto e offra ai clienti un’esperienza migliore.
Nessuna carta di credito richiesta, configurazione in pochi minuti