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

Il Suo Template dei dati per la gestione delle richieste di servizio

Zendesk Support

Attributi della gestione delle richieste di servizio (21) Attività della gestione delle richieste di servizio (13) Guide all'estrazione (3)

Il Suo Template dei dati per la gestione delle richieste di servizio

Questo Template offre una guida completa per estrarre i dati necessari ad analizzare il processo di gestione delle richieste di servizio in Zendesk Support. Illustra gli attributi essenziali da raccogliere, le attività principali da monitorare e indicazioni pratiche per estrarre queste informazioni direttamente dal Suo sistema. Utilizzi questa risorsa per creare un event log solido a supporto delle Sue iniziative di Process Mining.

Attributi consigliati per un'analisi completa
Attività chiave delle richieste di servizio da monitorare
Indicazioni per l'estrazione dei dati da Zendesk Support

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

Scarica il Template

Attributi della gestione delle richieste di servizio

Questi sono i campi dati consigliati da includere nell’Event Log per un’analisi completa della gestione delle richieste di servizio in Zendesk Support.

5 Obbligatorio 7 Consigliato 9 Facoltativo

	Nome	Descrizione
	Attività ActivityName	Il nome dell’attività aziendale o dell’evento che si è verificato per una richiesta di assistenza.
Descrizione L’Attività rappresenta una fase o un evento distinto nel ciclo di vita della richiesta di assistenza, come 'Service Request Created', 'Request Assigned to Agent' o 'Service Request Resolved'. Queste attività derivano dalle modifiche registrate nel registro di audit del ticket Zendesk, che tiene traccia degli aggiornamenti a campi come stato, assegnatario e priorità, nonché dell’aggiunta di commenti. L’analisi delle attività costituisce il nucleo del Process Mining. Consente di visualizzare la mappa del processo, identificare 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, consentendo di visualizzare le mappe di processo e analizzare il flusso, le variazioni e la conformità del processo. Dove reperirlo Viene derivato concettualmente dagli eventi registrati nella Zendesk Ticket Audits API. Ad esempio, una modifica del campo 'status' da 'new' a 'open' può essere associata a un’attività come 'Request Triaged'. Esempi Richiesta di assistenza creataAgente riassegnatoRichiesta di assistenza risolta
	ID della richiesta di assistenza ServiceRequestId	L’identificativo univoco di ogni ticket di richiesta di assistenza all’interno di Zendesk.
Descrizione Il Service Request ID, spesso denominato Ticket ID in Zendesk, funge da chiave primaria per ogni caso. Collega tutte le attività, i commenti e i cambiamenti di stato correlati, dal momento della creazione della richiesta fino alla chiusura. Consente così di tracciare in modo completo, end-to-end, il ciclo di vita di una singola richiesta. Nell’analisi di Process Mining, questo Attributo è fondamentale. Definisce il caso, consentendo di ricostruire i flussi di processo, identificare le varianti e calcolare metriche a livello di caso, come il tempo di ciclo. Ogni evento del dataset deve essere associato a un Service Request ID per comprenderne il contesto all’interno del processo complessivo. Perché è importante È l’identificativo essenziale del caso che collega tutti gli eventi del percorso di una richiesta di assistenza, rendendo possibile l’analisi del processo end-to-end. Dove reperirlo Zendesk Tickets API, campo 'id'. Esempi 102451024610247
	Ora di inizio EventTimestamp	La data e l’ora precise in cui si è verificata l’attività.
Descrizione Il timestamp dell’evento, o Ora di inizio, registra il momento esatto in cui si è svolta un’attività. Ad esempio, indica quando è stato assegnato un agente, quando è stata inviata una risposta pubblica o quando lo stato del ticket è stato modificato in 'Resolved'. Questi dati temporali provengono dal registro di audit di ciascun ticket Zendesk. Questo Attributo è fondamentale per qualsiasi analisi basata sul tempo. Viene utilizzato per ordinare cronologicamente gli eventi, calcolare la durata tra le attività, misurare i tempi di attesa e analizzare il tempo di ciclo complessivo del caso. È essenziale per individuare i colli di bottiglia e valutare le performance rispetto a obiettivi temporali come gli SLA. Perché è importante Questo timestamp ordina cronologicamente gli eventi ed è essenziale per tutte le analisi della durata, delle performance e dei colli di bottiglia. Dove reperirlo Zendesk Ticket Audits API, campo 'created_at' per ogni evento di audit. Esempi 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
	Sistema di origine SourceSystem	Indica il sistema dal quale sono stati estratti i dati.
Descrizione Questo Attributo specifica l’origine dei dati delle richieste di assistenza. Per questa vista di processo, il valore sarà sempre 'Zendesk Support', identificandolo come sistema di riferimento per tutte le attività di gestione dell’assistenza. Negli ambienti con più sistemi integrati, questo campo è fondamentale per la tracciabilità dei dati e la risoluzione dei problemi. Garantisce che le analisi siano correttamente circoscritte al sistema previsto e aiuta a distinguere i dati quando vengono uniti dati provenienti da diverse fonti. Perché è importante Identifica il sistema di origine dei dati, garantendo la tracciabilità e prevenendo confusioni quando vengono combinati dati provenienti da più sistemi. Dove reperirlo È un valore statico ('Zendesk Support') aggiunto durante l’estrazione e la trasformazione dei dati. Esempi Zendesk Support
	Ultimo aggiornamento dei dati LastDataUpdate	Il timestamp che indica l’ultima volta in cui i dati sono stati aggiornati dal sistema di origine.
Descrizione Questo Attributo registra la data e l’ora dell’estrazione più recente dei dati da Zendesk Support. Fornisce il contesto sull’aggiornamento dei dati analizzati, assicurando che gli utenti sappiano quanto è attuale la vista del processo. Per il monitoraggio continuo e la creazione di Dashboard, queste informazioni sono essenziali. Consentono ad analisti e utenti aziendali di capire se stanno esaminando dati quasi in tempo reale o un’istantanea relativa a un periodo precedente, un elemento che influisce sulla validità delle conclusioni. Perché è importante Fornisce un contesto essenziale sull’aggiornamento dei dati, indicando agli utenti quanto sia attuale l’analisi. Dove reperirlo È un campo di metadati generato e registrato nel dataset al momento dell’estrazione dei dati. Esempi 2023-10-27T08:00:00Z
	Canale della richiesta RequestChannel	Il canale attraverso il quale è stata inviata la richiesta di servizio, ad esempio e-mail, modulo web o telefono.
Descrizione Questo attributo identifica la fonte di invio della richiesta di servizio. Zendesk registra il modo in cui è stato creato un ticket, tramite e-mail, portale web, integrazione API, chat o altri canali. In questo modo fornisce il contesto relativo alla modalità di interazione del cliente. Il canale della richiesta è una dimensione di analisi particolarmente utile. Supporta il Dashboard «Efficienza dei canali delle richieste», consentendo di confrontare i tempi di risoluzione, i livelli di soddisfazione e i tassi di rilavorazione tra canali diversi. Queste informazioni aiutano le aziende a ottimizzare i propri canali di supporto e a indirizzare gli utenti verso quelli più efficienti. Perché è importante Aiuta ad analizzare l'efficienza e i risultati dei diversi canali di supporto clienti, consentendo di definire interventi di miglioramento mirati. Dove reperirlo Zendesk Tickets API, oggetto 'via' e relativa proprietà 'channel'. Esempi webe-mailapichat
	Nome dell’agente AgentName	Il nome dell’agente assegnato alla richiesta di assistenza al momento dell’evento.
Descrizione Questo Attributo identifica l’agente di supporto responsabile della gestione della richiesta di assistenza. L’agente assegnato può cambiare più volte durante il ciclo di vita del ticket e questo campo registra chi era responsabile in ogni fase. Il Nome dell’agente è fondamentale per l’analisi delle performance. 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. Aiuta inoltre a creare il Dashboard Agent & Team Performance e a comprendere il contributo individuale all’efficienza complessiva del processo. Perché è importante Questo Attributo è essenziale per analizzare le performance degli agenti, la distribuzione del carico di lavoro e l’impatto delle riassegnazioni sui tempi di risoluzione. Dove reperirlo Zendesk Users API, tramite il collegamento dell’'assignee_id' dalla risposta della Tickets API. Esempi Jane DoeJohn SmithEmily Jones
	Priorità della richiesta RequestPriority	Il livello di priorità assegnato alla richiesta di servizio, ad esempio Bassa, Normale, Alta o Urgente.
Descrizione La priorità della richiesta è una classificazione che indica l'urgenza di una richiesta di servizio. Questo livello determina spesso i tempi obiettivo di risoluzione e le policy SLA applicate al ticket. La priorità può essere impostata inizialmente dal sistema o dall'utente e può essere modificata da un agente durante il ciclo di vita del ticket. Questo attributo è fondamentale per la segmentazione e l'analisi delle cause principali. Consente di verificare se i ticket ad alta priorità vengono risolti più rapidamente rispetto a quelli a bassa priorità ed è un fattore chiave nei Dashboard «Tendenze delle escalation delle richieste di servizio» e «Rispetto degli SLA». Perché è importante Consente di segmentare le richieste in base all'urgenza, un aspetto fondamentale per analizzare la conformità agli SLA e garantire che i problemi critici vengano gestiti tempestivamente. Dove reperirlo Zendesk Tickets API, campo 'priority'. Esempi BassaNormaleAltaUrgente
	Stato della richiesta RequestStatus	Lo stato della richiesta di servizio al momento dell'evento, ad esempio Nuova, Aperta o In attesa.
Descrizione Lo stato della richiesta rappresenta la condizione del ticket in un determinato momento. Zendesk prevede diversi stati standard, come Nuova, Aperta, In attesa, In sospeso, Risolta e Chiusa, che indicano l'avanzamento della richiesta durante il suo ciclo di vita. Le modifiche a questo campo sono i principali fattori che determinano la creazione delle attività nell'event log. L'analisi del tempo trascorso nei diversi stati è una componente essenziale dell'analisi dei colli di bottiglia. Consente di individuare i punti in cui i ticket si bloccano, ad esempio quando rimangono troppo a lungo nello stato «In attesa» o «In sospeso». Comprendere le transizioni tra gli stati è inoltre fondamentale 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 reperirlo Zendesk Tickets API, campo 'status'. Esempi NuovoApertoIn attesaRisoltoChiuso
	Tag dei ticket TicketTags	Un elenco di tag applicati alla richiesta di servizio per finalità di classificazione e routing.
Descrizione I tag sono etichette flessibili che gli agenti possono aggiungere manualmente ai ticket oppure che possono essere applicate automaticamente tramite regole aziendali. Servono ad aggiungere a un ticket un contesto o una categoria specifici che potrebbero non essere rappresentati dai campi standard, come Tipo o Priorità. I tag sono attributi estremamente versatili per l'analisi di Process Mining. Possono essere utilizzati per filtrare scenari molto specifici, monitorare Workflow personalizzati o individuare le cause principali. Ad esempio, il tag «VIP» può servire ad analizzare il processo relativo ai clienti strategici, mentre il tag «product_bug» può essere utilizzato per seguire il ciclo di vita delle segnalazioni di difetti. Perché è importante Offre un modo flessibile per segmentare e analizzare i dati in dettaglio, consentendo di esaminare a fondo sottoprocessi specifici o attributi dei ticket non acquisiti da altri campi. Dove reperirlo Zendesk Tickets API, campo 'tags'. Si tratta di un array di stringhe. Esempi richiesta_commercialeproblema_fatturazionerichiesta_funzionalitàcliente_vip
	Team assegnato AssignedTeam	Il team o gruppo di supporto assegnato alla richiesta di assistenza.
Descrizione Questo Attributo indica quale team o gruppo all’interno dell’organizzazione di supporto è responsabile della richiesta di assistenza. In Zendesk, questi elementi sono denominati 'Groups'. I ticket vengono spesso assegnati prima a un gruppo e successivamente presi in carico da un singolo agente. L’analisi per Team assegnato è essenziale per comprendere le performance e il carico di lavoro a livello di team. Aiuta a rispondere a domande come quali team gestiscono determinati tipi di richieste, quali sono i loro tempi medi di risoluzione e quali sono i rispettivi tassi di rispetto degli SLA. È una dimensione primaria per il Dashboard Agent & Team Performance. Perché è importante Consente di analizzare le prestazioni dei team, bilanciare i carichi di lavoro e valutare l'efficienza del routing tra diversi gruppi di supporto. Dove reperirlo Zendesk Groups API, unendo il campo 'group_id' della risposta dell'API Tickets. Esempi Supporto di primo livelloSupporto tecnicoFatturazione
	Tipo di servizio ServiceType	La categoria o il tipo della richiesta di servizio, ad esempio Incidente, Domanda, Problema o Attività.
Descrizione Il tipo di servizio classifica la natura della richiesta di servizio. Zendesk utilizza un campo 'type' per distinguere i diversi tipi di interazione con il supporto. Questa classificazione iniziale aiuta a indirizzare il ticket al team corretto e ad applicare i processi appropriati. Questo attributo è essenziale per i filtri e i confronti. Consente agli analisti di esaminare i flussi di processo relativi a diversi tipi di richiesta, che spesso seguono percorsi di risoluzione e SLA molto differenti. È una dimensione fondamentale del Dashboard «Prestazioni di agenti e team», che permette di individuare chi gestisce al meglio specifici tipi di richiesta. Perché è importante Classifica le richieste per consentire un'analisi distinta dei diversi processi, ad esempio degli incidenti rispetto alle domande, che seguono percorsi specifici. Dove reperirlo Zendesk Tickets API, campo 'type'. Esempi domandaincidenteproblemaattività
	È rilavorazione IsRework	Un indicatore impostato su vero se la richiesta di servizio è stata riaperta dopo essere stata risolta.
Descrizione Questo indicatore booleano identifica i casi sottoposti a rilavorazione. Una richiesta di servizio viene generalmente considerata una rilavorazione se il suo stato passa da «Risolta» a uno stato aperto, indicando che la risoluzione iniziale non era sufficiente e che il cliente ha dovuto ricontattare il supporto per lo stesso problema. Questo attributo è essenziale per calcolare il KPI «Tasso di rilavorazione delle richieste di servizio» e per il Dashboard «Analisi delle attività di rilavorazione e riapertura». Contrassegnare i casi di rilavorazione consente agli analisti di isolare i flussi di processo inefficienti, individuare le cause principali delle riaperture e migliorare la risoluzione al primo contatto. Perché è importante Individua i casi in cui la risoluzione non è stata definitiva, mettendo in evidenza problemi di qualità ed efficienza che incidono direttamente sulla soddisfazione dei clienti. Dove reperirlo Calcolato analizzando la sequenza degli stati di un ticket nell'API Zendesk Ticket Audits. Una transizione da «solved» a «open» indica una rilavorazione. Esempi truefalse
	Nome del richiedente RequestorName	Il nome dell'utente finale o del cliente che ha inviato la richiesta di servizio.
Descrizione Questo attributo identifica la persona che ha avviato la richiesta di servizio. Collegare la richiesta a uno specifico cliente offre una visione del processo di supporto incentrata sull'utente. Nell'analisi dei processi, il richiedente può essere utilizzato per esaminare i modelli relativi a singoli clienti o segmenti di clientela. Ad esempio, è possibile verificare se determinati clienti registrano tempi di risoluzione più lunghi o tassi di rilavorazione più elevati, circostanza che potrebbe indicare problemi legati al prodotto o al servizio utilizzato. Perché è importante Collega il processo al cliente, consentendo di analizzare problemi specifici, richieste ripetute e livelli di soddisfazione. Dove reperirlo Zendesk Users API, unendo il campo 'requester_id' della risposta dell'API Tickets. Esempi Alice JohnsonBob WilliamsCharlie Brown
	Nome della policy SLA SlaPolicyName	Il nome della policy del Service Level Agreement (SLA) applicata alla richiesta.
Descrizione Questo attributo identifica la specifica policy SLA che stabilisce i tempi obiettivo di risposta e risoluzione della richiesta di servizio. Una policy viene generalmente determinata da fattori quali la priorità o il tipo della richiesta e il livello di abbonamento del cliente. Conoscere la policy SLA applicata è essenziale per il Dashboard «Analisi del rispetto e delle violazioni degli SLA». Fornisce il contesto necessario per valutare le prestazioni, poiché policy diverse prevedono obiettivi differenti. In questo modo è possibile verificare in modo equo e accurato se un ticket ha raggiunto i propri obiettivi specifici di livello di servizio. Perché è importante Fornisce il contesto per l'analisi degli SLA identificando l'insieme di obiettivi rispetto ai quali è stata misurata una richiesta e consentendo una reportistica accurata sulla conformità. Dove reperirlo Zendesk Ticket Metrics API. I dati SLA sono spesso associati alle metriche del ticket. Esempi Urgente - risposta entro 1 oraStandard - risoluzione entro 24 oreSLA cliente Premium
	Numero di riassegnazioni all'agente AgentReassignmentCount	Il numero totale di volte in cui una richiesta è stata riassegnata da un agente a un altro.
Descrizione Questo attributo è un contatore che aumenta ogni volta che cambia il campo 'assignee_id' di un ticket. Un numero elevato di riassegnazioni per un singolo ticket può indicare diversi problemi di processo, come un routing iniziale errato, una conoscenza insufficiente da parte degli agenti o richieste troppo complesse per essere gestite da un solo agente. È una metrica fondamentale per misurare l'efficienza del processo e supporta direttamente il KPI «Tasso di riassegnazione degli agenti». L'analisi dei casi con un numero elevato di riassegnazioni può evidenziare opportunità per migliorare le regole di routing, la formazione degli agenti o le risorse della knowledge base, così da assegnare più rapidamente i ticket alla persona corretta. Perché è importante Aiuta a quantificare i passaggi interni e a individuare gli attriti del processo, poiché tassi elevati di riassegnazione causano spesso ritardi e inefficienze. Dove reperirlo Calcolato contando il numero di modifiche al campo 'assignee_id' nell'API Zendesk Ticket Audits per ciascun ticket. Esempi 013
	Ora di fine EndTime	La data e l’ora precise in cui l’attività è stata completata.
Descrizione L’Ora di fine indica il completamento di un’attività. Per molti eventi in Zendesk, la durata è istantanea, quindi l’Ora di fine coincide con l’Ora di inizio. Tuttavia, per attività basate sullo stato, come 'Request Placed On-Hold', l’Ora di fine corrisponde al momento in cui il ticket viene tolto dallo stato di attesa. Questo Attributo è essenziale per calcolare la durata di attività specifiche, un elemento fondamentale per l’analisi dei colli di bottiglia. Confrontando l’Ora di inizio e l’Ora 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 elemento fondamentale per identificare i colli di bottiglia del processo e misurare l’efficienza a livello di fase. Dove reperirlo Spesso coincide con StartTime per gli eventi discreti. Per le durate basate sullo stato, 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	L'organizzazione o l'azienda a cui appartiene il richiedente.
Descrizione Questo attributo collega la richiesta di servizio a una specifica organizzazione cliente. È particolarmente rilevante negli scenari di supporto B2B, in cui gli accordi sui livelli di servizio e i contratti di supporto sono spesso definiti a livello organizzativo. L'analisi dei dati per organizzazione offre una visione delle prestazioni del supporto a livello aziendale. Può aiutare a individuare le organizzazioni che generano un volume elevato di ticket, riscontrano problemi ricorrenti o registrano bassi punteggi di soddisfazione. Queste informazioni sono utili per la gestione degli account e per individuare tendenze più ampie relative alla salute della clientela. Perché è importante Consente di analizzare il servizio B2B raggruppando le richieste per azienda, un aspetto fondamentale per gestire le relazioni con i clienti e gli SLA a livello organizzativo. Dove reperirlo Zendesk Organizations API, unendo il campo 'organization_id' della risposta dell'API Tickets. Esempi Acme CorporationGlobal Tech Inc.Innovate Solutions
	Risoluzione al primo contatto IsFirstContactResolution	Un 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 che indica la risoluzione del problema del cliente attraverso una singola interazione. Questo attributo calcolato è un indicatore booleano impostato su vero se un ticket è stato risolto dal primo agente a cui è stato assegnato, senza riassegnazioni e con una sola risposta dell'agente. Questo attributo supporta direttamente il KPI «Tasso di risoluzione al primo contatto». Analizzare le caratteristiche dei casi FCR può fornire un modello per l'eccellenza operativa. Al contrario, l'analisi dei casi che non raggiungono l'FCR può evidenziare opportunità per migliorare la formazione degli agenti, gli articoli della knowledge base o il triage iniziale. Perché è importante Misura la capacità di risolvere i problemi in modo efficiente attraverso un'unica interazione, un fattore che incide fortemente sia sulla soddisfazione dei clienti sia sull'efficienza operativa. Dove reperirlo Si tratta di un attributo calcolato complesso. Richiede l'analisi dell'event log di un ticket per verificare le riassegnazioni agli agenti e il numero di risposte pubbliche degli agenti. Esempi truefalse
	SLA violato IsSlaBreached	Un indicatore che segnala se la richiesta di servizio ha violato uno degli obiettivi SLA previsti.
Descrizione Questo attributo è un indicatore booleano o categoriale che mostra l'esito SLA di un ticket. Può indicare stati quali «Rispettato», «Violato» o «Attivo». Il risultato viene determinato confrontando i tempi effettivi di risposta o risoluzione con gli obiettivi definiti nella policy SLA applicata. È un attributo fondamentale per il Dashboard «Analisi del rispetto e delle violazioni degli SLA». Consente di contare e visualizzare facilmente i ticket conformi e non conformi. L'analisi successiva può concentrarsi sulle caratteristiche dei ticket che hanno violato gli SLA, per individuarne le cause principali, come tempi di attesa lunghi o riassegnazioni eccessive. Perché è importante Misura direttamente le prestazioni rispetto agli impegni di livello di servizio, un indicatore chiave della qualità del servizio e della soddisfazione dei clienti. Dove reperirlo Derivato dall'API Zendesk Ticket Metrics, che fornisce informazioni sullo stato SLA di ciascun ticket. Esempi RispettatoViolatoAttivo
	Valutazione della soddisfazione SatisfactionRating	Il punteggio di soddisfazione fornito dal richiedente dopo la risoluzione del ticket.
Descrizione Questo attributo raccoglie il feedback del cliente sulla propria esperienza di supporto, generalmente tramite un sondaggio dopo che un ticket è stato contrassegnato come risolto. Le valutazioni più comuni sono «Buono» o «Cattivo», talvolta accompagnate da un commento. La valutazione della soddisfazione è una metrica fondamentale dei risultati. Correlare i modelli di processo con i punteggi di soddisfazione può rivelare quali comportamenti del processo portano a clienti soddisfatti o insoddisfatti. Ad esempio, l'analisi potrebbe mostrare una forte correlazione tra tassi elevati di riassegnazione o tempi di risoluzione lunghi e valutazioni negative della soddisfazione. Perché è importante Collega direttamente l'esecuzione del processo ai risultati ottenuti dai clienti, aiutando a individuare i comportamenti del processo che determinano la soddisfazione della clientela. Dove reperirlo Zendesk Tickets API, campo 'satisfaction_rating.score' o 'satisfaction_rating.reason'. Esempi BuonoCattivoProposto

Obbligatorio Consigliato Facoltativo

Attività della gestione delle richieste di servizio

Questi sono i passaggi chiave e le tappe fondamentali del processo da acquisire nell’Event Log per individuare con precisione il processo delle richieste di servizio.

7 Consigliato 6 Facoltativo

	Attività	Descrizione
	Obiettivo SLA non rispettato	Questa attività indica il momento in cui una richiesta di assistenza non raggiunge un obiettivo SLA definito, come il tempo di prima risposta o il tempo di risoluzione. Zendesk registra questo evento esplicitamente quando un obiettivo non viene rispettato.
Perché è importante È un evento critico per il monitoraggio della Conformità e un input fondamentale per il KPI SLA Adherence Rate. Individua con precisione il mancato rispetto degli impegni di servizio. Dove reperirlo Acquisito dall’evento 'SLABreach' negli eventi del ticket Zendesk o nel registro di audit. L’evento specifica quale metrica SLA è stata violata. Acquisizione Identificato 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. Viene dedotta da un evento 'Change' nel registro di audit dei 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 della prima assegnazione e la distribuzione del carico di lavoro tra gli agenti. Dove reperirlo Deducibile dal primo evento 'Change' sul campo 'assignee_id' nel registro di audit dei ticket, quando viene impostato l’ID di un utente specifico. Acquisizione Deducibile dal primo evento di modifica che imposta il campo 'assignee_id' su un agente. Tipo di evento inferred
	Richiesta di assistenza chiusa	Rappresenta la chiusura definitiva e permanente della richiesta di assistenza. Un ticket passa automaticamente allo stato 'closed' dopo essere rimasto 'solved' per un periodo prestabilito e non può più essere riaperto.
Perché è importante Questa attività segna la fine definitiva del processo di gestione della richiesta di assistenza. Fornisce il punto finale per calcolare la durata complessiva del caso. Dove reperirlo Deducibile da un evento 'Change' sul campo 'status' nel registro di audit dei ticket, quando il nuovo valore è 'closed'. Acquisizione Deducibile da un evento 'Change' nel registro di audit, quando lo stato diventa 'closed'. Tipo di evento inferred
	Richiesta di assistenza creata	Indica l’inizio del ciclo di vita della richiesta di assistenza, quando un richiedente invia un nuovo ticket attraverso qualsiasi canale. Viene acquisito come evento 'Create' nel registro di audit dei ticket Zendesk e fornisce un momento di inizio definito per il processo.
Perché è importante Questa attività costituisce l’evento iniziale principale per ogni richiesta di assistenza, rendendola essenziale per calcolare i tempi di ciclo end-to-end e analizzare i volumi di acquisizione delle richieste. Dove reperirlo Viene registrato come tipo di evento 'Create' nel registro di audit dei ticket Zendesk. Il timestamp di questo evento corrisponde all’ora di creazione del ticket della richiesta di assistenza. Acquisizione Acquisito direttamente dall’evento 'Create' nel registro di audit dei ticket. Tipo di evento explicit
	Richiesta di assistenza riaperta	Si verifica quando un richiedente risponde a una richiesta che si trova nello stato 'solved', modificandone automaticamente lo stato in 'open'. Indica che la soluzione proposta non era sufficiente.
Perché è importante Questa attività è il principale indicatore di rilavorazione. Analizzarne la frequenza aiuta a misurare la qualità della risoluzione e a individuare le cause dell’insoddisfazione dei clienti. Dove reperirlo Deducibile da un evento 'Change' sul campo 'status' nel registro di audit dei ticket, quando il valore precedente era 'solved' e quello nuovo è 'open'. Acquisizione Deducibile 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 modificato lo stato del ticket in 'solved'. Dal punto di vista dell’agente, la richiesta è considerata completata, ma il richiedente può ancora riaprirla.
Perché è importante È una tappa fondamentale che segna la fine del lavoro attivo dell’agente. Il tempo necessario per raggiungere questo stato è una misura primaria dell’efficienza di risoluzione. Dove reperirlo Deducibile da un evento 'Change' sul campo 'status' nel registro di audit dei ticket, quando il nuovo valore è 'solved'. Acquisizione Deducibile da un evento 'Change' nel registro di audit, quando lo stato diventa 'solved'. Tipo di evento inferred
	Risposta pubblica inviata	Questa attività indica qualsiasi comunicazione inviata da un agente al richiedente. Viene acquisita come evento 'Comment' esplicito nei dati del ticket Zendesk, quando 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 il numero di interazioni necessarie per la risoluzione. Dove reperirlo Si tratta di un evento 'Comment' esplicito nei dati del ticket. I dettagli dell’evento includono l’Attributo 'public: true', che lo distingue dalle note interne. Acquisizione Acquisito dagli eventi 'Comment' dei ticket in cui il flag 'public' è impostato su true. Tipo di evento explicit
	Agente riassegnato	Rappresenta il trasferimento della responsabilità di una richiesta di assistenza da un agente a un altro. Viene dedotto da qualsiasi evento 'Change' successivo sul campo 'assignee_id' dopo l’assegnazione iniziale.
Perché è importante Monitorare le riassegnazioni è fondamentale per calcolare il KPI Agent Reassignment Rate, che aiuta a individuare inefficienze di processo, instradamenti errati o lacune nelle conoscenze. Dove reperirlo Deducibile dagli eventi 'Change' sul campo 'assignee_id' nel registro di audit dei ticket, escludendo il primo evento di assegnazione del ticket. Acquisizione Deducibile dal secondo evento 'Change' e da quelli successivi sul 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 esclusivamente agli altri agenti. Viene registrato come evento 'Comment' con l’Attributo 'public' impostato su false.
Perché è importante Monitorare le note interne offre visibilità sulla collaborazione tra agenti o team, che può essere una fonte di ritardi oppure un elemento chiave per risolvere i problemi in modo efficiente. Dove reperirlo Si tratta di un evento 'Comment' esplicito nei dati del ticket. I dettagli dell’evento includono l’Attributo 'public: false', a indicare che si tratta di una nota interna. Acquisizione Acquisito dagli eventi 'Comment' dei ticket in cui il flag 'public' è impostato su false. Tipo di evento explicit
	Obiettivo SLA applicato	Rappresenta il momento in cui una policy di Service Level Agreement (SLA) viene applicata al ticket della richiesta di assistenza. L’evento viene registrato esplicitamente quando le proprietà del ticket corrispondono alle condizioni di una policy SLA attiva.
Perché è importante Monitorare il momento in cui viene applicato uno SLA è fondamentale per controllare la Conformità, analizzare le potenziali violazioni e comprendere i tempi di servizio previsti per i diversi tipi di richiesta. Dove reperirlo Acquisito dall’evento 'SLAPolicyApplied' negli eventi del ticket Zendesk o nel registro di audit. L’evento specifica quale policy è stata associata. Acquisizione Identificato 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 'Low', 'Normal', 'High' o 'Urgent', è stato aggiornato. Viene acquisito come evento 'Change' sul campo 'priority' nel registro di audit dei ticket.
Perché è importante L’analisi delle modifiche di priorità aiuta a individuare le richieste che diventano più urgenti nel tempo e a valutare se la definizione delle priorità viene gestita in modo efficace. Dove reperirlo Registrato come evento 'Change' sul campo 'priority' nel registro di audit dei ticket Zendesk, con indicazione dei valori precedente e nuovo. Acquisizione Deducibile dagli eventi 'Change' sul campo 'priority' nel registro di audit. Tipo di evento inferred
	Richiesta messa in attesa	Questa attività si verifica quando lo stato della richiesta di assistenza viene modificato in 'on-hold', generalmente perché l’agente è in attesa di informazioni da parte del richiedente o di terzi. Viene dedotta da un evento di modifica dello stato.
Perché è importante Aiuta a isolare e misurare i tempi di attesa che non sono sotto il controllo diretto del team di supporto, offrendo una visione più accurata del tempo di gestione degli agenti. Dove reperirlo Deducibile da un evento 'Change' sul campo 'status' nel registro di audit dei ticket, quando il nuovo valore è 'on-hold'. Acquisizione Deducibile da un evento 'Change' nel registro di audit, quando lo stato diventa 'on-hold'. Tipo di evento inferred
	Richiesta sottoposta a escalation	Rappresenta l’escalation formale di una richiesta di assistenza a un livello di supporto superiore, a un team diverso o alla direzione. In genere viene dedotta da una modifica del gruppo assegnato al ticket o di un campo personalizzato designato per monitorare le escalation.
Perché è importante Monitorare le escalation aiuta a individuare le richieste complesse, le esigenze formative degli agenti di prima linea e i problemi sistemici che richiedono un intervento di livello superiore. Dove reperirlo Non è un evento standard. Deve essere dedotto da un evento 'Change' sul campo 'group_id' verso un gruppo di escalation oppure dalla modifica di un campo personalizzato del ticket utilizzato per monitorare le escalation. Acquisizione Deducibile dalla modifica di 'group_id' o di un campo personalizzato 'escalation'. Tipo di evento inferred

Consigliato Facoltativo

Guide all'estrazione

Come ottenere i Suoi dati da Zendesk Support

Passaggi

Acceda a Zendesk Explore e crei il report principale: acceda all’icona dei prodotti Zendesk nella barra superiore a destra e selezioni Explore. In Explore, faccia clic sull’icona Queries a sinistra, quindi faccia clic su New query. Selezioni il dataset Support: Ticket updates come origine.
Configuri metriche e attributi per gli eventi dei ticket: nel generatore di query, aggiunga una metrica come COUNT(Tickets) per visualizzare i dati. Quindi acceda alla sezione Rows e 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.
Crei un attributo calcolato per ActivityName: per trasformare gli aggiornamenti grezzi in attività significative, crei un attributo calcolato standard. Acceda al menu Calculations, rappresentato dall’icona della calcolatrice, selezioni Standard calculated attribute e lo denomini ActivityName. Incolli nella casella della formula la logica fornita nella sezione Query. Questa formula associa i diversi eventi di aggiornamento dei ticket ai nomi delle attività richiesti.
Raffini e filtri il report principale: aggiunga il nuovo attributo ActivityName alla sezione Rows. Crei un filtro su questo attributo per escludere eventuali valori (null) o valori indesiderati generati dal sistema, così da ripulire il dataset. Aggiunga inoltre un filtro per Ticket created - Date per limitare la query a un intervallo gestibile, ad esempio gli ultimi 6 mesi.
Crei il secondo report per gli eventi SLA: crei un’altra query, selezionando questa volta il dataset Support: SLAs. Questo passaggio è necessario perché gli eventi SLA non sono disponibili nel dataset Ticket updates.
Configuri il report SLA: nella query SLA, aggiunga COUNT(SLA tickets) a Metrics. Nella sezione Rows, aggiunga Ticket ID, SLA policy, SLA target, SLA updated - Timestamp, SLA status e Updater name. L’attività verrà dedotta da SLA status durante la fase di trasformazione.
Esporti entrambi i dataset: esegua entrambe le query nell’interfaccia Explore. Quando le tabelle sono state generate, faccia clic sul pulsante Export e scelga CSV come formato. Otterrà così due file CSV distinti.
Unisca e trasformi i dati: combini i due file CSV utilizzando uno strumento per fogli di calcolo come Microsoft Excel o un linguaggio di scripting come Python. L’obiettivo è creare un unico Event Log. Per il file SLA, dovrà creare la colonna ActivityName. Se SLA status è Attivo, l’attività è SLA Target Applied. Se SLA status è Breached, l’attività è SLA Target Breached. Utilizzi SLA updated - Timestamp come EventTimestamp.
Standardizzi le intestazioni delle colonne: nel file unito finale, rinomini le colonne in modo che corrispondano al formato richiesto per il Process Mining. Ad esempio, rinomini Ticket ID in ServiceRequestId, Update - Timestamp in EventTimestamp e Updater name in AgentName.
Aggiunga le colonne statiche e completi il file: aggiunga due nuove colonne al file CSV finale. Compili SourceSystem con il valore 'Zendesk'. Compili LastDataUpdate con il timestamp dell’esportazione. Il file è ora pronto per il caricamento.

Configurazione

Piano Zendesk: è necessario un piano Zendesk Support che includa Zendesk Explore Professional o Enterprise per creare query e Attributi personalizzati.
Autorizzazioni: deve essere un Agent con le autorizzazioni necessarie per creare e modificare query in Explore. In genere si tratta di un Administrator o di un Agent con un ruolo personalizzato.
Selezione del dataset: questo metodo richiede la creazione di due report separati basati su due 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 compreso tra 3 e 6 mesi.
Attributi calcolati: la logica per ricavare i nomi delle attività viene gestita da un Attributo calcolato personalizzato e complesso all’interno di Explore. Verifichi che la formula sia creata correttamente per evitare errori nell’output.
Volume dei dati: l’interfaccia Zendesk Explore e la funzionalità di esportazione possono risultare lente o andare in timeout con dataset molto grandi. Per estrazioni che coprono più di un anno o milioni di ticket, valuti la possibilità di suddividere l’esportazione in intervalli temporali più brevi.

a 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. Avrà inoltre bisogno dell’accesso amministrativo alla Sua istanza Zendesk Support per generare un token API.
Installi le librerie Python: apra il terminale o il prompt dei comandi e installi con pip le librerie Python necessarie. La libreria requests viene utilizzata per effettuare le chiamate API, mentre pandas serve per manipolare i dati ed esportarli in un file CSV.
```
pip install requests pandas
```
Generi il token API Zendesk: acceda a Zendesk come Administrator. Vada in Admin Center > Apps and integrations > APIs > Zendesk API. Nella sezione Token Access, lo abiliti se non è già attivo e faccia clic su "Add API token". Inserisca una descrizione, ad esempio "ProcessMind Extraction", quindi copi il token generato. Il token non verrà visualizzato 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 nome del dominio Zendesk della Sua azienda), ZENDESK_EMAIL (l’indirizzo e-mail dell’utente Administrator 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’efficiente Incremental Tickets API. Per ogni ticket recupera quindi l’intero audit trail, i commenti e le metriche SLA. Elabora questi eventi in ordine cronologico per creare una cronologia dettagliata.
Mappi gli eventi Zendesk alle attività: lo script contiene la logica per trasformare gli eventi Zendesk grezzi nelle attività aziendali richieste. Ad esempio, un evento 'Change' sul campo 'status' viene associato ad attività come 'Service Request Resolved' o 'Request Placed On-Hold'. Gli eventi relativi ai commenti vengono analizzati per determinare se si tratta di 'Public Reply Sent' o 'Internal Note Added'.
Esegua lo script di estrazione: esegua lo script dal terminale con il comando python your_script_name.py. Lo script mostrerà gli aggiornamenti sull’avanzamento mentre recupera i dati dall’API Zendesk. In base al volume dei dati e ai limiti di frequenza dell’API, il processo potrebbe richiedere del tempo.
Verifichi il file di output: al termine dell’esecuzione, lo script genererà nella stessa directory 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 caricamento: apra il file CSV per verificare che sia formattato correttamente. Le intestazioni delle colonne dovrebbero corrispondere agli Attributi richiesti: ServiceRequestId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate e altri. Il file è ora pronto per essere caricato in ProcessMind.

Configurazione

Accesso all’API Zendesk: lo script richiede un token API attivo associato a un Administrator o a un Agent con autorizzazioni sufficienti. L’e-mail dell’utente configurata nello script deve corrispondere a quella dell’utente che ha creato il token API.
Parametri dello script: prima dell’esecuzione, configuri nello script queste variabili chiave: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN e START_TIME_STR. START_TIME_STR deve essere nel formato 'YYYY-MM-DD'.
Intervallo di date: si consiglia di iniziare con un’estrazione relativa agli ultimi 3-6 mesi di dati (START_TIME_STR). In questo modo otterrà un dataset rappresentativo per l’analisi, evitando tempi di esecuzione eccessivi o il raggiungimento troppo frequente dei limiti dell’API. Un intervallo più ampio aumenterà significativamente il tempo di 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 momento di inizio specificato. Questo metodo è molto più performante rispetto alla scansione di tutti i ticket.
Limitazione della frequenza: Zendesk applica limiti di frequenza alle API. Lo script include una gestione di base per sospendere l’esecuzione quando viene raggiunto un limite, ma nelle istanze di dimensioni molto grandi l’estrazione potrebbe richiedere molto tempo. È preferibile eseguire lo script negli orari di minore attività.
Logica di escalation: l’attività 'Request Escalated' viene dedotta da una modifica al campo group_id. Se la Sua organizzazione utilizza un meccanismo diverso, ad esempio un campo personalizzato del ticket, dovrà modificare la logica dello script per identificare correttamente le escalation.

a 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 la Native Full Account JSON Export utilizzando la funzionalità di esportazione disponibile nel Suo abbonamento e nel Suo account Zendesk. Il percorso esatto nei menu e i requisiti di autorizzazione variano in base alla configurazione dell’account; utilizzi quindi l’opzione di esportazione disponibile in Admin Center e segua il processo di approvazione della Sua organizzazione.
Selezioni un intervallo di date che copra il periodo richiesto per l’analisi, preferibilmente da tre a sei mesi. Se l’esportazione nativa non offre un filtro per data, scarichi l’esportazione completa dell’account e applichi il filtro per data durante la trasformazione.
Scarichi e conservi tutti i file JSON prodotti dall’esportazione. Mantenga i file originali, il timestamp dell’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 contenuti 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 dell’esecuzione.
Normalizzi ogni evento di audit del ticket in una struttura comune contenente ServiceRequestId, timestamp 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à idonea. 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 eventi aggiuntivi.
Risolva gli identificativi di agenti, gruppi, organizzazioni e richiedenti utilizzando, ove disponibili, i corrispondenti record esportati di utenti, gruppi e organizzazioni. Compili AgentName e AssignedTeam in base allo stato di assegnazione al momento dell’evento. Mantenga l’identificativo oppure lasci il valore vuoto quando non è possibile risolvere il nome visualizzato.
Applichi regole deterministiche per gli eventi. Utilizzi l’evento di audit Create del ticket per Service Request Created, gli eventi di audit SLA espliciti per SLA Target Applied e SLA Target Breached, la prima modifica idonea dell’assegnatario per Request Assigned to Agent, le modifiche successive 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 e le modifiche al gruppo o al campo di escalation configurato per Request Escalated.
Ordini le righe risultanti per ServiceRequestId ed EventTimestamp, mantenendo una sequenza stabile dell’evento di origine come criterio di ordinamento secondario. Non deduplichi gli eventi solo perché hanno lo stesso timestamp, poiché più commenti o eventi di audit possono verificarsi nello stesso momento.
Verifichi che tutte le colonne richieste siano presenti e che ogni attività disponga di almeno una riga idonea quando i dati di origine contengono l’evento corrispondente. Esporti il risultato finale come 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 la Zendesk Support Native Full Account JSON Export e conservi ogni file JSON generato dall’esportazione. L’esportazione dovrebbe includere i dati dei ticket e i dati degli audit o degli eventi dei ticket. Se i dati relativi a SLA, commenti, utenti, organizzazioni, gruppi o campi personalizzati vengono forniti separatamente, includa tali file nell’input della trasformazione.
Intervallo di date: per l’estrazione e la convalida iniziali, preferisca un periodo 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 comunque l’archivio completo di origine.
Regole delle attività: configuri mappature esplicite per tutte le 13 attività. Non faccia affidamento su ProcessMind per ricavare gli eventi di assegnazione, escalation, SLA, stato o commento da altre righe.
Configurazione SLA: associ i nomi o le proprietà effettivamente utilizzati dall’account per gli eventi di applicazione e violazione del target SLA. Se l’esportazione non contiene eventi SLA espliciti, non li inventi. Configuri i percorsi di origine corrispondenti nei segnaposto e documenti le attività non disponibili.
Configurazione dell’escalation: individui il campo del gruppo specifico dell’account o il campo personalizzato che rappresenta l’escalation. Imposti ESCALATION_FIELD_ID o la configurazione equivalente sull’identificativo effettivo del campo esportato prima dell’esecuzione.
Percorsi di origine: imposti i percorsi dei file JSON e le mappature delle proprietà JSON nello script. I nomi dei file e la struttura annidata dell’esportazione 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 brand 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: elabori i JSON in modo incrementale ove possibile, 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 produrre l’Event Log finale. Per 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 o gruppi, un abbonamento Zendesk che supporti la funzionalità di esportazione, spazio di archiviazione locale per l’esportazione completa e un ambiente di esecuzione in grado di analizzare JSON e scrivere 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 in conformità ai requisiti aziendali di conservazione, controllo degli accessi e privacy.

a 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 per iniziare?

Inizi oggi stesso a ottimizzare il processo di gestione delle richieste di servizio. Utilizzi questo Template dei dati per individuare i colli di bottiglia e aumentare l'efficienza in Zendesk Support.

Torna alla guida al miglioramento Scarica il Template

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

Elimini i rallentamenti nella gestione delle richieste e la frustrazione degli utenti. Raggiunga il 70% di automazione.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. Configurazione rapida.

Il Suo Template dei dati per la gestione delle richieste di servizio

Il Suo Template dei dati per la gestione delle richieste di servizio

Attributi della gestione delle richieste di servizio

Attività della gestione delle richieste di servizio

Guide all'estrazione

Interfaccia Zendesk Explore per report ed esportazione dei dati

Passaggi

Configurazione

a Query di esempio config

Estrazione tramite API REST di Zendesk con uno script Python

Passaggi

Configurazione

a Query di esempio python

Esportazione JSON nativa completa dell’account Zendesk Support

Passaggi

Configurazione

a Query di esempio config

Pronto per iniziare?

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

Il Suo Template dei dati per la gestione delle richieste di servizio

Il Suo Template dei dati per la gestione delle richieste di servizio

Attributi della gestione delle richieste di servizio

Attività della gestione delle richieste di servizio

Guide all'estrazione

Interfaccia Zendesk Explore per report ed esportazione dei dati

Passaggi

Configurazione

a Query di esempio config

Estrazione tramite API REST di Zendesk con uno script Python

Passaggi

Configurazione

a Query di esempio python

Esportazione JSON nativa completa dell’account Zendesk Support

Passaggi

Configurazione

a Query di esempio config

Pronto per iniziare?

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

La Sua privacy è importante