> Miglioramento Continuo dei Processi > Servizio clienti > Zendesk Support > Template Dati

Il Suo `Template` di Dati per il Servizio Clienti

Zendesk Support

`Attributi` del Servizio Clienti. (19) `Attività` di Servizio Clienti. (14) Guide all'Estrazione (4)

Il Suo `Template` di Dati per il Servizio Clienti

Questo `template` La aiuta a raccogliere i `dati` giusti per analizzare il Suo processo di assistenza clienti. Delinea `attributi` `dati` essenziali da raccogliere, attività chiave da tracciare e fornisce una guida pratica su come estrarre queste informazioni. Utilizzando questa guida, può costruire un robusto `Event Log` per scoprire `insight` e migliorare le Sue operazioni di servizio.

Attributi consigliati da raccogliere
`Attività` chiave da tracciare per il vostro processo di servizio clienti.
Guida all'estrazione per Zendesk Support.

È nuovo agli event log? Impari come creare un event log di Process Mining.

Scarica Template

`Attributi` del Servizio Clienti.

Questi sono i campi `dati` raccomandati da includere nel Suo `Event Log` per un'analisi completa del servizio clienti.

5 Obbligatorio 7 Consigliato 7 Facoltativo

	Nome	Descrizione
	Ora di Inizio StartTime	Il timestamp che indica quando è iniziata un'attività o un evento.
Descrizione L'Ora di Inizio, o `timestamp` dell'`event`, registra la data e l'ora esatte in cui si è verificata una specifica attività. Ad esempio, cattura quando un commento del cliente è stato aggiunto, quando un agente è stato assegnato o quando lo stato del `ticket` è cambiato in 'Risolto'. Questo `timestamp` è fondamentale per il `Process Mining` in quanto stabilisce l'ordine cronologico degli `event`. Viene utilizzato per calcolare le durate tra le attività, misurare i tempi di ciclo, analizzare le performance rispetto agli SLA e comprendere le dinamiche temporali del processo di servizio. Perché è importante Questo `timestamp` è essenziale per ordinare gli `event`, calcolare le durate e analizzare la `timeline` del processo di richiesta di servizio. Dove trovare API `Zendesk Ticket Audits`, campo `created_at` per ogni `event` nel `trail` di `audit`. Esempi 2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
	Richiesta di Servizio ServiceRequest	L'identificatore unico per ogni richiesta di servizio clienti, conosciuto anche come `ticket` o `case`.
Descrizione La Richiesta di Servizio è l'identificatore `case` primario che collega tutte le attività relative a una singola richiesta o problema del cliente, dalla sua creazione alla risoluzione finale. Ogni interazione, aggiornamento o azione interna è collegata a questo ID unico. Nel `Process Mining`, l'analisi degli `event` raggruppati per Richiesta di Servizio consente una visione completa e `end-to-end` del percorso di assistenza clienti. È la base per il calcolo di metriche chiave come il tempo totale di risoluzione, l'identificazione delle deviazioni di processo e la comprensione del ciclo di vita di ogni problema del cliente. Perché è importante Questo è l'ID di `Case` essenziale che collega tutti i passaggi del processo, consentendo la ricostruzione e l'analisi di ogni singolo percorso di assistenza clienti. Dove trovare API `Zendesk Tickets`, campo `id`. Esempi 102451287415332
	Nome attività ActivityName	Il nome dello specifico `event` o `task` che si è verificato all'interno del ciclo di vita della richiesta di servizio.
Descrizione Il Nome Attività descrive un singolo passo o `milestone` nel processo di assistenza clienti, come 'Richiesta di Servizio Creata', 'Richiesta Assegnata All'Agente' o 'Richiesta di Servizio Risolta'. Questi `event` sono con `timestamp` e formano la sequenza di azioni per ogni richiesta di servizio. Questo `attributo` è critico per visualizzare il flusso del processo, scoprire varianti di processo e analizzare la frequenza e l'ordine degli `event`. Consente agli analisti di comprendere quali azioni vengono eseguite e di identificare percorsi comuni, `bottleneck` e deviazioni dalla procedura standard. Perché è importante Questo `attributo` definisce le fasi del processo, consentendo la visualizzazione della mappa del processo e l'analisi dei flussi e delle variazioni del processo. Dove trovare Derivato dai `log` di `audit` dei ticket Zendesk o dagli `stream` di `eventi` che registrano cambiamenti e azioni. Esempi Richiesta di Servizio CreataRichiesta Assegnata All'AgentePrima Risposta Pubblica dell'Agente Inviata.Richiesta di Servizio Risolta
	Sistema di Origine SourceSystem	Il sistema di origine da cui sono stati estratti i dati.
Descrizione Questo `attributo` specifica il sistema di origine per i `dati` della richiesta di servizio, che in questo `case` è Zendesk Support. Aiuta nella `data governance` e nella `lineage`, specialmente quando si combinano `dati` da più sistemi. Nell'analisi, assicura che i `dati` siano correttamente attribuiti alla loro fonte, il che è importante per mantenere l'integrità dei `dati` e comprendere il contesto del processo, particolarmente negli ambienti `multi-system`. Perché è importante Identifica l'origine dei `dati`, che è cruciale per la `data governance` e per distinguere i `dati` di processo in ambienti integrati. Dove trovare Questo è un valore statico aggiunto durante il processo di estrazione dei `dati` per etichettare l'origine dei `dati`. Esempi Zendesk Support
	Ultimo `Data Update` LastDataUpdate	Il timestamp del più recente data refresh o estrazione dal sistema sorgente.
Descrizione Questo `attributo` indica l'ultima volta che il `dataset` è stato aggiornato da Zendesk Support. Fornisce contesto sulla freschezza dei `dati` analizzati. Conoscere l'ora dell'ultimo aggiornamento è cruciale per gli analisti e gli utenti aziendali per comprendere se stanno visualizzando le informazioni di processo più attuali. Aiuta a gestire le aspettative sulla recentezza dei `dati` ed è vitale per scopi di `reporting` e monitoraggio. Perché è importante Fornisce chiarezza sulla recentezza dei dati, assicurando che gli utenti comprendano quanto sia attuale l'analisi del processo. Dove trovare Questo è un campo `metadata` generato e memorizzato durante il processo di estrazione dei `dati`, che registra il `timestamp` del `job` di estrazione. Esempi 2023-10-27T02:00:00Z
	Agente Assegnato AssignedAgent	Il nome o l'ID dell'agente del servizio clienti assegnato per gestire la richiesta di servizio.
Descrizione Questo `attributo` identifica l'agente specifico responsabile di un'attività o della richiesta di servizio in un dato momento. Può cambiare durante il ciclo di vita se la richiesta viene riassegnata. L'analisi per Agente Assegnato è fondamentale per comprendere il carico di lavoro, le performance e l'efficienza dell'agente. Supporta la `dashboard` 'Carico di Lavoro ed Efficienza degli Agenti' consentendo confronti dei tempi di gestione e dei volumi di `case` tra diversi agenti, contribuendo a identificare opportunità di `coaching` e assicurare carichi di lavoro bilanciati. Perché è importante Traccia quale agente ha eseguito un'azione, consentendo l'analisi delle performance individuali, della distribuzione del carico di lavoro e dell'allocazione delle risorse. Dove trovare API `Zendesk Tickets`, campo `assignee_id`. I dettagli utente possono essere recuperati dall'API `Users`. Esempi John SmithJane DoeSupportBot
	Canale di Comunicazione. CommunicationChannel	Il canale attraverso il quale è stata inviata la richiesta di servizio o è avvenuta la comunicazione.
Descrizione Questo `attributo` identifica il metodo di comunicazione utilizzato, come e-mail, modulo `web`, `chat` o telefono. Riflette come i clienti interagiscono con il `service desk`. Comprendere l'utilizzo del canale è importante per la pianificazione delle risorse e il miglioramento dell'esperienza del cliente. La `dashboard` 'Panoramica sull'Utilizzo dei Canali di Comunicazione' analizza questi `dati` per vedere quali canali sono più popolari e se certi canali sono associati a tempi di risoluzione più lunghi o a diversi percorsi di processo. Può aiutare a decidere dove investire in miglioramenti del servizio o automazione. Perché è importante Mostra come interagiscono clienti e agenti, consentendo l'analisi dell'efficienza del canale e del suo impatto sul processo e sull'esperienza del cliente. Dove trovare API `Zendesk Tickets`, campo `via.channel`. Esempi webemailapichat
	Priorità Priority	Il livello di priorità assegnato alla richiesta di servizio, come 'Basso', 'Normale', 'Alto' o 'Urgente'.
Descrizione La priorità indica l'urgenza di una richiesta di servizio e spesso ne influenza la posizione in coda e il tempo di risoluzione previsto. Aiuta gli agenti a concentrarsi prima sui problemi più critici. Questo attributo è essenziale per l'analisi delle performance e degli SLA. La dashboard 'Service Request Resolution Time Analysis' utilizza la priorità per segmentare i dati, rivelando se le richieste ad alta priorità vengono gestite più velocemente di quelle a bassa priorità e se le risorse sono allocate efficacemente in base alle esigenze aziendali. Perché è importante Indica l'urgenza di una richiesta, che è fondamentale per analizzare la `SLA compliance` e garantire che i problemi critici siano affrontati tempestivamente. Dove trovare API `Zendesk Tickets`, campo `priority`. Esempi BassoNormaleElevatoUrgente
	SLA Violato IsSlaBreached	Un `flag` booleano che indica se il tempo di risoluzione della richiesta di servizio ha superato il suo obiettivo `SLA`.
Descrizione Questo `attributo` calcolato è un semplice `flag true` o `false` che mostra se una richiesta di servizio non ha soddisfatto l'Accordo sul Livello di Servizio definito per il tempo di risoluzione. È derivato confrontando la durata effettiva della risoluzione con l'`SLA target` pianificato. Questo `flag` semplifica l'analisi della Conformità SLA. È il punto `data` principale per la `dashboard` 'Performance di Conformità SLA' e il KPI 'Tasso di Conformità SLA', consentendo una rapida aggregazione e visualizzazione di how many requests are meeting service targets versus how many are not. Perché è importante Fornisce un risultato chiaro e binario per le performance SLA su ciascun caso, semplificando il monitoraggio della Conformità e la reportistica. Dove trovare Calcolato durante la trasformazione dei `dati` confrontando il tempo di risoluzione totale con il `SlaTargetResolutionTime`. Esempi truefalse
	Tempo di Risoluzione ServiceRequestResolutionTime	Il tempo totale trascorso dalla creazione di una richiesta di servizio fino alla sua risoluzione finale.
Descrizione Questa metrica misura la durata `end-to-end` di una richiesta di servizio. È calcolata come la differenza tra il `timestamp` dell'attività 'Richiesta di Servizio Risolta' e l'attività 'Richiesta di Servizio Creata'. Questa è una delle KPI più importanti per qualsiasi processo di assistenza clienti. È la metrica primaria per la `dashboard` 'Analisi del Tempo di Risoluzione delle Richieste di Servizio' e il KPI 'Tempo Medio di Risoluzione delle Richieste di Servizio'. L'analisi di questa durata aiuta a identificare ritardi sistemici e a misurare l'efficienza complessiva del processo di supporto. Perché è importante Misura la durata end-to-end del `case`, un `KPI` critico per valutare l'efficienza complessiva del processo e l'esperienza del cliente. Dove trovare Calcolato sottraendo il `timestamp` di creazione dal `timestamp` di risoluzione finale per ogni richiesta di servizio. Esempi 720086400172800
	Tempo di Risoluzione Obiettivo SLA SlaTargetResolutionTime	La durata `target` entro la quale una richiesta di servizio dovrebbe essere risolta, basata sulla sua politica SLA.
Descrizione Questo `attributo` definisce l'`SLA target` (Accordo sul Livello di Servizio) per la risoluzione di un `ticket`. Questo `target` è spesso dinamico e dipende da fattori come la priorità della richiesta, il tipo o il piano di servizio del cliente. Questo è un `attributo` fondamentale per la `dashboard` 'Performance di Conformità SLA'. Serve come `benchmark` rispetto al quale viene misurato il tempo di risoluzione effettivo. L'analisi delle performance rispetto a questo `target` aiuta a quantificare la qualità dell'erogazione del servizio e assicura che gli obblighi contrattuali verso i clienti siano rispettati. Perché è importante Definisce la promessa di servizio al cliente, fungendo da `benchmark` per misurare le prestazioni puntuali e la `SLA compliance`. Dove trovare Derivato dalle politiche `SLA` applicate a un ticket. Questa informazione è disponibile tramite l'API Zendesk Ticket Metrics. Esempi 144002880086400
	Tipo di Richiesta di Servizio ServiceRequestType	La classificazione della richiesta di servizio, come 'Domanda', 'Incidente', 'Problema' o 'Task'.
Descrizione Questo `attributo` categorizza la richiesta di servizio in base alla sua natura. Questa classificazione viene tipicamente impostata quando la richiesta viene creata o in `triage` e aiuta a determinare il `workflow` e la priorità appropriati. Nell'analisi, la segmentazione per Tipo di Richiesta di Servizio è fondamentale. Consente di confrontare i tempi di risoluzione, i tassi di escalation e i flussi di processo per diversi tipi di problemi, come mostrato in `dashboard` come 'Analisi del Tempo di Risoluzione delle Richieste di Servizio' e 'Tasso e Cause di Escalation Interna'. Questo aiuta a identificare se certi tipi di richieste sono più problematici o inefficienti da gestire. Perché è importante Categorizza le richieste per consentire il confronto delle prestazioni e l'analisi tra diversi tipi di problemi, il che è cruciale per un miglioramento mirato del processo. Dove trovare API `Zendesk Tickets`, campo `type`. Esempi DomandaIncidenteProblemaTask
	Categoria Servizio Prodotto ProductServiceCategory	Lo specifico prodotto, servizio o funzionalità a cui si riferisce la richiesta del cliente.
Descrizione Questo `attributo` fornisce un contesto dettagliato categorizzando la richiesta di servizio in base a un prodotto o a un'area di servizio. È spesso impostato manualmente da un agente o automaticamente in base al contenuto della richiesta. Questa categorizzazione è vitale per le `dashboard` 'Accuratezza della Categorizzazione delle Richieste' e 'Ripartizione del Tempo del Ciclo di Indagine'. Consente un'analisi approfondita di quali prodotti generano la maggior parte delle richieste di supporto, quali sono i più complessi da risolvere, e se la categorizzazione iniziale si allinea con la soluzione finale, contribuendo a migliorare lo smistamento e la formazione degli agenti. Perché è importante Collega le richieste a specifiche aree aziendali, prodotti o servizi, consentendo un'analisi focalizzata sulle aree problematiche e il loro impatto sul processo. Dove trovare Questo è tipicamente un campo `ticket` personalizzato in Zendesk. Il nome esatto del campo dipende dalla configurazione specifica di Zendesk. Esempi App MobileGestione AbbonamentiIntegrazione API.Hardware
	Codice di Risoluzione ResolutionCode	Un codice o una categoria che indica il motivo della risoluzione finale o della chiusura della richiesta.
Descrizione Il Codice di Risoluzione fornisce informazioni strutturate sull'esito di una richiesta di servizio. Esempi includono 'Risolto dall'Agente', 'Duplicato', 'Nessuna Azione Necessaria' o 'Problema Noto'. Offre più contesto di un semplice stato 'Chiuso'. Questo `attributo` è particolarmente prezioso per l'analisi delle cause radice. Per la `dashboard` 'Tendenze delle Richieste di Servizio Riaperture', l'analisi dei tassi di riapertura per codice di risoluzione può rivelare se determinati tipi di soluzioni sono meno efficaci, portando i clienti a dover interagire nuovamente con il supporto. Perché è importante Fornisce un'indicazione sull'esito di una richiesta di servizio, cruciale per l'analisi delle cause radice e per comprendere il motivo delle riaperture. Dove trovare Questo è tipicamente un campo `ticket` personalizzato in Zendesk. Il nome esatto del campo dipende dalla configurazione specifica di Zendesk. Esempi Risoluzione al Primo Contatto.Escalato al Livello 2.In Attesa del Cliente.Bug del Prodotto
	Conteggio Richieste di Informazioni. InformationRequestCount	Il numero totale di volte che sono state richieste informazioni al cliente per una singola richiesta di servizio.
Descrizione Questa metrica calcolata conta le occorrenze dell'attività 'Informazioni Richieste Dal Cliente' per ogni richiesta di servizio. Un conteggio elevato suggerisce che gli agenti non stanno raccogliendo tutte le informazioni necessarie in anticipo. Questo `attributo` è utilizzato nella `dashboard` 'Analisi delle Richieste di Informazioni Ripetute'. Il monitoraggio di questo conteggio aiuta a identificare le inefficienze del processo e le aree per la formazione degli agenti. Ridurre il numero di volte in cui vengono richieste informazioni può accorciare significativamente i tempi di risoluzione e migliorare l'esperienza del cliente. Perché è importante Quantifica la comunicazione avanti e indietro con il cliente, evidenziando le inefficienze che prolungano i tempi di risoluzione e degradano l'esperienza del cliente. Dove trovare Calcolato contando il numero di `eventi` in cui l'`ActivityName` è 'Information Requested From Customer' per ogni richiesta di servizio. Esempi 013
	È Riaperto IsReopened	Un `flag` booleano che indica se una richiesta di servizio è stata riaperta dopo essere stata contrassegnata come risolta.
Descrizione Questo `attributo` è un `flag` che diventa `true` se una richiesta di servizio transita di nuovo a uno stato aperto dopo essere stata precedentemente impostata come risolta o chiusa. Segnala che la risoluzione iniziale non è stata sufficiente. Questo `flag` è cruciale per tracciare il rilavoro e i fallimenti della risoluzione al primo contatto. Supporta direttamente la `dashboard` 'Tendenze delle Richieste di Servizio Riaperture' e il KPI 'Tasso di Riapertura delle Richieste di Servizio', rendendo facile contare e analizzare i `case` che richiedono attenzione aggiuntiva, il che spesso indica problemi sottostanti più profondi. Perché è importante Identifica le rilavorazioni e le risoluzioni fallite, aiutando a misurare la qualità e l'efficacia delle soluzioni fornite. Dove trovare Calcolato durante la trasformazione dei `dati` verificando se lo stato di un ticket cambia da 'risolto' o 'chiuso' a 'aperto'. Esempi truefalse
	Gruppo Agenti. AgentGroup	Il gruppo di supporto o il `team` a cui è assegnata la richiesta di servizio.
Descrizione Questo `attributo` rappresenta il `team` di agenti responsabile della richiesta di servizio. Le richieste sono spesso indirizzate a gruppi specifici in base a competenze, area prodotto o lingua. L'analisi per Gruppo Agente aiuta a comprendere le performance a livello di `team`, la distribuzione del carico di lavoro e gli schemi di escalation tra i `team`. Fornisce una visione di livello superiore rispetto all'analisi individuale dell'agente e può aiutare a identificare problemi sistemici all'interno di dipartimenti o funzioni specifiche. Perché è importante Traccia la responsabilità del `team`, consentendo l'analisi delle performance di gruppo, dei trasferimenti tra `team` e dell'allocazione delle risorse tra diversi livelli di supporto o specialità. Dove trovare API `Zendesk Tickets`, campo `group_id`. I dettagli del gruppo possono essere recuperati dall'API `Groups`. Esempi Supporto di primo livelloSupporto TecnicoFatturazione.
	Ora di Fine EndTime	Il `timestamp` che indica quando un'attività o un `event` è stato completato.
Descrizione L'Ora di Fine rappresenta il tempo di completamento di un'attività. In molte strutture di `Event Log`, l'Ora di Inizio dell'attività successiva può fungere da Ora di Fine di quella corrente. Per attività basate su stato come 'L'Agente Indaga il Problema', segna quando quello stato si è concluso. Questo `attributo` è essenziale per calcolare la durata precisa delle attività, un componente fondamentale dell'analisi delle performance. Aiuta a identificare quali fasi richiedono più tempo e fornisce la base per un'analisi dettagliata dei `bottleneck` e calcoli di efficienza delle risorse. Perché è importante Consente il calcolo delle durate delle `attività`, il che è critico per identificare i `bottleneck` e misurare le prestazioni. Dove trovare Questo è spesso derivato prendendo lo StartTime dell'`event` successivo nella sequenza per una data Richiesta di Servizio. Esempi 2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z
	Valutazione di Soddisfazione SatisfactionRating	Il punteggio di soddisfazione fornito dal cliente dopo che la richiesta di servizio è stata risolta.
Descrizione Questo `attributo` cattura il `feedback` del cliente sulla Sua esperienza di servizio, tipicamente raccolto tramite un sondaggio dopo che il `ticket` è risolto. Le valutazioni comuni includono 'Buono', 'Cattivo' o un punteggio numerico. Questa è una misura diretta del `sentiment` del cliente ed è una metrica di risultato chiave. Viene utilizzata per calcolare il KPI 'Customer Sentiment Score'. L'analisi delle valutazioni di soddisfazione in congiunzione con i `dati` di processo, come il tempo di risoluzione o il numero di interazioni dell'agente, può rivelare quali comportamenti di processo portano a migliori risultati per il cliente. Perché è importante Misura direttamente il `feedback` del cliente sul servizio fornito, collegando le prestazioni del processo ai risultati per il cliente. Dove trovare API `Zendesk Tickets`, campo `satisfaction_rating.score`. Esempi goodbadoffered

Obbligatorio Consigliato Facoltativo

`Attività` di Servizio Clienti.

Questi sono i passaggi chiave del processo e le `milestone` da catturare nel Suo `Event Log` per una scoperta accurata del processo di assistenza clienti.

6 Consigliato 8 Facoltativo

	Activity	Descrizione
	Informazioni Richieste al Cliente.	Si verifica quando un agente richiede maggiori informazioni da un cliente per procedere e cambia lo stato del ticket in 'in sospeso'. Questo cambiamento di stato indica esplicitamente che il processo è ora in attesa di una parte esterna.
Perché è importante Questa attività evidenzia le dipendenze dal cliente e sospende i `clock` SLA interni. Istanze frequenti o ripetute su un singolo `ticket` possono indicare una raccolta incompleta delle informazioni iniziali e portare a tempi di risoluzione più lunghi. Dove trovare Questo è un `event` esplicito di cambiamento di stato registrato nell'API `Zendesk Ticket Audits`. Viene catturato quando il campo 'status' cambia a 'pending'. Acquisisci Identificare gli `eventi` 'Change' negli `audit` dei ticket in cui lo stato del ticket è impostato su 'in sospeso'. Tipo di evento explicit
	Richiesta Assegnata All'Agente	Questo `event` significa che la richiesta di servizio è stata assegnata a un agente specifico per la gestione. Può avvenire automaticamente in base a regole di `routing` o manualmente da un `team lead` o un agente.
Perché è importante L'assegnazione è un `milestone` critico per la responsabilità e la gestione del carico di lavoro. Analizzare il tempo di assegnazione e i `pattern` di riassegnazione rivela i `bottleneck` nel processo di triage e distribuzione. Dove trovare Questo è un `event` di 'Change' esplicito nell'API `Zendesk Ticket Audits`, registrato ogni volta che il campo 'assignee_id' viene popolato o modificato. Acquisisci Tracciare i cambiamenti al campo 'assignee_id' nel `log` degli `Audit` del `Ticket`. Tipo di evento explicit
	Richiesta di Servizio Chiusa	Questa è l'attività finale, che segna la chiusura permanente della richiesta di servizio. Questo avviene tipicamente in automatico dopo che è trascorso un certo periodo di tempo da quando il `ticket` è stato contrassegnato come 'solved', senza nuove risposte dal cliente.
Perché è importante Come `evento` finale definitivo, completa il ciclo di vita del ticket. Il tempo da 'risolto' a 'chiuso' rappresenta la finestra per potenziali riaperture, e l'`evento` 'chiuso' conferma che la risoluzione è stata accettata. Dove trovare Questo è un cambiamento di stato esplicito registrato nell'API `Zendesk Ticket Audits` quando il campo 'status' è impostato su 'closed'. Acquisisci Identificare gli `eventi` 'Change' negli `audit` dei ticket in cui lo stato del ticket è impostato su 'chiuso'. Tipo di evento explicit
	Richiesta di Servizio Creata	Questa attività segna l'inizio del processo di assistenza clienti, quando un nuovo `ticket` viene generato in Zendesk da qualsiasi canale come e-mail, modulo `web` o `chat`. Questo `event` è esplicitamente registrato dal sistema con un ID `ticket` unico e un `timestamp` al momento della creazione.
Perché è importante Come `evento` di inizio primario, è essenziale per calcolare la durata complessiva del `case` e analizzare i volumi di richieste in ingresso nel tempo. Serve come `baseline` per misurare indicatori chiave di performance (`KPI`) come il tempo alla prima risposta e il tempo di risoluzione totale. Dove trovare Questo è un `event` esplicito catturato nell'API `Zendesk Ticket Audits`. Corrisponde all'`event` 'Create' per un `ticket`, fornendo il `timestamp` di creazione iniziale. Acquisisci Acquisito dall'`evento` di creazione del ticket nel `log` di Ticket Audits. Tipo di evento explicit
	Richiesta di Servizio Riaperta	Questa attività si verifica se un cliente risponde a un `ticket` che è nello stato 'risolto'. Zendesk cambia automaticamente lo stato di nuovo a 'aperto', indicando che il problema non è stato completamente risolto.
Perché è importante Le riaperture sono un indicatore critico del fallimento della risoluzione al primo contatto e di una scarsa qualità della soluzione. L'analisi della frequenza e dei motivi dei ticket riaperti aiuta a identificare le aree per migliorare la formazione degli agenti e le procedure di risoluzione. Dove trovare Questo è un cambiamento di stato esplicito nell'API `Ticket Audits`, catturato quando lo 'status' passa da 'solved' di nuovo a 'open'. Acquisisci Tracciare gli `event` di 'Change' di stato da 'solved' a 'open'. Tipo di evento explicit
	Richiesta di Servizio Risolta	Un agente contrassegna la richiesta di servizio come 'risolta' dopo aver fornito una soluzione al cliente. Questo è uno stato temporaneo, poiché il ticket può essere riaperto da una risposta del cliente prima che venga chiuso permanentemente.
Perché è importante Questa è la `milestone` primaria per misurare il tempo di risoluzione e l'efficienza dell'agente. Significa il punto in cui l'agente ritiene che il lavoro sia completo, fornendo una base per analizzare il rilavoro se il `ticket` viene riaperto. Dove trovare Questo è un cambiamento di stato esplicito registrato nell'API `Zendesk Ticket Audits` quando il campo 'status' è impostato su 'solved'. Acquisisci Identificare gli `eventi` 'Change' negli `audit` dei ticket in cui lo stato del ticket è impostato su 'risolto'. Tipo di evento explicit
	`Escalation` Interna Attivata.	Rappresenta il trasferimento di una richiesta di servizio a un diverso `team` interno o a un livello di supporto superiore. Questo viene tipicamente dedotto quando il gruppo assegnato al `ticket` viene cambiato.
Perché è importante Il monitoraggio delle escalation è fondamentale per identificare debolezze di processo, lacune di conoscenza nel supporto di prima linea e tipi di richiesta complessi. Alti tassi di escalation possono indicare la necessità di una migliore formazione o documentazione di processo. Dove trovare Dedotto da un `evento` 'Change' nell'API Ticket Audits dove il campo 'group_id' viene modificato. Un cambiamento di gruppo significa un trasferimento (`handoff`) tra team. Acquisisci Monitorare le modifiche al campo 'group_id' nel `log` di Ticket Audits. Tipo di evento inferred
	Il cliente ha risposto	Questo `event` viene `triggerato` quando un cliente risponde a un `ticket`, tipicamente uno che era in stato 'in sospeso'. Zendesk transita automaticamente lo stato del `ticket` da 'in sospeso' di nuovo a 'aperto', segnalando che l'agente può riprendere il lavoro.
Perché è importante Questa attività segna la fine di un tempo di attesa ed è un `trigger` per la continuazione del processo. Analizzare il tempo impiegato dai clienti per rispondere può fornire `insight` sulla chiarezza delle richieste degli agenti. Dove trovare Questo `event` corrisponde a un nuovo commento pubblico dell'utente finale, che `triggera` un esplicito cambiamento di stato da 'in sospeso' a 'aperto' nell'API `Ticket Audits`. Acquisisci Tracciare gli `event` di 'Change' di stato da 'pending' a 'open' o identificare nuovi commenti pubblici da un utente finale. Tipo di evento explicit
	Prima Risposta Pubblica dell'Agente Inviata.	Questa attività segna la prima volta che un agente invia un commento pubblico al cliente, in opposizione a un riconoscimento automatizzato. Questo `event` è un indicatore cruciale del primo coinvolgimento dell'agente con il problema del cliente.
Perché è importante Questa è una `milestone` chiave per misurare lo SLA 'Tempo di Prima Risposta', un indicatore critico della reattività del servizio. Separa la comunicazione automatizzata dall'inizio dell'indagine e del supporto attivo, guidato dall'uomo. Dove trovare Identificato trovando il primo commento pubblico nello `stream` di Ticket Comments dove l'autore è un agente umano (non un utente di sistema automatizzato). Acquisisci Scansionare i commenti del `ticket`, filtrando i commenti pubblici degli agenti e selezionando quello con il `timestamp` più vecchio. Tipo di evento inferred
	Richiesta Categorizzata E Prioritizzata	Questa attività si verifica quando un agente o un'automazione imposta o aggiorna campi del `ticket` come tipo, categoria e priorità. Questo passo viene registrato come `event` di cambiamento nella cronologia del `ticket`.
Perché è importante Una corretta categorizzazione e prioritizzazione sono vitali per uno smistamento efficiente e l'allocazione delle risorse. L'analisi di questa attività aiuta a determinare l'accuratezza del triage iniziale e il suo impatto sui tempi di risoluzione. Dove trovare Acquisito dall'API Zendesk Ticket Audits come `eventi` 'Change'. Può essere identificato cercando il primo aggiornamento di campi come 'priority', 'type' o campi personalizzati relativi alla categorizzazione. Acquisisci Filtra i `log` di Ticket Audit per il primo `evento` 'Change' sui campi chiave di categorizzazione dopo la creazione. Tipo di evento explicit
	Riconoscimento Iniziale Inviato.	Rappresenta la prima risposta automatica inviata al cliente, a conferma della ricezione della Sua richiesta. Questo viene generalmente gestito da un `trigger` di Zendesk che invia una notifica e-mail `template` immediatamente dopo la creazione del `ticket`.
Perché è importante Il monitoraggio di questa attività è cruciale per misurare la reattività iniziale e gestire le aspettative del cliente. Il tempo tra la creazione della richiesta e questo riconoscimento è una metrica chiave per la soddisfazione del cliente. Dove trovare Dedotto dal primo commento pubblico sul ticket se il suo autore è un utente automatizzato o se si verifica entro pochi secondi dalla creazione del ticket. Questo può essere identificato analizzando lo `stream` di Ticket Comments. Acquisisci Identificare il primo commento pubblico creato da un'automazione o un `trigger` immediatamente dopo la creazione del ticket. Tipo di evento inferred
	Sondaggio di Soddisfazione Inviato	Rappresenta il momento in cui un sondaggio sulla soddisfazione del cliente (CSAT) viene inviato automaticamente al cliente. Questo di solito avviene poco tempo dopo che il `ticket` è contrassegnato come risolto.
Perché è importante Questa attività avvia il ciclo di `feedback` del cliente. Comprendere quando e se i sondaggi vengono inviati è importante per contestualizzare i punteggi di soddisfazione e misurare l'efficacia del programma di `feedback`. Dove trovare Questo può essere dedotto da un `automation log` o dall'aggiunta di un `tag` specifico al `ticket`. La sezione 'satisfaction_rating' nell'API `Ticket Audits` registra anche quando il sondaggio è stato offerto. Acquisisci Cercare `tag` come 'csat_sent' o utilizzare il `timestamp` da quando è stata offerta la valutazione di soddisfazione. Tipo di evento inferred
	Valutazione di Soddisfazione Ricevuta	Questo `event` si verifica quando il cliente invia la sua risposta al sondaggio di soddisfazione, fornendo una valutazione come 'Buono' o 'Cattivo'. La valutazione e qualsiasi commento associato vengono registrati nel `ticket`.
Perché è importante Il `feedback` diretto del cliente è inestimabile per misurare la qualità del servizio e il `sentiment` del cliente. Analizzare queste valutazioni nel contesto del flusso di processo aiuta a correlare specifiche `attività` o agenti con i risultati. Dove trovare Acquisito come `evento` 'Change' nell'API Ticket Audits quando il campo 'satisfaction_rating' viene popolato con il punteggio e il commento del cliente. Acquisisci Filtra i `log` di Ticket Audit per le modifiche al campo 'satisfaction_rating'. Tipo di evento explicit
	Violazione SLA Verificata	Questa attività segna il punto nel tempo in cui una richiesta di servizio non riesce a soddisfare un Accordo sul Livello di Servizio predefinito, come il tempo di prima risposta o il tempo di risoluzione. Questo `event` è calcolato in base ai `timestamp` delle attività del `ticket` confrontati con le politiche SLA.
Perché è importante Le violazioni degli SLA influiscono direttamente sulla soddisfazione del cliente e sulla Conformità contrattuale. Analizzare quando e perché si verificano è fondamentale per identificare ritardi sistemici, carenze di risorse o obiettivi di performance irrealistici. Dove trovare Questo può essere ricavato dall'API `Zendesk Ticket Metrics`, che memorizza i `timestamp` di violazione SLA ('breached_at'). Alternativamente, può essere calcolato confrontando i `timestamp` degli `event` del `ticket` con le regole SLA definite. Acquisisci Utilizzi il `timestamp` 'breached_at' dall'API `Ticket Metrics` o calcoli confrontando il tempo di risoluzione con il tempo della politica SLA. Tipo di evento calculated

Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i vostri `dati` da Zendesk Support.

Fasi

Navigare su Zendesk Explore: Effettuate il login all'istanza Zendesk e aprite il prodotto Explore cliccando sull'icona del launcher del prodotto nella barra superiore e selezionando Explore.
Creare una Nuova Query: In Explore, cliccate sull'icona Queries nella barra laterale sinistra, quindi cliccate sul pulsante "New query" in alto a destra.
Selezionare il Dataset: Nella finestra "Choose a dataset", selezionate il dataset Support: Tickets. Questo dataset contiene gli attributi principali del ticket e i timestamp degli eventi chiave.
Aggiungere Metriche: Nel query builder, andate al pannello "Metrics" e cliccate su "Add". Selezionate COUNT(Tickets). Questo aiuta a convalidare il volume dei dati.
Aggiungere Attributi alle Righe: Andate al pannello "Rows" e cliccate su "Add". Aggiungete i seguenti attributi. Questi formeranno le colonne di base della vostra esportazione in formato wide.
- Ticket ID (Questo è il vostro identificatore di Case, ServiceRequest)
- Assignee name (AssignedAgent)
- Ticket type (ServiceRequestType)
- Ticket priority (Priority)
- Ticket channel (CommunicationChannel)
- SLA resolution time (SlaTargetResolutionTime)
- SLA breach status (IsSlaBreached)
- Full resolution time (min) (ServiceRequestResolutionTime)
Aggiungere i Timestamp delle Attività alle Righe: Aggiungete i seguenti attributi timestamp al pannello "Rows". Ognuno di questi rappresenta una potenziale attività. Alcune attività richiedono la creazione di un attributo calcolato personalizzato.
- Ticket created - Timestamp: Per Service Request Created e Initial Acknowledgment Sent.
- Ticket assigned - Timestamp: Per Request Assigned To Agent.
- First reply time - Timestamp: Per First Agent Public Reply Sent.
- Ticket solved - Timestamp: Per Service Request Resolved e Satisfaction Survey Sent.
- Ticket reopened - Timestamp: Per Service Request Reopened.
- Satisfaction rating received - Timestamp: Per Satisfaction Rating Received.
- Ticket closed - Timestamp: Per Service Request Closed.
Creare Attributi Calcolati Personalizzati per Altre Attività: Alcune attività si basano su modifiche di campi specifici e richiedono la creazione di attributi personalizzati per catturare il loro timestamp. Andate al menu Calculations (icona della calcolatrice) e selezionate "Standard calculated attribute". Create un attributo per ciascuna delle seguenti attività. Sarà necessario trovare i nomi esatti per i campi e i valori nella vostra istanza Zendesk.
- Nome: Timestamp - Categorized and Prioritized. Formula: IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF. Dopo averlo creato, aggiungete questo nuovo attributo al pannello "Rows" e cambiatene l'aggregatore in MIN.
- Nome: Timestamp - Info Requested. Formula: IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF. Aggiungetelo a "Rows" e impostate l'aggregatore su MIN.
- Nome: Timestamp - Customer Responded. Formula: IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF. Aggiungetelo a "Rows" e impostate l'aggregatore su MIN.
- Nome: Timestamp - Escalated. Formula: IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF. Aggiungetelo a "Rows" e impostate l'aggregatore su MIN.
- Nome: Timestamp - SLA Breach. Formula: IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF. Aggiungetelo a "Rows" e impostate l'aggregatore su MIN.
Filtrare i Dati: Andate al pannello "Filters" e cliccate su "Add". Aggiungete un filtro per Ticket created - Date e selezionate un intervallo di date appropriato, come gli ultimi 3-6 mesi, per mantenere il dataset gestibile.
Eseguire ed Esportare il Report: Cliccate su "Save" per eseguire la query. Una volta che la tabella visualizza i dati, cliccate sul pulsante "Export" e scegliete il formato preferito, come CSV o Excel.
Trasformare i Dati in Formato Event Log: Il file esportato è in un formato "wide" dove ogni riga è un ticket e ogni colonna è un timestamp di evento. È necessario trasformarlo in un formato "long" per il process mining. Utilizzate uno strumento come Microsoft Excel (con la funzione Unpivot di Power Query), Python o un altro strumento di preparazione dati.
- Per ogni riga (ticket), create più nuove righe, una per ogni colonna timestamp non vuota.
- La tabella finale dovrebbe avere colonne come ServiceRequest, ActivityName, StartTime, e gli altri attributi, che saranno duplicati per ogni attività di una data richiesta di servizio.

Configurazione

Dataset: Il dataset principale da utilizzare è Support: Tickets. Questo consente l'accesso alla maggior parte delle proprietà dei ticket e ai timestamp chiave in una singola query.
Permissions: È necessario almeno un ruolo di Editor o Admin in Zendesk Explore per creare e salvare le query.
Date Range: È fondamentale impostare un filtro per l'intervallo di date su Ticket created - Date. Si raccomanda un intervallo di dati da 3 a 6 mesi per bilanciare l'insight con le prestazioni. L'esportazione di milioni di ticket può essere lenta o fallire.
Query Filters: Si consideri di aggiungere filtri per proprietà specifiche dei ticket come Ticket brand, Ticket form o Ticket group per focalizzare l'analisi su un servizio o un team particolare.
Calculated Attributes: Questo metodo si basa fortemente sulla creazione di attributi calcolati standard per acquisire timestamp per eventi che non sono attributi predefiniti, come cambi di stato o escalation. Assicuratevi di avere i permessi per creare questi attributi.

a Query di Esempio config

This extraction is configured through the Zendesk Explore graphical user interface. There is no single script to execute. The configuration below outlines the components to add in the query builder.

**Dataset**: `Support: Tickets`

**Metrics**:
1.  `COUNT(Tickets)`

**Rows (Attributes)**:
1.  `Ticket ID`
2.  `Assignee name`
3.  `Ticket type`
4.  `Ticket priority`
5.  `Ticket channel`
6.  `SLA resolution time`
7.  `SLA breach status`
8.  `Full resolution time (min)`
9.  `MIN(Ticket created - Timestamp)`
10. `MIN(Ticket assigned - Timestamp)`
11. `MIN(First reply time - Timestamp)`
12. `MIN(Ticket solved - Timestamp)`
13. `MIN(Ticket reopened - Timestamp)`
14. `MIN(Satisfaction rating received - Timestamp)`
15. `MIN(Ticket closed - Timestamp)`
16. `MIN(Timestamp - Categorized and Prioritized)` (Custom calculated attribute)
17. `MIN(Timestamp - Info Requested)` (Custom calculated attribute)
18. `MIN(Timestamp - Customer Responded)` (Custom calculated attribute)
19. `MIN(Timestamp - Escalated)` (Custom calculated attribute)
20. `MIN(Timestamp - SLA Breach)` (Custom calculated attribute)

**Filters**:
1.  `Ticket created - Date`: Select a date range (e.g., last 180 days)

**Standard Calculated Attribute Formulas**:
*   `Timestamp - Categorized and Prioritized`: `IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Info Requested`: `IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Customer Responded`: `IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Escalated`: `IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - SLA Breach`: `IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF`

Fasi

Preparare l'Accesso all'API Zendesk: Effettuate il login a Zendesk come amministratore. Navigate all'Admin Center, quindi andate su Apps and integrations > APIs > Zendesk API. Sotto la scheda Settings, assicuratevi che Token Access sia abilitato. Cliccate su 'Add API token' per creare un nuovo token. Copiate in modo sicuro il token generato, poiché non verrà più visualizzato.
Configurare l'Ambiente Python: Assicuratevi di avere Python 3.6 o più recente installato. Installate la libreria requests, necessaria per effettuare richieste HTTP all'API Zendesk. Potete installarla usando la riga di comando: pip install requests.
Configurare lo Script Python: Salvate lo script Python fornito in un file, ad esempio extract_zendesk_log.py. Aprite il file in un editor di testo e aggiornate le variabili placeholder in alto: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL e API_TOKEN con i dettagli e le credenziali della vostra istanza Zendesk specifica.
Definire il Periodo di Estrazione: Individuate la variabile START_TIMESTAMP all'interno dello script. Questo valore determina la data di inizio storica per l'estrazione dei dati. Deve essere un timestamp Unix epoch. Per un'analisi iniziale, è consigliato un valore corrispondente agli ultimi 3-6 mesi.
Eseguire lo Script: Aprite un terminal o un prompt dei comandi, navigate nella directory dove avete salvato lo script ed eseguitelo usando il comando: python extract_zendesk_log.py.
Monitorare l'Esecuzione: Lo script stamperà gli aggiornamenti di progress sulla console, indicando il numero di ticket elaborati. Il tempo totale di esecuzione dipenderà dal volume di dati estratti e da eventuali limiti di rate limiting imposti da Zendesk. Lo script include una logica di base per gestire le risposte di rate limit.
Recuperare il Log di Eventi: Al completamento con successo, lo script creerà un file denominato zendesk_event_log.csv nella stessa directory. Questo file contiene il log di eventi strutturato pronto per l'analisi.
Preparare per l'Upload: Aprite il file zendesk_event_log.csv per assicurarvi che sia stato generato correttamente. Verificate che le colonne corrispondano agli attributi richiesti: ServiceRequest, ActivityName, StartTime, SourceSystem e LastDataUpdate. Il file è ora pronto per l'upload nello strumento di process mining.

Configurazione

API Credentials: Lo script richiede un sottodominio Zendesk valido, l'indirizzo email di un agente o utente amministratore e un token API attivo. L'utente associato alle credenziali deve avere i permessi per leggere ticket, audit dei ticket, utenti e metriche dei ticket.
Date Range: La data di inizio dell'estrazione è controllata dalla variabile START_TIMESTAMP nello script, che deve essere un timestamp Unix epoch. È consigliabile iniziare con un periodo più breve, ad esempio 3 mesi, per convalidare l'output e le prestazioni dello script prima di tentare un'estrazione di dati storici più ampia.
Incremental Export API: Questa soluzione utilizza l'Incremental Export API di Zendesk. Questo è il metodo più efficiente e raccomandato per recuperare un gran numero di ticket, in quanto è progettato per l'esportazione massiva di dati ed evita i comuni inconvenienti della paginazione.
Performance and Rate Limiting: Zendesk impone limiti di frequenza API (rate limits) che variano in base al piano di abbonamento. Lo script include una logica integrata per sospendere l'esecuzione quando viene raggiunto un limite di frequenza, basandosi sull'intestazione Retry-After restituita dall'API. Per istanze molto grandi, l'estrazione potrebbe richiedere diverse ore.
Prerequisites: Questo metodo di estrazione richiede un ambiente Python 3.6+ funzionante e la libreria esterna requests. L'accesso da amministratore all'istanza Zendesk di destinazione è necessario per generare il token API richiesto.

a Query di Esempio python

import requests
import json
import time
import datetime
import csv

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">'[your_zendesk_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_zendesk_login_email]'
API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Set the start time for the export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is Jan 1, 2023 00:00:00 GMT
START_TIMESTAMP = 1672531200

class=class="hl-string">"hl-comment"># --- Script --- 

BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
AUTH = (fclass="hl-string">'{ZENDESK_EMAIL}/token', API_TOKEN)
SOURCE_SYSTEM = class="hl-string">'Zendesk Support'
LAST_DATA_UPDATE = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

CSV_FILENAME = class="hl-string">'zendesk_event_log.csv'
CSV_HEADERS = [
    class="hl-string">'ServiceRequest', class="hl-string">'ActivityName', class="hl-string">'StartTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
    class="hl-string">'AssignedAgent', class="hl-string">'ServiceRequestType', class="hl-string">'Priority', class="hl-string">'CommunicationChannel',
    class="hl-string">'SlaTargetResolutionTime', class="hl-string">'IsSlaBreached', class="hl-string">'ServiceRequestResolutionTime'
]

def get_user_name(user_id, users_cache, session):
    if user_id in users_cache:
        return users_cache[user_id]
    if user_id is None:
        return None
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_name = response.json().get(class="hl-string">'user', {}).get(class="hl-string">'name')
        users_cache[user_id] = user_name
        return user_name
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Warning: Could not fetch user {user_id}. Error: {e}')
        users_cache[user_id] = str(user_id)
        return str(user_id)

def format_duration(seconds):
    if seconds is None:
        return None
    return str(datetime.timedelta(seconds=seconds))

def main():
    session = requests.Session()
    session.auth = AUTH
    users_cache = {}
    event_log = []

    class=class="hl-string">"hl-comment"># Fetch tickets using the incremental export API
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}'
    ticket_count = 0

    while url:
        print(fclass="hl-string">'Fetching tickets from: {url}')
        try:
            response = session.get(url)

            if response.status_code == 429:
                retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
                print(fclass="hl-string">'Rate limit hit. Retrying after {retry_after} seconds.')
                time.sleep(retry_after)
                continue

            response.raise_for_status()
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])

            for ticket in tickets:
                ticket_count += 1
                ticket_id = ticket[class="hl-string">'id']
                print(fclass="hl-string">'Processing ticket {ticket_id} ({ticket_count} total)...')

                class=class="hl-string">"hl-comment"># Fetch ticket metrics for SLA and resolution time
                metrics_response = session.get(fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json')
                ticket_metrics = metrics_response.json().get(class="hl-string">'ticket_metric', {}) if metrics_response.ok else {}

                resolution_time_seconds = ticket_metrics.get(class="hl-string">'full_resolution_time_in_minutes', {}).get(class="hl-string">'business')
                if resolution_time_seconds:
                    resolution_time_seconds *= 60

                class=class="hl-string">"hl-comment"># Fetch ticket audits for events
                audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
                audits_response = session.get(audits_url)
                audits = audits_response.json().get(class="hl-string">'audits', []) if audits_response.ok else []

                first_agent_reply_sent = False

                for audit in audits:
                    audit_created_at = audit[class="hl-string">'created_at']
                    base_event = {
                        class="hl-string">'ServiceRequest': ticket_id,
                        class="hl-string">'StartTime': audit_created_at,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'AssignedAgent': get_user_name(ticket.get(class="hl-string">'assignee_id'), users_cache, session),
                        class="hl-string">'ServiceRequestType': ticket.get(class="hl-string">'type'),
                        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'CommunicationChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaTargetResolutionTime': None, class=class="hl-string">"hl-comment"># Requires parsing SLA policies, complex
                        class="hl-string">'IsSlaBreached': ticket_metrics.get(class="hl-string">'sla_breach_at') is not None,
                        class="hl-string">'ServiceRequestResolutionTime': format_duration(resolution_time_seconds)
                    }

                    for event in audit.get(class="hl-string">'events', []):
                        event_type = event.get(class="hl-string">'type')
                        class=class="hl-string">"hl-comment"># Service Request Created
                        if event_type == class="hl-string">'Create' and event.get(class="hl-string">'field_name') == class="hl-string">'id':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Created'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Initial Acknowledgment Sent (Proxy by Notification event)
                        if event_type == class="hl-string">'Notification':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Initial Acknowledgment Sent'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Request Categorized And Prioritized, Assigned, Status Changes
                        if event_type == class="hl-string">'Change':
                            field = event.get(class="hl-string">'field_name')
                            if field in [class="hl-string">'type', class="hl-string">'priority', class="hl-string">'custom_field_[your_category_field_id]']:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Categorized And Prioritized'
                                event_log.append(new_event)
                            
                            if field == class="hl-string">'assignee_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Assigned To Agent'
                                new_event[class="hl-string">'AssignedAgent'] = get_user_name(event.get(class="hl-string">'value'), users_cache, session)
                                event_log.append(new_event)

                            if field == class="hl-string">'group_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Internal Escalation Triggered'
                                event_log.append(new_event)

                            if field == class="hl-string">'status':
                                new_status = event.get(class="hl-string">'value')
                                if new_status == class="hl-string">'pending':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Information Requested From Customer'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'solved':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Resolved'
                                    event_log.append(new_event)
                                    class=class="hl-string">"hl-comment"># Satisfaction Survey Sent (Proxy: occurs after solve)
                                    solve_time = datetime.datetime.fromisoformat(audit_created_at.replace(class="hl-string">'Z', class="hl-string">'+00:00'))
                                    survey_time = solve_time + datetime.timedelta(hours=1)
                                    survey_event = new_event.copy()
                                    survey_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Survey Sent'
                                    survey_event[class="hl-string">'StartTime'] = survey_time.isoformat().replace(class="hl-string">'+00:00', class="hl-string">'Z')
                                    event_log.append(survey_event)
                                elif new_status == class="hl-string">'closed':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Closed'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'open' and event.get(class="hl-string">'previous_value') in [class="hl-string">'solved', class="hl-string">'pending']:
                                    activity = class="hl-string">'Service Request Reopened' if event.get(class="hl-string">'previous_value') == class="hl-string">'solved' else class="hl-string">'Customer Responded'
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = activity
                                    event_log.append(new_event)
                            
                            if field == class="hl-string">'satisfaction_score':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Rating Received'
                                event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># First Agent Public Reply Sent & Customer Responded
                        if event_type == class="hl-string">'Comment':
                            author_id = event.get(class="hl-string">'author_id')
                            author_details_response = session.get(fclass="hl-string">'{BASE_URL}/users/{author_id}.json')
                            author_role = author_details_response.json().get(class="hl-string">'user',{}).get(class="hl-string">'role', class="hl-string">'end-user') if author_details_response.ok else class="hl-string">'end-user'

                            if author_role in [class="hl-string">'agent', class="hl-string">'admin'] and event.get(class="hl-string">'public') and not first_agent_reply_sent:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'First Agent Public Reply Sent'
                                event_log.append(new_event)
                                first_agent_reply_sent = True

                class=class="hl-string">"hl-comment"># SLA Breach Occurred
                if ticket_metrics.get(class="hl-string">'sla_breach_at'):
                    sla_breach_time = ticket_metrics.get(class="hl-string">'sla_breach_at')
                    new_event = base_event.copy()
                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'SLA Breach Occurred'
                    new_event[class="hl-string">'StartTime'] = sla_breach_time
                    event_log.append(new_event)

            url = data.get(class="hl-string">'after_url')
            if not data.get(class="hl-string">'end_of_stream', False):
                time.sleep(1) class=class="hl-string">"hl-comment"># Be a good API citizen
            else:
                url = None

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'An error occurred: {e}')
            break

    class=class="hl-string">"hl-comment"># Write to CSV
    print(fclass="hl-string">'Writing {len(event_log)} events to {CSV_FILENAME}...')
    with open(CSV_FILENAME, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
        writer = csv.DictWriter(csvfile, fieldnames=CSV_HEADERS)
        writer.writeheader()
        class=class="hl-string">"hl-comment"># Sort events by ticket and then by time for chronological order
        sorted_log = sorted(event_log, key=lambda x: (x[class="hl-string">'ServiceRequest'], x[class="hl-string">'StartTime']))
        for row in sorted_log:
            writer.writerow(row)
    print(class="hl-string">'Extraction complete.')

if __name__ == class="hl-string">'__main__':
    main()

Fasi

Preparare l'Accesso all'API Zendesk: Effettuate il login a Zendesk come amministratore. Navigate all'Admin Center, quindi andate su Apps and integrations > APIs > Zendesk API. Sotto la scheda Settings, assicuratevi che Token Access sia abilitato. Cliccate su 'Add API token' per creare un nuovo token. Copiate in modo sicuro il token generato, poiché non verrà più visualizzato.
Configurare l'Ambiente Python: Assicuratevi di avere Python 3.6 o più recente installato. Installate la libreria requests, necessaria per effettuare richieste HTTP all'API Zendesk. Potete installarla usando la riga di comando: pip install requests.
Configurare lo Script Python: Salvate lo script Python fornito in un file, ad esempio extract_zendesk_log.py. Aprite il file in un editor di testo e aggiornate le variabili placeholder in alto: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL e API_TOKEN con i dettagli e le credenziali della vostra istanza Zendesk specifica.
Definire il Periodo di Estrazione: Individuate la variabile START_TIMESTAMP all'interno dello script. Questo valore determina la data di inizio storica per l'estrazione dei dati. Deve essere un timestamp Unix epoch. Per un'analisi iniziale, è consigliato un valore corrispondente agli ultimi 3-6 mesi.
Eseguire lo Script: Aprite un terminal o un prompt dei comandi, navigate nella directory dove avete salvato lo script ed eseguitelo usando il comando: python extract_zendesk_log.py.
Monitorare l'Esecuzione: Lo script stamperà gli aggiornamenti di progress sulla console, indicando il numero di ticket elaborati. Il tempo totale di esecuzione dipenderà dal volume di dati estratti e da eventuali limiti di rate limiting imposti da Zendesk. Lo script include una logica di base per gestire le risposte di rate limit.
Recuperare il Log di Eventi: Al completamento con successo, lo script creerà un file denominato zendesk_event_log.csv nella stessa directory. Questo file contiene il log di eventi strutturato pronto per l'analisi.
Preparare per l'Upload: Aprite il file zendesk_event_log.csv per assicurarvi che sia stato generato correttamente. Verificate che le colonne corrispondano agli attributi richiesti: ServiceRequest, ActivityName, StartTime, SourceSystem e LastDataUpdate. Il file è ora pronto per l'upload nello strumento di process mining.

Configurazione

API Credentials: Lo script richiede un sottodominio Zendesk valido, l'indirizzo email di un agente o utente amministratore e un token API attivo. L'utente associato alle credenziali deve avere i permessi per leggere ticket, audit dei ticket, utenti e metriche dei ticket.
Date Range: La data di inizio dell'estrazione è controllata dalla variabile START_TIMESTAMP nello script, che deve essere un timestamp Unix epoch. È consigliabile iniziare con un periodo più breve, ad esempio 3 mesi, per convalidare l'output e le prestazioni dello script prima di tentare un'estrazione di dati storici più ampia.
Incremental Export API: Questa soluzione utilizza l'Incremental Export API di Zendesk. Questo è il metodo più efficiente e raccomandato per recuperare un gran numero di ticket, in quanto è progettato per l'esportazione massiva di dati ed evita i comuni inconvenienti della paginazione.
Performance and Rate Limiting: Zendesk impone limiti di frequenza API (rate limits) che variano in base al piano di abbonamento. Lo script include una logica integrata per sospendere l'esecuzione quando viene raggiunto un limite di frequenza, basandosi sull'intestazione Retry-After restituita dall'API. Per istanze molto grandi, l'estrazione potrebbe richiedere diverse ore.
Prerequisites: Questo metodo di estrazione richiede un ambiente Python 3.6+ funzionante e la libreria esterna requests. L'accesso da amministratore all'istanza Zendesk di destinazione è necessario per generare il token API richiesto.

a Query di Esempio python

import requests
import json
import time
import datetime
import csv

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">'[your_zendesk_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_zendesk_login_email]'
API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Set the start time for the export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is Jan 1, 2023 00:00:00 GMT
START_TIMESTAMP = 1672531200

class=class="hl-string">"hl-comment"># --- Script --- 

BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
AUTH = (fclass="hl-string">'{ZENDESK_EMAIL}/token', API_TOKEN)
SOURCE_SYSTEM = class="hl-string">'Zendesk Support'
LAST_DATA_UPDATE = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

CSV_FILENAME = class="hl-string">'zendesk_event_log.csv'
CSV_HEADERS = [
    class="hl-string">'ServiceRequest', class="hl-string">'ActivityName', class="hl-string">'StartTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
    class="hl-string">'AssignedAgent', class="hl-string">'ServiceRequestType', class="hl-string">'Priority', class="hl-string">'CommunicationChannel',
    class="hl-string">'SlaTargetResolutionTime', class="hl-string">'IsSlaBreached', class="hl-string">'ServiceRequestResolutionTime'
]

def get_user_name(user_id, users_cache, session):
    if user_id in users_cache:
        return users_cache[user_id]
    if user_id is None:
        return None
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_name = response.json().get(class="hl-string">'user', {}).get(class="hl-string">'name')
        users_cache[user_id] = user_name
        return user_name
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Warning: Could not fetch user {user_id}. Error: {e}')
        users_cache[user_id] = str(user_id)
        return str(user_id)

def format_duration(seconds):
    if seconds is None:
        return None
    return str(datetime.timedelta(seconds=seconds))

def main():
    session = requests.Session()
    session.auth = AUTH
    users_cache = {}
    event_log = []

    class=class="hl-string">"hl-comment"># Fetch tickets using the incremental export API
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}'
    ticket_count = 0

    while url:
        print(fclass="hl-string">'Fetching tickets from: {url}')
        try:
            response = session.get(url)

            if response.status_code == 429:
                retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
                print(fclass="hl-string">'Rate limit hit. Retrying after {retry_after} seconds.')
                time.sleep(retry_after)
                continue

            response.raise_for_status()
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])

            for ticket in tickets:
                ticket_count += 1
                ticket_id = ticket[class="hl-string">'id']
                print(fclass="hl-string">'Processing ticket {ticket_id} ({ticket_count} total)...')

                class=class="hl-string">"hl-comment"># Fetch ticket metrics for SLA and resolution time
                metrics_response = session.get(fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json')
                ticket_metrics = metrics_response.json().get(class="hl-string">'ticket_metric', {}) if metrics_response.ok else {}

                resolution_time_seconds = ticket_metrics.get(class="hl-string">'full_resolution_time_in_minutes', {}).get(class="hl-string">'business')
                if resolution_time_seconds:
                    resolution_time_seconds *= 60

                class=class="hl-string">"hl-comment"># Fetch ticket audits for events
                audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
                audits_response = session.get(audits_url)
                audits = audits_response.json().get(class="hl-string">'audits', []) if audits_response.ok else []

                first_agent_reply_sent = False

                for audit in audits:
                    audit_created_at = audit[class="hl-string">'created_at']
                    base_event = {
                        class="hl-string">'ServiceRequest': ticket_id,
                        class="hl-string">'StartTime': audit_created_at,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'AssignedAgent': get_user_name(ticket.get(class="hl-string">'assignee_id'), users_cache, session),
                        class="hl-string">'ServiceRequestType': ticket.get(class="hl-string">'type'),
                        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'CommunicationChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaTargetResolutionTime': None, class=class="hl-string">"hl-comment"># Requires parsing SLA policies, complex
                        class="hl-string">'IsSlaBreached': ticket_metrics.get(class="hl-string">'sla_breach_at') is not None,
                        class="hl-string">'ServiceRequestResolutionTime': format_duration(resolution_time_seconds)
                    }

                    for event in audit.get(class="hl-string">'events', []):
                        event_type = event.get(class="hl-string">'type')
                        class=class="hl-string">"hl-comment"># Service Request Created
                        if event_type == class="hl-string">'Create' and event.get(class="hl-string">'field_name') == class="hl-string">'id':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Created'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Initial Acknowledgment Sent (Proxy by Notification event)
                        if event_type == class="hl-string">'Notification':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Initial Acknowledgment Sent'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Request Categorized And Prioritized, Assigned, Status Changes
                        if event_type == class="hl-string">'Change':
                            field = event.get(class="hl-string">'field_name')
                            if field in [class="hl-string">'type', class="hl-string">'priority', class="hl-string">'custom_field_[your_category_field_id]']:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Categorized And Prioritized'
                                event_log.append(new_event)
                            
                            if field == class="hl-string">'assignee_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Assigned To Agent'
                                new_event[class="hl-string">'AssignedAgent'] = get_user_name(event.get(class="hl-string">'value'), users_cache, session)
                                event_log.append(new_event)

                            if field == class="hl-string">'group_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Internal Escalation Triggered'
                                event_log.append(new_event)

                            if field == class="hl-string">'status':
                                new_status = event.get(class="hl-string">'value')
                                if new_status == class="hl-string">'pending':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Information Requested From Customer'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'solved':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Resolved'
                                    event_log.append(new_event)
                                    class=class="hl-string">"hl-comment"># Satisfaction Survey Sent (Proxy: occurs after solve)
                                    solve_time = datetime.datetime.fromisoformat(audit_created_at.replace(class="hl-string">'Z', class="hl-string">'+00:00'))
                                    survey_time = solve_time + datetime.timedelta(hours=1)
                                    survey_event = new_event.copy()
                                    survey_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Survey Sent'
                                    survey_event[class="hl-string">'StartTime'] = survey_time.isoformat().replace(class="hl-string">'+00:00', class="hl-string">'Z')
                                    event_log.append(survey_event)
                                elif new_status == class="hl-string">'closed':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Closed'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'open' and event.get(class="hl-string">'previous_value') in [class="hl-string">'solved', class="hl-string">'pending']:
                                    activity = class="hl-string">'Service Request Reopened' if event.get(class="hl-string">'previous_value') == class="hl-string">'solved' else class="hl-string">'Customer Responded'
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = activity
                                    event_log.append(new_event)
                            
                            if field == class="hl-string">'satisfaction_score':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Rating Received'
                                event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># First Agent Public Reply Sent & Customer Responded
                        if event_type == class="hl-string">'Comment':
                            author_id = event.get(class="hl-string">'author_id')
                            author_details_response = session.get(fclass="hl-string">'{BASE_URL}/users/{author_id}.json')
                            author_role = author_details_response.json().get(class="hl-string">'user',{}).get(class="hl-string">'role', class="hl-string">'end-user') if author_details_response.ok else class="hl-string">'end-user'

                            if author_role in [class="hl-string">'agent', class="hl-string">'admin'] and event.get(class="hl-string">'public') and not first_agent_reply_sent:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'First Agent Public Reply Sent'
                                event_log.append(new_event)
                                first_agent_reply_sent = True

                class=class="hl-string">"hl-comment"># SLA Breach Occurred
                if ticket_metrics.get(class="hl-string">'sla_breach_at'):
                    sla_breach_time = ticket_metrics.get(class="hl-string">'sla_breach_at')
                    new_event = base_event.copy()
                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'SLA Breach Occurred'
                    new_event[class="hl-string">'StartTime'] = sla_breach_time
                    event_log.append(new_event)

            url = data.get(class="hl-string">'after_url')
            if not data.get(class="hl-string">'end_of_stream', False):
                time.sleep(1) class=class="hl-string">"hl-comment"># Be a good API citizen
            else:
                url = None

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'An error occurred: {e}')
            break

    class=class="hl-string">"hl-comment"># Write to CSV
    print(fclass="hl-string">'Writing {len(event_log)} events to {CSV_FILENAME}...')
    with open(CSV_FILENAME, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
        writer = csv.DictWriter(csvfile, fieldnames=CSV_HEADERS)
        writer.writeheader()
        class=class="hl-string">"hl-comment"># Sort events by ticket and then by time for chronological order
        sorted_log = sorted(event_log, key=lambda x: (x[class="hl-string">'ServiceRequest'], x[class="hl-string">'StartTime']))
        for row in sorted_log:
            writer.writerow(row)
    print(class="hl-string">'Extraction complete.')

if __name__ == class="hl-string">'__main__':
    main()

Fasi

Navigare su Zendesk Explore: Effettuate il login all'istanza Zendesk e aprite il prodotto Explore cliccando sull'icona del launcher del prodotto nella barra superiore e selezionando Explore.
Creare una Nuova Query: In Explore, cliccate sull'icona Queries nella barra laterale sinistra, quindi cliccate sul pulsante "New query" in alto a destra.
Selezionare il Dataset: Nella finestra "Choose a dataset", selezionate il dataset Support: Tickets. Questo dataset contiene gli attributi principali del ticket e i timestamp degli eventi chiave.
Aggiungere Metriche: Nel query builder, andate al pannello "Metrics" e cliccate su "Add". Selezionate COUNT(Tickets). Questo aiuta a convalidare il volume dei dati.
Aggiungere Attributi alle Righe: Andate al pannello "Rows" e cliccate su "Add". Aggiungete i seguenti attributi. Questi formeranno le colonne di base della vostra esportazione in formato wide.
- Ticket ID (Questo è il vostro identificatore di Case, ServiceRequest)
- Assignee name (AssignedAgent)
- Ticket type (ServiceRequestType)
- Ticket priority (Priority)
- Ticket channel (CommunicationChannel)
- SLA resolution time (SlaTargetResolutionTime)
- SLA breach status (IsSlaBreached)
- Full resolution time (min) (ServiceRequestResolutionTime)
Aggiungere i Timestamp delle Attività alle Righe: Aggiungete i seguenti attributi timestamp al pannello "Rows". Ognuno di questi rappresenta una potenziale attività. Alcune attività richiedono la creazione di un attributo calcolato personalizzato.
- Ticket created - Timestamp: Per Service Request Created e Initial Acknowledgment Sent.
- Ticket assigned - Timestamp: Per Request Assigned To Agent.
- First reply time - Timestamp: Per First Agent Public Reply Sent.
- Ticket solved - Timestamp: Per Service Request Resolved e Satisfaction Survey Sent.
- Ticket reopened - Timestamp: Per Service Request Reopened.
- Satisfaction rating received - Timestamp: Per Satisfaction Rating Received.
- Ticket closed - Timestamp: Per Service Request Closed.
Creare Attributi Calcolati Personalizzati per Altre Attività: Alcune attività si basano su modifiche di campi specifici e richiedono la creazione di attributi personalizzati per catturare il loro timestamp. Andate al menu Calculations (icona della calcolatrice) e selezionate "Standard calculated attribute". Create un attributo per ciascuna delle seguenti attività. Sarà necessario trovare i nomi esatti per i campi e i valori nella vostra istanza Zendesk.
- Nome: Timestamp - Categorized and Prioritized. Formula: IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF. Dopo averlo creato, aggiungete questo nuovo attributo al pannello "Rows" e cambiatene l'aggregatore in MIN.
- Nome: Timestamp - Info Requested. Formula: IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF. Aggiungetelo a "Rows" e impostate l'aggregatore su MIN.
- Nome: Timestamp - Customer Responded. Formula: IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF. Aggiungetelo a "Rows" e impostate l'aggregatore su MIN.
- Nome: Timestamp - Escalated. Formula: IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF. Aggiungetelo a "Rows" e impostate l'aggregatore su MIN.
- Nome: Timestamp - SLA Breach. Formula: IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF. Aggiungetelo a "Rows" e impostate l'aggregatore su MIN.
Filtrare i Dati: Andate al pannello "Filters" e cliccate su "Add". Aggiungete un filtro per Ticket created - Date e selezionate un intervallo di date appropriato, come gli ultimi 3-6 mesi, per mantenere il dataset gestibile.
Eseguire ed Esportare il Report: Cliccate su "Save" per eseguire la query. Una volta che la tabella visualizza i dati, cliccate sul pulsante "Export" e scegliete il formato preferito, come CSV o Excel.
Trasformare i Dati in Formato Event Log: Il file esportato è in un formato "wide" dove ogni riga è un ticket e ogni colonna è un timestamp di evento. È necessario trasformarlo in un formato "long" per il process mining. Utilizzate uno strumento come Microsoft Excel (con la funzione Unpivot di Power Query), Python o un altro strumento di preparazione dati.
- Per ogni riga (ticket), create più nuove righe, una per ogni colonna timestamp non vuota.
- La tabella finale dovrebbe avere colonne come ServiceRequest, ActivityName, StartTime, e gli altri attributi, che saranno duplicati per ogni attività di una data richiesta di servizio.

Configurazione

Dataset: Il dataset principale da utilizzare è Support: Tickets. Questo consente l'accesso alla maggior parte delle proprietà dei ticket e ai timestamp chiave in una singola query.
Permissions: È necessario almeno un ruolo di Editor o Admin in Zendesk Explore per creare e salvare le query.
Date Range: È fondamentale impostare un filtro per l'intervallo di date su Ticket created - Date. Si raccomanda un intervallo di dati da 3 a 6 mesi per bilanciare l'insight con le prestazioni. L'esportazione di milioni di ticket può essere lenta o fallire.
Query Filters: Si consideri di aggiungere filtri per proprietà specifiche dei ticket come Ticket brand, Ticket form o Ticket group per focalizzare l'analisi su un servizio o un team particolare.
Calculated Attributes: Questo metodo si basa fortemente sulla creazione di attributi calcolati standard per acquisire timestamp per eventi che non sono attributi predefiniti, come cambi di stato o escalation. Assicuratevi di avere i permessi per creare questi attributi.

a Query di Esempio config

This extraction is configured through the Zendesk Explore graphical user interface. There is no single script to execute. The configuration below outlines the components to add in the query builder.

**Dataset**: `Support: Tickets`

**Metrics**:
1.  `COUNT(Tickets)`

**Rows (Attributes)**:
1.  `Ticket ID`
2.  `Assignee name`
3.  `Ticket type`
4.  `Ticket priority`
5.  `Ticket channel`
6.  `SLA resolution time`
7.  `SLA breach status`
8.  `Full resolution time (min)`
9.  `MIN(Ticket created - Timestamp)`
10. `MIN(Ticket assigned - Timestamp)`
11. `MIN(First reply time - Timestamp)`
12. `MIN(Ticket solved - Timestamp)`
13. `MIN(Ticket reopened - Timestamp)`
14. `MIN(Satisfaction rating received - Timestamp)`
15. `MIN(Ticket closed - Timestamp)`
16. `MIN(Timestamp - Categorized and Prioritized)` (Custom calculated attribute)
17. `MIN(Timestamp - Info Requested)` (Custom calculated attribute)
18. `MIN(Timestamp - Customer Responded)` (Custom calculated attribute)
19. `MIN(Timestamp - Escalated)` (Custom calculated attribute)
20. `MIN(Timestamp - SLA Breach)` (Custom calculated attribute)

**Filters**:
1.  `Ticket created - Date`: Select a date range (e.g., last 180 days)

**Standard Calculated Attribute Formulas**:
*   `Timestamp - Categorized and Prioritized`: `IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Info Requested`: `IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Customer Responded`: `IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Escalated`: `IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - SLA Breach`: `IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF`

Il Suo `Template` di Dati per il Servizio Clienti

Il Suo `Template` di Dati per il Servizio Clienti

`Attributi` del Servizio Clienti.

`Attività` di Servizio Clienti.

Guide all'Estrazione

UI di Zendesk Explore per `Report` ed Esportazione `Dati`.

Fasi

Configurazione

a Query di Esempio config

Script Python che utilizza l'API REST di Zendesk Support

Fasi

Configurazione

a Query di Esempio python

API Zendesk `Incremental Exports` per `Dati` in Massa.

Fasi

Configurazione

a Query di Esempio python

Connettore `Tool ETL` di Terze Parti per Zendesk

Fasi

Configurazione

a Query di Esempio config

Pronto per iniziare?

Elimina i `Bottleneck` del Servizio Clienti, Aumenta il CSAT Ora.

Il Suo Template di Dati per il Servizio Clienti

Il Suo Template di Dati per il Servizio Clienti

Attributi del Servizio Clienti.

Attività di Servizio Clienti.

Guide all'Estrazione

UI di Zendesk Explore per `Report` ed Esportazione `Dati`.

Fasi

Configurazione

a Query di Esempio config

Script Python che utilizza l'API REST di Zendesk Support

Fasi

Configurazione

a Query di Esempio python

API Zendesk `Incremental Exports` per `Dati` in Massa.

Fasi

Configurazione

a Query di Esempio python

Connettore `Tool ETL` di Terze Parti per Zendesk

Fasi

Configurazione

a Query di Esempio config

Abbiamo a cuore la Sua privacy

Pronto per iniziare?

Elimina i Bottleneck del Servizio Clienti, Aumenta il CSAT Ora.

Il Suo `Template` di Dati per il Servizio Clienti

Il Suo `Template` di Dati per il Servizio Clienti

`Attributi` del Servizio Clienti.

`Attività` di Servizio Clienti.

Elimina i `Bottleneck` del Servizio Clienti, Aumenta il CSAT Ora.