> Miglioramento Continuo dei Processi > `Incident Management` > Zendesk Support > Template Dati

Il Suo template dati per la gestione degli incidenti

Zendesk Support

Attributi di Gestione degli Incidenti (24) `Attività di Incident Management` (13) Guide all'Estrazione (4)

Il Suo template dati per la gestione degli incidenti

Questo template fornisce una panoramica strutturata dei dati essenziali necessari per analizzare efficacemente il Suo processo di gestione degli incidenti. Delinea gli attributi chiave da raccogliere, le attività critiche da tracciare e include una guida pratica per estrarre questi dati da Zendesk Support. Lo utilizzi per garantire che il Suo progetto di Process Mining inizi con un dataset robusto e completo.

Attributi consigliati da raccogliere
Attività chiave da tracciare per la mappatura del processo
Guida pratica all'estrazione dei dati

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

Scarica Template

Attributi di Gestione degli Incidenti

Questi sono i campi dati raccomandati da includere nel Suo Event Log per un'analisi approfondita del Suo processo di gestione degli incidenti.

5 Obbligatorio 7 Consigliato 12 Facoltativo

	Nome	Descrizione
	`ID` incidente TicketId	L'identificatore univoco generato dal sistema per ogni ticket di incidente.
Descrizione L'ID Incidente è la chiave primaria che identifica in modo univoco ogni case di incidente all'interno di Zendesk Support. Serve come CaseId per il Process Mining, collegando tutte le attività correlate, i cambiamenti di stato e le comunicazioni dal momento in cui l'incidente viene creato fino alla sua chiusura. Nell'analisi, questo ID è cruciale per ricostruire il percorso end-to-end di ogni incidente. Consente l'aggregazione dei dati di evento per tracciare metriche come il tempo totale di risoluzione, il numero di passaggi di consegne e l'adesione agli accordi sui livelli di servizio per i singoli case. Raggruppando gli eventi per questo ID, gli analisti possono visualizzare i flussi di processo, identificare percorsi comuni e rilevare deviazioni dalla procedura standard. Perché è importante Questo è l'identificatore essenziale che collega tutti gli eventi a un singolo incidente, rendendo possibile tracciare l'intero ciclo di vita e analizzare accuratamente le prestazioni del processo. Dove trovare API Ticket Zendesk (/api/v2/tickets/{id}), campo id. Esempi 19428230113521941055
	Timestamp Evento EventTimestamp	La data e l'ora esatte in cui si è verificata l'attività.
Descrizione Questo timestamp registra il momento preciso in cui un evento è accaduto nel ciclo di vita dell'incidente, come quando è stato aggiunto un commento o è stato modificato lo stato. Fornisce l'ordine cronologico per tutte le attività all'interno di un case. Questo attributo è fondamentale per qualsiasi analisi di Process Mining basata sul tempo. Viene utilizzato per calcolare i tempi di ciclo tra le attività, identificare i tempi di attesa, misurare la durata complessiva del case e analizzare le prestazioni del processo in diversi periodi di tempo. Timestamp accurati sono essenziali per creare una mappa di processo animata che mostri il flusso dei case nel tempo e per costruire dashboard di performance che tracciano KPI come il tempo medio di risoluzione. Perché è importante I timestamp forniscono il contesto cronologico per tutte le attività, consentendo il calcolo delle durate, l'identificazione dei bottleneck e l'analisi delle prestazioni del processo nel tempo. Dove trovare API di Audit Ticket Zendesk (/api/v2/tickets/{ticket_id}/audits), campo created_at per ogni evento di audit. Esempi 2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
	Activity ActivityName	Il nome dell'attività aziendale o dell'evento che si è verificato in un punto specifico del ciclo di vita dell'incidente.
Descrizione Questo attributo descrive un passaggio o un'azione specifica intrapresa all'interno del processo di gestione degli incidenti, come 'Incidente Creato', 'Ticket Assegnato all'Agente' o 'Incidente Risolto'. Queste attività sono derivate dai dati del Event Log o dalla traccia di audit di Zendesk, dove vengono registrate le modifiche di sistema. Nel Process Mining, la sequenza di queste attività forma la mappa del processo, che è il fondamento di tutta l'analisi. Analizzando il flusso di attività, le organizzazioni possono scoprire i percorsi reali che gli incidenti intraprendono, identificare i bottleneck tra i passaggi, misurare i cicli di rilavorazione (ad esempio, riaprire un ticket risolto) e verificare la conformità a un processo standard definito. Perché è importante La sequenza di attività definisce il flusso di processo, che è il cuore dell'analisi del Process Mining per identificare inefficienze, deviazioni e opportunità di miglioramento. Dove trovare Derivato da eventi nell'API Zendesk Ticket Audits. Ad esempio, un evento di Cambio sul campo stato potrebbe essere mappato a 'Stato Cambiato'. Esempi Incidente CreatoTicket Assegnato all'AgenteStato cambiato in In SospesoIncidente RisoltoIncidente chiuso
	Sistema di Origine SourceSystem	Il `sistema` da cui sono stati estratti i `dati` dell'`incidente`.
Descrizione Questo attributo identifica l'origine dei dati di processo. Per questa visualizzazione, il valore sarebbe statico, ad esempio, 'Zendesk Support', indicando che tutti gli eventi e gli attributi sono stati acquisiti da quel sistema. Negli ambienti in cui i dati di più sistemi sono combinati, questo campo è critico per distinguere tra diverse fonti di dati. Aiuta a garantire l'integrità dei dati e consente un'analisi specifica della fonte, come il confronto del processo di gestione degli incidenti in Zendesk con un altro strumento ITSM. Perché è importante Identifica l'origine dei dati, il che è cruciale per la data governance e per le analisi che combinano dati da più sistemi sorgente. Dove trovare Valore statico impostato durante la trasformazione dei dati per identificare l'origine dei dati. Esempi Zendesk SupportZendesk
	Ultimo `Data Update` LastDataUpdate	Il timestamp che indica l'ultima volta che i dati per questo processo sono stati aggiornati.
Descrizione Questo attributo registra la data e l'ora dell'estrazione o dell'aggiornamento più recente dei dati dal sistema sorgente. È tipicamente un singolo valore applicato all'intero dataset da un dato ciclo di aggiornamento. Queste informazioni sono vitali per la governance dei dati e per gli utenti dell'analisi del Process Mining. Fornisce contesto sulla freschezza dei dati, aiutando gli analisti a capire se stanno visualizzando le informazioni più attuali disponibili. Questo è particolarmente importante per monitorare le prestazioni operative e prendere decisioni tempestive basate sull'analisi. Perché è importante Fornisce un contesto cruciale sulla freschezza dei dati, garantendo che gli utenti comprendano quanto sia attuale l'analisi e quando i dati sono stati acquisiti l'ultima volta. Dove trovare Timestamp generato dal processo ETL/pipeline di dati al completamento dell'aggiornamento dei dati. Esempi 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Agente Assegnato Assignee	L'agente di supporto individuale attualmente assegnato per gestire l'incidente.
Descrizione Questo attributo identifica l'agente specifico responsabile dell'incidente in un dato momento. I cambiamenti nell'assegnatario sono eventi critici che significano un passaggio di consegne del lavoro da una persona all'altra. L'analisi dell'agente assegnato aiuta a comprendere la distribuzione del carico di lavoro, le prestazioni individuali e i modelli di collaborazione. Il monitoraggio delle modifiche in questo campo è essenziale per calcolare il KPI 'Passaggi di Consegne Medi per Incidente' e identificare situazioni in cui gli incidenti vengono spesso passati di mano, il che può indicare lacune di conoscenza o instradamento inefficiente. Perché è importante Identifica l'agente responsabile, consentendo l'analisi del carico di lavoro e il monitoraggio dei passaggi di consegne, il che è cruciale per identificare le inefficienze di processo. Dove trovare API Ticket Zendesk, campo assignee_id. Le modifiche sono registrate nell'API di Audit Ticket. Esempi John SmithJane DoeAutomazione Service Desk
	Canale di segnalazione Channel	Il canale attraverso il quale l'incidente è stato inizialmente segnalato, come 'Email', 'Web' o 'API'.
Descrizione Questo attributo cattura il metodo utilizzato dall'utente finale o dal sistema per creare il ticket di incidente. Comprendere il canale è importante per analizzare le fonti degli incidenti e adattare di conseguenza il processo di supporto. L'analisi degli incidenti per canale può rivelare schemi diversi. Ad esempio, gli incidenti segnalati via telefono potrebbero avere tempi di risoluzione più brevi rispetto a quelli via email. Queste informazioni supportano la dashboard 'Volume di Throughput Incidenti' e aiutano nella pianificazione delle risorse e negli sforzi di ottimizzazione dei canali. Perché è importante Aiuta ad analizzare i volumi degli incidenti e le prestazioni del processo per fonte, consentendo miglioramenti di processo specifici per canale e allocazione delle risorse. Dove trovare API Ticket Zendesk, campo via.channel. Esempi webemailapiphone
	Gruppo Assegnato AssignedGroup	Il team o gruppo di supporto attualmente assegnato all'incidente.
Descrizione Questo attributo indica quale team è responsabile dell'incidente. Gli incidenti spesso si spostano tra diversi livelli di supporto o gruppi specializzati, ad esempio, dal 'Supporto L1' al 'Team di Rete'. Questa è una dimensione critica per analizzare i passaggi di consegne del processo e identificare i bottleneck. Monitorando come gli incidenti fluiscono tra i gruppi, gli analisti possono misurare le dipendenze inter-team, calcolare i tempi di coda per team specifici e ottimizzare le regole di instradamento. Supporta direttamente la dashboard 'Analisi Passaggi di Consegne e Rilavorazione'. Perché è importante Traccia la proprietà del team, che è essenziale per analizzare i passaggi di consegne inter-team, identificare i bottleneck specifici del team e misurare i tempi di coda. Dove trovare API Ticket Zendesk, campo group_id. Le modifiche sono registrate nell'API di Audit Ticket. Esempi Supporto L1L2 Network TeamL3 InfrastructureFatturazione
	Ora Fine Evento EventEndTime	Il timestamp che indica quando un'attività è stata completata.
Descrizione L'Ora di Fine dell'Evento segna la conclusione di un'attività. Nei dati del Event Log, l'ora di fine di un'attività è spesso dedotta come l'ora di inizio dell'attività successiva nella sequenza per quel case. Per l'ultima attività in un case, l'ora di fine potrebbe essere la stessa della sua ora di inizio. Questo attributo è essenziale per calcolare la durata delle singole attività (ProcessingTime) e il tempo di attesa tra le attività. Queste informazioni sono la base per l'analisi dei bottleneck, consentendo agli analisti di vedere non solo quanto tempo impiega un passaggio, ma anche quanto tempo il case è rimasto inattivo prima che quel passaggio iniziasse. Perché è importante Consente il calcolo delle durate delle attività e dei tempi di attesa, il che è fondamentale per eseguire un'analisi dettagliata dei colli di bottiglia e identificare i ritardi di processo. Dove trovare Calcolato come l'ora di inizio dell'evento successivo all'interno dello stesso case. L'ora di fine dell'ultimo evento può essere la stessa della sua ora di inizio o dell'ora di chiusura del case. Esempi 2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
	Priorità TicketPriority	Il livello di priorità assegnato all'incidente, come 'Bassa', 'Normale', 'Alta' o 'Urgente'.
Descrizione La priorità di un incidente determina l'urgenza richiesta per una risposta e una risoluzione. È un fattore chiave nella prioritizzazione del lavoro e nell'allocazione delle risorse all'interno del team di supporto. Nell'analisi dei processi, la priorità viene utilizzata per segmentare gli incidenti per confrontare i loro flussi di processo e le loro prestazioni. Ad esempio, gli analisti possono verificare se gli incidenti 'Urgente' vengono effettivamente risolti più velocemente di quelli a priorità 'Bassa'. Viene anche utilizzata per monitorare la conformità agli SLA, poiché gli SLA sono spesso definiti in base ai livelli di priorità. Il KPI 'Tasso di Variazione della Priorità' si basa sul monitoraggio delle modifiche a questo campo. Perché è importante Questo attributo è cruciale per segmentare l'analisi, valutare l'efficacia della prioritizzazione e monitorare la conformità agli SLA per diversi livelli di urgenza. Dove trovare API Ticket Zendesk, campo priority. Le modifiche sono registrate nell'API di Audit Ticket. Esempi lownormalhighurgent
	Stato SLA SlaStatus	Lo stato attuale dell'accordo sul livello di servizio (SLA) per l'incidente.
Descrizione Questo attributo indica se un incidente è sulla buona strada per raggiungere i suoi obiettivi SLA definiti, li ha già violati, o se i timer SLA sono in pausa. Zendesk traccia automaticamente le metriche SLA basate sulle politiche configurate. Questo è un attributo critico per la dashboard 'Monitoraggio della Conformità SLA'. Fornisce una misura diretta delle prestazioni rispetto agli impegni di servizio. Analizzando quando e perché gli SLA vengono violati, le organizzazioni possono identificare le debolezze del processo e migliorare l'affidabilità del servizio. Supporta direttamente il KPI 'Tasso di Adesione SLA degli Incidenti'. Perché è importante Misura direttamente le prestazioni rispetto agli impegni di servizio, consentendo l'analisi delle violazioni degli SLA e il monitoraggio proattivo per migliorare la conformità. Dove trovare API Metriche Ticket Zendesk (/api/v2/ticket_metrics.json), derivata da campi come sla_policy, breached_at, ecc. Esempi AttivoSospesoViolatoEvaso
	Stato ticket TicketStatus	Lo stato del ticket di incidente al momento dell'evento, come 'Aperto', 'In Sospeso' o 'Risolto'.
Descrizione Questo attributo riflette lo stato del ticket di incidente in diversi punti del suo ciclo di vita. Gli stati standard di Zendesk includono nuovo, aperto, in sospeso, in attesa, risolto e chiuso. Il monitoraggio delle modifiche a questo campo è un modo primario per generare attività per il Process Mining. L'analisi dello stato del ticket è fondamentale per comprendere il processo. Aiuta a identificare quanto tempo gli incidenti trascorrono in certi stati, come 'In Sospeso', che spesso indica l'attesa di una risposta del cliente. È anche fondamentale per definire il completamento del case e calcolare i tempi di risoluzione. Perché è importante Il monitoraggio dei cambiamenti di stato è fondamentale per comprendere la progressione del processo, identificare i tempi di attesa e definire i punti di inizio e fine del ciclo di vita dell'incidente. Dove trovare API Ticket Zendesk, campo status. Le modifiche sono registrate nell'API di Audit Ticket. Esempi newapertoin sospesorisoltoclosed
	`Handoff Count` HandoffCount	Il numero totale di volte in cui un incidente è stato riassegnato a un agente o gruppo diverso.
Descrizione Questa metrica calcolata quantifica il numero di volte in cui la responsabilità di un incidente è stata trasferita. Ogni modifica nel campo Assegnatario o Gruppo Assegnato incrementa questo conteggio per il case. I passaggi di consegne sono una fonte comune di inefficienza e ritardo nella gestione degli incidenti. Un elevato numero di passaggi di consegne può indicare regole di instradamento poco chiare, lacune di conoscenza nei team di supporto o processi eccessivamente complessi. Questa metrica è la base per il KPI 'Passaggi di Consegne Medi per Incidente' ed è cruciale per la dashboard 'Analisi Passaggi di Consegne e Rilavorazione'. Perché è importante Quantifica l'attrito del processo causato dai trasferimenti, aiutando a individuare le inefficienze di instradamento e le lacune di conoscenza che prolungano i tempi di risoluzione. Dove trovare Calcolato contando il numero di volte in cui il campo Gruppo Assegnato o Assegnatario è cambiato per un incidente. Esempi 0135
	Categoria della causa radice RootCauseCategory	La categoria di alto livello della causa principale sottostante dell'incidente.
Descrizione Questo attributo viene utilizzato per classificare la ragione fondamentale per cui si è verificato un incidente. Viene tipicamente catturato verso la fine del ciclo di vita dell'incidente, spesso come parte di un processo di post-mortem o di gestione dei problemi, e memorizzato in un campo personalizzato. Questi dati sono essenziali per la dashboard 'Accuratezza Identificazione Causa Radice' e il KPI 'Copertura RCA'. L'analisi degli incidenti per causa radice aiuta a identificare problemi ricorrenti, guidando gli sforzi per implementare soluzioni permanenti e ridurre il volume futuro degli incidenti. Sposta l'attenzione dalla risoluzione reattiva dei problemi alla prevenzione proattiva dei problemi. Perché è importante Consente una gestione proattiva dei problemi categorizzando le cause degli incidenti, aiutando a identificare le tendenze e prevenire futuri accadimenti. Dove trovare Questo è tipicamente un campo ticket personalizzato. Verifichi la configurazione dei Campi Ticket nel Centro Amministrazione Zendesk. Esempi Bug SoftwareGuasto HardwareErrore dell'utenteInterruzione di rete
	Durata del Caso CaseDuration	Il tempo totale trascorso dalla creazione dell'incidente alla sua chiusura finale.
Descrizione Questa metrica calcolata rappresenta il tempo di ciclo end-to-end per un singolo incidente. Viene calcolata prendendo la differenza tra il timestamp del primissimo evento (ad esempio, 'Incidente Creato') e l'ultimissimo evento (ad esempio, 'Incidente Chiuso'). La Durata del Case è un indicatore chiave di performance (KPI) primario per l'efficienza complessiva del processo. È ampiamente utilizzato nelle dashboard per mostrare i tempi di ciclo medi, identificare i case a lungo termine e analizzare le tendenze nel tempo. Fornisce una misura di alto livello della velocità con cui il processo può gestire e risolvere gli incidenti. Perché è importante Questo è un KPI critico per misurare la velocità complessiva del processo e identificare i fattori che contribuiscono a tempi di risoluzione lunghi. Dove trovare Calcolato trovando la differenza tra il timestamp dell'ultimo evento e il primo evento per ogni ID Incidente. Esempi 25920060480086400
	È Automatizzato IsAutomated	Un flag booleano che indica se un'attività è stata eseguita da un sistema automatizzato o da un agente umano.
Descrizione Questo attributo derivato permette di distinguere tra gli eventi eseguiti da utenti umani e quelli gestiti da automazioni di sistema, trigger o integrazioni API. In genere, viene determinato verificando se l'autore di un evento è un utente di sistema noto. Comprendere il livello di automazione è fondamentale per una moderna analisi dei processi. Aiuta a valutare l'efficacia delle regole di automazione, a identificare i task manuali che potrebbero essere automatizzati e a misurare l'impatto dell'automazione su efficienza e tempi di risoluzione. Questo attributo può essere utilizzato per confrontare l'andamento dei processi tra attività automatizzate e manuali. Perché è importante Distingue tra azioni umane e di sistema, il che è essenziale per analizzare l'impatto dell'automazione sull'efficienza del processo e identificare nuove opportunità di automazione. Dove trovare Derivato controllando se l'autore dell'evento (author_id nell'API Ticket Audits) corrisponde a un sistema noto o a un utente di automazione. Esempi truefalse
	È Risoluzione al Primo Contatto IsFirstContactResolution	Un flag booleano che è vero se l'incidente è stato risolto dal primo agente o gruppo assegnato senza alcun passaggio di consegna.
Descrizione La First Contact Resolution (FCR) è una metrica critica per l'efficienza del centro di supporto e la soddisfazione del cliente. Questo attributo calcolato segnala gli incidenti risolti senza essere riassegnati a un altro agente o team. La logica tipicamente controlla se il ticket ha raggiunto lo stato 'Risolto' pur rimanendo assegnato all'agente e al gruppo iniziali. Nel Process Mining, questo consente il calcolo diretto del tasso FCR e il confronto dei percorsi di processo degli incidenti FCR rispetto a quelli che hanno richiesto l'escalation, aiutando a identificare opportunità per potenziare il supporto di prima linea. Perché è importante Misura direttamente l'efficienza del punto di contatto di supporto iniziale e aiuta a identificare le opportunità per anticipare la risoluzione nel processo. Dove trovare Flag booleano calcolato. Vero se lo stato del ticket è 'risolto' o 'chiuso' e c'è stato un solo assegnatario o gruppo assegnato unico per tutta la durata del ciclo di vita dell'incidente. Esempi truefalse
	Gravità Severity	Il livello di impatto che l'incidente ha sull'azienda.
Descrizione La Gravità definisce l'impatto aziendale di un incidente, spesso in combinazione con la priorità per determinare l'urgenza complessiva. È tipicamente configurata come un campo personalizzato in Zendesk. L'analisi della gravità aiuta a comprendere la criticità degli incidenti gestiti. È una dimensione chiave per la segmentazione dei dati in dashboard come 'Monitoraggio della Conformità SLA' e 'Metriche di Efficacia della Prioritizzazione'. Il confronto dei flussi di processo per diversi livelli di gravità può rivelare se gli incidenti ad alta gravità vengono gestiti con la velocità e le risorse appropriate. Perché è importante Indica l'impatto aziendale di un incidente, consentendo un'analisi focalizzata sulle questioni più critiche e garantendo che siano risolte in modo efficiente. Dove trovare Questo è tipicamente un campo personalizzato. Verifichi la configurazione dei Campi Ticket nel Centro Amministrazione Zendesk. Esempi 1 - Critico2 - Alto3 - Medio4 - Basso
	Mittente Submitter	L'utente finale o il sistema che ha originariamente segnalato l'incidente.
Descrizione Questo attributo identifica la persona o l'entità che ha creato il ticket. Questo è distinto dal richiedente, poiché un agente potrebbe creare un ticket per conto di qualcun altro. Nell'analisi, il mittente può essere utilizzato per capire chi segnala i problemi. Se combinato con i dati dell'organizzazione, può aiutare a identificare se clienti specifici o gruppi di utenti stanno riscontrando un volume elevato di incidenti. Questo può guidare iniziative di supporto proattivo o sforzi di formazione. Perché è importante Identifica la fonte della segnalazione dell'incidente, che può essere analizzata per trovare modelli correlati a utenti specifici, dipartimenti o sistemi automatizzati. Dove trovare API Ticket Zendesk, campo submitter_id. Esempi alice.jones@example.combob.williams@example.comMonitor di Sistema
	Organizzazione Cliente Organization	L'organizzazione o l'azienda a cui appartiene il richiedente dell'incidente.
Descrizione Questo attributo collega un incidente all'organizzazione del cliente. È essenziale per gli ambienti di supporto B2B dove i livelli di servizio e i processi di supporto possono variare per cliente. L'analisi degli incidenti per organizzazione consente ai team di supporto di monitorare la salute dei clienti, identificare problemi ricorrenti che interessano clienti specifici e garantire che gli obblighi contrattuali siano rispettati. È una dimensione chiave per filtrare dashboard e rapporti per fornire una visione delle prestazioni centrata sul cliente. Perché è importante Consente un'analisi specifica per cliente, aiutando a monitorare i livelli di servizio, identificare le tendenze per i clienti chiave e gestire efficacemente le relazioni con i clienti. Dove trovare API Ticket Zendesk, campo organization_id. Esempi Global Tech Inc.Innovare SoluzioniData Corp
	Tags Tags	Un elenco di tag applicati all'incidente per categorizzazione e contesto.
Descrizione I Tags sono etichette flessibili che possono essere aggiunte ai ticket per fornire contesto aggiuntivo o aiutare nella categorizzazione e nell'instradamento. Possono essere aggiunti manualmente dagli agenti o automaticamente tramite trigger e automazioni. I Tags sono una ricca fonte di dati per l'analisi del Process Mining. Possono essere utilizzati per creare segmenti granulari per l'analisi, come filtrare gli incidenti relativi a un lancio di prodotto specifico ('launch_q4') o a un'interruzione nota ('outage_20231027'). Questa flessibilità consente indagini approfondite che vanno oltre i campi standard dei ticket. Perché è importante Offre un modo flessibile per categorizzare e filtrare gli incidenti, consentendo un'analisi dettagliata e specifica del contesto che potrebbe non essere possibile solo con i campi standard. Dove trovare API Ticket Zendesk, campo tags. Esempi vip_usernetwork_issueoutage_20231027billing_related
	Tempo di Elaborazione ProcessingTime	La durata di una singola attività, che rappresenta il tempo trascorso a lavorare attivamente su un task.
Descrizione Questa metrica misura il tempo trascorso dall'inizio di un'attività alla sua fine. Viene calcolata come la differenza tra EventEndTime e EventTimestamp per ogni riga nel Event Log. Il tempo di elaborazione, noto anche come durata dell'attività, aiuta a differenziare tra tempo di lavoro attivo e tempo di inattività o di attesa. Nella dashboard 'Panoramica Attività Bottleneck', tempi di elaborazione medi elevati per determinate attività possono indicare task complessi e che richiedono molto tempo. Questo è distinto dal tempo di attesa, che rappresenta i ritardi tra i task. Perché è importante Misura il tempo di lavoro attivo per attività specifiche, aiutando a identificare le attività che sono intrinsecamente dispendiose in termini di tempo e sono candidate per la semplificazione o l'automazione. Dove trovare Calcolato come la differenza tra EventEndTime e EventTimestamp per ogni attività. Esempi 30018003600
	Tipo di Ticket TicketType	La classificazione del ticket, come 'Incidente', 'Problema', 'Domanda' o 'Task'.
Descrizione Questo campo categorizza il ticket in base alla natura della richiesta. Il processo di gestione degli incidenti si concentra specificamente sui ticket in cui il tipo è 'Incidente', che rappresenta un'interruzione non pianificata o una riduzione della qualità di un servizio IT. Nell'analisi, questo attributo è utilizzato principalmente come filtro per garantire che solo gli incidenti siano inclusi nella vista del processo. Può anche essere utilizzato per un'analisi ITSM più ampia per confrontare i processi di gestione degli incidenti rispetto ai problemi o alle richieste di servizio. Perché è importante Consente il filtraggio dei dati per concentrarsi specificamente sugli incidenti, assicurando che l'analisi del processo sia pertinente al ciclo di vita della gestione degli incidenti. Dove trovare API Ticket Zendesk, campo type. Esempi incidentproblemquestiontask
	Valutazione di Soddisfazione SatisfactionRating	La valutazione di soddisfazione fornita dall'utente finale dopo la risoluzione dell'incidente.
Descrizione Questo attributo cattura il feedback del cliente sulla loro esperienza di supporto, tipicamente raccolto tramite un sondaggio dopo che il ticket è stato risolto. Le valutazioni comuni in Zendesk sono 'Buono' o 'Cattivo'. Sebbene non sia una misura diretta dell'efficienza del processo, le valutazioni di soddisfazione forniscono una metrica di risultato critica. Nel Process Mining, questo può essere correlato alle varianti del processo per comprendere quali percorsi di risoluzione portano a una maggiore soddisfazione del cliente. Ad esempio, gli incidenti con più passaggi di consegne ricevono valutazioni inferiori? Perché è importante Fornisce una metrica di risultato chiave che può essere correlata alle caratteristiche del processo per comprendere come la performance del processo influenzi la soddisfazione dell'utente. Dove trovare API Metriche Ticket Zendesk (/api/v2/ticket_metrics.json), campo satisfaction_rating.score. Esempi goodbadofferedunoffered

Obbligatorio Consigliato Facoltativo

`Attività di Incident Management`

Questi sono i passaggi di processo e le tappe fondamentali critiche da catturare nel Suo Event Log per una scoperta e un'analisi accurate.

6 Consigliato 7 Facoltativo

	Activity	Descrizione
	Incidente chiuso	Segna la fine definitiva del ciclo di vita dell'incidente quando il ticket viene chiuso in modo permanente. In Zendesk, ciò avviene spesso automaticamente dopo un periodo di tempo prestabilito dalla risoluzione, ed è catturato come un cambiamento di stato finale.
Perché è importante Questa è l'attività di fine definitiva per il processo. La durata totale del processo è calcolata da 'Incidente Creato' a questo evento, fornendo una visione end-to-end del tempo di ciclo. Dove trovare Catturato dall'audit log del ticket tramite un evento di 'Cambio' in cui il nuovo valore del campo 'status' diventa 'chiuso'. Acquisisci Identificato da un evento di 'Cambio' per il campo 'status' a 'chiuso'. Tipo di evento explicit
	Incidente Creato	Segna l'inizio del ciclo di vita dell'incidente quando un nuovo ticket viene creato in Zendesk. Questo evento viene catturato esplicitamente attraverso l'audit log di creazione dei ticket di Zendesk, servendo come punto di partenza per ogni case.
Perché è importante Questa è l'attività di inizio primaria. L'analisi del tempo da questo evento ad altri è cruciale per misurare la durata complessiva del ciclo di vita del ticket e i tempi di risposta iniziali. Dove trovare Questo è un evento esplicito catturato nei log di audit dei ticket di Zendesk. Ogni nuovo ticket genera un evento 'Crea' con un timestamp corrispondente. Acquisisci Direttamente dall'evento di creazione del ticket nell'audit log. Tipo di evento explicit
	Incidente Risolto	Questa tappa fondamentale si verifica quando un agente ha implementato una soluzione e contrassegna il ticket come 'risolto'. Questa è un'azione esplicita, catturata come modifica di stato nel log di audit del ticket.
Perché è importante Questa è l'attività di risoluzione primaria e un punto critico per misurare il tempo di risoluzione. Il tempo tra questo evento e 'Incidente Chiuso' rappresenta il periodo di conferma dell'utente o di auto-chiusura. Dove trovare Catturato dall'audit log del ticket tramite un evento di 'Cambio' in cui il nuovo valore del campo 'status' diventa 'risolto'. Acquisisci Identificato da un evento di 'Cambio' per il campo 'status' a 'risolto'. Tipo di evento explicit
	Stato Modificato in Aperto	Indica che un agente ha iniziato a lavorare attivamente sull'incidente. Questa attività è tipicamente inferita dal cambiamento del campo 'status' del ticket da 'nuovo' a 'aperto', significando l'inizio della fase di indagine e diagnosi.
Perché è importante Questo evento segna la transizione dalla coda al lavoro attivo. La durata che i ticket trascorrono nello stato 'nuovo' prima di passare a 'aperto' è una metrica chiave per il tempo di risposta iniziale. Dove trovare Inferito dall'audit log del ticket identificando un evento di 'Cambio' in cui il nuovo valore del campo 'status' è 'aperto' e il valore precedente era 'nuovo'. Acquisisci Inferito da un cambiamento del campo stato da 'new' a 'open'. Tipo di evento inferred
	Ticket Assegnato all'Agente	Questa attività si verifica quando un ticket viene assegnato a un agente specifico per la gestione. Questo è un evento esplicito registrato nella cronologia di audit del ticket e significa che un individuo ha assunto la responsabilità.
Perché è importante Questa tappa è essenziale per misurare il tempo alla prima assegnazione ed è la base per analizzare i passaggi di consegne, la rilavorazione e i tassi di Risoluzione al Primo Contatto. Dove trovare Catturato dall'audit log del ticket quando il campo 'assignee_id' viene popolato o modificato. La prima assegnazione è una tappa fondamentale per il calcolo del KPI. Acquisisci Identificato da un evento di 'Cambio' per il campo 'assignee_id' nell'audit log del ticket. Tipo di evento explicit
	Ticket riassegnato	Si verifica quando la proprietà del ticket viene trasferita da un agente o gruppo all'altro dopo l'assegnazione iniziale. Questo è un evento esplicito tracciato nella cronologia di audit del ticket.
Perché è importante Le riassegnazioni sono fondamentali per analizzare i passaggi di consegne e le rilavorazioni. Un'alta frequenza di riassegnazioni spesso indica un instradamento iniziale errato, problemi complessi o bottleneck di processo. Dove trovare Catturato dall'audit log del ticket identificando un evento di 'Cambio' sul campo 'assignee_id' o 'group_id' dopo che è stato popolato per la prima volta. Acquisisci Identificato da un successivo evento di 'Cambio' per il campo 'assignee_id' o 'group_id'. Tipo di evento explicit
	Nota Interna Aggiunta	Questa attività significa collaborazione interna, dove un agente aggiunge una nota privata al ticket per altri membri del team. Questo è catturato esplicitamente quando un commento non è contrassegnato come pubblico.
Perché è importante L'analisi delle note interne può fornire insight su problemi complessi che richiedono collaborazione, ma un numero eccessivo potrebbe indicare lacune di conoscenza o inefficienze di processo. Dove trovare Catturato dai dati dei commenti del ticket. Un commento viene identificato come nota interna quando il suo attributo 'pubblico' è falso. Acquisisci Evento registrato quando un nuovo commento con 'public: false' viene aggiunto al ticket. Tipo di evento explicit
	Obiettivo SLA violato	Segna il momento in cui un ticket non è riuscito a soddisfare un Accordo sul Livello del Servizio definito, come il tempo di prima risposta o il tempo di risoluzione. Questo evento è calcolato in base alle definizioni delle policy SLA e ai timestamp di aggiornamento del ticket.
Perché è importante Questo evento supporta direttamente il monitoraggio della conformità agli SLA. Identificare quando e perché si verificano le violazioni è fondamentale per migliorare l'affidabilità del servizio e la fiducia del cliente. Dove trovare Questo è un evento calcolato. Può essere derivato analizzando i dati 'sla_policy_metrics' associati a un ticket, utilizzando il timestamp 'breached_at' per ogni obiettivo SLA. Acquisisci Derivato dal timestamp 'breached_at' all'interno dei dati delle metriche SLA del ticket. Tipo di evento calculated
	Priorità Impostata	Viene definito il livello di priorità di un incidente (ad es. Bassa, Normale, Alta, Urgente). Questo viene registrato come un evento di cambiamento esplicito e detta l'urgenza e il tempo di risposta richiesto per il ticket.
Perché è importante Il monitoraggio di quando e come viene impostata la priorità è vitale per la dashboard 'Metriche di Efficacia della Prioritizzazione', garantendo che le questioni critiche siano affrontate tempestivamente. Dove trovare Catturato da un evento di 'Cambio' sul campo 'priorità' all'interno dell'audit log del ticket. I cambiamenti successivi possono anche essere tracciati per misurare il KPI del Tasso di Variazione della Priorità. Acquisisci Identificato da un evento di 'Cambio' per il campo 'priorità' nell'audit log del ticket. Tipo di evento explicit
	Risposta Pubblica Inviata	Rappresenta una comunicazione inviata da un agente di supporto all'utente finale. Questo è un evento esplicito in Zendesk, catturato ogni volta che un commento pubblico viene aggiunto al ticket.
Perché è importante Il monitoraggio delle risposte pubbliche è importante per comprendere la frequenza di comunicazione e può essere una parte chiave della timeline nell'analisi dei ritardi di conferma dell'utente. Dove trovare Catturato dai dati dei commenti del ticket. Un commento viene identificato come pubblico quando il suo attributo 'pubblico' è vero. Acquisisci Evento registrato quando un nuovo commento con 'public: true' viene aggiunto al ticket. Tipo di evento explicit
	Soddisfazione Utente Valutata	Rappresenta il momento in cui l'utente finale fornisce una valutazione di soddisfazione per il supporto ricevuto. Questo è un evento esplicito catturato in Zendesk dopo che un ticket è stato risolto.
Perché è importante L'analisi delle valutazioni di soddisfazione fornisce un feedback cruciale sulle prestazioni dell'agente e sull'efficacia del processo, collegando le metriche di processo ai risultati per il cliente. Dove trovare Catturato dai dati di valutazione della soddisfazione associati al ticket. Questo include tipicamente un punteggio ('buono' o 'cattivo') e un commento opzionale. Acquisisci Evento registrato quando una valutazione di soddisfazione viene inviata per il ticket. Tipo di evento explicit
	Stato cambiato in In Sospeso	Indica che il processo è in pausa in attesa di una risposta dal richiedente. Questo evento è inferito dal cambiamento del campo 'status' del ticket in 'in sospeso'.
Perché è importante Questa attività è cruciale per calcolare il Tempo di Attesa per la Conferma dell'Utente. Lunghe durate in questo stato possono aumentare significativamente il tempo di risoluzione complessivo ed evidenziare ritardi nella comunicazione. Dove trovare Inferito dall'audit log del ticket identificando un evento di 'Cambio' in cui il nuovo valore del campo 'status' è 'in sospeso'. Acquisisci Inferito da un cambiamento del campo stato a 'in sospeso'. Tipo di evento inferred
	Ticket Assegnato al Gruppo	Rappresenta l'instradamento iniziale o il triage di un incidente a un gruppo di supporto specifico. Questo è tipicamente il primo passo nell'assegnazione della responsabilità ed è registrato come evento di modifica esplicito nella cronologia di audit del ticket.
Perché è importante Il monitoraggio delle assegnazioni ai gruppi aiuta ad analizzare l'efficienza del processo di triage iniziale e a identificare i ritardi prima che un ticket venga instradato al team corretto. Dove trovare Catturato dall'audit log del ticket ogni volta che il campo 'group_id' viene impostato o modificato. La prima istanza di questo cambiamento dopo la creazione è l'assegnazione iniziale. Acquisisci Identificato da un evento di 'Cambio' per il campo 'group_id' nell'audit log del ticket. Tipo di evento explicit

Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i vostri `dati` da Zendesk Support.

Fasi

Accesso a Zendesk Explore: accedete alla vostra istanza Zendesk Support con un account utente che disponga dei permessi per creare e gestire report in Zendesk Explore.
Creazione di un nuovo report: andate nel modulo Explore. Cliccate sull'icona 'Report' nella barra di navigazione a sinistra, quindi sul pulsante 'Nuovo report'.
Selezione del dataset: nella finestra 'Scegli un dataset', selezionate Support: Ticket updates [default]. Questo dataset contiene la traccia di audit per ogni modifica ai ticket, essenziale per la creazione di un event log.
Aggiunta degli attributi iniziali (Colonne): nel builder del report, andate nella sezione 'Righe'. Cliccate su 'Aggiungi' e selezionate i seguenti attributi, che formeranno le colonne del vostro event log: ID ticket, Update - Timestamp, Stato ticket, Nome assegnatario, Gruppo ticket, Priorità ticket, Canale ticket, Modifiche - Nome campo, Modifiche - Valore precedente, Modifiche - Valore nuovo, Commento pubblico.
Creazione degli attributi calcolati: questo è il passaggio più critico. Andate nel menu 'Calcoli' (l'icona del becher) e selezionate 'Attributo calcolato standard'. Create i tre attributi definiti nella sezione 'Query' sottostante: ActivityName, SourceSystem e LastDataUpdate. È necessario copiare esattamente le formule fornite.
Perfezionamento delle colonne del report: aggiungete i nuovi attributi calcolati (ActivityName, SourceSystem, LastDataUpdate) alla sezione 'Righe'. A questo punto potete rimuovere i campi grezzi usati per creare ActivityName (Modifiche - Nome campo, Modifiche - Valore precedente, Modifiche - Valore nuovo, Commento pubblico) per pulire la visualizzazione.
Aggiunta dei filtri del report: andate nella sezione 'Filtri' e cliccate su 'Aggiungi'. Aggiungete un filtro per Update - Date e selezionate un intervallo temporale appropriato (ad es. gli ultimi 3 mesi). Aggiungete un altro filtro sull'attributo calcolato ActivityName ed escludete i valori null per rimuovere gli aggiornamenti dei ticket che non corrispondono a un'attività desiderata.
Esecuzione e revisione del report: Zendesk Explore aggiornerà automaticamente il report man mano che aggiungete attributi e filtri. Controllate la tabella dei dati per assicurarvi che righe e colonne appaiano come previsto. Il report dovrebbe mostrare una riga per ogni evento.
Esportazione dei dati in CSV: una volta finalizzato il report, cliccate sul pulsante 'Esporta' in alto a destra e selezionate 'CSV'. Zendesk genererà e scaricherà il file.
Preparazione per l'upload: aprite il file CSV esportato. Rinominate le intestazioni delle colonne in modo che corrispondano ai nomi degli attributi richiesti dal vostro strumento di Process Mining (ad es. rinominate 'ID ticket' in TicketId, 'Update - Timestamp' in EventTimestamp). Assicuratevi che il formato della data per i timestamp sia conforme allo standard ISO 8601. Il file è ora pronto per l'upload.

Configurazione

Dataset Zendesk: il report deve essere basato sul dataset Support: Ticket updates [default]. Questo è l'unico dataset standard che fornisce la traccia di audit dettagliata necessaria per ricostruire il processo evento per evento.
Filtro intervallo di date: è fondamentale applicare un filtro temporale per limitare il volume dei dati. Utilizzate l'attributo Update - Date come filtro principale. Per un'analisi iniziale, si consiglia solitamente un intervallo di 3-6 mesi.
Filtro attività: dopo aver creato l'attributo calcolato ActivityName, è necessario filtrare il report per escludere le righe in cui questo valore è null. In questo modo si rimuovono dall'event log le modifiche ai ticket irrilevanti (ad es. aggiornamenti di sistema, modifiche ai tag).
Attributi calcolati: la logica di questa estrazione si basa fortemente su un attributo calcolato standard per tradurre le modifiche ai campi grezzi del ticket in nomi di attività leggibili. La precisione della formula è fondamentale.
Prerequisiti: l'utente che esegue il report deve avere almeno il ruolo 'Viewer' in Zendesk Explore. Per creare e salvare il report, sono necessari i permessi di 'Editor' o 'Admin'.

a Query di Esempio config

This extraction is configured using the Zendesk Explore UI. The core logic is contained within a standard calculated attribute. 

**1. Dataset Selection:**
* `Support: Ticket updates [default]`

**2. Report Columns (Add to 'Rows' panel):**
* `Ticket ID`
* `ActivityName` (Calculated Attribute)
* `EventTimestamp` (Use the `Update - Timestamp` attribute)
* `SourceSystem` (Calculated Attribute)
* `LastDataUpdate` (Calculated Attribute)
* `Ticket status`
* `Assignee name`
* `Ticket group`
* `Ticket priority`
* `Ticket channel`
* `SLA metric status`
* `EventEndTime` (Use the `Update - Timestamp` attribute again)

**3. Standard Calculated Attribute Formulas:**

**Attribute Name:** `ActivityName`
**Formula:**
```
IF ([Changes - Field name] = "status" AND [Changes - Previous value] = NULL AND [Changes - New value] = "new") THEN "Incident Created"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "open") THEN "Status Changed to Open"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN "Status Changed to Pending"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "solved") THEN "Incident Resolved"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "closed") THEN "Incident Closed"
ELIF ([Changes - Field name] = "group_id") THEN "Ticket Assigned to Group"
ELIF ([Changes - Field name] = "assignee_id") THEN "Ticket Assigned to Agent"
ELIF ([Changes - Field name] = "priority") THEN "Priority Set"
ELIF ([Changes - Field name] = "satisfaction_score") THEN "User Satisfaction Rated"
ELIF ([Changes - Field name] = "SLA metric breach") THEN "SLA Target Breached"
ELIF ([Comment public] = TRUE) THEN "Public Reply Sent"
ELIF ([Comment public] = FALSE) THEN "Internal Note Added"
ELSE NULL
ENDIF
```

**Attribute Name:** `SourceSystem`
**Formula:**
```
"Zendesk Support"
```

**Attribute Name:** `LastDataUpdate`
**Formula:**
```
NOW()
```

Fasi

Prerequisiti: assicuratevi di avere Python 3.6+ installato sul sistema, insieme alle librerie requests e pandas. Potete installarle tramite pip: pip install requests pandas.
Generazione del token API Zendesk: accedete alla vostra istanza Zendesk Support come amministratori. Andate in Centro amministrativo > App e integrazioni > API > API Zendesk. Nella sezione "Token API", aggiungete un nuovo token attivo e salvatelo in modo sicuro.
Configurazione dello script Python: create un nuovo file Python (ad es. extract_zendesk_logs.py) e incollatevi lo script fornito. Aggiornate le variabili segnaposto all'inizio dello script (ZENDESK_SUBDOMAIN, ZENDESK_EMAIL e ZENDESK_API_TOKEN) con le vostre credenziali. Impostate START_TIMESTAMP per definire l'inizio del periodo di estrazione desiderato (un timestamp Unix epoch).
Endpoint API: lo script utilizza principalmente due endpoint API di Zendesk. L'endpoint incremental/tickets/cursor.json serve a estrarre in modo efficiente tutti i ticket aggiornati a partire dallo START_TIMESTAMP. Per ogni ticket, lo script interroga poi l'endpoint tickets/{ticket_id}/audits.json per ottenere la cronologia dettagliata di ogni modifica ed evento.
Esecuzione dello script: lanciate lo script dal terminale usando il comando: python extract_zendesk_logs.py. Lo script inizierà a recuperare i dati dalle API di Zendesk.
Monitoraggio dei progressi: lo script stamperà sulla console il numero di ticket elaborati, permettendovi di monitorarne l'avanzamento. A seconda dell'intervallo di date e del volume di ticket, l'operazione potrebbe richiedere tempo.
Recupero dati e paginazione: lo script gestisce automaticamente la paginazione delle API. Inizia con l'URL di esportazione iniziale e segue l'after_url fornito in ogni risposta API finché non sono stati recuperati tutti i ticket del periodo.
Trasformazione degli eventi: per ogni ticket, lo script itera sulla cronologia di audit. Analizza ogni evento mappando i tipi di evento interni di Zendesk (come Create, Change, Comment) nelle attività di business richieste (come Incidente creato, Stato modificato in Aperto, Risposta pubblica inviata).
Gestione dei dati SLA: lo script include una funzione dedicata, get_sla_breach_events, per recuperare le metriche SLA per ogni ticket risolto. Ciò è necessario perché le violazioni degli SLA non sono eventi standard nel log di audit. Questa funzione effettua una chiamata API supplementare per ottenere i dettagli dell'applicazione delle policy SLA.
Generazione dell'event log: una volta elaborati tutti i ticket, lo script compila gli eventi estratti in un DataFrame pandas e salva l'event log finale come file CSV denominato zendesk_incident_event_log.csv nella stessa directory dello script.
Preparazione per l'upload: verificate la correttezza del file CSV generato. Il file è ora nel formato corretto per essere caricato direttamente in ProcessMind per l'analisi.

Configurazione

Credenziali API di Zendesk: è necessario fornire il sottodominio Zendesk, l'indirizzo email associato a un account amministratore o agente e un token API valido. Archiviate queste credenziali in modo sicuro ed evitate l'hardcoding negli script sotto controllo di versione per l'uso in produzione.
Timestamp di inizio (START_TIMESTAMP): questo valore intero determina il punto di partenza per l'estrazione dei dati e deve essere un timestamp Unix epoch. Si consiglia di partire da 3-6 mesi nel passato per raccogliere una quantità significativa di dati senza sovraccaricare il sistema. È possibile utilizzare un convertitore online per ottenere il timestamp corretto per una data specifica.
Limiti di frequenza delle API (Rate Limiting): lo script effettua numerose chiamate API. Zendesk applica limiti di frequenza che variano in base al piano. Sebbene lo script sia funzionale per volumi di dati moderati, per istanze molto grandi potrebbe essere necessario aggiungere chiamate time.sleep() all'interno dei cicli per evitare di raggiungere il limite e ricevere un errore 429.
Librerie Python richieste: lo script dipende dalla libreria requests per le chiamate API e dalla libreria pandas per la manipolazione dei dati e l'esportazione in CSV. Assicuratevi che siano installate nel vostro ambiente Python.
Permessi utente: l'account utente associato al token API deve disporre di permessi sufficienti per leggere i dati dei ticket, inclusi gli audit e le metriche dei ticket.

a Query di Esempio python

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

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">"[your_subdomain]"
ZENDESK_EMAIL = class="hl-string">"[your_login_email@example.com]"
ZENDESK_API_TOKEN = class="hl-string">"[your_zendesk_api_token]"

class=class="hl-string">"hl-comment"># Set the start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is for January 1, 2023 00:00:00 UTC
class=class="hl-string">"hl-comment"># It's recommended to extract the last 3-6 months of data.
START_TIMESTAMP = 1672531200 

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

def get_sla_breach_events(ticket_id, session):
    class="hl-string">"""Fetches SLA metrics for a ticket and creates breach events."""
    sla_events = []
    try:
        metrics_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/metrics.json"
        response = session.get(metrics_url)
        response.raise_for_status()
        metrics = response.json().get(class="hl-string">'ticket_metric', {})
        
        if metrics and metrics.get(class="hl-string">'sla_policy'):
            for sla in metrics.get(class="hl-string">'sla_policy').get(class="hl-string">'policy_metrics', []):
                if sla.get(class="hl-string">'breach_at'):
                    breach_timestamp = sla[class="hl-string">'breach_at']
                    sla_events.append({
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'ActivityName': class="hl-string">'SLA Target Breached',
                        class="hl-string">'EventTimestamp': breach_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': class="hl-string">'breached',
                        class="hl-string">'Assignee': metrics.get(class="hl-string">'assignee_updated_at'), 
                        class="hl-string">'AssignedGroup': metrics.get(class="hl-string">'group_stations'),
                        class="hl-string">'TicketPriority': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'Channel': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'SlaStatus': fclass="hl-string">"{sla.get('metric')} Breached",
                        class="hl-string">'EventEndTime': breach_timestamp
                    })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not fetch SLA metrics for ticket {ticket_id}: {e}")
    return sla_events

def process_ticket(ticket, session):
    class="hl-string">"""Processes a single ticket's audits to extract all relevant events."""
    all_events = []
    ticket_id = ticket[class="hl-string">'id']
    ticket_created_at = ticket[class="hl-string">'created_at']
    
    class=class="hl-string">"hl-comment"># 1. Incident Created event
    all_events.append({
        class="hl-string">'TicketId': ticket_id,
        class="hl-string">'ActivityName': class="hl-string">'Incident Created',
        class="hl-string">'EventTimestamp': ticket_created_at,
        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
        class="hl-string">'TicketStatus': class="hl-string">'new',
        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
        class="hl-string">'SlaStatus': None,
        class="hl-string">'EventEndTime': ticket_created_at
    })
    
    class=class="hl-string">"hl-comment"># Process audits for other events
    audits_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    try:
        response = session.get(audits_url)
        response.raise_for_status()
        audits = response.json().get(class="hl-string">'audits', [])
        
        is_first_group_assignment = True
        is_first_agent_assignment = True

        for audit in audits:
            event_timestamp = audit[class="hl-string">'created_at']
            for event in audit.get(class="hl-string">'events', []):
                activity = {}
                event_type = event.get(class="hl-string">'type')

                if event_type == class="hl-string">'Change':
                    field_name = event.get(class="hl-string">'field_name')
                    value = event.get(class="hl-string">'value')
                    
                    if field_name == class="hl-string">'group_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Group' if is_first_group_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_group_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'AssignedGroup': value}

                    elif field_name == class="hl-string">'assignee_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Agent' if is_first_agent_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_agent_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'Assignee': value}
                        
                    elif field_name == class="hl-string">'priority':
                        activity = {class="hl-string">'ActivityName': class="hl-string">'Priority Set', class="hl-string">'TicketPriority': value}
                        
                    elif field_name == class="hl-string">'status':
                        if value == class="hl-string">'open': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Open', class="hl-string">'TicketStatus': class="hl-string">'open'}
                        elif value == class="hl-string">'pending': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Pending', class="hl-string">'TicketStatus': class="hl-string">'pending'}
                        elif value == class="hl-string">'solved': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Resolved', class="hl-string">'TicketStatus': class="hl-string">'solved'}
                        elif value == class="hl-string">'closed': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Closed', class="hl-string">'TicketStatus': class="hl-string">'closed'}
                        
                elif event_type == class="hl-string">'Comment':
                    is_public = event.get(class="hl-string">'public', False)
                    activity_name = class="hl-string">'Public Reply Sent' if is_public else class="hl-string">'Internal Note Added'
                    activity = {class="hl-string">'ActivityName': activity_name}

                elif event_type == class="hl-string">'SatisfactionRating':
                    activity = {class="hl-string">'ActivityName': class="hl-string">'User Satisfaction Rated'}

                if activity:
                    base_event = {
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'EventTimestamp': event_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': ticket.get(class="hl-string">'status'),
                        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
                        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
                        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaStatus': None,
                        class="hl-string">'EventEndTime': event_timestamp
                    }
                    base_event.update(activity)
                    all_events.append(base_event)
    
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not process audits for ticket {ticket_id}: {e}")

    class=class="hl-string">"hl-comment"># Get SLA Breach events if ticket is solved
    if ticket.get(class="hl-string">'status') in [class="hl-string">'solved', class="hl-string">'closed']:
        all_events.extend(get_sla_breach_events(ticket_id, session))

    return all_events

def main():
    class="hl-string">"""Main function to fetch tickets and generate the event log."""
    all_ticket_events = []
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}"
    
    with requests.Session() as session:
        session.auth = AUTH
        
        ticket_count = 0
        while url:
            try:
                response = session.get(url)
                response.raise_for_status()
                data = response.json()
                tickets = data.get(class="hl-string">'tickets', [])
                
                for ticket in tickets:
                    ticket_count += 1
                    all_ticket_events.extend(process_ticket(ticket, session))
                    if ticket_count % 100 == 0:
                        print(fclass="hl-string">"Processed {ticket_count} tickets...")

                if data.get(class="hl-string">'end_of_stream', True):
                    print(class="hl-string">"Reached the end of the ticket stream.")
                    break
                
                url = data.get(class="hl-string">'after_url')
                class=class="hl-string">"hl-comment"># Respect rate limits
                time.sleep(1) 

            except requests.exceptions.RequestException as e:
                print(fclass="hl-string">"An API error occurred: {e}")
                if hasattr(e, class="hl-string">'response') and e.response.status_code == 429:
                    retry_after = int(e.response.headers.get(class="hl-string">'Retry-After', 60))
                    print(fclass="hl-string">"Rate limit exceeded. Retrying after {retry_after} seconds...")
                    time.sleep(retry_after)
                else:
                    break

    if not all_ticket_events:
        print(class="hl-string">"No events were extracted. Check configuration and API access.")
        return

    print(fclass="hl-string">"\nTotal events extracted: {len(all_ticket_events)}")
    df = pd.DataFrame(all_ticket_events)
    
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    cols = [
        class="hl-string">'TicketId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventEndTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'TicketStatus', class="hl-string">'Assignee', class="hl-string">'AssignedGroup', class="hl-string">'TicketPriority', class="hl-string">'Channel', class="hl-string">'SlaStatus'
    ]
    df = df[cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    output_file = class="hl-string">'zendesk_incident_event_log.csv'
    df.to_csv(output_file, index=False)
    print(fclass="hl-string">"Event log successfully saved to {output_file}")

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

Fasi

Prerequisiti: assicuratevi di avere Python 3.6+ installato sul sistema, insieme alle librerie requests e pandas. Potete installarle tramite pip: pip install requests pandas.
Generazione del token API Zendesk: accedete alla vostra istanza Zendesk Support come amministratori. Andate in Centro amministrativo > App e integrazioni > API > API Zendesk. Nella sezione "Token API", aggiungete un nuovo token attivo e salvatelo in modo sicuro.
Configurazione dello script Python: create un nuovo file Python (ad es. extract_zendesk_logs.py) e incollatevi lo script fornito. Aggiornate le variabili segnaposto all'inizio dello script (ZENDESK_SUBDOMAIN, ZENDESK_EMAIL e ZENDESK_API_TOKEN) con le vostre credenziali. Impostate START_TIMESTAMP per definire l'inizio del periodo di estrazione desiderato (un timestamp Unix epoch).
Endpoint API: lo script utilizza principalmente due endpoint API di Zendesk. L'endpoint incremental/tickets/cursor.json serve a estrarre in modo efficiente tutti i ticket aggiornati a partire dallo START_TIMESTAMP. Per ogni ticket, lo script interroga poi l'endpoint tickets/{ticket_id}/audits.json per ottenere la cronologia dettagliata di ogni modifica ed evento.
Esecuzione dello script: lanciate lo script dal terminale usando il comando: python extract_zendesk_logs.py. Lo script inizierà a recuperare i dati dalle API di Zendesk.
Monitoraggio dei progressi: lo script stamperà sulla console il numero di ticket elaborati, permettendovi di monitorarne l'avanzamento. A seconda dell'intervallo di date e del volume di ticket, l'operazione potrebbe richiedere tempo.
Recupero dati e paginazione: lo script gestisce automaticamente la paginazione delle API. Inizia con l'URL di esportazione iniziale e segue l'after_url fornito in ogni risposta API finché non sono stati recuperati tutti i ticket del periodo.
Trasformazione degli eventi: per ogni ticket, lo script itera sulla cronologia di audit. Analizza ogni evento mappando i tipi di evento interni di Zendesk (come Create, Change, Comment) nelle attività di business richieste (come Incidente creato, Stato modificato in Aperto, Risposta pubblica inviata).
Gestione dei dati SLA: lo script include una funzione dedicata, get_sla_breach_events, per recuperare le metriche SLA per ogni ticket risolto. Ciò è necessario perché le violazioni degli SLA non sono eventi standard nel log di audit. Questa funzione effettua una chiamata API supplementare per ottenere i dettagli dell'applicazione delle policy SLA.
Generazione dell'event log: una volta elaborati tutti i ticket, lo script compila gli eventi estratti in un DataFrame pandas e salva l'event log finale come file CSV denominato zendesk_incident_event_log.csv nella stessa directory dello script.
Preparazione per l'upload: verificate la correttezza del file CSV generato. Il file è ora nel formato corretto per essere caricato direttamente in ProcessMind per l'analisi.

Configurazione

Credenziali API di Zendesk: è necessario fornire il sottodominio Zendesk, l'indirizzo email associato a un account amministratore o agente e un token API valido. Archiviate queste credenziali in modo sicuro ed evitate l'hardcoding negli script sotto controllo di versione per l'uso in produzione.
Timestamp di inizio (START_TIMESTAMP): questo valore intero determina il punto di partenza per l'estrazione dei dati e deve essere un timestamp Unix epoch. Si consiglia di partire da 3-6 mesi nel passato per raccogliere una quantità significativa di dati senza sovraccaricare il sistema. È possibile utilizzare un convertitore online per ottenere il timestamp corretto per una data specifica.
Limiti di frequenza delle API (Rate Limiting): lo script effettua numerose chiamate API. Zendesk applica limiti di frequenza che variano in base al piano. Sebbene lo script sia funzionale per volumi di dati moderati, per istanze molto grandi potrebbe essere necessario aggiungere chiamate time.sleep() all'interno dei cicli per evitare di raggiungere il limite e ricevere un errore 429.
Librerie Python richieste: lo script dipende dalla libreria requests per le chiamate API e dalla libreria pandas per la manipolazione dei dati e l'esportazione in CSV. Assicuratevi che siano installate nel vostro ambiente Python.
Permessi utente: l'account utente associato al token API deve disporre di permessi sufficienti per leggere i dati dei ticket, inclusi gli audit e le metriche dei ticket.

a Query di Esempio python

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

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">"[your_subdomain]"
ZENDESK_EMAIL = class="hl-string">"[your_login_email@example.com]"
ZENDESK_API_TOKEN = class="hl-string">"[your_zendesk_api_token]"

class=class="hl-string">"hl-comment"># Set the start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is for January 1, 2023 00:00:00 UTC
class=class="hl-string">"hl-comment"># It's recommended to extract the last 3-6 months of data.
START_TIMESTAMP = 1672531200 

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

def get_sla_breach_events(ticket_id, session):
    class="hl-string">"""Fetches SLA metrics for a ticket and creates breach events."""
    sla_events = []
    try:
        metrics_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/metrics.json"
        response = session.get(metrics_url)
        response.raise_for_status()
        metrics = response.json().get(class="hl-string">'ticket_metric', {})
        
        if metrics and metrics.get(class="hl-string">'sla_policy'):
            for sla in metrics.get(class="hl-string">'sla_policy').get(class="hl-string">'policy_metrics', []):
                if sla.get(class="hl-string">'breach_at'):
                    breach_timestamp = sla[class="hl-string">'breach_at']
                    sla_events.append({
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'ActivityName': class="hl-string">'SLA Target Breached',
                        class="hl-string">'EventTimestamp': breach_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': class="hl-string">'breached',
                        class="hl-string">'Assignee': metrics.get(class="hl-string">'assignee_updated_at'), 
                        class="hl-string">'AssignedGroup': metrics.get(class="hl-string">'group_stations'),
                        class="hl-string">'TicketPriority': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'Channel': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'SlaStatus': fclass="hl-string">"{sla.get('metric')} Breached",
                        class="hl-string">'EventEndTime': breach_timestamp
                    })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not fetch SLA metrics for ticket {ticket_id}: {e}")
    return sla_events

def process_ticket(ticket, session):
    class="hl-string">"""Processes a single ticket's audits to extract all relevant events."""
    all_events = []
    ticket_id = ticket[class="hl-string">'id']
    ticket_created_at = ticket[class="hl-string">'created_at']
    
    class=class="hl-string">"hl-comment"># 1. Incident Created event
    all_events.append({
        class="hl-string">'TicketId': ticket_id,
        class="hl-string">'ActivityName': class="hl-string">'Incident Created',
        class="hl-string">'EventTimestamp': ticket_created_at,
        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
        class="hl-string">'TicketStatus': class="hl-string">'new',
        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
        class="hl-string">'SlaStatus': None,
        class="hl-string">'EventEndTime': ticket_created_at
    })
    
    class=class="hl-string">"hl-comment"># Process audits for other events
    audits_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    try:
        response = session.get(audits_url)
        response.raise_for_status()
        audits = response.json().get(class="hl-string">'audits', [])
        
        is_first_group_assignment = True
        is_first_agent_assignment = True

        for audit in audits:
            event_timestamp = audit[class="hl-string">'created_at']
            for event in audit.get(class="hl-string">'events', []):
                activity = {}
                event_type = event.get(class="hl-string">'type')

                if event_type == class="hl-string">'Change':
                    field_name = event.get(class="hl-string">'field_name')
                    value = event.get(class="hl-string">'value')
                    
                    if field_name == class="hl-string">'group_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Group' if is_first_group_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_group_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'AssignedGroup': value}

                    elif field_name == class="hl-string">'assignee_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Agent' if is_first_agent_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_agent_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'Assignee': value}
                        
                    elif field_name == class="hl-string">'priority':
                        activity = {class="hl-string">'ActivityName': class="hl-string">'Priority Set', class="hl-string">'TicketPriority': value}
                        
                    elif field_name == class="hl-string">'status':
                        if value == class="hl-string">'open': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Open', class="hl-string">'TicketStatus': class="hl-string">'open'}
                        elif value == class="hl-string">'pending': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Pending', class="hl-string">'TicketStatus': class="hl-string">'pending'}
                        elif value == class="hl-string">'solved': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Resolved', class="hl-string">'TicketStatus': class="hl-string">'solved'}
                        elif value == class="hl-string">'closed': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Closed', class="hl-string">'TicketStatus': class="hl-string">'closed'}
                        
                elif event_type == class="hl-string">'Comment':
                    is_public = event.get(class="hl-string">'public', False)
                    activity_name = class="hl-string">'Public Reply Sent' if is_public else class="hl-string">'Internal Note Added'
                    activity = {class="hl-string">'ActivityName': activity_name}

                elif event_type == class="hl-string">'SatisfactionRating':
                    activity = {class="hl-string">'ActivityName': class="hl-string">'User Satisfaction Rated'}

                if activity:
                    base_event = {
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'EventTimestamp': event_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': ticket.get(class="hl-string">'status'),
                        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
                        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
                        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaStatus': None,
                        class="hl-string">'EventEndTime': event_timestamp
                    }
                    base_event.update(activity)
                    all_events.append(base_event)
    
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not process audits for ticket {ticket_id}: {e}")

    class=class="hl-string">"hl-comment"># Get SLA Breach events if ticket is solved
    if ticket.get(class="hl-string">'status') in [class="hl-string">'solved', class="hl-string">'closed']:
        all_events.extend(get_sla_breach_events(ticket_id, session))

    return all_events

def main():
    class="hl-string">"""Main function to fetch tickets and generate the event log."""
    all_ticket_events = []
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}"
    
    with requests.Session() as session:
        session.auth = AUTH
        
        ticket_count = 0
        while url:
            try:
                response = session.get(url)
                response.raise_for_status()
                data = response.json()
                tickets = data.get(class="hl-string">'tickets', [])
                
                for ticket in tickets:
                    ticket_count += 1
                    all_ticket_events.extend(process_ticket(ticket, session))
                    if ticket_count % 100 == 0:
                        print(fclass="hl-string">"Processed {ticket_count} tickets...")

                if data.get(class="hl-string">'end_of_stream', True):
                    print(class="hl-string">"Reached the end of the ticket stream.")
                    break
                
                url = data.get(class="hl-string">'after_url')
                class=class="hl-string">"hl-comment"># Respect rate limits
                time.sleep(1) 

            except requests.exceptions.RequestException as e:
                print(fclass="hl-string">"An API error occurred: {e}")
                if hasattr(e, class="hl-string">'response') and e.response.status_code == 429:
                    retry_after = int(e.response.headers.get(class="hl-string">'Retry-After', 60))
                    print(fclass="hl-string">"Rate limit exceeded. Retrying after {retry_after} seconds...")
                    time.sleep(retry_after)
                else:
                    break

    if not all_ticket_events:
        print(class="hl-string">"No events were extracted. Check configuration and API access.")
        return

    print(fclass="hl-string">"\nTotal events extracted: {len(all_ticket_events)}")
    df = pd.DataFrame(all_ticket_events)
    
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    cols = [
        class="hl-string">'TicketId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventEndTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'TicketStatus', class="hl-string">'Assignee', class="hl-string">'AssignedGroup', class="hl-string">'TicketPriority', class="hl-string">'Channel', class="hl-string">'SlaStatus'
    ]
    df = df[cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    output_file = class="hl-string">'zendesk_incident_event_log.csv'
    df.to_csv(output_file, index=False)
    print(fclass="hl-string">"Event log successfully saved to {output_file}")

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

Fasi

Accesso a Zendesk Explore: accedete alla vostra istanza Zendesk Support con un account utente che disponga dei permessi per creare e gestire report in Zendesk Explore.
Creazione di un nuovo report: andate nel modulo Explore. Cliccate sull'icona 'Report' nella barra di navigazione a sinistra, quindi sul pulsante 'Nuovo report'.
Selezione del dataset: nella finestra 'Scegli un dataset', selezionate Support: Ticket updates [default]. Questo dataset contiene la traccia di audit per ogni modifica ai ticket, essenziale per la creazione di un event log.
Aggiunta degli attributi iniziali (Colonne): nel builder del report, andate nella sezione 'Righe'. Cliccate su 'Aggiungi' e selezionate i seguenti attributi, che formeranno le colonne del vostro event log: ID ticket, Update - Timestamp, Stato ticket, Nome assegnatario, Gruppo ticket, Priorità ticket, Canale ticket, Modifiche - Nome campo, Modifiche - Valore precedente, Modifiche - Valore nuovo, Commento pubblico.
Creazione degli attributi calcolati: questo è il passaggio più critico. Andate nel menu 'Calcoli' (l'icona del becher) e selezionate 'Attributo calcolato standard'. Create i tre attributi definiti nella sezione 'Query' sottostante: ActivityName, SourceSystem e LastDataUpdate. È necessario copiare esattamente le formule fornite.
Perfezionamento delle colonne del report: aggiungete i nuovi attributi calcolati (ActivityName, SourceSystem, LastDataUpdate) alla sezione 'Righe'. A questo punto potete rimuovere i campi grezzi usati per creare ActivityName (Modifiche - Nome campo, Modifiche - Valore precedente, Modifiche - Valore nuovo, Commento pubblico) per pulire la visualizzazione.
Aggiunta dei filtri del report: andate nella sezione 'Filtri' e cliccate su 'Aggiungi'. Aggiungete un filtro per Update - Date e selezionate un intervallo temporale appropriato (ad es. gli ultimi 3 mesi). Aggiungete un altro filtro sull'attributo calcolato ActivityName ed escludete i valori null per rimuovere gli aggiornamenti dei ticket che non corrispondono a un'attività desiderata.
Esecuzione e revisione del report: Zendesk Explore aggiornerà automaticamente il report man mano che aggiungete attributi e filtri. Controllate la tabella dei dati per assicurarvi che righe e colonne appaiano come previsto. Il report dovrebbe mostrare una riga per ogni evento.
Esportazione dei dati in CSV: una volta finalizzato il report, cliccate sul pulsante 'Esporta' in alto a destra e selezionate 'CSV'. Zendesk genererà e scaricherà il file.
Preparazione per l'upload: aprite il file CSV esportato. Rinominate le intestazioni delle colonne in modo che corrispondano ai nomi degli attributi richiesti dal vostro strumento di Process Mining (ad es. rinominate 'ID ticket' in TicketId, 'Update - Timestamp' in EventTimestamp). Assicuratevi che il formato della data per i timestamp sia conforme allo standard ISO 8601. Il file è ora pronto per l'upload.

Configurazione

Dataset Zendesk: il report deve essere basato sul dataset Support: Ticket updates [default]. Questo è l'unico dataset standard che fornisce la traccia di audit dettagliata necessaria per ricostruire il processo evento per evento.
Filtro intervallo di date: è fondamentale applicare un filtro temporale per limitare il volume dei dati. Utilizzate l'attributo Update - Date come filtro principale. Per un'analisi iniziale, si consiglia solitamente un intervallo di 3-6 mesi.
Filtro attività: dopo aver creato l'attributo calcolato ActivityName, è necessario filtrare il report per escludere le righe in cui questo valore è null. In questo modo si rimuovono dall'event log le modifiche ai ticket irrilevanti (ad es. aggiornamenti di sistema, modifiche ai tag).
Attributi calcolati: la logica di questa estrazione si basa fortemente su un attributo calcolato standard per tradurre le modifiche ai campi grezzi del ticket in nomi di attività leggibili. La precisione della formula è fondamentale.
Prerequisiti: l'utente che esegue il report deve avere almeno il ruolo 'Viewer' in Zendesk Explore. Per creare e salvare il report, sono necessari i permessi di 'Editor' o 'Admin'.

a Query di Esempio config

This extraction is configured using the Zendesk Explore UI. The core logic is contained within a standard calculated attribute. 

**1. Dataset Selection:**
* `Support: Ticket updates [default]`

**2. Report Columns (Add to 'Rows' panel):**
* `Ticket ID`
* `ActivityName` (Calculated Attribute)
* `EventTimestamp` (Use the `Update - Timestamp` attribute)
* `SourceSystem` (Calculated Attribute)
* `LastDataUpdate` (Calculated Attribute)
* `Ticket status`
* `Assignee name`
* `Ticket group`
* `Ticket priority`
* `Ticket channel`
* `SLA metric status`
* `EventEndTime` (Use the `Update - Timestamp` attribute again)

**3. Standard Calculated Attribute Formulas:**

**Attribute Name:** `ActivityName`
**Formula:**
```
IF ([Changes - Field name] = "status" AND [Changes - Previous value] = NULL AND [Changes - New value] = "new") THEN "Incident Created"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "open") THEN "Status Changed to Open"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN "Status Changed to Pending"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "solved") THEN "Incident Resolved"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "closed") THEN "Incident Closed"
ELIF ([Changes - Field name] = "group_id") THEN "Ticket Assigned to Group"
ELIF ([Changes - Field name] = "assignee_id") THEN "Ticket Assigned to Agent"
ELIF ([Changes - Field name] = "priority") THEN "Priority Set"
ELIF ([Changes - Field name] = "satisfaction_score") THEN "User Satisfaction Rated"
ELIF ([Changes - Field name] = "SLA metric breach") THEN "SLA Target Breached"
ELIF ([Comment public] = TRUE) THEN "Public Reply Sent"
ELIF ([Comment public] = FALSE) THEN "Internal Note Added"
ELSE NULL
ENDIF
```

**Attribute Name:** `SourceSystem`
**Formula:**
```
"Zendesk Support"
```

**Attribute Name:** `LastDataUpdate`
**Formula:**
```
NOW()
```

Il Suo template dati per la gestione degli incidenti

Il Suo template dati per la gestione degli incidenti

Attributi di Gestione degli Incidenti

`Attività di Incident Management`

Guide all'Estrazione

Esportazione Report UI Zendesk Explore in file CSV

Fasi

Configurazione

a Query di Esempio config

Script Python che utilizza le API REST di Zendesk Support

Fasi

Configurazione

a Query di Esempio python

API di Esportazione Incrementale Zendesk per la Sincronizzazione di Dati in Blocco

Fasi

Configurazione

a Query di Esempio python

Strumento ETL di Terze Parti con Connettore API Zendesk

Fasi

Configurazione

a Query di Esempio config

Pronto per iniziare?

Ottimizzate la Gestione degli Incidenti, Risolvete Più Velocemente Oggi

Il Suo template dati per la gestione degli incidenti

Il Suo template dati per la gestione degli incidenti

Attributi di Gestione degli Incidenti

Attività di Incident Management

Guide all'Estrazione

Esportazione Report UI Zendesk Explore in file CSV

Fasi

Configurazione

a Query di Esempio config

Script Python che utilizza le API REST di Zendesk Support

Fasi

Configurazione

a Query di Esempio python

API di Esportazione Incrementale Zendesk per la Sincronizzazione di Dati in Blocco

Fasi

Configurazione

a Query di Esempio python

Strumento ETL di Terze Parti con Connettore API Zendesk

Fasi

Configurazione

a Query di Esempio config

Abbiamo a cuore la Sua privacy

Pronto per iniziare?

Ottimizzate la Gestione degli Incidenti, Risolvete Più Velocemente Oggi

`Attività di Incident Management`