> Miglioramento continuo dei processi > Gestione degli incidenti > Zendesk Support > Template dei dati

Il Suo template dei dati per la gestione degli incidenti

Zendesk Support

Attributi per la gestione degli incidenti (23) Attività di gestione degli incidenti (13) Guide all’estrazione (4)

Il Suo template dei dati per la gestione degli incidenti

Questo template offre una panoramica strutturata dei dati essenziali per analizzare in modo efficace il processo di gestione degli incidenti. Indica gli attributi principali da raccogliere, le attività da monitorare e fornisce istruzioni pratiche per estrarre i dati da Zendesk Support. Lo utilizzi per avviare il progetto di Process Mining con un insieme di dati solido e completo.

Attributi consigliati da raccogliere
Attività principali da monitorare per la mappatura dei processi
Indicazioni pratiche per l’estrazione dei dati

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

Scarica il template

Attributi per la gestione degli incidenti

Questi sono i campi dati consigliati da includere nell’Event Log per analizzare in modo approfondito il processo di gestione degli incidenti.

5 Obbligatorio 7 Consigliato 11 Facoltativo

	Nome	Descrizione
	Data e ora dell’evento EventTimestamp	Data e ora esatte in cui si è verificata l’attività.
Descrizione Questa data e ora registra il momento preciso in cui si è verificato un evento nel ciclo di vita dell’incidente, ad esempio quando è stato aggiunto un commento o modificato lo stato. Definisce l’ordine cronologico di tutte le attività di un caso. Questo attributo è fondamentale per qualsiasi analisi del processo basata sul tempo. Serve a calcolare i tempi di ciclo tra le attività, individuare i tempi di attesa, misurare la durata complessiva dei casi e analizzare le prestazioni del processo in periodi diversi. Date e ore accurate sono indispensabili per creare una mappa animata del processo, che mostri l’andamento dei casi nel tempo, e per realizzare Dashboard che monitorino indicatori chiave di prestazione come il tempo medio di risoluzione. Perché è importante Le date e le ore forniscono il contesto cronologico di tutte le attività e consentono di calcolare le durate, individuare i colli di bottiglia e analizzare nel tempo le prestazioni del processo. Dove reperirli API Zendesk Ticket Audits (/api/v2/tickets/{ticket_id}/audits), campo created_at per ciascun evento di controllo. Esempi 2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
	ID incidente TicketId	Identificativo univoco generato dal sistema per ciascun ticket relativo a un incidente.
Descrizione L’ID incidente è la chiave primaria che identifica in modo univoco ogni caso in Zendesk Support. Nel Process Mining funge da CaseId e collega tutte le attività, le modifiche di stato e le comunicazioni correlate, dalla creazione dell’incidente fino alla sua chiusura. Nell’analisi, questo ID è essenziale per ricostruire l’intero percorso di ogni incidente. Consente di aggregare i dati degli eventi e monitorare indicatori quali il tempo totale di risoluzione, il numero di passaggi di consegne e il rispetto degli accordi sui livelli di servizio per ciascun caso. Raggruppando gli eventi in base a questo ID, gli analisti possono visualizzare i flussi del processo, individuare i percorsi più comuni e rilevare le deviazioni dalla procedura standard. Perché è importante È l’identificativo essenziale che collega tutti gli eventi a un singolo incidente, rendendo possibile ricostruirne l’intero ciclo di vita e analizzare accuratamente le prestazioni del processo. Dove reperirli API Zendesk Tickets (/api/v2/tickets/{id}), campo id. Esempi 19428230113521941055
	Attività ActivityName	Nome dell’attività aziendale o dell’evento che si è verificato in un determinato momento del ciclo di vita dell’incidente.
Descrizione Questo attributo descrive un passaggio o un’azione specifica del processo di gestione degli incidenti, ad esempio 'Incidente creato', 'Ticket assegnato a un agente' o 'Incidente risolto'. Le attività sono ricavate dai dati del log degli eventi o dalla traccia di controllo di Zendesk, in cui vengono registrate le modifiche apportate al sistema. Nel Process Mining, la sequenza di queste attività costituisce la mappa del processo e rappresenta la base di ogni analisi. Analizzando il flusso delle attività, le organizzazioni possono scoprire i percorsi effettivi degli incidenti, individuare i colli di bottiglia tra un passaggio e l’altro, misurare i cicli di rilavorazione, ad esempio la riapertura di un ticket risolto, e verificare la conformità rispetto a un processo standard definito. Perché è importante La sequenza delle attività definisce il flusso del processo, elemento centrale dell’analisi con Process Mining per individuare inefficienze, deviazioni e opportunità di miglioramento. Dove reperirli Ricavato dagli eventi dell’API Zendesk Ticket Audits. Ad esempio, un evento Change sul campo status può essere associato all’attività 'Stato modificato'. Esempi Incidente creatoTicket assegnato a un agenteStato modificato in In attesaIncidente risoltoIncidente chiuso
	Sistema di origine SourceSystem	Sistema da cui sono stati estratti i dati sugli incidenti.
Descrizione Questo attributo identifica l’origine dei dati del processo. In questa vista, il valore è statico, ad esempio 'Zendesk Support', e indica che tutti gli eventi e gli attributi provengono da quel sistema. Negli ambienti in cui vengono combinati dati provenienti da più sistemi, questo campo è essenziale per distinguere le diverse origini. Aiuta a garantire l’integrità dei dati e consente analisi specifiche per sistema, ad esempio confrontando il processo di gestione degli incidenti in Zendesk con quello di un altro strumento ITSM. Perché è importante Identifica l’origine dei dati, un’informazione essenziale per la governance dei dati e per le analisi che combinano dati provenienti da più sistemi di origine. Dove reperirli Valore statico impostato durante la trasformazione dei dati per identificarne l’origine. Esempi Zendesk SupportZendesk
	Ultimo aggiornamento dei dati LastDataUpdate	Data e ora dell’ultimo aggiornamento dei dati relativi a questo processo.
Descrizione Questo attributo registra la data e l’ora dell’estrazione o dell’aggiornamento più recente dal sistema di origine. In genere, durante ogni ciclo di aggiornamento viene applicato un unico valore all’intero dataset. Questa informazione è importante per la governance dei dati e per chi utilizza l’analisi del processo. Indica quanto sono aggiornati i dati e aiuta gli analisti a capire se stanno consultando le informazioni più recenti disponibili. È particolarmente utile per monitorare le prestazioni operative e prendere decisioni tempestive sulla base dell’analisi. Perché è importante Fornisce un contesto essenziale sull’aggiornamento dei dati, così che gli utenti sappiano quanto è attuale l’analisi e quando sono stati acquisiti i dati. Dove reperirli Data e ora generate dal processo ETL o dalla pipeline dei dati al termine dell’aggiornamento. Esempi 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Agente assegnato Assignee	L’agente dell’assistenza attualmente incaricato di gestire l’incidente.
Descrizione Questo attributo identifica l’agente specifico responsabile dell’incidente in un determinato momento. I cambi di assegnatario sono eventi importanti, perché indicano il passaggio del lavoro da una persona a un’altra. Analizzare l’agente assegnato aiuta a comprendere la distribuzione del carico di lavoro, le prestazioni individuali e le modalità di collaborazione. Monitorare le modifiche di questo campo è essenziale per calcolare il KPI «Media dei passaggi per incidente» e individuare i casi in cui gli incidenti vengono trasferiti frequentemente, possibile segnale di lacune nelle conoscenze o di un instradamento inefficiente. Perché è importante Identifica l’agente responsabile e consente di analizzare il carico di lavoro e monitorare i passaggi di consegne, aspetti fondamentali per individuare le inefficienze del processo. Dove reperirli API Tickets di Zendesk, campo assignee_id. Le modifiche vengono registrate nell’API Ticket Audits. Esempi John SmithJane DoeAutomazione del Service Desk
	Canale di segnalazione Channel	Il canale attraverso cui è stato segnalato inizialmente l’incidente, ad esempio «E-mail», «Web» o «API».
Descrizione Questo attributo registra il metodo utilizzato dall’utente finale o dal sistema per creare il ticket dell’incidente. Conoscere il canale è importante per analizzare l’origine degli incidenti e adattare di conseguenza il processo di assistenza. L’analisi degli incidenti per canale può rivelare schemi diversi. Per esempio, gli incidenti segnalati per telefono potrebbero avere tempi di risoluzione più brevi rispetto a quelli ricevuti via e-mail. Queste informazioni alimentano la Dashboard «Volume degli incidenti gestiti» e aiutano a pianificare le risorse e a ottimizzare i canali. Perché è importante Consente di analizzare il volume degli incidenti e le prestazioni del processo in base alla fonte, così da migliorare i processi per ciascun canale e assegnare le risorse in modo adeguato. Dove reperirli API Tickets di Zendesk, campo via.channel. Esempi webe-mailapitelefono
	Gruppo assegnato AssignedGroup	Il team o gruppo di assistenza attualmente incaricato dell’incidente.
Descrizione Questo attributo indica quale team è responsabile dell’incidente. Spesso gli incidenti passano tra diversi livelli di assistenza o gruppi specializzati, ad esempio dal «Supporto L1» al «Team Reti». È una dimensione fondamentale per analizzare i passaggi di consegne tra team e individuare i colli di bottiglia. Monitorando il flusso degli incidenti tra i gruppi, gli analisti possono misurare le dipendenze tra team, calcolare i tempi di attesa nelle code dei singoli gruppi e ottimizzare le regole di instradamento. L’attributo alimenta direttamente la Dashboard «Analisi dei passaggi di consegne e della rilavorazione». Perché è importante Monitora il team responsabile, un dato essenziale per analizzare i passaggi di consegne tra team, individuare i colli di bottiglia specifici e misurare i tempi di attesa nelle code. Dove reperirli API Tickets di Zendesk, campo group_id. Le modifiche vengono registrate nell’API Ticket Audits. Esempi Supporto L1Team Reti L2Infrastruttura L3Fatturazione
	Ora di fine dell’evento EventEndTime	Il timestamp che indica quando è stata completata un’attività.
Descrizione L’ora di fine dell’evento segna la conclusione di un’attività. Nei dati dell’Event Log, spesso l’ora di fine di un’attività viene dedotta dall’ora di inizio dell’attività successiva nella sequenza dello stesso caso. Per l’ultima attività di un caso, l’ora di fine può coincidere con quella di inizio. Questo attributo è essenziale per calcolare la durata delle singole attività (ProcessingTime) e i tempi di attesa tra un’attività e l’altra. Queste informazioni sono alla base dell’analisi dei colli di bottiglia: permettono agli analisti di capire non solo quanto dura un passaggio, ma anche per quanto tempo il caso è rimasto inattivo prima che iniziasse. Perché è importante Consente di calcolare la durata delle attività e i tempi di attesa, un passaggio fondamentale per analizzare nel dettaglio i colli di bottiglia e individuare i ritardi nel processo. Dove reperirli Si calcola usando l’ora di inizio dell’evento successivo nello stesso caso. Per l’ultimo evento, l’ora di fine può coincidere con quella di inizio o con l’ora di chiusura del caso. Esempi 2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
	Priorità TicketPriority	Il livello di priorità assegnato all’incidente, ad esempio «Bassa», «Normale», «Alta» o «Urgente».
Descrizione La priorità di un incidente determina il livello di urgenza richiesto per la risposta e la risoluzione. È un fattore chiave per stabilire le priorità del lavoro e assegnare le risorse all’interno del team di assistenza. Nell’analisi dei processi, la priorità consente di suddividere gli incidenti in gruppi e confrontarne i flussi e le prestazioni. Per esempio, gli analisti possono verificare se gli incidenti «Urgenti» vengono davvero risolti più rapidamente di quelli a priorità «Bassa». La priorità serve anche a monitorare il rispetto degli SLA, spesso definiti in base ai livelli di priorità. Il KPI «Tasso di modifica della priorità» si basa sul monitoraggio delle variazioni di questo campo. Perché è importante Questo attributo è fondamentale per segmentare l’analisi, valutare l’efficacia delle priorità assegnate e monitorare il rispetto degli SLA per i diversi livelli di urgenza. Dove reperirli API Tickets di Zendesk, campo priority. Le modifiche vengono registrate nell’API Ticket Audits. Esempi bassanormalealtaurgente
	Stato del ticket TicketStatus	Stato del ticket relativo all’incidente al momento dell’evento, ad esempio 'Aperto', 'In attesa' o 'Risolto'.
Descrizione Questo attributo indica lo stato del ticket relativo all’incidente nei diversi momenti del suo ciclo di vita. Gli stati standard di Zendesk includono nuovo, aperto, in attesa, sospeso, risolto e chiuso. Monitorare le modifiche di questo campo è uno dei metodi principali per generare attività da utilizzare nel Process Mining. Analizzare lo stato del ticket è fondamentale per comprendere il processo. Aiuta a individuare quanto tempo gli incidenti trascorrono in determinati stati, come 'In attesa', che spesso indica che si aspetta una risposta dell’utente. È inoltre essenziale per definire il completamento del caso e calcolare i tempi di risoluzione. Perché è importante Monitorare i cambiamenti di stato è fondamentale per capire come avanza il processo, individuare i tempi di attesa e definire i punti di inizio e fine del ciclo di vita dell’incidente. Dove reperirli API Tickets di Zendesk, campo status. Le modifiche vengono registrate nell’API Ticket Audits. Esempi nuovoapertoin attesarisoltochiuso
	Stato SLA SlaStatus	Lo stato attuale dell’accordo sul livello di servizio (SLA) relativo all’incidente.
Descrizione Questo attributo indica se l’incidente è in linea con gli obiettivi SLA definiti, se li ha già superati o se i timer SLA sono in pausa. Zendesk monitora automaticamente le metriche SLA in base alle politiche configurate. È un attributo fondamentale per la Dashboard «Monitoraggio del rispetto degli SLA» e misura direttamente le prestazioni rispetto agli impegni di servizio. Analizzando quando e perché gli SLA vengono superati, le organizzazioni possono individuare i punti deboli del processo e migliorare l’affidabilità del servizio. L’attributo alimenta direttamente il KPI «Tasso di rispetto degli SLA per gli incidenti». Perché è importante Misura direttamente le prestazioni rispetto agli impegni di servizio e consente di analizzare il mancato rispetto degli SLA e di monitorare la situazione in modo proattivo per migliorare la conformità. Dove reperirli API Ticket Metrics di Zendesk (/api/v2/ticket_metrics.json), ricavato da campi quali sla_policy, breached_at e altri. Esempi AttivoIn pausaSuperatoRispettato
	Categoria della causa profonda RootCauseCategory	La categoria generale della causa profonda alla base dell’incidente.
Descrizione Questo attributo classifica la ragione fondamentale per cui si è verificato un incidente. In genere viene registrato verso la fine del ciclo di vita dell’incidente, spesso durante una revisione successiva all’evento o nell’ambito della gestione dei problemi, e salvato in un campo personalizzato. Questi dati sono essenziali per la Dashboard «Precisione nell’individuazione delle cause profonde» e per il KPI «Copertura dell’analisi delle cause profonde». Analizzare gli incidenti in base alla causa profonda aiuta a individuare i problemi ricorrenti e a orientare gli interventi correttivi permanenti, riducendo il numero di incidenti futuri. In questo modo si passa dalla gestione reattiva delle emergenze alla prevenzione proattiva dei problemi. Perché è importante Favorisce una gestione proattiva dei problemi classificando le cause degli incidenti, così da individuare le tendenze e prevenire nuovi casi. Dove reperirli In genere si tratta di un campo personalizzato del ticket. Verificare la configurazione di Ticket Fields nello Zendesk Admin Center. Esempi Errore softwareGuasto hardwareErrore dell’utenteInterruzione della rete
	Durata del caso CaseDuration	Il tempo totale trascorso dalla creazione dell’incidente alla sua chiusura definitiva.
Descrizione Questa metrica calcolata rappresenta il tempo di ciclo complessivo di un singolo incidente. Si ottiene calcolando la differenza tra il timestamp del primo evento (ad esempio, «Incidente creato») e quello dell’ultimo (ad esempio, «Incidente chiuso»). La durata del caso è un indicatore chiave di prestazione (KPI) per misurare l’efficienza complessiva del processo. Viene ampiamente utilizzata nelle Dashboard per mostrare i tempi di ciclo medi, individuare i casi di lunga durata e analizzare le tendenze nel tempo. Fornisce una misura complessiva della rapidità con cui il processo gestisce e risolve gli incidenti. Perché è importante È un KPI fondamentale per misurare la velocità complessiva del processo e individuare i fattori che contribuiscono a tempi di risoluzione lunghi. Dove reperirli Si calcola per ogni ID incidente sottraendo il timestamp del primo evento da quello dell’ultimo. Esempi 25920060480086400
	È automatizzata IsAutomated	Indicatore booleano che segnala se un’attività è stata eseguita da un sistema automatizzato o da un agente umano.
Descrizione Questo attributo derivato distingue gli eventi eseguiti da utenti da quelli generati da automazioni di sistema, trigger o integrazioni API. In genere viene determinato verificando se l’autore dell’evento è un utente di sistema noto. Conoscere il livello di automazione è fondamentale per l’analisi dei processi moderni. Aiuta a valutare l’efficacia delle regole di automazione, individuare le attività manuali che potrebbero essere automatizzate e misurare l’impatto dell’automazione sull’efficienza e sui tempi di risoluzione. L’attributo consente di confrontare i flussi di processo delle attività automatizzate con quelli delle attività manuali. Perché è importante Distingue le azioni umane da quelle di sistema, un aspetto essenziale per analizzare l’impatto dell’automazione sull’efficienza del processo e individuare nuove opportunità di automazione. Dove reperirli Si ricava verificando se l’autore dell’evento (author_id nell’API Ticket Audits) corrisponde a un utente di sistema o di automazione noto. Esempi truefalse
	Gravità Severity	Il livello di impatto dell’incidente sull’attività aziendale.
Descrizione La gravità definisce l’impatto di un incidente sull’attività aziendale e, spesso insieme alla priorità, ne determina il livello complessivo di urgenza. In Zendesk viene in genere configurata come campo personalizzato. Analizzare la gravità aiuta a comprendere la criticità degli incidenti gestiti. È una dimensione chiave per segmentare i dati in Dashboard come «Monitoraggio del rispetto degli SLA» e «Metriche di efficacia delle priorità». Confrontare i flussi di processo per i diversi livelli di gravità può rivelare se gli incidenti più gravi vengono gestiti con la rapidità e le risorse adeguate. Perché è importante Indica l’impatto di un incidente sull’attività aziendale e consente di concentrarsi sui problemi più critici, assicurandone una risoluzione efficiente. Dove reperirli In genere si tratta di un campo personalizzato. Verificare la configurazione di Ticket Fields nello Zendesk Admin Center. Esempi 1 - Critico2 - Alto3 - Medio4 - Basso
	Numero di passaggi di consegne HandoffCount	Il numero totale di volte in cui un incidente è stato riassegnato a un altro agente o gruppo.
Descrizione Questa metrica calcolata quantifica quante volte è stata trasferita la responsabilità di un incidente. Ogni modifica dei campi Assignee o AssignedGroup incrementa il conteggio del caso. I passaggi di consegne sono una causa frequente di inefficienza e ritardi nella gestione degli incidenti. Un numero elevato può indicare regole di instradamento poco chiare, lacune nelle conoscenze dei team di assistenza o processi troppo complessi. Questa metrica è alla base del KPI «Media dei passaggi per incidente» ed è fondamentale per la Dashboard «Analisi dei passaggi di consegne e della rilavorazione». Perché è importante Quantifica gli attriti nel processo causati dai trasferimenti e aiuta a individuare inefficienze nell’instradamento e lacune nelle conoscenze che allungano i tempi di risoluzione. Dove reperirli Si calcola contando quante volte è cambiato il campo AssignedGroup o Assignee per un incidente. Esempi 0135
	Organizzazione del 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 nei contesti di assistenza B2B, dove i livelli di servizio e i processi di supporto possono variare da un cliente all’altro. Analizzare gli incidenti per organizzazione consente ai team di assistenza di monitorare lo stato dei clienti, individuare i problemi ricorrenti che interessano clienti specifici e verificare il rispetto degli obblighi contrattuali. È una dimensione fondamentale per filtrare le Dashboard e i report e ottenere una visione delle prestazioni incentrata sul cliente. Perché è importante Consente analisi specifiche per cliente, aiutando a monitorare i livelli di servizio, individuare tendenze nei clienti strategici e gestire efficacemente le relazioni con i clienti. Dove reperirli API Tickets di Zendesk, campo organization_id. Esempi Global Tech Inc.Innovate SolutionsData Corp
	Risolto al primo contatto IsFirstContactResolution	Indicatore booleano che vale vero se l’incidente è stato risolto dal primo agente o gruppo assegnato, senza passaggi di consegne.
Descrizione La risoluzione al primo contatto (FCR) è una metrica fondamentale per l’efficienza dei centri di assistenza e la soddisfazione dei clienti. Questo attributo calcolato segnala gli incidenti risolti senza essere riassegnati a un altro agente o team. In genere, la logica verifica se il ticket ha raggiunto lo stato «Risolto» mantenendo l’agente e il gruppo inizialmente assegnati. Nel Process Mining, consente di calcolare direttamente il tasso FCR e confrontare i percorsi degli incidenti risolti al primo contatto con quelli che hanno richiesto un’escalation, aiutando a individuare come dare maggiore autonomia al supporto di primo livello. Perché è importante Misura direttamente l’efficienza del primo punto di contatto con l’assistenza e aiuta a individuare opportunità per risolvere i problemi prima nel processo. Dove reperirli Indicatore booleano calcolato. Vale vero se lo stato del ticket è «risolto» o «chiuso» e, durante l’intero ciclo di vita dell’incidente, è stato assegnato a un solo agente o gruppo. Esempi truefalse
	Segnalante Submitter	L’utente finale o il sistema che ha segnalato inizialmente l’incidente.
Descrizione Questo attributo identifica la persona o l’entità che ha creato il ticket. È diverso dal richiedente, perché un agente può creare un ticket per conto di un’altra persona. Nell’analisi, il segnalante aiuta a capire chi comunica i problemi. Incrociando questo dato con le informazioni sull’organizzazione, è possibile individuare clienti o gruppi di utenti che registrano un numero elevato di incidenti. Queste informazioni possono orientare iniziative di assistenza proattiva o attività di formazione. Perché è importante Identifica la fonte della segnalazione dell’incidente e consente di individuare schemi ricorrenti legati a utenti, reparti o sistemi automatizzati specifici. Dove reperirli API Tickets di Zendesk, campo submitter_id. Esempi alice.jones@example.combob.williams@example.comMonitor di sistema
	Tag Tags	Elenco dei tag applicati all’incidente per classificarlo e aggiungere informazioni di contesto.
Descrizione I tag sono etichette flessibili che si possono aggiungere ai ticket per fornire ulteriori informazioni o agevolarne la classificazione e l’instradamento. Gli agenti possono inserirli manualmente oppure possono essere aggiunti automaticamente tramite trigger e automazioni. I tag sono una fonte di dati preziosa per l’analisi di Process Mining. Consentono di creare segmenti dettagliati, ad esempio filtrando gli incidenti legati al lancio di un prodotto specifico («launch_q4») o a un’interruzione nota («outage_20231027»). Questa flessibilità permette di approfondire l’analisi oltre i campi standard dei ticket. Perché è importante Offre un metodo flessibile per classificare e filtrare gli incidenti, consentendo analisi dettagliate e specifiche per contesto che i soli campi standard potrebbero non permettere. Dove reperirli API Tickets di Zendesk, campo tags. Esempi vip_usernetwork_issueoutage_20231027billing_related
	Tipo di ticket TicketType	La classificazione del ticket, ad esempio «Incidente», «Problema», «Domanda» o «Attività».
Descrizione Questo campo classifica il ticket in base alla natura della richiesta. Il processo di gestione degli incidenti si concentra in particolare sui ticket di tipo «Incidente», che rappresentano un’interruzione imprevista o una riduzione della qualità di un servizio IT. Nell’analisi, questo attributo viene usato soprattutto come filtro per includere nella vista del processo solo gli incidenti. Può inoltre servire per analisi ITSM più ampie, confrontando i processi di gestione degli incidenti con quelli relativi ai problemi o alle richieste di servizio. Perché è importante Consente di filtrare i dati e concentrarsi sugli incidenti, assicurando che l’analisi del processo sia pertinente al ciclo di vita della gestione degli incidenti. Dove reperirli API Tickets di Zendesk, campo type. Esempi incidenteproblemadomandaattività
	Valutazione della soddisfazione SatisfactionRating	La valutazione della soddisfazione fornita dall’utente finale dopo la risoluzione dell’incidente.
Descrizione Questo attributo registra il giudizio del cliente sull’esperienza di assistenza, raccolto in genere tramite un sondaggio dopo la risoluzione del ticket. In Zendesk, le valutazioni più comuni sono «Buono» e «Negativo». Pur non misurando direttamente l’efficienza del processo, la valutazione della soddisfazione è un indicatore importante del risultato. Nel Process Mining può essere messa in relazione con le varianti del processo per capire quali percorsi di risoluzione portano a una maggiore soddisfazione dei clienti. Per esempio, gli incidenti che comportano più passaggi di consegne ricevono valutazioni più basse? Perché è importante Fornisce un indicatore importante del risultato, che può essere messo in relazione con le caratteristiche del processo per capire come le prestazioni incidono sulla soddisfazione degli utenti. Dove reperirli API Ticket Metrics di Zendesk (/api/v2/ticket_metrics.json), campo satisfaction_rating.score. Esempi buononegativopropostonon proposto

Obbligatorio Consigliato Facoltativo

Attività di gestione degli incidenti

Questi sono i passaggi e le tappe fondamentali da registrare nell’Event Log per individuare e analizzare il processo con precisione.

6 Consigliato 7 Facoltativo

	Attività	Descrizione
	Incidente chiuso	Segna la conclusione definitiva del ciclo di vita dell’incidente, quando il ticket viene chiuso in modo permanente. In Zendesk, spesso la chiusura avviene automaticamente dopo un periodo prestabilito dalla risoluzione ed è registrata come modifica finale dello stato.
Perché è importante È l’attività conclusiva del processo. La durata complessiva si calcola dall’evento 'Incidente creato' a questo evento e offre una visione completa del tempo di ciclo. Dove reperirli Ricavato dal log di controllo del ticket tramite un evento 'Change' in cui il nuovo valore del campo 'status' diventa 'closed'. Acquisizione Individuato da un evento 'Change' che imposta il campo 'status' su 'closed'. Tipo di evento explicit
	Incidente creato	Segna l’inizio del ciclo di vita dell’incidente, quando viene creato un nuovo ticket in Zendesk. L’evento è registrato esplicitamente nel registro di controllo della creazione dei ticket di Zendesk e costituisce il punto di partenza di ogni caso.
Perché è importante È la principale attività iniziale. Analizzare il tempo che intercorre tra questo evento e gli eventi successivi è essenziale per misurare la durata complessiva del ciclo di vita del ticket e i tempi di prima risposta. Dove reperirli È un evento esplicito registrato nei log di controllo dei ticket di Zendesk. Ogni nuovo ticket genera un evento 'Create' con la relativa data e ora. Acquisizione Direttamente dall’evento di creazione del ticket nel log di controllo. Tipo di evento explicit
	Incidente risolto	Questa tappa fondamentale si verifica quando un agente ha applicato una soluzione e contrassegna il ticket come 'solved'. È un’azione esplicita, registrata come modifica di stato nel log di controllo del ticket.
Perché è importante È la principale attività di risoluzione e un momento cruciale per misurare il tempo necessario alla risoluzione. Il tempo tra questo evento e 'Incidente chiuso' corrisponde al periodo di attesa della conferma dell’utente o alla chiusura automatica. Dove reperirli Ricavato dal log di controllo del ticket tramite un evento 'Change' in cui il nuovo valore del campo 'status' diventa 'solved'. Acquisizione Individuato da un evento 'Change' che imposta il campo 'status' su 'solved'. Tipo di evento explicit
	Stato modificato in Aperto	Indica che un agente ha iniziato a lavorare attivamente sull’incidente. In genere, l’attività viene dedotta quando il campo 'status' del ticket passa da 'new' a 'open', segnando l’inizio della fase di indagine e diagnosi.
Perché è importante Questo evento segna il passaggio dalla coda al lavoro attivo. Il tempo trascorso dai ticket nello stato 'new' prima di passare a 'open' è un indicatore chiave del tempo di prima risposta. Dove reperirli Dedotto dal log di controllo del ticket individuando un evento 'Change' in cui il nuovo valore del campo 'status' è 'open' e quello precedente era 'new'. Acquisizione Dedotto da una modifica del campo di stato da 'new' a 'open'. Tipo di evento inferred
	Ticket assegnato a un agente	Questa attività si verifica quando un ticket viene assegnato a un agente specifico. È registrata esplicitamente nella cronologia di controllo del ticket e indica che una persona ne ha assunto la gestione.
Perché è importante Questa tappa è essenziale per misurare il tempo necessario alla prima assegnazione e costituisce la base per analizzare i passaggi di consegne, le rilavorazioni e il tasso di risoluzione al primo contatto. Dove reperirli Registrato nel log di controllo del ticket quando il campo 'assignee_id' viene compilato o modificato. La prima assegnazione è una tappa fondamentale per il calcolo degli indicatori chiave di prestazione. Acquisizione Individuato da un evento 'Change' relativo al campo 'assignee_id' nel log di controllo del ticket. Tipo di evento explicit
	Ticket riassegnato	Si verifica quando, dopo l’assegnazione iniziale, la responsabilità del ticket passa da un agente o gruppo a un altro. È un evento esplicito registrato nella cronologia di controllo del ticket.
Perché è importante Le riassegnazioni sono importanti per analizzare i passaggi di consegne e le rilavorazioni. Una frequenza elevata può indicare un instradamento iniziale errato, problemi complessi o colli di bottiglia nel processo. Dove reperirli Ricavato dal log di controllo del ticket individuando un evento 'Change' sul campo 'assignee_id' o 'group_id' dopo la prima compilazione del campo. Acquisizione Individuato da un successivo evento 'Change' relativo al campo 'assignee_id' o 'group_id'. Tipo di evento explicit
	Nota interna aggiunta	Questa attività indica una collaborazione interna: un agente aggiunge al ticket una nota privata destinata agli altri membri del team. Viene registrata esplicitamente quando un commento è contrassegnato come non pubblico.
Perché è importante L’analisi delle note interne può far emergere problemi complessi che richiedono collaborazione; un numero eccessivo di note, tuttavia, può indicare lacune nelle conoscenze o inefficienze del processo. Dove reperirli Ricavato dai dati dei commenti del ticket. Un commento è considerato una nota interna quando il relativo attributo 'public' è impostato su false. Acquisizione Evento registrato quando viene aggiunto al ticket un nuovo commento con 'public: false'. Tipo di evento explicit
	Obiettivo SLA non raggiunto	Segna il momento in cui un ticket non rispetta un livello di servizio concordato, ad esempio il tempo di prima risposta o il tempo di risoluzione. L’evento viene calcolato in base alle definizioni delle policy SLA e alle date e ore di aggiornamento del ticket.
Perché è importante Questo evento consente di monitorare il rispetto degli SLA. Individuare quando e perché si verificano le violazioni è fondamentale per migliorare l’affidabilità del servizio e la fiducia degli utenti. Dove reperirli È un evento calcolato. Può essere ricavato analizzando i dati 'sla_policy_metrics' associati a un ticket e utilizzando la data e l’ora 'breached_at' di ciascun obiettivo SLA. Acquisizione Ricavato dalla data e ora 'breached_at' nei dati delle metriche SLA del ticket. Tipo di evento calculated
	Priorità impostata	Viene definito il livello di priorità dell’incidente, ad esempio Bassa, Normale, Alta o Urgente. La modifica è registrata esplicitamente e determina l’urgenza e i tempi di risposta richiesti per il ticket.
Perché è importante Monitorare quando e come viene impostata la priorità è essenziale per la Dashboard 'Metriche di efficacia della definizione delle priorità' e consente di intervenire tempestivamente sui problemi critici. Dove reperirli Registrato come evento 'Change' sul campo 'priority' nel log di controllo del ticket. È possibile monitorare anche le modifiche successive per calcolare l’indicatore del tasso di modifica della priorità. Acquisizione Individuato da un evento 'Change' relativo al campo 'priority' nel log di controllo del ticket. Tipo di evento explicit
	Risposta pubblica inviata	Rappresenta una comunicazione inviata da un agente di supporto all’utente finale. In Zendesk è un evento esplicito, registrato ogni volta che viene aggiunto un commento pubblico al ticket.
Perché è importante Monitorare le risposte pubbliche è importante per comprendere la frequenza delle comunicazioni e può aiutare a ricostruire la cronologia dei ritardi nella conferma da parte dell’utente. Dove reperirli Ricavato dai dati dei commenti del ticket. Un commento è considerato pubblico quando il relativo attributo 'public' è impostato su true. Acquisizione Evento registrato quando viene aggiunto al ticket un nuovo commento con 'public: true'. Tipo di evento explicit
	Soddisfazione dell’utente valutata	Indica il momento in cui l’utente finale assegna una valutazione al supporto ricevuto. In Zendesk è un evento esplicito, registrato dopo la risoluzione del ticket.
Perché è importante Analizzare le valutazioni di soddisfazione fornisce indicazioni preziose sul lavoro degli agenti e sull’efficacia del processo, collegando gli indicatori di processo ai risultati per gli utenti. Dove reperirli Ricavato dai dati delle valutazioni di soddisfazione associate al ticket. In genere comprende un punteggio ('buono' o 'negativo') e un commento facoltativo. Acquisizione Evento registrato quando viene inviata una valutazione di soddisfazione per il ticket. Tipo di evento explicit
	Stato modificato in In attesa	Indica che il processo è in pausa in attesa di una risposta da parte del richiedente. L’evento è dedotto quando il campo 'status' del ticket passa a 'pending'.
Perché è importante Questa attività è essenziale per calcolare il tempo di attesa della conferma dell’utente. Una permanenza prolungata in questo stato può aumentare sensibilmente il tempo complessivo di risoluzione e mettere in evidenza ritardi nelle comunicazioni. Dove reperirli Dedotto dal log di controllo del ticket individuando un evento 'Change' in cui il nuovo valore del campo 'status' è 'pending'. Acquisizione Dedotto da una modifica del campo di stato a 'pending'. Tipo di evento inferred
	Ticket assegnato a un gruppo	Rappresenta l’assegnazione iniziale o il triage dell’incidente a uno specifico gruppo di supporto. In genere è il primo passaggio per assegnare la responsabilità e viene registrato come evento di modifica esplicito nella cronologia di controllo del ticket.
Perché è importante Monitorare le assegnazioni ai gruppi aiuta ad analizzare l’efficienza del triage iniziale e a individuare i ritardi che precedono l’instradamento del ticket al team corretto. Dove reperirli Registrato nel log di controllo del ticket ogni volta che il campo 'group_id' viene impostato o modificato. La prima modifica dopo la creazione corrisponde all’assegnazione iniziale. Acquisizione Individuato da un evento 'Change' relativo al campo 'group_id' nel log di controllo del ticket. Tipo di evento explicit

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da Zendesk Support

Passaggi

Acceda a Zendesk Explore: acceda alla Sua istanza Zendesk Support con un account utente autorizzato a creare e gestire report in Zendesk Explore.
Crei un nuovo report: apra il modulo Explore. Selezioni l’icona «Reports» nella barra di navigazione a sinistra, quindi selezioni il pulsante «New report».
Selezioni il set di dati: nella finestra «Choose a dataset», selezioni il set di dati Support: Ticket updates [default]. Contiene la traccia di controllo di ogni modifica ai ticket, indispensabile per creare un Event Log.
Aggiunga gli attributi iniziali (colonne): nel generatore di report, apra la sezione «Rows». Selezioni «Add» e scelga i seguenti attributi, che diventeranno le colonne dell’Event Log: Ticket ID, Update - Timestamp, Ticket status, Assignee name, Ticket group, Ticket priority, Ticket channel, Changes - Field name, Changes - Previous value, Changes - New value, Comment public.
Crei gli attributi calcolati: questo è il passaggio più importante. Apra il menu «Calculations» (icona della beuta) e selezioni «Standard calculated attribute». Crei i tre attributi indicati nella sezione «Query» qui sotto: ActivityName, SourceSystem e LastDataUpdate. Copi esattamente le formule fornite.
Riveda le colonne del report: aggiunga alla sezione «Rows» gli attributi calcolati appena creati (ActivityName, SourceSystem, LastDataUpdate). Può quindi rimuovere i campi grezzi utilizzati per creare ActivityName (Changes - Field name, Changes - Previous value, Changes - New value, Comment public) e rendere la visualizzazione più chiara.
Aggiunga i filtri al report: apra la sezione «Filters» e selezioni «Add». Aggiunga un filtro per Update - Date e selezioni un intervallo adeguato, ad esempio gli ultimi 3 mesi. Aggiunga un altro filtro sull’attributo calcolato ActivityName ed escluda i valori nulli, così da rimuovere gli aggiornamenti dei ticket che non corrispondono a un’attività pertinente.
Esegua e riveda il report: Zendesk Explore aggiorna automaticamente il report man mano che aggiunge attributi e filtri. Controlli la tabella dei dati per verificare che righe e colonne siano visualizzate come previsto. Il report dovrebbe contenere una riga per ogni evento.
Esporti i dati in CSV: una volta completato il report, selezioni il pulsante «Export» nell’angolo in alto a destra e scelga «CSV». Zendesk genererà e scaricherà il file CSV.
Prepari il caricamento: apra il file CSV esportato e rinomini le intestazioni delle colonne in base ai nomi degli attributi richiesti dallo strumento di Process Mining, ad esempio Ticket ID in TicketId e Update - Timestamp in EventTimestamp. Verifichi che il formato delle date e delle ore sia conforme allo standard ISO 8601. Il file è ora pronto per il caricamento.

Configurazione

Set di dati Zendesk: il report deve basarsi sul set di dati Support: Ticket updates [default]. È l’unico set di dati standard che fornisce la traccia di controllo dettagliata necessaria per ricostruire il processo evento per evento.
Filtro per intervallo di date: è fondamentale applicare un filtro sulle date per limitare il volume dei dati. Utilizzi l’attributo Update - Date come filtro principale. Per un’analisi iniziale, si consiglia in genere un intervallo di 3-6 mesi.
Filtro sulle attività: dopo aver creato l’attributo calcolato ActivityName, deve filtrare il report per escludere le righe in cui il valore è nullo. In questo modo rimuove le modifiche irrilevanti ai ticket, come gli aggiornamenti di sistema e le modifiche ai tag, dall’Event Log.
Attributi calcolati: l’estrazione si basa in larga misura su un attributo calcolato standard che converte le modifiche grezze ai campi dei ticket in nomi di attività comprensibili. È fondamentale che la formula sia precisa.
Prerequisiti: l’utente che esegue il report deve avere almeno il ruolo «Viewer» in Zendesk Explore. Per creare e salvare il report sono necessarie le autorizzazioni «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()
```

Passaggi

Prerequisiti: verifichi di avere Python 3.6 o versione successiva installato sul sistema, insieme alle librerie requests e pandas. Può installarle con pip: pip install requests pandas.
Generi un token API Zendesk: acceda alla Sua istanza Zendesk Support come amministratore. Apra Admin Center > Apps and integrations > APIs > Zendesk APIs. Nella sezione «API Tokens», aggiunga un nuovo token API attivo e conservi in modo sicuro la stringa generata.
Configuri lo script Python: crei un nuovo file Python, ad esempio extract_zendesk_logs.py, e vi copi lo script fornito. Aggiorni le variabili segnaposto all’inizio dello script, ZENDESK_SUBDOMAIN, ZENDESK_EMAIL e ZENDESK_API_TOKEN, inserendo le credenziali specifiche. Imposti START_TIMESTAMP per definire l’inizio del periodo di estrazione desiderato, utilizzando un timestamp Unix epoch.
Comprenda gli endpoint API: lo script utilizza principalmente due endpoint API Zendesk. L’endpoint incremental/tickets/cursor.json consente di recuperare in modo efficiente tutti i ticket aggiornati dopo START_TIMESTAMP. Per ogni ticket, lo script richiama quindi l’endpoint tickets/{ticket_id}/audits.json per ottenere la cronologia dettagliata di ogni modifica ed evento.
Esegua lo script: esegua lo script dal terminale con il comando python extract_zendesk_logs.py. Lo script inizierà a recuperare i dati dall’API Zendesk.
Controlli l’avanzamento dello script: lo script stampa nella console il numero di ticket elaborati, così può seguirne l’avanzamento. A seconda dell’intervallo di date e del volume dei ticket, l’operazione potrebbe richiedere parecchio tempo.
Recupero dei dati e paginazione: lo script gestisce automaticamente la paginazione dell’API. Parte dall’URL iniziale per l’esportazione dei ticket e segue l’after_url fornito in ogni risposta API finché non recupera tutti i ticket del periodo.
Trasformazione degli eventi: per ogni ticket, lo script scorre la relativa cronologia di controllo. Analizza ogni evento e associa i tipi di evento interni di Zendesk, come Create, Change e Comment, alle attività aziendali richieste, come Incidente creato, Stato modificato in Aperto e Risposta pubblica inviata.
Gestione dei dati SLA: lo script include una funzione dedicata, get_sla_breach_events, per recuperare le metriche SLA di ogni ticket risolto. È necessario perché il superamento degli SLA non è registrato come evento standard nella traccia di controllo. La funzione effettua un’ulteriore chiamata API per ottenere i dettagli sull’applicazione delle politiche SLA.
Generi l’Event Log: una volta elaborati tutti i ticket, lo script raccoglie gli eventi estratti in un DataFrame pandas e salva l’Event Log finale in un file CSV denominato zendesk_incident_event_log.csv, nella stessa cartella da cui è stato eseguito lo script.
Prepari il caricamento: controlli che il file CSV generato sia corretto. Il file è ora nel formato richiesto per essere caricato direttamente in ProcessMind e analizzato.

Configurazione

Credenziali API Zendesk: deve fornire il sottodominio Zendesk, l’indirizzo e-mail associato a un account amministratore o agente e un token API valido. Conservi queste credenziali in modo sicuro e, negli ambienti di produzione, non le inserisca direttamente in script sottoposti al controllo delle versioni.
Timestamp iniziale (START_TIMESTAMP): questo valore intero determina il punto di inizio dell’estrazione dei dati e deve essere un timestamp Unix epoch. Per raccogliere una quantità significativa di dati senza sovraccaricare il sistema, si consiglia di partire da 3-6 mesi prima. Può utilizzare un convertitore online per ottenere il timestamp corretto per una data specifica.
Limiti di frequenza dell’API: lo script effettua numerose chiamate API. Zendesk applica limiti di frequenza che variano in base al piano. Lo script è adatto a volumi di dati moderati; per istanze molto grandi potrebbe essere necessario aggiungere chiamate time.sleep() nei cicli, per evitare di superare i limiti e ricevere un errore 429.
Librerie Python necessarie: lo script utilizza la libreria requests per le chiamate API e pandas per la manipolazione dei dati e l’esportazione in CSV. Verifichi che siano installate nell’ambiente Python.
Autorizzazioni utente: l’account associato al token API deve disporre delle autorizzazioni necessarie per leggere i dati dei ticket, comprese le tracce di controllo 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()

Passaggi

Crei un client API Zendesk autorizzato a leggere ticket, tracce di controllo dei ticket, utenti, gruppi, valutazioni di soddisfazione ed esportazioni incrementali. Utilizzi un token API o credenziali OAuth configurate per la Sua istanza Zendesk Support. Memorizzi il sottodominio, le credenziali e il punto di ripresa dell’estrazione come valori di configurazione protetti.
Utilizzi l’API di esportazione incrementale dei ticket Zendesk per recuperare i ticket aggiornati dopo l’ultimo punto di ripresa completato correttamente. Lo script seguente utilizza il formato di endpoint documentato, https://[Your Zendesk subdomain].zendesk.com/api/v2/incremental/tickets/cursor.json, e segue la paginazione tramite cursore finché l’API non segnala che il set di risultati è completo.
Per ogni ticket restituito, richieda la relativa cronologia di controllo tramite l’endpoint delle tracce di controllo dei ticket. Questi dati sono necessari perché ProcessMind legge l’Event Log così com’è e non deduce le attività dallo stato finale del ticket. Conservi il timestamp della traccia, l’autore, l’identificativo del ticket e gli eventi registrati.
Converta gli eventi della traccia in righe esplicite dell’Event Log. Estragga la creazione del ticket, l’assegnazione al gruppo, l’assegnazione all’agente, le modifiche alla priorità, i cambiamenti di stato in aperto, le risposte pubbliche, le note interne, le riassegnazioni, i cambiamenti di stato in sospeso, lo stato risolto e lo stato chiuso. Se disponibili, estragga le valutazioni di soddisfazione come righe separate. Calcoli il superamento degli SLA solo quando sono disponibili l’obiettivo SLA richiesto e i timestamp degli eventi, documentando i dati utilizzati per il calcolo.
Conservi il timestamp o il cursore dell’ultimo aggiornamento elaborato correttamente. Non aggiorni il punto di ripresa finché tutte le pagine, le tracce di controllo dei ticket e gli eventuali dati di soddisfazione non sono stati scritti correttamente. Per la prima esecuzione, utilizzi un periodo iniziale delimitato, ad esempio [Start date in ISO 8601 format], che in genere copra da tre a sei mesi.
Compili le colonne obbligatorie TicketId, ActivityName, EventTimestamp, SourceSystem e LastDataUpdate. Compili, quando supportate dai dati di origine, le colonne consigliate TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus ed EventEndTime. Utilizzi valori vuoti solo quando Zendesk non fornisce l’attributo per l’evento.
Elimini i duplicati utilizzando TicketId, ActivityName, EventTimestamp e, quando disponibile, un identificativo stabile dell’evento di origine. Conservi le occorrenze legittime ripetute della stessa attività, come più risposte pubbliche, note interne, assegnazioni o cambiamenti di stato.
Scriva le righe risultanti in CSV o in un altro formato di Event Log supportato da ProcessMind. Verifichi che i timestamp siano in formato ISO 8601 con offset UTC esplicito, che TicketId abbia un tipo coerente, che i valori di ActivityName corrispondano esattamente ai nomi delle attività documentati e che LastDataUpdate sia identico per tutte le righe dello stesso lotto di estrazione.
Carichi l’Event Log in ProcessMind e configuri ID incidente come identificativo del caso, Attività come colonna delle attività e Timestamp evento come colonna dell’ora dell’evento. Verifichi che ogni attività obbligatoria sia rappresentata da righe esplicite, anziché essere dedotta durante la visualizzazione.

Configurazione

Metodo API: API di esportazione incrementale dei ticket Zendesk con paginazione tramite cursore. Utilizzi l’endpoint delle tracce di controllo dei ticket per estrarre gli eventi e l’endpoint delle valutazioni di soddisfazione quando queste sono abilitate e accessibili.
Configurazione obbligatoria: sottodominio Zendesk, autenticazione API, data iniziale, punto di ripresa dell’estrazione, timeout delle richieste, criteri per i nuovi tentativi e percorso di output. Sostituisca [Your Zendesk subdomain], [Your API email] e [Your API token] con valori protetti per la distribuzione.
Intervallo di date: per il caricamento iniziale, utilizzi un periodo da tre a sei mesi, salvo che sia necessaria una cronologia più ampia. Per i caricamenti ricorrenti, richieda i record successivi all’ultimo punto di ripresa completato correttamente e includa un breve intervallo di sovrapposizione per gestire gli aggiornamenti tardivi, eliminando poi i duplicati.
Filtri: applichi filtri per azienda, marchio, gruppo, organizzazione, modulo ticket, canale o campi personalizzati solo se richiesti esplicitamente dall’ambito del processo. Zendesk Support non utilizza filtri come Codice società o Tipo documento, tipici di SAP, a meno che tali concetti non siano rappresentati da campi Zendesk configurati.
Semantica degli eventi: consideri autorevoli le tracce di controllo per le modifiche esplicite. Non crei un evento di cambio di stato solo perché lo stato corrente del ticket ha un determinato valore. Un evento di stato deve derivare da una traccia di controllo o da un’altra fonte di eventi documentata.
Configurazione SLA: per determinare il superamento dell’obiettivo SLA sono necessari l’accesso alla politica SLA applicabile, la durata dell’obiettivo, il calendario delle ore lavorative e i timestamp utili a verificare l’obiettivo. Se Zendesk espone un evento o una metrica di superamento, utilizzi tale fonte. In caso contrario, effettui il calcolo solo sulla base di dati documentati relativi alle politiche e ne conservi i criteri.
Configurazione della soddisfazione: l’attività Valutazione della soddisfazione utente richiede che le valutazioni siano abilitate e che il relativo record sia accessibile tramite API. A un ticket risolto senza valutazione non deve essere associato un evento di valutazione fittizio.
Prestazioni: utilizzi la paginazione tramite cursore, un numero controllato di richieste simultanee per le tracce di controllo dei ticket, il riutilizzo delle connessioni, un’attesa progressiva tra i tentativi in caso di limiti di frequenza e punti di ripresa dopo i lotti completati correttamente. Eviti di richiedere nuovamente tutte le tracce di controllo dei ticket a ogni esecuzione.
Completezza: le esportazioni incrementali possono includere ticket aggiornati dopo l’ora richiesta, ma il recupero delle tracce di controllo e la gestione degli aggiornamenti tardivi richiedono passaggi separati. Utilizzi un intervallo di sovrapposizione e chiavi di deduplicazione stabili.
Prerequisiti: accesso API, autorizzazione a leggere ticket e tracce di controllo, accesso a utenti e gruppi per risolvere i nomi, accesso ai dati di soddisfazione se richiesti e accesso ai dati SLA se occorre calcolare i superamenti. La disponibilità di specifici tipi di eventi nelle tracce può variare in base alla configurazione e al piano Zendesk.

a Query di esempio python

import csv
import json
import os
import time
from datetime import datetime, timezone, timedelta
from typing import Any, Dict, Iterable, List, Optional, Tuple

import requests

ZENDESK_SUBDOMAIN = os.getenv(class="hl-string">"ZENDESK_SUBDOMAIN", class="hl-string">"[Your Zendesk subdomain]")
API_EMAIL = os.getenv(class="hl-string">"ZENDESK_API_EMAIL", class="hl-string">"[Your API email]")
API_TOKEN = os.getenv(class="hl-string">"ZENDESK_API_TOKEN", class="hl-string">"[Your API token]")
START_DATE = os.getenv(class="hl-string">"START_DATE", class="hl-string">"[Start date in ISO 8601 format]")
OUTPUT_FILE = os.getenv(class="hl-string">"OUTPUT_FILE", class="hl-string">"incident_event_log.csv")
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"
LAST_DATA_UPDATE = datetime.now(timezone.utc).isoformat()

if class="hl-string">"[" in ZENDESK_SUBDOMAIN or class="hl-string">"[" in API_EMAIL or class="hl-string">"[" in API_TOKEN or class="hl-string">"[" in START_DATE:
    raise ValueError(class="hl-string">"Set ZENDESK_SUBDOMAIN, ZENDESK_API_EMAIL, ZENDESK_API_TOKEN, and START_DATE before running")

BASE_URL = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2"
SESSION = requests.Session()
SESSION.auth = (fclass="hl-string">"{API_EMAIL}/token", API_TOKEN)
SESSION.headers.update({class="hl-string">"Accept": class="hl-string">"application/json"})

FIELDS = [
    class="hl-string">"TicketId", class="hl-string">"ActivityName", class="hl-string">"EventTimestamp", 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", class="hl-string">"EventEndTime"
]


def parse_time(value: Optional[str]) -> Optional[datetime]:
    if not value:
        return None
    return datetime.fromisoformat(value.replace(class="hl-string">"Z", class="hl-string">"+00:00"))


def iso(value: Any) -> str:
    if isinstance(value, datetime):
        return value.astimezone(timezone.utc).isoformat()
    if value is None:
        return class="hl-string">""
    return str(value)


def get_json(url: str, params: Optional[Dict[str, Any]] = None) -> Dict[str, Any]:
    for attempt in range(6):
        response = SESSION.get(url, params=params, timeout=60)
        if response.status_code == 429:
            retry_after = int(response.headers.get(class="hl-string">"Retry-After", class="hl-string">"5"))
            time.sleep(max(retry_after, 2 ** attempt))
            continue
        response.raise_for_status()
        return response.json()
    raise RuntimeError(fclass="hl-string">"Request failed after retries: {url}")


def incremental_tickets(start_time: str) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json"
    params: Optional[Dict[str, Any]] = {class="hl-string">"start_time": int(parse_time(start_time).timestamp())}
    while url:
        payload = get_json(url, params)
        for ticket in payload.get(class="hl-string">"tickets", []):
            yield ticket
        if payload.get(class="hl-string">"end_of_stream"):
            break
        url = payload.get(class="hl-string">"after_url")
        params = None


def ticket_audits(ticket_id: int) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    while url:
        payload = get_json(url)
        for audit in payload.get(class="hl-string">"audits", []):
            yield audit
        url = payload.get(class="hl-string">"next_page")


def satisfaction_for_ticket(ticket_id: int) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/satisfaction_ratings.json"
    try:
        payload = get_json(url)
    except requests.HTTPError as error:
        if error.response is not None and error.response.status_code in (403, 404):
            return
        raise
    for rating in payload.get(class="hl-string">"satisfaction_ratings", []):
        yield rating


def user_name(user_id: Any, cache: Dict[str, str]) -> str:
    if not user_id:
        return class="hl-string">""
    key = str(user_id)
    if key not in cache:
        payload = get_json(fclass="hl-string">"{BASE_URL}/users/{user_id}.json")
        user = payload.get(class="hl-string">"user", {})
        cache[key] = user.get(class="hl-string">"name") or user.get(class="hl-string">"email") or key
    return cache[key]


def group_name(group_id: Any, cache: Dict[str, str]) -> str:
    if not group_id:
        return class="hl-string">""
    key = str(group_id)
    if key not in cache:
        payload = get_json(fclass="hl-string">"{BASE_URL}/groups/{group_id}.json")
        cache[key] = payload.get(class="hl-string">"group", {}).get(class="hl-string">"name") or key
    return cache[key]


def ticket_context(ticket: Dict[str, Any], users: Dict[str, str], groups: Dict[str, str]) -> Dict[str, str]:
    assignee = user_name(ticket.get(class="hl-string">"assignee_id"), users)
    group = group_name(ticket.get(class="hl-string">"group_id"), groups)
    return {
        class="hl-string">"TicketStatus": str(ticket.get(class="hl-string">"status") or class="hl-string">""),
        class="hl-string">"Assignee": assignee,
        class="hl-string">"AssignedGroup": group,
        class="hl-string">"TicketPriority": str(ticket.get(class="hl-string">"priority") or class="hl-string">""),
        class="hl-string">"Channel": str((ticket.get(class="hl-string">"via") or {}).get(class="hl-string">"channel") or class="hl-string">""),
        class="hl-string">"SlaStatus": class="hl-string">"",
    }


def make_row(ticket_id: Any, activity: str, event_time: Any, context: Dict[str, str], end_time: Any = class="hl-string">"") -> Dict[str, str]:
    row = {
        class="hl-string">"TicketId": str(ticket_id),
        class="hl-string">"ActivityName": activity,
        class="hl-string">"EventTimestamp": iso(event_time),
        class="hl-string">"SourceSystem": SOURCE_SYSTEM,
        class="hl-string">"LastDataUpdate": LAST_DATA_UPDATE,
        class="hl-string">"TicketStatus": context.get(class="hl-string">"TicketStatus", class="hl-string">""),
        class="hl-string">"Assignee": context.get(class="hl-string">"Assignee", class="hl-string">""),
        class="hl-string">"AssignedGroup": context.get(class="hl-string">"AssignedGroup", class="hl-string">""),
        class="hl-string">"TicketPriority": context.get(class="hl-string">"TicketPriority", class="hl-string">""),
        class="hl-string">"Channel": context.get(class="hl-string">"Channel", class="hl-string">""),
        class="hl-string">"SlaStatus": context.get(class="hl-string">"SlaStatus", class="hl-string">""),
        class="hl-string">"EventEndTime": iso(end_time),
    }
    return row


def audit_value(audit_event: Dict[str, Any], field: str) -> Any:
    for change in audit_event.get(class="hl-string">"changes", []):
        if change.get(class="hl-string">"field") == field:
            return change
    return None


def append_audit_rows(ticket: Dict[str, Any], audit: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    ticket_id = ticket.get(class="hl-string">"id")
    event_time = audit.get(class="hl-string">"created_at")
    context = ticket_context(ticket, users, groups)
    author = user_name(audit.get(class="hl-string">"author_id"), users)
    for change in audit.get(class="hl-string">"events", []):
        event_type = change.get(class="hl-string">"type")
        field = change.get(class="hl-string">"field")
        value = change.get(class="hl-string">"value")
        previous = change.get(class="hl-string">"previous_value")
        if event_type == class="hl-string">"Create" or field == class="hl-string">"created_at":
            rows.append(make_row(ticket_id, class="hl-string">"Incident Created", event_time, context))
        if field == class="hl-string">"group_id" and value is not None:
            context[class="hl-string">"AssignedGroup"] = group_name(value, groups)
            if previous not in (None, class="hl-string">"", value):
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Reassigned", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Assigned to Group", event_time, context))
        if field == class="hl-string">"assignee_id" and value is not None:
            context[class="hl-string">"Assignee"] = user_name(value, users)
            if previous not in (None, class="hl-string">"", value):
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Reassigned", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Assigned to Agent", event_time, context))
        if field == class="hl-string">"priority" and value is not None:
            context[class="hl-string">"TicketPriority"] = str(value)
            rows.append(make_row(ticket_id, class="hl-string">"Priority Set", event_time, context))
        if field == class="hl-string">"status":
            context[class="hl-string">"TicketStatus"] = str(value or class="hl-string">"")
            if value == class="hl-string">"open":
                rows.append(make_row(ticket_id, class="hl-string">"Status Changed to Open", event_time, context))
            if value == class="hl-string">"pending":
                rows.append(make_row(ticket_id, class="hl-string">"Status Changed to Pending", event_time, context))
            if value == class="hl-string">"solved":
                rows.append(make_row(ticket_id, class="hl-string">"Incident Resolved", event_time, context))
            if value == class="hl-string">"closed":
                rows.append(make_row(ticket_id, class="hl-string">"Incident Closed", event_time, context))
        if event_type == class="hl-string">"Comment":
            if bool(change.get(class="hl-string">"public")):
                rows.append(make_row(ticket_id, class="hl-string">"Public Reply Sent", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Internal Note Added", event_time, context))


def append_satisfaction_rows(ticket: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    context = ticket_context(ticket, users, groups)
    for rating in satisfaction_for_ticket(ticket.get(class="hl-string">"id")):
        rated_at = rating.get(class="hl-string">"created_at") or rating.get(class="hl-string">"updated_at")
        if rated_at:
            rows.append(make_row(ticket.get(class="hl-string">"id"), class="hl-string">"User Satisfaction Rated", rated_at, context))


def append_sla_breach_rows(ticket: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    context = ticket_context(ticket, users, groups)
    sla_breach_time = ticket.get(class="hl-string">"sla_breach_at")
    if sla_breach_time:
        context[class="hl-string">"SlaStatus"] = class="hl-string">"Breached"
        rows.append(make_row(ticket.get(class="hl-string">"id"), class="hl-string">"SLA Target Breached", sla_breach_time, context))


def extract() -> List[Dict[str, str]]:
    rows: List[Dict[str, str]] = []
    users: Dict[str, str] = {}
    groups: Dict[str, str] = {}
    seen = set()
    for ticket in incremental_tickets(START_DATE):
        for audit in ticket_audits(ticket.get(class="hl-string">"id")):
            append_audit_rows(ticket, audit, rows, users, groups)
        append_satisfaction_rows(ticket, rows, users, groups)
        append_sla_breach_rows(ticket, rows, users, groups)
    unique_rows: List[Dict[str, str]] = []
    for row in rows:
        key = (row[class="hl-string">"TicketId"], row[class="hl-string">"ActivityName"], row[class="hl-string">"EventTimestamp"], row[class="hl-string">"Assignee"], row[class="hl-string">"AssignedGroup"])
        if key not in seen:
            seen.add(key)
            unique_rows.append(row)
    unique_rows.sort(key=lambda item: (item[class="hl-string">"TicketId"], item[class="hl-string">"EventTimestamp"], item[class="hl-string">"ActivityName"]))
    return unique_rows


if __name__ == class="hl-string">"__main__":
    event_rows = extract()
    with open(OUTPUT_FILE, class="hl-string">"w", newline=class="hl-string">"", encoding=class="hl-string">"utf-8") as output:
        writer = csv.DictWriter(output, fieldnames=FIELDS)
        writer.writeheader()
        writer.writerows(event_rows)
    print(json.dumps({class="hl-string">"output_file": OUTPUT_FILE, class="hl-string">"rows": len(event_rows), class="hl-string">"last_data_update": LAST_DATA_UPDATE}))

Passaggi

Scelga uno strumento ETL commerciale o di integrazione dei dati con un connettore Zendesk Support verificato, in grado di estrarre la cronologia delle tracce di controllo dei ticket e i commenti e di scrivere nel data warehouse o nel file system di destinazione. Verifichi che il connettore supporti l’estrazione incrementale, la paginazione, la gestione dei limiti di frequenza e la conservazione dei timestamp di origine.
Crei la connessione Zendesk nello strumento scelto. Inserisca il sottodominio Zendesk, il metodo di autenticazione, le credenziali o il token e le eventuali impostazioni di connessione richieste, utilizzando l’interfaccia di configurazione dello strumento. Conceda l’accesso a ticket, tracce di controllo, commenti, utenti, gruppi, valutazioni di soddisfazione e dati SLA, se disponibili nel piano Zendesk e nel connettore.
Configuri l’intervallo di estrazione. Per il caricamento iniziale, utilizzi un periodo mobile da 3 a 6 mesi; successivamente, configuri i caricamenti incrementali in base al timestamp di aggiornamento o di registrazione della traccia supportato dal connettore. Memorizzi l’ultimo punto di ripresa completato correttamente al di fuori dell’Event Log, così da evitare duplicazioni o omissioni nelle esecuzioni successive.
Estragga i dati a livello di ticket necessari per il contesto del caso, inclusi identificativo del ticket, stato corrente o relativo all’evento, assegnatario, gruppo, priorità, canale di segnalazione, stato SLA e timestamp di aggiornamento pertinenti. Estragga le tracce di controllo dei ticket, poiché le modifiche all’assegnatario, alla priorità, allo stato e agli altri campi devono essere rappresentate da righe di evento esplicite.
Estragga i commenti dei ticket e distingua i commenti pubblici dalle note interne utilizzando l’indicatore di visibilità o di pubblicazione del connettore. Estragga i timestamp dei commenti, gli identificativi dei ticket e degli autori e gli eventuali orari di fine o timestamp di completamento disponibili. Crei righe Risposta pubblica inviata per i commenti pubblici e righe Nota interna aggiunta per quelli privati.
Estragga i record delle valutazioni di soddisfazione e del superamento degli SLA quando il connettore li rende disponibili. Se il connettore non espone direttamente gli eventi di superamento degli SLA, configuri lo strumento ETL per calcolarli usando gli obiettivi SLA, le politiche, gli orari lavorativi e i timestamp degli eventi disponibili. Non crei una riga di superamento se i dati di origine o il calcolo configurato non dimostrano che l’obiettivo è stato superato.
Riorganizzi i record di origine estratti in un Event Log normalizzato, creando una riga per ogni occorrenza esplicita di un’attività. Mappi la creazione del ticket su Incidente creato, le modifiche all’assegnazione del gruppo su Ticket assegnato al gruppo o Ticket riassegnato, le modifiche all’assegnazione dell’agente su Ticket assegnato all’agente o Ticket riassegnato, le modifiche alla priorità su Priorità impostata, le transizioni di stato sulla relativa attività, i commenti su Risposta pubblica inviata o Nota interna aggiunta, lo stato risolto su Incidente risolto, i record di soddisfazione su Valutazione della soddisfazione utente e lo stato chiuso su Incidente chiuso.
Applichi le regole di classificazione degli eventi in un ordine deterministico. Utilizzi, quando disponibili, i valori precedenti e nuovi della cronologia delle tracce di controllo. Classifichi la prima assegnazione a un gruppo come Ticket assegnato al gruppo, la prima assegnazione a un agente come Ticket assegnato all’agente e i successivi cambi di assegnatario come Ticket riassegnato. Generi una riga per ogni modifica pertinente, non solo per l’ultimo stato del ticket.
Compili le colonne obbligatorie TicketId, ActivityName, EventTimestamp, SourceSystem e LastDataUpdate. Compili le colonne consigliate TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus ed EventEndTime in base al contesto dell’evento o al record di origine valido più vicino. Mantenga i timestamp di origine in un fuso orario coerente, preferibilmente UTC, conservando la precisione supportata dal connettore.
Convalidi i dati trasformati verificando che ogni TicketId abbia una riga Incidente creato, che i timestamp degli eventi rientrino nell’intervallo di estrazione ove applicabile, che siano presenti tutti i 13 nomi di attività obbligatori quando i dati di origine lo consentono e che le chiavi degli eventi duplicati siano gestite in base all’identificativo della traccia di controllo o a una chiave composta documentata.
Scriva l’Event Log nella tabella del data warehouse o nel file di destinazione, in un formato tabellare compatibile con ProcessMind, ad esempio CSV o il formato supportato dal connettore del data warehouse. Utilizzi una riga di intestazione, nomi di colonna stabili, codifica UTF-8, timestamp ISO 8601 e nessun JSON annidato nelle colonne finali degli eventi. Carichi o colleghi l’Event Log risultante a ProcessMind senza fare affidamento su attività dedotte, poiché ProcessMind legge le righe estratte così come sono.

Configurazione

Connettore e licenza: utilizzi uno strumento ETL commerciale o di integrazione dei dati con un connettore Zendesk Support che esponga ticket, tracce di controllo, commenti, utenti, gruppi, valutazioni di soddisfazione e informazioni SLA, nei limiti del piano Zendesk e della versione del connettore.
Autenticazione e autorizzazioni: configuri il sottodominio Zendesk e un metodo di autenticazione approvato. Conceda solo le autorizzazioni necessarie per estrarre ticket, tracce di controllo, commenti, utenti, gruppi, dati di soddisfazione e dati SLA. Verifichi che l’account di integrazione possa leggere i record storici.
Intervallo di date: inizi con un periodo da 3 a 6 mesi per la convalida e il caricamento iniziale. Estenda l’intervallo solo dopo aver verificato il numero di righe, la paginazione e il comportamento dei limiti di frequenza. Per le esecuzioni pianificate, utilizzi un punto di ripresa incrementale.
Filtri obbligatori: applichi solo filtri specifici per l’azienda confermati nella configurazione di origine, ad esempio sottodominio Zendesk, marchio, organizzazione, gruppo o ambito dei ticket selezionati. Non applichi filtri Codice società o Tipo documento, a meno che tali campi non esistano nel modello di dati Zendesk configurato.
Cronologia delle tracce di controllo: abiliti l’estrazione degli eventi delle tracce di controllo dei ticket e conservi, quando disponibile, l’identificativo della traccia di origine per evitare duplicati nei caricamenti incrementali.
Commenti: estragga sia i commenti pubblici sia quelli privati. Utilizzi l’indicatore di visibilità di origine per classificare Risposta pubblica inviata e Nota interna aggiunta. Non deduca la visibilità dal testo del commento.
Classificazione delle assegnazioni: confronti i valori precedenti e nuovi del gruppo o dell’assegnatario. Classifichi separatamente la prima assegnazione pertinente e generi Ticket riassegnato per i successivi cambi di assegnatario.
Classificazione degli stati: generi righe solo per le transizioni di stato esplicite. Mappi i valori nuovo, aperto, in sospeso, risolto e chiuso in base al modello di stato Zendesk configurato. Se vengono utilizzati stati personalizzati, documenti la mappatura prima del caricamento.
Gestione degli SLA: dia la precedenza agli eventi di superamento degli SLA forniti dalla fonte. Se non sono disponibili, configuri un calcolo documentato basato sugli obiettivi SLA, sulle politiche, sugli orari lavorativi e sui timestamp degli eventi disponibili. Registri i criteri di calcolo nei metadati ETL, senza inventare campi di origine.
Gestione dei timestamp: normalizzi EventTimestamp ed EventEndTime in UTC o in un altro fuso orario documentato. Conservi il timestamp di origine ed eviti di sostituire l’ora dell’evento con quella dell’estrazione.
LastDataUpdate: imposti LastDataUpdate sul timestamp dell’aggiornamento ETL completato correttamente, mantenendo lo stesso valore per tutte le righe del caricamento.
Prestazioni: utilizzi paginazione, estrazione incrementale, partizionamento in base al timestamp di aggiornamento del ticket o della traccia di controllo, parallelismo controllato, gestione dei nuovi tentativi e attese in caso di limiti di frequenza. Eviti di estrarre ripetutamente l’intera cronologia dei ticket a ogni esecuzione pianificata.
Schema di destinazione: configuri una tabella o un file di eventi semplice con le colonne obbligatorie TicketId, ActivityName, EventTimestamp, SourceSystem e LastDataUpdate, oltre agli attributi consigliati disponibili.
Comportamento di ProcessMind: non faccia affidamento su ProcessMind per dedurre cambiamenti di stato, assegnazioni, risposte, note, superamenti degli SLA o tappe del ciclo di vita. Ogni attività deve essere già presente come riga di evento prima del caricamento.

a Query di esempio config

-- Configure this transformation in the selected ETL tool using its Zendesk connector.
-- Replace bracketed connection, credential, date, and company-specific values in the tool configuration.
-- The connector source objects and field mappings must be selected from the tool's verified Zendesk schema.

WITH
source_tickets AS (
    SELECT
        ticket_id,
        created_at,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        updated_at
    FROM [Your Zendesk tickets source]
    WHERE updated_at >= [Start date parameter]
      AND updated_at < [End date parameter]
),
source_audits AS (
    SELECT
        ticket_id,
        audit_id,
        event_timestamp,
        event_type,
        previous_value,
        new_value,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk ticket audits source]
    WHERE event_timestamp >= [Start date parameter]
      AND event_timestamp < [End date parameter]
),
source_comments AS (
    SELECT
        ticket_id,
        comment_id,
        event_timestamp,
        is_public,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk ticket comments source]
    WHERE event_timestamp >= [Start date parameter]
      AND event_timestamp < [End date parameter]
),
source_sla_breaches AS (
    SELECT
        ticket_id,
        breach_timestamp,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk SLA breach source]
    WHERE breach_timestamp >= [Start date parameter]
      AND breach_timestamp < [End date parameter]
),
source_satisfaction AS (
    SELECT
        ticket_id,
        rating_timestamp,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk satisfaction rating source]
    WHERE rating_timestamp >= [Start date parameter]
      AND rating_timestamp < [End date parameter]
),
classified_audits AS (
    SELECT
        a.*,
        ROW_NUMBER() OVER (
            PARTITION BY a.ticket_id, a.event_type
            ORDER BY a.event_timestamp, a.audit_id
        ) AS event_sequence
    FROM source_audits a
),
event_log AS (
    SELECT
        CAST(t.ticket_id AS VARCHAR(255)) AS TicketId,
        'Incident Created' AS ActivityName,
        t.created_at AS EventTimestamp,
        'Zendesk Support' AS SourceSystem,
        [ETL refresh timestamp] AS LastDataUpdate,
        t.status AS TicketStatus,
        t.assignee AS Assignee,
        t.assigned_group AS AssignedGroup,
        t.priority AS TicketPriority,
        t.channel AS Channel,
        t.sla_status AS SlaStatus,
        CAST(NULL AS TIMESTAMP) AS EventEndTime
    FROM source_tickets t

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Assigned to Group',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'group_assignment'
      AND a.event_sequence = 1
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Assigned to Agent',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'assignee_assignment'
      AND a.event_sequence = 1
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Priority Set',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.new_value,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'priority_change'
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Status Changed to Open',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.previous_value = 'new'
      AND a.new_value = 'open'

    UNION ALL

    SELECT
        CAST(c.ticket_id AS VARCHAR(255)),
        'Public Reply Sent',
        c.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        c.status,
        c.assignee,
        c.assigned_group,
        c.priority,
        c.channel,
        c.sla_status,
        c.event_end_time
    FROM source_comments c
    WHERE c.is_public = TRUE

    UNION ALL

    SELECT
        CAST(c.ticket_id AS VARCHAR(255)),
        'Internal Note Added',
        c.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        c.status,
        c.assignee,
        c.assigned_group,
        c.priority,
        c.channel,
        c.sla_status,
        c.event_end_time
    FROM source_comments c
    WHERE c.is_public = FALSE

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Reassigned',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type IN ('group_assignment', 'assignee_assignment')
      AND a.event_sequence > 1
      AND COALESCE(a.previous_value, '') <> COALESCE(a.new_value, '')

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Status Changed to Pending',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'pending'

    UNION ALL

    SELECT
        CAST(s.ticket_id AS VARCHAR(255)),
        'SLA Target Breached',
        s.breach_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        s.status,
        s.assignee,
        s.assigned_group,
        s.priority,
        s.channel,
        s.sla_status,
        s.event_end_time
    FROM source_sla_breaches s
    WHERE s.breach_timestamp IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Incident Resolved',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'solved'

    UNION ALL

    SELECT
        CAST(s.ticket_id AS VARCHAR(255)),
        'User Satisfaction Rated',
        s.rating_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        s.status,
        s.assignee,
        s.assigned_group,
        s.priority,
        s.channel,
        s.sla_status,
        s.event_end_time
    FROM source_satisfaction s
    WHERE s.rating_timestamp IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Incident Closed',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'closed'
)
SELECT
    TicketId,
    ActivityName,
    EventTimestamp,
    SourceSystem,
    LastDataUpdate,
    TicketStatus,
    Assignee,
    AssignedGroup,
    TicketPriority,
    Channel,
    SlaStatus,
    EventEndTime
FROM event_log
WHERE TicketId IS NOT NULL
  AND ActivityName IS NOT NULL
  AND EventTimestamp IS NOT NULL
ORDER BY TicketId, EventTimestamp, ActivityName;

È pronto a iniziare?

Utilizzi questo template per semplificare la preparazione dei dati e ottenere indicazioni utili sulle prestazioni del processo di gestione degli incidenti. Inizi oggi a ottimizzare il processo.

Torna alla guida al miglioramento Scarica il template

Ottimizzi la gestione degli incidenti e li risolva più rapidamente

Riduca del 35% il tempo medio di risoluzione (MTTR), elimini gli incidenti ricorrenti e migliori la soddisfazione.

Inizi la prova gratuita

Non è richiesta la carta di credito. Inizi a migliorare in pochi minuti.

Il Suo template dei dati per la gestione degli incidenti

Il Suo template dei dati per la gestione degli incidenti

Attributi per la gestione degli incidenti

Attività di gestione degli incidenti

Guide all’estrazione

Esportazione di un report da Zendesk Explore in formato CSV tramite l’interfaccia

Passaggi

Configurazione

a Query di esempio config

Script Python che utilizza l’API REST di Zendesk Support

Passaggi

Configurazione

a Query di esempio python

API di esportazione incrementale Zendesk per la sincronizzazione di grandi volumi di dati

Passaggi

Configurazione

a Query di esempio python

Strumento ETL di terze parti con connettore API Zendesk

Passaggi

Configurazione

a Query di esempio config

È pronto a iniziare?

Ottimizzi la gestione degli incidenti e li risolva più rapidamente

Il Suo template dei dati per la gestione degli incidenti

Il Suo template dei dati per la gestione degli incidenti

Attributi per la gestione degli incidenti

Attività di gestione degli incidenti

Guide all’estrazione

Esportazione di un report da Zendesk Explore in formato CSV tramite l’interfaccia

Passaggi

Configurazione

a Query di esempio config

Script Python che utilizza l’API REST di Zendesk Support

Passaggi

Configurazione

a Query di esempio python

API di esportazione incrementale Zendesk per la sincronizzazione di grandi volumi di dati

Passaggi

Configurazione

a Query di esempio python

Strumento ETL di terze parti con connettore API Zendesk

Passaggi

Configurazione

a Query di esempio config

È pronto a iniziare?

Ottimizzi la gestione degli incidenti e li risolva più rapidamente

La Sua privacy è importante