> Miglioramento continuo dei processi > Gestione delle richieste di servizio > Zendesk Support > Template dei dati

Il template dei dati per la gestione delle richieste di assistenza

Zendesk Support

Attributi per la gestione delle richieste di assistenza(21) Attività di gestione delle richieste di assistenza(13) Guide all’estrazione(3)

Il template dei dati per la gestione delle richieste di assistenza

Questo template fornisce indicazioni dettagliate sui dati da estrarre per analizzare il processo di gestione delle richieste di assistenza in Zendesk Support. Descrive gli attributi da raccogliere, le attività principali da monitorare e le modalità pratiche per estrarre queste informazioni direttamente dal sistema. Utilizzi questa risorsa per creare un event log completo per le iniziative di Process Mining.

Attributi consigliati per un’analisi completa
Attività principali delle richieste di assistenza da monitorare
Indicazioni per estrarre i dati da Zendesk Support

Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Scarica il template

Attributi per la gestione delle richieste di assistenza

Questi sono i campi dati consigliati da includere nell’event log per un’analisi completa della gestione delle richieste di assistenza in Zendesk Support.

5 Obbligatorio 7 Consigliato 9 Facoltativo

	Nome	Descrizione
	Attività ActivityName	Nome dell’attività aziendale o dell’evento relativo a una richiesta di assistenza.
Descrizione L’attività rappresenta una fase o un evento specifico nel ciclo di vita della richiesta di assistenza, come 'Richiesta di assistenza creata', 'Richiesta assegnata a un agente' o 'Richiesta di assistenza risolta'. Le attività derivano dalle modifiche registrate nel registro di audit del ticket Zendesk, che tiene traccia degli aggiornamenti a campi quali stato, assegnatario e priorità, oltre all’aggiunta di commenti. L’analisi delle attività è alla base del Process Mining. Consente di visualizzare la mappa del processo, individuare i colli di bottiglia tra le fasi e analizzare i cicli di rilavorazione. Comprendendo la sequenza e la frequenza delle attività, le organizzazioni possono individuare inefficienze e opportunità di miglioramento del processo. Perché è importante Questo attributo definisce le fasi del processo e consente di visualizzare le mappe di processo e analizzare i flussi, le varianti e la conformità. Dove reperirli Deriva concettualmente dagli eventi registrati nell’API Zendesk Ticket Audits. Per esempio, la modifica del campo 'status' da 'new' a 'open' può essere associata a un’attività come 'Richiesta sottoposta a valutazione iniziale'. Esempi Richiesta di assistenza creataAgente riassegnatoRichiesta di assistenza risolta
	ID della richiesta di assistenza ServiceRequestId	Identificativo univoco di ogni ticket di richiesta di assistenza in Zendesk.
Descrizione L’ID della richiesta di assistenza, spesso chiamato ID del ticket in Zendesk, è la chiave primaria di ogni caso. Collega tutte le attività, i commenti e le modifiche di stato correlate, dalla creazione della richiesta fino alla sua chiusura. In questo modo è possibile ricostruire l’intero ciclo di vita di una singola richiesta. Nell’analisi di Process Mining, questo attributo è fondamentale: definisce il caso e consente di ricostruire i flussi di processo, individuare le varianti e calcolare metriche a livello di caso, come il tempo di ciclo. Ogni evento del set di dati deve essere associato a un ID della richiesta di assistenza, così da comprenderne il contesto nel processo complessivo. Perché è importante È l’identificativo essenziale del caso, che collega tutti gli eventi del percorso di una richiesta di assistenza e permette di analizzare il processo dall’inizio alla fine. Dove reperirli API Zendesk Tickets, campo 'id'. Esempi 102451024610247
	Ora di inizio EventTimestamp	Data e ora esatte in cui si è verificata l’attività.
Descrizione La data e ora dell’evento, o ora di inizio, registra il momento esatto in cui si è svolta un’attività. Per esempio, indica quando è stato assegnato un agente, quando è stata inviata una risposta pubblica o quando lo stato del ticket è passato a 'Resolved'. Questi dati temporali provengono dal registro di audit di ciascun ticket Zendesk. Questo attributo è essenziale per qualsiasi analisi basata sul tempo: serve a ordinare gli eventi cronologicamente, calcolare la durata tra le attività, misurare i tempi di attesa e analizzare il tempo di ciclo complessivo del caso. È inoltre fondamentale per individuare i colli di bottiglia e valutare i risultati rispetto a obiettivi temporali come gli SLA. Perché è importante Questo timestamp ordina gli eventi cronologicamente ed è essenziale per tutte le analisi di durata, prestazioni e colli di bottiglia. Dove reperirli API Zendesk Ticket Audits, campo 'created_at' di ciascun evento di audit. Esempi 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
	Sistema di origine SourceSystem	Indica il sistema da cui sono stati estratti i dati.
Descrizione Questo attributo specifica l’origine dei dati delle richieste di assistenza. In questa vista del processo, il valore è sempre 'Zendesk Support', che identifica il sistema di riferimento per tutte le attività di gestione dell’assistenza. Negli ambienti con più sistemi integrati, questo campo è fondamentale per ricostruire la provenienza dei dati e risolvere i problemi. Permette di circoscrivere correttamente le analisi al sistema previsto e di distinguere i dati quando vengono uniti quelli provenienti da fonti diverse. Perché è importante Identifica il sistema di origine dei dati, consentendo di ricostruirne la provenienza e di evitare confusione quando si combinano dati provenienti da più sistemi. Dove reperirli È un valore statico ('Zendesk Support'), aggiunto durante l’estrazione e la trasformazione dei dati. Esempi Zendesk Support
	Ultimo aggiornamento dei dati LastDataUpdate	Timestamp che indica l’ultimo aggiornamento dei dati dal sistema di origine.
Descrizione Questo attributo registra la data e l’ora dell’estrazione più recente dei dati da Zendesk Support. Indica quanto sono aggiornati i dati analizzati e permette di sapere a quale periodo si riferisce la vista del processo. Questa informazione è essenziale per il monitoraggio continuo e le Dashboard: consente ad analisti e utenti aziendali di capire se stanno consultando dati quasi in tempo reale o una fotografia di un periodo precedente, aspetto che incide sulla validità delle conclusioni. Perché è importante Fornisce un’indicazione essenziale sull’aggiornamento dei dati, mostrando quanto è recente l’analisi. Dove reperirli È un campo di metadati generato e aggiunto al set di dati al momento dell’estrazione. Esempi 2023-10-27T08:00:00Z
	Canale della richiesta RequestChannel	Canale attraverso cui è stata inviata la richiesta di assistenza, per esempio e-mail, modulo web o telefono.
Descrizione Questo attributo identifica il canale da cui proviene la richiesta di assistenza. Zendesk registra come è stato creato un ticket, per esempio tramite e-mail, portale web, integrazione API, chat o altri canali. In questo modo è possibile conoscere la modalità di interazione scelta dal cliente. Il canale della richiesta è una dimensione di analisi utile. La Dashboard 'Efficienza dei canali di richiesta' consente di confrontare i tempi di risoluzione, i livelli di soddisfazione e i tassi di rilavorazione dei diversi canali. Queste informazioni possono aiutare le aziende a ottimizzare i canali di assistenza e a indirizzare gli utenti verso quelli più efficienti. Perché è importante Aiuta ad analizzare l’efficienza e i risultati dei diversi canali di assistenza clienti, consentendo di definire interventi mirati. Dove reperirli API Zendesk Tickets, oggetto 'via' e relativa proprietà 'channel'. Esempi webe-mailapichat
	Nome dell’agente AgentName	Nome dell’agente assegnato alla richiesta di assistenza al momento dell’evento.
Descrizione Questo attributo identifica l’agente di assistenza responsabile della gestione della richiesta. L’agente assegnato può cambiare più volte durante il ciclo di vita del ticket; il campo indica chi era responsabile in ciascuna fase. Il nome dell’agente è fondamentale per l’analisi delle prestazioni: consente di filtrare e segmentare i dati per valutare la distribuzione del carico di lavoro, i tempi di risoluzione per agente e la frequenza delle riassegnazioni. Queste informazioni contribuiscono alla creazione della Dashboard Prestazioni di agenti e team e aiutano a comprendere il contributo dei singoli all’efficienza complessiva del processo. Perché è importante Questo attributo è essenziale per analizzare le prestazioni degli agenti, la distribuzione del carico di lavoro e l’impatto delle riassegnazioni sui tempi di risoluzione. Dove reperirli API Zendesk Users, unendo il valore 'assignee_id' della risposta dell’API Tickets. Esempi Jane DoeJohn SmithEmily Jones
	Priorità della richiesta RequestPriority	Livello di priorità assegnato alla richiesta di assistenza, per esempio Bassa, Normale, Alta o Urgente.
Descrizione La priorità della richiesta indica il livello di urgenza di una richiesta di assistenza. Spesso determina i tempi di risoluzione previsti e le politiche SLA applicate al ticket. Può essere impostata inizialmente dal sistema o dall’utente e modificata da un agente durante il ciclo di vita del ticket. Questo attributo è fondamentale per la segmentazione e l’analisi delle cause profonde. Aiuta a verificare se i ticket ad alta priorità vengono risolti più rapidamente di quelli a bassa priorità ed è una dimensione essenziale per le Dashboard 'Tendenze degli inoltri delle richieste di assistenza' e 'Rispetto degli SLA'. Perché è importante Consente di segmentare le richieste in base all’urgenza, un aspetto fondamentale per analizzare il rispetto degli SLA e garantire una gestione tempestiva dei problemi critici. Dove reperirli API Zendesk Tickets, campo 'priority'. Esempi BassaNormaleAltaUrgente
	Stato della richiesta RequestStatus	Stato della richiesta di assistenza al momento dell’evento, per esempio Nuova, Aperta o In attesa.
Descrizione Lo stato della richiesta indica la condizione del ticket in un determinato momento. Zendesk prevede diversi stati standard, come New, Open, Pending, On-hold, Solved e Closed, che descrivono l’avanzamento della richiesta nel suo ciclo di vita. Le modifiche a questo campo sono tra i principali eventi che generano attività nel registro degli eventi. Analizzare il tempo trascorso nei diversi stati è una parte fondamentale dell’analisi dei colli di bottiglia. Aiuta a individuare i ticket che restano bloccati, per esempio troppo a lungo nello stato 'Pending' o 'On-hold'. Comprendere le transizioni di stato è inoltre essenziale per individuare i cicli di rilavorazione. Perché è importante Monitorare lo stato è fondamentale per comprendere l’avanzamento della richiesta e individuare quanto tempo viene trascorso in attesa o in attività. Dove reperirli API Zendesk Tickets, campo 'status'. Esempi NuovoApertoIn attesaRisoltoChiuso
	Tag del ticket TicketTags	Elenco dei tag applicati alla richiesta di assistenza per classificarla e instradarla.
Descrizione Gli agenti possono aggiungere manualmente tag ai ticket, oppure questi possono essere applicati automaticamente tramite regole aziendali. I tag sono etichette flessibili che aggiungono contesto o categorie non previste da campi standard come Tipo o Priorità. I tag sono un attributo estremamente versatile per l’analisi di Process Mining. Possono servire a filtrare scenari specifici, monitorare flussi di lavoro personalizzati o individuare le cause profonde. Per esempio, il tag 'VIP' può essere usato per analizzare il processo relativo ai clienti più importanti, mentre 'product_bug' può aiutare a ricostruire il ciclo di vita delle segnalazioni di difetti. Perché è importante Offre un modo flessibile per segmentare i dati e analizzare in profondità sottoprocessi specifici o attributi dei ticket non registrati in altri campi. Dove reperirli API Zendesk Tickets, campo 'tags'. È un array di stringhe. Esempi richiesta_informazioni_commercialiproblema_fatturazionerichiesta_nuova_funzionalitàcliente_vip
	Team assegnato AssignedTeam	Team o gruppo di assistenza assegnato alla richiesta.
Descrizione Questo attributo indica quale team o gruppo dell’organizzazione di assistenza è responsabile della richiesta. In Zendesk, questi team sono denominati 'Groups'. Spesso i ticket vengono assegnati prima a un gruppo e poi a un singolo agente. L’analisi per team assegnato è essenziale per comprendere le prestazioni e il carico di lavoro dei singoli team. Aiuta a capire quali team gestiscono determinati tipi di richieste, quali sono i loro tempi medi di risoluzione e quanto rispettano gli SLA. È una dimensione di analisi fondamentale per la Dashboard Prestazioni di agenti e team. Perché è importante Consente di analizzare le prestazioni dei team, bilanciare il carico di lavoro e valutare l’efficienza dell’instradamento tra i diversi gruppi di assistenza. Dove reperirli API Zendesk Groups, unendo il valore 'group_id' della risposta dell’API Tickets. Esempi Assistenza di livello 1Assistenza tecnicaFatturazione
	Tipo di servizio ServiceType	Categoria o tipo della richiesta di assistenza, per esempio incidente, domanda, problema o attività.
Descrizione Il tipo di servizio classifica la natura della richiesta di assistenza. Zendesk utilizza un campo 'type' per distinguere i diversi tipi di interazione con il supporto. Questa classificazione iniziale aiuta a instradare il ticket al team corretto e ad applicare i processi appropriati. Questo attributo è essenziale per filtrare e confrontare i dati. Consente agli analisti di esaminare i flussi di processo dei diversi tipi di richiesta, che spesso seguono percorsi di risoluzione e SLA molto diversi. È una dimensione fondamentale per la Dashboard Prestazioni di agenti e team, che permette di capire chi gestisce meglio specifiche tipologie di richieste. Perché è importante Classifica le richieste e consente di analizzare separatamente processi diversi, come quelli relativi agli incidenti e alle domande, che seguono percorsi distinti. Dove reperirli API Zendesk Tickets, campo 'type'. Esempi domandaincidenteproblemaattività
	Nome dei criteri SLA SlaPolicyName	Nome dei criteri dell’accordo sul livello di servizio (SLA) applicati alla richiesta.
Descrizione Questo attributo identifica la specifica policy SLA che stabilisce i tempi previsti di risposta e risoluzione per la richiesta di assistenza. In genere, la policy dipende da fattori quali la priorità e il tipo della richiesta o il livello di abbonamento del cliente. Conoscere la policy SLA applicata è essenziale per la Dashboard «Analisi del rispetto e delle violazioni degli SLA». Questo dato fornisce il contesto necessario per valutare le prestazioni, poiché ogni policy può prevedere obiettivi diversi. Consente così di verificare in modo equo e accurato se un ticket ha rispettato gli obiettivi del livello di servizio a esso assegnati. Perché è importante Fornisce il contesto per l’analisi SLA, identificando gli obiettivi rispetto ai quali è stata valutata una richiesta e consentendo di generare report accurati sulla conformità. Dove reperirli API Zendesk Ticket Metrics. I dati SLA sono spesso associati alle metriche del ticket. Esempi Urgente - risposta entro 1 oraStandard - risoluzione entro 24 oreSLA per clienti premium
	Nome del richiedente RequestorName	Nome dell’utente finale o del cliente che ha inviato la richiesta di assistenza.
Descrizione Questo attributo identifica la persona che ha avviato la richiesta di assistenza. Collegare la richiesta a un cliente specifico offre una visione del processo di assistenza incentrata sull’utente. Nell’analisi del processo, il richiedente può essere usato per individuare schemi ricorrenti relativi a singoli clienti o segmenti di clientela. Per esempio, è possibile verificare se alcuni clienti registrano tempi di risoluzione più lunghi o un maggior numero di rilavorazioni, circostanze che potrebbero indicare problemi con il prodotto o il servizio utilizzato. Perché è importante Collega il processo al cliente e consente di analizzare problemi specifici, richieste ricorrenti e livelli di soddisfazione. Dove reperirli API Zendesk Users, unendo il valore 'requester_id' della risposta dell’API Tickets. Esempi Alice JohnsonBob WilliamsCharlie Brown
	Numero di riassegnazioni dell’agente AgentReassignmentCount	Numero totale di volte in cui una richiesta è stata riassegnata da un agente a un altro.
Descrizione Questo attributo conta quante volte cambia il campo 'assignee_id' di un ticket. Un numero elevato di riassegnazioni per un singolo ticket può indicare diversi problemi di processo, ad esempio un instradamento iniziale errato, una conoscenza insufficiente da parte dell’agente o una richiesta troppo complessa per essere gestita da una sola persona. È una metrica fondamentale per misurare l’efficienza del processo e contribuisce direttamente al KPI «Tasso di riassegnazione degli agenti». Analizzando i casi con molte riassegnazioni è possibile individuare opportunità per migliorare le regole di instradamento, la formazione degli agenti o le risorse della base di conoscenza, così che i ticket arrivino più rapidamente alla persona giusta. Perché è importante Aiuta a quantificare i passaggi interni e a individuare gli attriti nel processo, poiché un tasso elevato di riassegnazione spesso comporta ritardi e inefficienze. Dove reperirli Si calcola contando, per ogni ticket, le modifiche di 'assignee_id' nell’API Zendesk Ticket Audits. Esempi 013
	Ora di fine EndTime	Data e ora esatte in cui è stata completata l’attività.
Descrizione L’ora di fine indica il completamento di un’attività. Per molti eventi in Zendesk, la durata è istantanea e quindi coincide con l’ora di inizio. Per le attività basate sullo stato, come 'Richiesta messa in sospeso', l’ora di fine corrisponde invece al momento in cui il ticket viene tolto dalla sospensione. Questo attributo è essenziale per calcolare la durata delle singole attività, un dato importante per l’analisi dei colli di bottiglia. Confrontando l’ora di inizio e quella di fine di un’attività, è possibile misurarne direttamente il tempo di elaborazione e individuare le fasi che richiedono più tempo. Perché è importante Consente di calcolare la durata delle singole attività, un dato fondamentale per individuare i colli di bottiglia del processo e misurare l’efficienza di ogni fase. Dove reperirli Per gli eventi puntuali, spesso coincide con StartTime. Per la durata degli stati, corrisponde al timestamp dell’evento successivo che modifica lo stato. Esempi 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
	Organizzazione del richiedente RequestorOrganization	Organizzazione o azienda a cui appartiene il richiedente.
Descrizione Questo attributo collega la richiesta di assistenza a una specifica organizzazione cliente. È particolarmente rilevante nei contesti B2B, in cui gli accordi sul livello di servizio e i contratti di assistenza sono spesso definiti a livello di organizzazione. L’analisi dei dati per organizzazione offre una visione delle prestazioni dell’assistenza a livello aziendale. Può aiutare a individuare le organizzazioni che generano molti ticket, riscontrano problemi ricorrenti o registrano bassi livelli di soddisfazione. Queste informazioni sono utili per la gestione dei clienti e per individuare tendenze più ampie sul loro stato. Perché è importante Consente di analizzare l’assistenza B2B raggruppando le richieste per azienda, un aspetto fondamentale per gestire le relazioni con i clienti e gli SLA a livello organizzativo. Dove reperirli API Zendesk Organizations, unendo il valore 'organization_id' della risposta dell’API Tickets. Esempi Acme CorporationGlobal Tech Inc.Innovate Solutions
	Rielaborazione IsRework	Indicatore vero se la richiesta di assistenza è stata riaperta dopo essere stata risolta.
Descrizione Questo indicatore booleano identifica i casi che hanno richiesto una rielaborazione. In genere, una richiesta di assistenza è considerata una rielaborazione quando il suo stato passa da «Risolto» a uno stato aperto, segnalando che la soluzione iniziale non era sufficiente e che il cliente ha dovuto ricontattare l’assistenza per lo stesso problema. Questo attributo è essenziale per calcolare il KPI «Tasso di rielaborazione delle richieste di assistenza» e per la Dashboard «Analisi delle rielaborazioni e delle riaperture». Segnalando i casi di rielaborazione, gli analisti possono isolare i flussi di processo inefficienti, individuare le cause profonde delle riaperture e intervenire per migliorare la risoluzione al primo contatto. Perché è importante Individua i casi in cui la risoluzione non è stata definitiva, evidenziando problemi di qualità ed efficienza che incidono direttamente sulla soddisfazione dei clienti. Dove reperirli Si calcola analizzando la sequenza degli stati di un ticket nell’API Zendesk Ticket Audits. Il passaggio da 'solved' a 'open' indica una rielaborazione. Esempi truefalse
	Risolto al primo contatto IsFirstContactResolution	Indicatore che segnala se la richiesta è stata risolta dal primo agente assegnato, senza riassegnazioni né risposte da parte del richiedente.
Descrizione La risoluzione al primo contatto (FCR) è una metrica fondamentale: indica che il problema del cliente è stato risolto in un’unica interazione. Questo attributo calcolato è un indicatore booleano, impostato su vero se il ticket è stato risolto dal primo agente a cui è stato assegnato, senza riassegnazioni e con una sola risposta dell’agente. L’attributo contribuisce direttamente al KPI «Tasso di risoluzione al primo contatto». Analizzare le caratteristiche dei casi risolti al primo contatto può offrire indicazioni utili per migliorare il processo. Al contrario, l’analisi dei casi che non raggiungono questo risultato può mettere in luce opportunità di miglioramento nella formazione degli agenti, negli articoli della base di conoscenza o nella valutazione iniziale delle richieste. Perché è importante Misura la capacità di risolvere i problemi in modo efficiente con un’unica interazione, un fattore che contribuisce in misura significativa sia alla soddisfazione dei clienti sia all’efficienza operativa. Dove reperirli È un attributo calcolato complesso, che richiede di analizzare l’event log di un ticket per verificare le riassegnazioni degli agenti e il numero di risposte pubbliche inviate dagli agenti. Esempi truefalse
	SLA violato IsSlaBreached	Indicatore che segnala se la richiesta di assistenza ha superato uno o più obiettivi SLA.
Descrizione Questo attributo è un indicatore booleano o categoriale che mostra l’esito SLA di un ticket. Può assumere valori come «Rispettato», «Violato» o «Attivo». Il valore si determina confrontando i tempi effettivi di risposta o risoluzione con gli obiettivi definiti nella policy SLA applicata. È un attributo fondamentale per la Dashboard «Analisi del rispetto e delle violazioni degli SLA». Consente di contare e visualizzare facilmente i ticket conformi e quelli non conformi. È quindi possibile concentrarsi sulle caratteristiche dei ticket con SLA violato per individuare le cause profonde, come tempi di attesa lunghi o riassegnazioni frequenti. Perché è importante Misura direttamente il rispetto degli impegni sul livello di servizio, un indicatore essenziale della qualità del servizio e della soddisfazione dei clienti. Dove reperirli Deriva dall’API Zendesk Ticket Metrics, che fornisce informazioni sullo stato SLA di ciascun ticket. Esempi RispettatoViolatoAttivo
	Valutazione della soddisfazione SatisfactionRating	Punteggio di soddisfazione fornito dal richiedente dopo la risoluzione del ticket.
Descrizione Questo attributo registra il feedback del cliente sulla propria esperienza di assistenza, in genere raccolto tramite un sondaggio dopo che il ticket è stato contrassegnato come risolto. Le valutazioni più comuni sono 'Buono' o 'Negativo', talvolta accompagnate da un commento. La valutazione della soddisfazione è una metrica fondamentale dei risultati. Correlare gli schemi di processo ai punteggi di soddisfazione può rivelare quali comportamenti del processo contribuiscono a rendere i clienti soddisfatti o insoddisfatti. Per esempio, l’analisi potrebbe mostrare una forte correlazione tra un elevato tasso di riassegnazione o tempi di risoluzione lunghi e valutazioni negative. Perché è importante Collega direttamente l’esecuzione del processo ai risultati per i clienti e aiuta a individuare i comportamenti che favoriscono la soddisfazione. Dove reperirli API Zendesk Tickets, campo 'satisfaction_rating.score' o 'satisfaction_rating.reason'. Esempi BuonoNegativoProposto

Obbligatorio Consigliato Facoltativo

Attività di gestione delle richieste di assistenza

Questi sono i passaggi e le tappe principali da registrare nell’event log per individuare con precisione il processo di gestione delle richieste di assistenza.

7 Consigliato 6 Facoltativo

	Attività	Descrizione
	Obiettivo SLA non rispettato	Questa attività indica il momento in cui una richiesta di assistenza non rispetta un obiettivo SLA definito, come il tempo per la prima risposta o quello di risoluzione. Zendesk registra un evento esplicito quando un obiettivo non viene raggiunto.
Perché è importante È un evento fondamentale per il monitoraggio della conformità e un dato essenziale per il KPI del tasso di rispetto degli SLA. Individua i casi in cui gli impegni di servizio non vengono rispettati. Dove reperirli Acquisito dall’evento 'SLABreach' nei dati degli eventi del ticket Zendesk o nel registro di audit. L’evento specifica quale metrica SLA non è stata rispettata. Acquisizione Individuato tramite l’evento esplicito 'SLABreach' nei dati del ticket. Tipo di evento explicit
	Richiesta assegnata a un agente	Questa attività si verifica quando una richiesta di assistenza viene assegnata per la prima volta a un agente specifico. Si deduce da un evento «Change» nel registro di audit del ticket, in cui il campo «assignee_id» viene valorizzato partendo da null o da un ID di gruppo.
Perché è importante Segna l’inizio del lavoro attivo da parte di un agente ed è fondamentale per misurare i tempi di prima risposta, il ritardo nella prima assegnazione e la distribuzione del carico di lavoro degli agenti. Dove reperirli Si deduce dal primo evento «Change» relativo al campo «assignee_id» nel registro di audit del ticket, in cui viene impostato l’ID di un utente specifico. Acquisizione Si deduce dal primo evento di modifica che imposta il campo «assignee_id» su un agente. Tipo di evento inferred
	Richiesta di assistenza chiusa	Indica la chiusura definitiva della richiesta di assistenza. Dopo un periodo prestabilito nello stato 'solved', il ticket passa automaticamente allo stato 'closed' e non può più essere riaperto.
Perché è importante Questa attività segna la conclusione definitiva del processo di assistenza e fornisce il punto finale per calcolare la durata complessiva del caso. Dove reperirli Dedotto da un evento 'Change' relativo al campo 'status' nel registro di audit del ticket, quando il nuovo valore è 'closed'. Acquisizione Dedotto da un evento 'Change' nel registro di audit in cui lo stato passa a 'closed'. Tipo di evento inferred
	Richiesta di assistenza creata	Segna l’inizio del ciclo di vita della richiesta di assistenza, quando il richiedente invia un nuovo ticket tramite uno qualsiasi dei canali disponibili. L’evento viene registrato come «Create» nel registro di audit dei ticket di Zendesk e fornisce un orario di inizio preciso per il processo.
Perché è importante Questa attività è l’evento di inizio principale di ogni richiesta di assistenza ed è quindi essenziale per calcolare i tempi di ciclo complessivi e analizzare i volumi delle richieste ricevute. Dove reperirli Viene registrata come tipo di evento «Create» nel registro di audit dei ticket di Zendesk. La data e l’ora dell’evento corrispondono al momento in cui è stato creato il ticket della richiesta di assistenza. Acquisizione Rilevata direttamente dall’evento «Create» nel registro di audit del ticket. Tipo di evento explicit
	Richiesta di assistenza riaperta	Si verifica quando il richiedente risponde a una richiesta con stato 'solved' e lo stato torna automaticamente a 'open'. Significa che la soluzione proposta non è stata sufficiente.
Perché è importante Questa attività è il principale indicatore di rilavorazione. Analizzarne la frequenza aiuta a misurare la qualità delle risoluzioni e a individuare le cause dell’insoddisfazione dei clienti. Dove reperirli Dedotto da un evento 'Change' relativo al campo 'status' nel registro di audit del ticket, in cui il valore precedente era 'solved' e quello nuovo è 'open'. Acquisizione Dedotto da una modifica dello stato da 'solved' a 'open'. Tipo di evento inferred
	Richiesta di assistenza risolta	Questa attività indica il momento in cui un agente ha fornito una soluzione e ha modificato lo stato del ticket in 'solved'. Dal punto di vista dell’agente, la richiesta è completa, ma il richiedente può ancora riaprirla.
Perché è importante È una tappa importante, che segna la fine del lavoro attivo dell’agente. Il tempo necessario per raggiungere questo stato è una misura fondamentale dell’efficienza di risoluzione. Dove reperirli Dedotto da un evento 'Change' relativo al campo 'status' nel registro di audit del ticket, quando il nuovo valore è 'solved'. Acquisizione Dedotto da un evento 'Change' nel registro di audit in cui lo stato passa a 'solved'. Tipo di evento inferred
	Risposta pubblica inviata	Questa attività indica qualsiasi comunicazione inviata da un agente al richiedente. È registrata come evento esplicito 'Comment' nei dati del ticket Zendesk, con l’attributo 'public' impostato su true.
Perché è importante Questi eventi sono fondamentali per analizzare la frequenza delle comunicazioni, misurare i tempi di risposta degli agenti e individuare quante interazioni sono necessarie per risolvere una richiesta. Dove reperirli Si tratta di un evento esplicito 'Comment' nei dati del ticket. I dettagli dell’evento includono l’attributo 'public: true', che lo distingue dalle note interne. Acquisizione Acquisito dagli eventi 'Comment' del ticket in cui il flag 'public' è impostato su true. Tipo di evento explicit
	Agente riassegnato	Indica il trasferimento della responsabilità di una richiesta di assistenza da un agente a un altro. Si deduce da qualsiasi evento 'Change' successivo relativo al campo 'assignee_id', dopo la prima assegnazione.
Perché è importante Monitorare le riassegnazioni è fondamentale per calcolare il KPI del tasso di riassegnazione degli agenti, che aiuta a individuare inefficienze del processo, instradamenti errati o lacune nelle conoscenze. Dove reperirli Dedotto dagli eventi 'Change' relativi al campo 'assignee_id' nel registro di audit del ticket, escludendo il primo evento di assegnazione. Acquisizione Dedotto dal secondo evento 'Change' e da quelli successivi relativi al campo 'assignee_id'. Tipo di evento inferred
	Nota interna aggiunta	Un agente ha aggiunto una nota o un commento interno alla richiesta di assistenza, visibile solo agli altri agenti. L’evento è registrato come 'Comment' con l’attributo 'public' impostato su false.
Perché è importante Monitorare le note interne offre indicazioni sulla collaborazione tra agenti o team, che può causare ritardi oppure favorire una risoluzione efficiente dei problemi. Dove reperirli Si tratta di un evento esplicito 'Comment' nei dati del ticket. I dettagli dell’evento includono l’attributo 'public: false', che indica che si tratta di una nota interna. Acquisizione Acquisito dagli eventi 'Comment' del ticket in cui il flag 'public' è impostato su false. Tipo di evento explicit
	Obiettivo SLA applicato	Indica il momento in cui viene applicata al ticket della richiesta di assistenza una politica relativa agli accordi sui livelli di servizio (SLA). L’evento viene registrato esplicitamente quando le proprietà del ticket soddisfano le condizioni di una politica SLA attiva.
Perché è importante Monitorare il momento in cui viene applicato un SLA è essenziale per verificare la conformità, analizzare le possibili violazioni e comprendere i tempi di servizio previsti per i diversi tipi di richiesta. Dove reperirli Rilevata dall’evento «SLAPolicyApplied» negli eventi del ticket o nel registro di audit di Zendesk. L’evento specifica quale politica è stata applicata. Acquisizione Individuata tramite l’evento esplicito «SLAPolicyApplied» nei dati del ticket. Tipo di evento explicit
	Priorità modificata	Indica che il livello di priorità della richiesta di assistenza, ad esempio «Bassa», «Normale», «Alta» o «Urgente», è stato aggiornato. La modifica viene registrata come evento «Change» sul campo «priority» nel registro di audit del ticket.
Perché è importante L’analisi delle variazioni di priorità aiuta a individuare le richieste che diventano più urgenti nel tempo e a valutare se le priorità vengono gestite in modo efficace. Dove reperirli Registrato come evento 'Change' nel campo 'priority' del registro di audit dei ticket Zendesk, con indicazione del valore precedente e di quello nuovo. Acquisizione Dedotto dagli eventi 'Change' relativi al campo 'priority' nel registro di audit. Tipo di evento inferred
	Richiesta inoltrata a un livello superiore	Indica l’inoltro formale di una richiesta di assistenza a un livello di supporto superiore, a un altro team o alla direzione. In genere si deduce da una modifica del gruppo assegnato al ticket o di un campo personalizzato usato per registrare gli inoltri.
Perché è importante Monitorare gli inoltri aiuta a individuare le richieste complesse, le esigenze di formazione degli agenti di primo livello e i problemi sistemici che richiedono un intervento di livello superiore. Dove reperirli Non è un evento standard. Deve essere dedotto da un evento 'Change' relativo al campo 'group_id' che assegna il ticket a un gruppo di escalation, oppure dalla modifica di un campo personalizzato del ticket usato per monitorare gli inoltri. Acquisizione Dedotto dalla modifica di 'group_id' o di un campo personalizzato 'escalation'. Tipo di evento inferred
	Richiesta messa in sospeso	Questa attività si verifica quando lo stato della richiesta di assistenza passa a 'on-hold', in genere perché l’agente è in attesa di informazioni dal richiedente o da terzi. Si deduce da un evento di modifica dello stato.
Perché è importante Consente di isolare e misurare i tempi di attesa che non dipendono direttamente dal team di assistenza, offrendo una visione più accurata del tempo di gestione degli agenti. Dove reperirli Dedotto da un evento 'Change' relativo al campo 'status' nel registro di audit del ticket, quando il nuovo valore è 'on-hold'. Acquisizione Dedotto da un evento 'Change' nel registro di audit in cui lo stato passa a 'on-hold'. Tipo di evento inferred

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da Zendesk Support

Passaggi

Accedere a Zendesk Explore e creare il report principale: Apra l’icona dei prodotti Zendesk nella barra in alto a destra e selezioni Explore. In Explore, faccia clic sull’icona Queries a sinistra, quindi su New query. Selezioni il set di dati Support: Ticket updates come origine.
Configurare metriche e attributi per gli eventi dei ticket: Nel generatore di query, aggiunga una metrica come COUNT(Tickets) per visualizzare i dati. Nella sezione Rows, aggiunga i seguenti attributi: Ticket ID, Update - Timestamp, Updater name, Update - Field name, Update - Previous value, Update - New value, Assignee name, Nome del Group, Ticket priority, Ticket status, Submission channel, Ticket type e Ticket tags.
Creare un attributo calcolato per ActivityName: Per convertire gli aggiornamenti grezzi in attività significative, crei un attributo calcolato standard. Apra il menu Calculations, identificato dall’icona della calcolatrice, selezioni Standard calculated attribute e lo denomini ActivityName. Incolli nella casella della formula la logica riportata nella sezione Query. La formula associa i diversi eventi di aggiornamento dei ticket ai nomi delle attività richiesti.
Rifinire e filtrare il report principale: Aggiunga il nuovo attributo ActivityName alla sezione Rows. Imposti un filtro su questo attributo per escludere i valori (null) e quelli indesiderati generati dal sistema, così da ripulire il set di dati. Aggiunga anche un filtro per Ticket created - Date, limitando la query a un periodo gestibile, per esempio gli ultimi 6 mesi.
Creare un secondo report per gli eventi SLA: Crei un’altra query e selezioni il set di dati Support: SLAs. Questo passaggio è necessario perché il set di dati Ticket updates non include gli eventi SLA.
Configurare il report SLA: Nella query SLA, aggiunga COUNT(SLA tickets) alla sezione Metrics. Nella sezione Rows, aggiunga Ticket ID, SLA policy, SLA target, SLA updated - Timestamp, SLA status e Updater name. L’attività verrà dedotta dal valore SLA status durante la trasformazione.
Esportare entrambi i set di dati: Esegua entrambe le query nell’interfaccia di Explore. Una volta generate le tabelle, faccia clic sul pulsante Export e scelga il formato CSV. Otterrà due file CSV distinti.
Unire e trasformare i dati: Combini i due file CSV con uno strumento per fogli di calcolo come Microsoft Excel o un linguaggio di scripting come Python. L’obiettivo è creare un unico Event Log. Nel file SLA, dovrà creare la colonna ActivityName: se SLA status è Attivo, l’attività è «Obiettivo SLA applicato»; se SLA status è Breached, l’attività è «Obiettivo SLA superato». Utilizzi SLA updated - Timestamp come EventTimestamp.
Uniformare le intestazioni delle colonne: Nel file finale unito, rinomini le colonne in modo che rispettino il formato richiesto per il Process Mining. Per esempio, rinomini Ticket ID in ServiceRequestId, Update - Timestamp in EventTimestamp e Updater name in AgentName.
Aggiungere colonne statiche e completare il file: Aggiunga due colonne al file CSV finale. Inserisca «Zendesk» in SourceSystem e l’ora di esecuzione dell’esportazione in LastDataUpdate. Il file è ora pronto per il caricamento.

Configurazione

Piano Zendesk: per creare query e attributi personalizzati è necessario un piano Zendesk Support che includa Zendesk Explore Professional o Enterprise.
Autorizzazioni: deve essere un agente autorizzato a creare e modificare query in Explore. In genere, si tratta di un amministratore o di un agente con un ruolo personalizzato.
Selezione dei dataset: questo metodo richiede la creazione di due report distinti basati su dataset diversi: Support: Ticket updates per gli eventi generali e Support: SLAs per gli eventi specifici degli SLA.
Filtro per intervallo di date: è fondamentale applicare un filtro per intervallo di date, ad esempio su Ticket created - Date, per mantenere gestibile il volume dei dati. Per l’analisi iniziale si consiglia un intervallo da 3 a 6 mesi.
Attributi calcolati: la logica per ricavare i nomi delle attività viene gestita tramite un attributo calcolato personalizzato complesso in Explore. Verifichi che la formula sia impostata correttamente per evitare errori nei risultati.
Volume dei dati: l’interfaccia Zendesk Explore e la funzione di esportazione possono essere lente o andare in timeout con dataset molto grandi. Per estrazioni che coprono più di un anno o milioni di ticket, è consigliabile suddividere l’esportazione in intervalli di tempo più brevi.

Query di esempio config

This method uses the Zendesk Explore UI, where queries are built visually. The following describes the configuration for the two required reports.

**Report 1: Ticket Events Configuration**
* **Dataset**: `Support: Ticket updates`
* **Metrics**: `COUNT(Tickets)`
* **Rows**:
  * `Ticket ID`
  * `ActivityName` (This is the custom calculated attribute defined below)
  * `Update - Timestamp`
  * `Updater name`
  * `Assignee name`
  * `Group name`
  * `Ticket priority`
  * `Ticket status`
  * `Submission channel`
  * `Ticket type`
  * `Ticket tags`
* **Standard Calculated Attribute (`ActivityName`) Formula**:
```
IF [Update - Field name] = "assignee_id" AND ([Update - Previous value] = "" OR [Update - Previous value] = NULL) THEN
    "Request Assigned to Agent"
ELIF [Update - Field name] = "assignee_id" AND [Update - Previous value] != "" AND [Update - Previous value] != NULL THEN
    "Agent Reassigned"
ELIF [Update - Field name] = "group_id" THEN
    "Request Escalated"
ELIF [Update - Field name] = "priority" AND [Update - New value] != [Update - Previous value] THEN
    "Priority Changed"
ELIF [Update - Field name] = "status" AND [Update - New value] = "hold" THEN
    "Request Placed On-Hold"
ELIF [Update - Field name] = "status" AND [Update - New value] = "solved" THEN
    "Service Request Resolved"
ELIF [Update - Field name] = "status" AND [Update - New value] = "closed" THEN
    "Service Request Closed"
ELIF [Update - Field name] = "status" AND [Update - New value] = "open" AND [Update - Previous value] = "solved" THEN
    "Service Request Reopened"
ELIF [Update - Field name] = "requester_id" AND [Update - Previous value] = NULL THEN
    "Service Request Created"
ELSE
    NULL
ENDIF
```
* **Note on Comment Activities**: Capturing `Public Reply Sent` and `Internal Note Added` from the `Ticket updates` dataset is not reliably possible as the public vs. internal distinction is often missing. For these events, creating a third report on the `Support: Comments` dataset and merging it is the recommended, though more complex, approach.

**Report 2: SLA Events Configuration**
* **Dataset**: `Support: SLAs`
* **Metrics**: `COUNT(SLA tickets)`
* **Rows**:
  * `Ticket ID`
  * `SLA updated - Timestamp`
  * `SLA status`
  * `Updater name`
  * `Assignee name`
  * `Group name`
  * `Ticket priority`
* **Note**: The `ActivityName` for this report (`SLA Target Applied`, `SLA Target Breached`) must be generated after export based on the value in the `SLA status` column.

Passaggi

Prerequisiti: verifichi di avere Python 3.6 o una versione successiva installata sul sistema. Per generare un token API, è inoltre necessario disporre dell’accesso amministrativo all’istanza Zendesk Support.
Installi le librerie Python: apra il terminale o il prompt dei comandi e installi con pip le librerie Python necessarie. La libreria requests serve per effettuare chiamate API, mentre pandas consente di elaborare i dati ed esportarli in un file CSV.
```
pip install requests pandas
```
Generi un token API Zendesk: acceda a Zendesk come amministratore. Vada in Admin Center > Apps and integrations > APIs > Zendesk API. Nella sezione Token Access, lo attivi se non è già attivo, quindi faccia clic su "Add API token". Inserisca una descrizione, ad esempio "ProcessMind Extraction", e copi il token generato. Non sarà possibile visualizzarlo nuovamente.
Configuri lo script Python: apra lo script Python fornito in un editor di testo. Compili le variabili di configurazione all’inizio del file: ZENDESK_SUBDOMAIN (il dominio Zendesk dell’azienda), ZENDESK_EMAIL (l’indirizzo e-mail dell’amministratore associato al token) e ZENDESK_API_TOKEN. Imposti inoltre START_TIME_STR per definire l’inizio del periodo di estrazione dei dati, in genere da 3 a 6 mesi prima.
Comprenda la logica dello script: lo script recupera innanzitutto l’elenco dei ticket aggiornati nell’intervallo di date specificato, utilizzando l’API Incremental Tickets, che consente di lavorare in modo efficiente. Quindi, per ciascun ticket, recupera la cronologia completa degli audit, i commenti e le metriche SLA. Elabora gli eventi in ordine cronologico per ricostruire una cronologia dettagliata.
Mappi gli eventi Zendesk alle attività: lo script contiene la logica per convertire gli eventi Zendesk grezzi nelle attività aziendali richieste. Ad esempio, un evento 'Change' nel campo 'status' viene associato ad attività come 'Service Request Resolved' o 'Request Placed On-Hold'. Gli eventi relativi ai commenti vengono analizzati per stabilire se si tratta di 'Public Reply Sent' o 'Internal Note Added'.
Esegua lo script di estrazione: dal terminale, esegua python your_script_name.py. Lo script mostrerà gli aggiornamenti sullo stato di avanzamento durante il recupero dei dati dall’API Zendesk. A seconda del volume dei dati e dei limiti di frequenza dell’API, l’operazione potrebbe richiedere del tempo.
Controlli il file di output: al termine dell’esecuzione, nella stessa cartella verrà creato un file CSV denominato zendesk_event_log.csv. Il file contiene l’event log estratto, con tutte le attività e gli attributi specificati.
Prepari il file per il caricamento: apra il file CSV e verifichi che il formato sia corretto. Le intestazioni delle colonne devono corrispondere agli attributi richiesti, tra cui ServiceRequestId, ActivityName, EventTimestamp, SourceSystem e LastDataUpdate. Il file è ora pronto per il caricamento in ProcessMind.

Configurazione

Accesso all’API Zendesk: lo script richiede un token API attivo associato a un amministratore o a un agente con autorizzazioni sufficienti. L’indirizzo e-mail dell’utente configurato nello script deve corrispondere a quello usato per creare il token API.
Parametri dello script: prima di eseguirlo, configuri nello script queste variabili principali: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN e START_TIME_STR. START_TIME_STR deve essere nel formato 'YYYY-MM-DD'.
Intervallo di date: per iniziare, consigliamo di estrarre i dati degli ultimi 3-6 mesi (START_TIME_STR). Si ottiene così un dataset rappresentativo per l’analisi, senza tempi di esecuzione eccessivi né richieste troppo frequenti ai limiti dell’API. Un intervallo più ampio aumenterà notevolmente la durata dell’estrazione.
API Incremental Exports: lo script utilizza l’endpoint Incremental Exports (/api/v2/incremental/tickets/cursor.json) per recuperare in modo efficiente solo i ticket aggiornati dall’ultima esecuzione o da un’ora di inizio specificata. È molto più efficiente rispetto alla scansione di tutti i ticket.
Limiti di frequenza: Zendesk applica limiti di frequenza alle chiamate API. Lo script include una gestione di base che lo mette in pausa quando raggiunge un limite, ma l’estrazione da istanze molto grandi può richiedere parecchio tempo. È preferibile eseguire lo script nelle fasce di minore attività.
Logica di escalation: l’attività 'Request Escalated' viene dedotta da una modifica del campo group_id. Se l’organizzazione utilizza un meccanismo diverso, ad esempio un campo personalizzato del ticket, sarà necessario modificare la logica dello script per identificare correttamente le escalation.

Query di esempio python

import requests
import pandas as pd
import time
from datetime import datetime, timezone
import os

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk subdomain, admin email, and API token
ZENDESK_SUBDOMAIN = class="hl-string">'[Your Subdomain]'
ZENDESK_EMAIL = class="hl-string">'[Your Zendesk Admin Email]'
ZENDESK_API_TOKEN = class="hl-string">'[Your Zendesk API Token]'

class=class="hl-string">"hl-comment"># Set the start date for the data extraction (YYYY-MM-DD)
START_TIME_STR = class="hl-string">'2023-01-01'

class=class="hl-string">"hl-comment"># --- End of Configuration ---

class=class="hl-string">"hl-comment"># Set up constants and session
BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
AUTH = (fclass="hl-string">'{ZENDESK_EMAIL}/token', ZENDESK_API_TOKEN)
SOURCE_SYSTEM = class="hl-string">'Zendesk Support'
LAST_DATA_UPDATE = datetime.now(timezone.utc).isoformat()

session = requests.Session()
session.auth = AUTH

class=class="hl-string">"hl-comment"># Caches for user and group names to reduce API calls
user_cache = {}
group_cache = {}

def get_user_name(user_id):
    if not user_id:
        return None
    if user_id in user_cache:
        return user_cache[user_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_cache[user_id] = response.json()[class="hl-string">'user'][class="hl-string">'name']
        return user_cache[user_id]
    except requests.exceptions.RequestException:
        return fclass="hl-string">'User ID {user_id}'

def get_group_name(group_id):
    if not group_id:
        return None
    if group_id in group_cache:
        return group_cache[group_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/groups/{group_id}.json')
        response.raise_for_status()
        group_cache[group_id] = response.json()[class="hl-string">'group'][class="hl-string">'name']
        return group_cache[group_id]
    except requests.exceptions.RequestException:
        return fclass="hl-string">'Group ID {group_id}'

def handle_rate_limit(response):
    if response.status_code == 429:
        retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
        print(fclass="hl-string">'Rate limit reached. Waiting for {retry_after} seconds...')
        time.sleep(retry_after)
        return True
    response.raise_for_status()
    return False

def fetch_paginated_data(url):
    while url:
        try:
            response = session.get(url)
            if handle_rate_limit(response):
                continue
            data = response.json()
            yield data
            url = data.get(class="hl-string">'next_page')
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'Error fetching data from {url}: {e}')
            break

def process_ticket(ticket, event_log):
    ticket_id = ticket[class="hl-string">'id']
    print(fclass="hl-string">'Processing Ticket ID: {ticket_id}')

    class=class="hl-string">"hl-comment"># --- 1. Fetch Ticket Audits ---
    audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
    all_events = [] class=class="hl-string">"hl-comment"># A temporary list to hold all events for sorting

    for audit_page in fetch_paginated_data(audits_url):
        for audit in audit_page.get(class="hl-string">'audits', []):
            author_id = audit.get(class="hl-string">'author_id')
            timestamp = audit[class="hl-string">'created_at']

            class=class="hl-string">"hl-comment"># Store ticket state at the time of the audit
            ticket_state = {}
            for event in audit.get(class="hl-string">'events', []):
                if event.get(class="hl-string">'field_name') in [class="hl-string">'assignee_id', class="hl-string">'group_id', class="hl-string">'priority', class="hl-string">'status', class="hl-string">'channel', class="hl-string">'type', class="hl-string">'tags']:
                    ticket_state[event[class="hl-string">'field_name']] = event.get(class="hl-string">'value')

            for event in audit.get(class="hl-string">'events', []):
                event[class="hl-string">'timestamp'] = timestamp
                event[class="hl-string">'author_id'] = author_id
                event[class="hl-string">'ticket_state'] = ticket_state
                all_events.append(event)

    class=class="hl-string">"hl-comment"># --- 2. Fetch Comments (which are not fully detailed in audits) ---
    comments_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/comments.json'
    for comment_page in fetch_paginated_data(comments_url):
        for comment in comment_page.get(class="hl-string">'comments', []):
            comment[class="hl-string">'type'] = class="hl-string">'Comment'
            comment[class="hl-string">'timestamp'] = comment[class="hl-string">'created_at']
            class=class="hl-string">"hl-comment"># Add ticket_state placeholder, though it's less relevant for comments
            comment[class="hl-string">'ticket_state'] = {}
            all_events.append(comment)

    class=class="hl-string">"hl-comment"># --- 3. Fetch SLA Metrics ---
    metrics_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json'
    try:
        response = session.get(metrics_url)
        if not handle_rate_limit(response):
            metrics_data = response.json().get(class="hl-string">'ticket_metric', {})
            if metrics_data.get(class="hl-string">'sla_policy'):
                for sla in metrics_data[class="hl-string">'sla_policy'][class="hl-string">'policy_metrics']:
                    all_events.append({
                        class="hl-string">'type': class="hl-string">'SlaApply',
                        class="hl-string">'timestamp': metrics_data[class="hl-string">'created_at'],
                        class="hl-string">'policy_name': sla[class="hl-string">'policy'][class="hl-string">'title'],
                        class="hl-string">'ticket_state': {}
                    })
                    if sla.get(class="hl-string">'breach_at') and datetime.fromisoformat(sla[class="hl-string">'breach_at'].replace(class="hl-string">'Z', class="hl-string">'+00:00')) < datetime.now(timezone.utc):
                        all_events.append({
                            class="hl-string">'type': class="hl-string">'SlaBreach',
                            class="hl-string">'timestamp': sla[class="hl-string">'breach_at'],
                            class="hl-string">'policy_name': sla[class="hl-string">'policy'][class="hl-string">'title'],
                            class="hl-string">'metric': sla[class="hl-string">'metric'],
                            class="hl-string">'ticket_state': {}
                        })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Could not fetch SLA metrics for ticket {ticket_id}: {e}')


    class=class="hl-string">"hl-comment"># --- 4. Sort all collected events by timestamp ---
    all_events.sort(key=lambda x: x[class="hl-string">'timestamp'])

    class=class="hl-string">"hl-comment"># --- 5. Process sorted events to create event log rows ---
    last_assignee = None

    for event in all_events:
        activity_name = None
        timestamp = event[class="hl-string">'timestamp']

        event_type = event.get(class="hl-string">'type')
        field_name = event.get(class="hl-string">'field_name')

        if event_type == class="hl-string">'Create':
            activity_name = class="hl-string">'Service Request Created'
            last_assignee = event.get(class="hl-string">'value') if field_name == class="hl-string">'assignee_id' else None

        elif event_type == class="hl-string">'Change':
            prev_value = event.get(class="hl-string">'previous_value')
            new_value = event.get(class="hl-string">'value')

            if field_name == class="hl-string">'status':
                if new_value == class="hl-string">'solved': activity_name = class="hl-string">'Service Request Resolved'
                elif new_value == class="hl-string">'closed': activity_name = class="hl-string">'Service Request Closed'
                elif new_value == class="hl-string">'hold': activity_name = class="hl-string">'Request Placed On-Hold'
                elif new_value == class="hl-string">'open' and prev_value == class="hl-string">'solved': activity_name = class="hl-string">'Service Request Reopened'
            elif field_name == class="hl-string">'priority': activity_name = class="hl-string">'Priority Changed'
            elif field_name == class="hl-string">'assignee_id':
                if prev_value is None and new_value is not None:
                    activity_name = class="hl-string">'Request Assigned to Agent'
                elif prev_value is not None and new_value is not None:
                    activity_name = class="hl-string">'Agent Reassigned'
                last_assignee = new_value
            elif field_name == class="hl-string">'group_id':
                if prev_value is not None and new_value is not None:
                    activity_name = class="hl-string">'Request Escalated'

        elif event_type == class="hl-string">'Comment':
            if event.get(class="hl-string">'public', False):
                activity_name = class="hl-string">'Public Reply Sent'
            else:
                activity_name = class="hl-string">'Internal Note Added'

        elif event_type == class="hl-string">'SlaApply':
            activity_name = class="hl-string">'SLA Target Applied'
        elif event_type == class="hl-string">'SlaBreach':
            activity_name = class="hl-string">'SLA Target Breached'

        if activity_name:
            class=class="hl-string">"hl-comment"># Get attribute values from the ticket object itself as a baseline
            agent_id = ticket.get(class="hl-string">'assignee_id')
            group_id = ticket.get(class="hl-string">'group_id')
            priority = ticket.get(class="hl-string">'priority')
            status = ticket.get(class="hl-string">'status')
            
            class=class="hl-string">"hl-comment"># Override with values at the time of the event if available
            state = event.get(class="hl-string">'ticket_state', {})
            agent_id = state.get(class="hl-string">'assignee_id', agent_id)
            group_id = state.get(class="hl-string">'group_id', group_id)
            priority = state.get(class="hl-string">'priority', priority)
            status = state.get(class="hl-string">'status', status)
            
            event_log.append({
                class="hl-string">'ServiceRequestId': ticket_id,
                class="hl-string">'ActivityName': activity_name,
                class="hl-string">'EventTimestamp': timestamp,
                class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                class="hl-string">'AgentName': get_user_name(agent_id),
                class="hl-string">'AssignedTeam': get_group_name(group_id),
                class="hl-string">'RequestPriority': priority,
                class="hl-string">'RequestStatus': status,
                class="hl-string">'RequestChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                class="hl-string">'ServiceType': ticket.get(class="hl-string">'type'),
                class="hl-string">'TicketTags': class="hl-string">', '.join(ticket.get(class="hl-string">'tags', [])),
            })


def main():
    print(class="hl-string">'Starting Zendesk data extraction...')
    event_log = []
    start_unix_time = int(datetime.strptime(START_TIME_STR, class="hl-string">'%Y-%m-%d').timestamp())
    
    class=class="hl-string">"hl-comment"># Use the incremental export endpoint for efficiency
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={start_unix_time}'

    while url:
        try:
            response = session.get(url)
            if handle_rate_limit(response):
                continue
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])
            print(fclass="hl-string">'Fetched {len(tickets)} tickets...')
            for ticket in tickets:
                process_ticket(ticket, event_log)
            
            if not data.get(class="hl-string">'after_cursor'):
                break
            url = data[class="hl-string">'next_page']

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

    print(fclass="hl-string">'Extraction complete. Total events found: {len(event_log)}')
    
    if not event_log:
        print(class="hl-string">'No events were extracted. Please check your configuration and date range.')
        return

    df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Reorder columns to match requirements
    columns = [
        class="hl-string">'ServiceRequestId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'AgentName', class="hl-string">'AssignedTeam', class="hl-string">'RequestPriority', class="hl-string">'RequestStatus',
        class="hl-string">'RequestChannel', class="hl-string">'ServiceType', class="hl-string">'TicketTags'
    ]
    df = df[columns]
    df = df.sort_values(by=[class="hl-string">'ServiceRequestId', class="hl-string">'EventTimestamp']).reset_index(drop=True)

    class=class="hl-string">"hl-comment"># Save to CSV
    output_filename = class="hl-string">'zendesk_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">'Event log saved to {output_filename}')

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

Passaggi

In Zendesk Admin Center, richieda o avvii l’esportazione JSON nativa dell’intero account, utilizzando la funzione di esportazione disponibile in base all’abbonamento e alla configurazione dell’account Zendesk. Il percorso esatto nei menu e i requisiti di autorizzazione variano a seconda della configurazione dell’account: utilizzi l’opzione di esportazione disponibile in Admin Center e segua la procedura di approvazione dell’organizzazione.
Selezioni un intervallo di date che copra il periodo di analisi richiesto, preferibilmente da tre a sei mesi. Se l’esportazione nativa non consente di filtrare per data, scarichi l’intero archivio dell’account e applichi il filtro durante la trasformazione.
Scarichi e conservi tutti i file JSON generati dall’esportazione. Mantenga i file originali, l’ora di esportazione, l’identificativo dell’account e qualsiasi file manifest o di metadati. Non sovrascriva i file di origine durante l’elaborazione.
Analizzi i record dei ticket, i record degli audit dei ticket, gli eventi di audit, i commenti, gli utenti, le organizzazioni, i gruppi, i record relativi agli SLA e i campi personalizzati inclusi nell’esportazione. Poiché i nomi dei file e le strutture JSON possono variare in base alla versione dell’esportazione Zendesk, configuri i percorsi di origine e le mappature delle proprietà JSON nei segnaposto dello script prima di eseguirlo.
Normalizzi ogni evento di audit del ticket in una struttura comune che includa ServiceRequestId, ora dell’audit, tipo di evento, nome del campo, valore precedente, nuovo valore, identificativo dell’autore, indicatore pubblico, stato del ticket, assegnatario, gruppo, priorità, canale, tipo di servizio, tag, sistema di origine e LastDataUpdate.
Generi una riga dell’event log per ogni attività pertinente. L’estrazione deve creare esplicitamente righe per Service Request Created, SLA Target Applied, Request Assigned to Agent, Priority Changed, Agent Reassigned, Public Reply Sent, Internal Note Added, Request Placed On-Hold, Request Escalated, SLA Target Breached, Service Request Reopened, Service Request Resolved e Service Request Closed. ProcessMind legge queste righe così come sono e non deduce altri eventi.
Risolva, ove possibile, gli identificativi di agenti, gruppi, organizzazioni e richiedenti utilizzando i record corrispondenti di utenti, gruppi e organizzazioni inclusi nell’esportazione. Compili AgentName e AssignedTeam in base allo stato dell’assegnazione al momento dell’evento. Se non è possibile ricavare il nome visualizzato, mantenga l’identificativo o lasci il campo vuoto.
Applichi regole deterministiche agli eventi. Utilizzi l’evento Create dell’audit del ticket per Service Request Created; gli eventi di audit SLA espliciti per SLA Target Applied e SLA Target Breached; la prima modifica pertinente dell’assegnatario per Request Assigned to Agent; le successive modifiche dell’assegnatario per Agent Reassigned; gli indicatori dei commenti pubblici e privati per gli eventi di risposta e nota; le transizioni di stato per gli eventi di sospensione, riapertura, risoluzione e chiusura; le modifiche del gruppo o del campo di escalation configurato per Request Escalated.
Ordini le righe risultanti per ServiceRequestId e EventTimestamp, mantenendo come criterio secondario l’ordine stabile degli eventi di origine. Non elimini gli eventi solo perché hanno la stessa ora: nello stesso momento possono verificarsi più commenti o eventi di audit.
Verifichi che siano presenti tutte le colonne richieste e che ogni attività abbia almeno una riga corrispondente quando i dati di origine contengono l’evento previsto. Esporti il risultato finale in formato CSV UTF-8 o in un altro formato di event log supportato da ProcessMind, con una riga per evento e i nomi di colonna richiesti: ServiceRequestId, ActivityName, EventTimestamp, SourceSystem e LastDataUpdate.

Configurazione

Ambito dell’esportazione: utilizzi l’esportazione JSON nativa dell’intero account Zendesk Support e conservi tutti i file JSON generati. L’esportazione dovrebbe includere i dati dei ticket e i relativi audit o eventi. Se i dati relativi a SLA, commenti, utenti, organizzazioni, gruppi o campi personalizzati vengono forniti separatamente, includa anche questi file nell’input della trasformazione.
Intervallo di date: per l’estrazione e la convalida iniziali, è preferibile un intervallo da tre a sei mesi. Se l’esportazione nativa riguarda l’intero account e non può essere limitata per data, applichi il filtro a EventTimestamp dopo l’analisi, conservando l’intero archivio di origine.
Regole per le attività: configuri mappature esplicite per tutte e 13 le attività. Non affidi a ProcessMind il compito di dedurre da altre righe gli eventi di assegnazione, escalation, SLA, stato o commento.
Configurazione SLA: mappi i nomi degli eventi o le proprietà effettivamente esportati dall’account per l’applicazione e la violazione degli obiettivi SLA. Se l’esportazione non contiene eventi SLA espliciti, non li inventi. Configuri nei segnaposto i percorsi di origine corrispondenti e documenti le attività non disponibili.
Configurazione delle escalation: individui il campo di gruppo specifico dell’account o il campo personalizzato che rappresenta un’escalation. Prima di eseguire lo script, imposti ESCALATION_FIELD_ID o la configurazione equivalente sull’identificativo effettivo del campo esportato.
Percorsi di origine: imposti nello script i percorsi dei file JSON e le mappature delle proprietà JSON. I nomi dei file e la struttura dei dati Zendesk possono variare in base alla versione dell’esportazione e alla configurazione dell’account.
Output richiesto: ServiceRequestId, ActivityName, EventTimestamp, SourceSystem e LastDataUpdate devono essere compilati per ogni riga di evento. Le colonne consigliate sono AgentName, AssignedTeam, RequestPriority, RequestStatus, RequestChannel, ServiceType e TicketTags.
Filtri: applichi l’intervallo di date richiesto per l’analisi, l’ambito dell’account o del marchio e gli eventuali filtri specifici dell’azienda solo dopo aver verificato la proprietà esportata corrispondente. Non applichi filtri basati su nomi di campi non supportati o non verificati.
Prestazioni: ove possibile, elabori i file JSON in modo incrementale, eviti di caricare in memoria l’intera esportazione dell’account, indicizzi gli identificativi dei ticket e degli audit e scriva file intermedi normalizzati prima di generare l’event log finale. Per le esportazioni di grandi dimensioni potrebbe essere necessario suddividere i dati per data o identificativo del ticket.
Prerequisiti: accesso amministrativo per richiedere o scaricare l’esportazione nativa dell’account; autorizzazione ad accedere agli audit dei ticket e ai dati di riferimento di utenti e gruppi; un abbonamento Zendesk che supporti la funzione di esportazione; spazio di archiviazione locale sufficiente per l’intero archivio; un ambiente di esecuzione in grado di analizzare JSON e scrivere file CSV UTF-8.
Protezione dei dati: consideri potenzialmente sensibili i dati relativi a richiedenti, agenti, organizzazioni, commenti e ticket. Conservi i file di origine e quelli trasformati nel rispetto dei requisiti aziendali di conservazione, controllo degli accessi e privacy.

Query di esempio config

import csv
import json
import os
from datetime import datetime, timezone
from pathlib import Path

SOURCE_DIRECTORY = "[Path to extracted Zendesk JSON directory]"
OUTPUT_FILE = "[Path to ProcessMind event log CSV]"
START_DATE = "[YYYY-MM-DD or blank]"
END_DATE = "[YYYY-MM-DD or blank]"
SOURCE_SYSTEM = "Zendesk Support"
LAST_DATA_UPDATE = "[ISO-8601 timestamp of source refresh]"
ESCALATION_FIELD_ID = "[Zendesk custom field identifier used for escalation, or blank]"


def load_json_files(directory):
    documents = []
    for path in Path(directory).rglob("*.json"):
        with path.open("r", encoding="utf-8") as handle:
            documents.append((path.name, json.load(handle)))
    return documents


def as_list(value):
    if isinstance(value, list):
        return value
    if isinstance(value, dict):
        for key in ("tickets", "ticket", "audits", "events", "comments", "users", "groups", "organizations", "data", "results"):
            if isinstance(value.get(key), list):
                return value[key]
    return []


def parse_timestamp(value):
    if not value:
        return None
    text = str(value).replace("Z", "+00:00")
    try:
        parsed = datetime.fromisoformat(text)
        if parsed.tzinfo is None:
            parsed = parsed.replace(tzinfo=timezone.utc)
        return parsed.astimezone(timezone.utc)
    except ValueError:
        return None


def in_range(timestamp):
    if timestamp is None:
        return False
    if START_DATE and timestamp.date().isoformat() < START_DATE:
        return False
    if END_DATE and timestamp.date().isoformat() > END_DATE:
        return False
    return True


def value(record, *keys):
    for key in keys:
        if isinstance(record, dict) and record.get(key) is not None:
            return record.get(key)
    return None


def identifier(record):
    return value(record, "id", "user_id", "group_id", "organization_id", "ticket_id")


def normalize_id(value_to_normalize):
    if value_to_normalize is None or value_to_normalize == "":
        return None
    return str(value_to_normalize)


def audit_events(audit):
    events = value(audit, "events", "audit_events")
    return events if isinstance(events, list) else []


def event_type(event):
    return str(value(event, "type", "event_type", "action") or "").lower()


def event_field(event):
    return str(value(event, "field_name", "field", "property") or "").lower()


def event_value(event, key):
    return value(event, key, key.replace("_", ""))


def status_value(ticket, event, new=True):
    if new:
        return value(event, "value", "new_value", "to") or value(ticket, "status")
    return value(event, "previous_value", "old_value", "from")


def comment_public(event):
    public_value = value(event, "public", "is_public")
    return public_value is True or str(public_value).lower() == "true"


def add_row(rows, ticket, activity, timestamp, agent_name=None, assigned_team=None, priority=None, status=None, channel=None, service_type=None, tags=None, sequence=0):
    parsed = parse_timestamp(timestamp)
    if not in_range(parsed):
        return
    rows.append({
        "ServiceRequestId": str(value(ticket, "id", "ticket_id")),
        "ActivityName": activity,
        "EventTimestamp": parsed.isoformat(),
        "SourceSystem": SOURCE_SYSTEM,
        "LastDataUpdate": LAST_DATA_UPDATE,
        "AgentName": agent_name or "",
        "AssignedTeam": assigned_team or "",
        "RequestPriority": priority or "",
        "RequestStatus": status or "",
        "RequestChannel": channel or "",
        "ServiceType": service_type or "",
        "TicketTags": ",".join(tags) if isinstance(tags, list) else (tags or ""),
        "SourceSequence": sequence
    })


def main():
    documents = load_json_files(SOURCE_DIRECTORY)
    tickets = {}
    audits_by_ticket = {}
    users = {}
    groups = {}
    organizations = {}
    standalone_comments = []
    standalone_sla_events = []

    for filename, document in documents:
        records = as_list(document)
        lower_name = filename.lower()
        for record in records:
            if not isinstance(record, dict):
                continue
            record_id = normalize_id(identifier(record))
            if any(token in lower_name for token in ("user", "agent")) and record_id:
                users[record_id] = record
            elif "group" in lower_name and record_id:
                groups[record_id] = record
            elif "organization" in lower_name and record_id:
                organizations[record_id] = record
            elif "audit" in lower_name and value(record, "ticket_id") is not None:
                audits_by_ticket.setdefault(normalize_id(value(record, "ticket_id")), []).append(record)
            elif "comment" in lower_name:
                standalone_comments.append(record)
            elif "sla" in lower_name:
                standalone_sla_events.append(record)
            elif value(record, "ticket_id") is not None and value(record, "type", "event_type") is not None:
                standalone_sla_events.append(record)
            elif value(record, "id") is not None and any(key in record for key in ("status", "priority", "assignee_id", "group_id", "tags")):
                tickets[record_id] = record

    rows = []
    for ticket_id, ticket in tickets.items():
        if not ticket_id:
            continue
        ticket_audits = audits_by_ticket.get(ticket_id, [])
        ticket_audits.sort(key=lambda item: (parse_timestamp(value(item, "created_at", "timestamp", "time")) or datetime.min.replace(tzinfo=timezone.utc), str(value(item, "id") or "")))
        current_assignee = normalize_id(value(ticket, "assignee_id"))
        current_group = normalize_id(value(ticket, "group_id"))
        assignment_seen = False
        sequence = 0
        base_priority = value(ticket, "priority")
        base_status = value(ticket, "status")
        base_channel = value(ticket, "via", "channel")
        base_service_type = value(ticket, "type", "service_type")
        base_tags = value(ticket, "tags") or []

        for audit in ticket_audits:
            audit_time = value(audit, "created_at", "timestamp", "time")
            actor_id = normalize_id(value(audit, "author_id", "actor_id", "user_id"))
            actor = users.get(actor_id, {})
            agent_name = value(actor, "name", "display_name", "email") or ""
            audit_group = groups.get(current_group, {})
            assigned_team = value(audit_group, "name", "display_name") or ""
            for event in audit_events(audit):
                sequence += 1
                kind = event_type(event)
                field = event_field(event)
                timestamp = value(event, "created_at", "timestamp", "time") or audit_time
                new_value = event_value(event, "value") or event_value(event, "new_value") or event_value(event, "to")
                old_value = event_value(event, "previous_value") or event_value(event, "old_value") or event_value(event, "from")
                event_agent = agent_name
                event_team = assigned_team
                if field in ("assignee_id", "assignee"):
                    new_assignee = normalize_id(new_value)
                    old_assignee = normalize_id(old_value)
                    if new_assignee and not assignment_seen and new_assignee != current_group:
                        assigned_agent = users.get(new_assignee, {})
                        add_row(rows, ticket, "Request Assigned to Agent", timestamp, value(assigned_agent, "name", "display_name", "email") or event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                        assignment_seen = True
                    elif new_assignee and assignment_seen and new_assignee != old_assignee:
                        assigned_agent = users.get(new_assignee, {})
                        add_row(rows, ticket, "Agent Reassigned", timestamp, value(assigned_agent, "name", "display_name", "email") or event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    current_assignee = new_assignee or current_assignee
                elif field in ("priority",):
                    add_row(rows, ticket, "Priority Changed", timestamp, event_agent, event_team, new_value, base_status, base_channel, base_service_type, base_tags, sequence)
                    base_priority = new_value or base_priority
                elif field in ("group_id", "group"):
                    new_group = normalize_id(new_value)
                    new_group_record = groups.get(new_group, {})
                    new_team = value(new_group_record, "name", "display_name") or event_team
                    if new_group and new_group != current_group:
                        add_row(rows, ticket, "Request Escalated", timestamp, event_agent, new_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    current_group = new_group or current_group
                elif field in ("status", "status_category"):
                    status_text = str(new_value or "").lower()
                    old_status_text = str(old_value or "").lower()
                    if status_text == "on-hold":
                        add_row(rows, ticket, "Request Placed On-Hold", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    if status_text == "solved":
                        add_row(rows, ticket, "Service Request Resolved", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    if status_text == "closed":
                        add_row(rows, ticket, "Service Request Closed", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    if old_status_text == "solved" and status_text in ("open", "pending", "on-hold"):
                        add_row(rows, ticket, "Service Request Reopened", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    base_status = new_value or base_status
                elif kind in ("comment", "comment_created", "comment_added") or field in ("comment", "comment_body"):
                    if comment_public(event):
                        add_row(rows, ticket, "Public Reply Sent", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    else:
                        add_row(rows, ticket, "Internal Note Added", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                elif "sla" in kind or "sla" in field:
                    sla_text = str(value(event, "target_status", "status", "action", "event_type", "type") or "").lower()
                    if any(token in sla_text for token in ("breach", "breached", "missed", "failed")):
                        add_row(rows, ticket, "SLA Target Breached", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    elif any(token in sla_text for token in ("applied", "active", "started", "target")):
                        add_row(rows, ticket, "SLA Target Applied", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                elif ESCALATION_FIELD_ID and field == ESCALATION_FIELD_ID.lower():
                    add_row(rows, ticket, "Request Escalated", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)

            if str(value(audit, "action", "type", "event_type") or "").lower() == "create":
                add_row(rows, ticket, "Service Request Created", audit_time, agent_name, assigned_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)

        for record in standalone_sla_events:
            if normalize_id(value(record, "ticket_id")) != ticket_id:
                continue
            timestamp = value(record, "created_at", "timestamp", "time")
            text = str(value(record, "event_type", "type", "status", "action") or "").lower()
            if "breach" in text or "missed" in text or "failed" in text:
                add_row(rows, ticket, "SLA Target Breached", timestamp, "", "", base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
            elif "sla" in text or "applied" in text or "active" in text:
                add_row(rows, ticket, "SLA Target Applied", timestamp, "", "", base_priority, base_status, base_channel, base_service_type, base_tags, sequence)

    rows.sort(key=lambda row: (row["ServiceRequestId"], row["EventTimestamp"], int(row["SourceSequence"])))
    output_columns = ["ServiceRequestId", "ActivityName", "EventTimestamp", "SourceSystem", "LastDataUpdate", "AgentName", "AssignedTeam", "RequestPriority", "RequestStatus", "RequestChannel", "ServiceType", "TicketTags"]
    with open(OUTPUT_FILE, "w", encoding="utf-8", newline="") as handle:
        writer = csv.DictWriter(handle, fieldnames=output_columns)
        writer.writeheader()
        for row in rows:
            writer.writerow({column: row.get(column, "") for column in output_columns})


if __name__ == "__main__":
    main()

È pronto a iniziare?

Inizi subito a ottimizzare il processo di gestione delle richieste di assistenza. Utilizzi questo template dei dati per individuare i colli di bottiglia e migliorare l’efficienza in Zendesk Support.

Torna alla guida al miglioramento

Scarica il template

Ottimizzi la gestione delle richieste di assistenza. Riduca subito i ritardi.

Riduca i tempi di evasione e la frustrazione degli utenti. Raggiunga il 70% di automazione.

Inizi la prova gratuita

Non è richiesta una carta di credito. Configurazione rapida.

Il template dei dati per la gestione delle richieste di assistenza

Il template dei dati per la gestione delle richieste di assistenza

Attributi per la gestione delle richieste di assistenza

Attività di gestione delle richieste di assistenza

Guide all’estrazione

Interfaccia di Zendesk Explore per report ed esportazione dei dati

Passaggi

Configurazione

Query di esempio config

Estrazione da Zendesk REST API tramite script Python

Passaggi

Configurazione

Query di esempio python

Esportazione JSON nativa dell’intero account Zendesk Support

Passaggi

Configurazione

Query di esempio config

È pronto a iniziare?

Ottimizzi la gestione delle richieste di assistenza. Riduca subito i ritardi.