> Miglioramento continuo dei processi > Gestione dei problemi > Zendesk Support > Template dei dati

Il template dei dati per la gestione dei problemi

Zendesk Support

Attributi della gestione dei problemi (19) Attività di gestione dei problemi (12) Guide all’estrazione (3)

Il template dei dati per la gestione dei problemi

Questo template offre un quadro completo per mappare il ciclo di vita della gestione dei problemi in Zendesk Support. Descrive gli attributi essenziali, le tappe del processo e la logica di estrazione necessari per individuare i colli di bottiglia nell’analisi delle cause profonde. Seguendo questa struttura, può creare un Event Log di qualità elevata e ottenere informazioni più approfondite sul processo.

Attributi consigliati per un’analisi dettagliata
Attività chiave del processo e transizioni di stato
Indicazioni per estrarre i dati di Zendesk Support

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

Scarica il template

Attributi della gestione dei problemi

Questi campi dati consigliati forniscono il contesto necessario per analizzare le categorie dei ticket, i livelli di priorità e le responsabilità durante l’intero ciclo di risoluzione dei problemi.

5 Obbligatorio 8 Consigliato 6 Facoltativo

	Nome	Descrizione
	Attività ActivityName	Nome dell’evento o dell’azione eseguita sul record del problema.
Descrizione Questo attributo registra il passaggio o l’azione specifica compiuta durante il ciclo di vita del record del problema. Tra gli esempi figurano le modifiche di stato, come il passaggio da 'Open' a 'Pending', le modifiche di assegnazione o passaggi specifici del flusso di lavoro, come 'Workaround Published'. Nell’analisi, le attività costituiscono i nodi della mappa del processo. La loro sequenza consente agli analisti di visualizzare il flusso di lavoro, individuare i colli di bottiglia e misurare il tempo tra specifiche fasi del processo. Perché è importante Definisce il «che cosa» del processo e consente di visualizzarne il flusso e analizzarne le varianti. Dove reperirli Ricavato dai log di audit dei ticket Zendesk o dalle metriche dei ticket Esempi Registrazione del record del problemaAvvio dell’indaginePubblicazione della soluzione temporanea
	Ora di inizio EventTimestamp	Data e ora precise in cui si è verificata un’attività.
Descrizione Questo attributo registra il momento esatto in cui si è svolta un’attività nel sistema Zendesk. Fornisce la dimensione temporale necessaria per ordinare correttamente gli eventi e calcolare la durata tra le diverse fasi. Nell’analisi, è fondamentale per calcolare i tempi di ciclo, individuare i ritardi, verificare il rispetto degli SLA e visualizzare l’andamento del processo nel tempo. Senza timestamp accurati, è impossibile comprendere la velocità del processo di risoluzione dei problemi. Perché è importante Consente di ordinare le attività e calcolare tutti i KPI basati sul tempo. Dove reperirli Log di audit dei ticket Zendesk, campo 'created_at' Esempi 2023-10-12T08:30:00Z2023-10-12T09:15:22Z
	Record del problema ProblemRecordId	Identificativo numerico univoco assegnato al ticket del problema in Zendesk.
Descrizione Questo attributo rappresenta la chiave univoca del record del problema nel sistema Zendesk Support. Funge da ID del caso centrale per il Process Mining e consente di raggruppare in un’unica istanza del processo tutti gli eventi, gli aggiornamenti e le interazioni successive. Nell’analisi, questo ID serve a distinguere ogni percorso di indagine sul problema, dalla creazione alla chiusura. Consente di correlare gli incidenti collegati e di monitorare il ciclo di vita del problema attraverso i diversi livelli di assistenza. Perché è importante È la chiave obbligatoria fondamentale per raggruppare gli eventi in casi in qualsiasi analisi di Process Mining. Dove reperirli Oggetto Zendesk Ticket, campo 'id' con type='problem' Esempi 1045293849921
	Sistema di origine SourceSystem	Nome del sistema da cui provengono i dati.
Descrizione Questo attributo identifica la piattaforma software da cui sono stati estratti i dati del processo. In questo caso, il valore sarà sempre 'Zendesk Support'. Nell’analisi, soprattutto quando si combinano dati provenienti da più sistemi, ad esempio Zendesk e Jira, questo campo consente agli analisti di filtrare o raggruppare i dati in base alla loro origine. Garantisce la tracciabilità della provenienza dei dati nelle viste di processo che includono più sistemi. Perché è importante Garantisce la tracciabilità della provenienza dei dati e supporta configurazioni di Process Mining che coinvolgono più sistemi. Dove reperirli Impostato durante l’estrazione Esempi Zendesk Support
	Ultimo aggiornamento dei dati LastDataUpdate	Timestamp che indica quando il record del problema è stato modificato l’ultima volta.
Descrizione Questo attributo indica l’ultima volta in cui i dati del record del problema sono stati aggiornati nel sistema di origine. È diverso dal timestamp dell’evento, perché si riferisce al record nel suo complesso e non alla singola attività. Nell’analisi, aiuta a determinare quanto sono aggiornati i dati. Consente di verificare se il set di dati è aggiornato o se si verificano ritardi di sincronizzazione tra il sistema di origine e l’ambiente di Process Mining. Perché è importante Monitora l’aggiornamento dei dati e supporta le strategie di caricamento incrementale. Dove reperirli Oggetto Zendesk Ticket, campo 'updated_at' Esempi 2023-11-01T14:20:00Z
	Categoria del problema ProblemCategory	Classificazione del problema (ad es. software, hardware, rete).
Descrizione Questo attributo classifica il problema in base al servizio interessato o allo stack tecnologico. In genere corrisponde a un campo a discesa personalizzato nei moduli Zendesk. Nell’analisi viene utilizzato per la Dashboard «Precisione della classificazione dei problemi». Il confronto tra la categoria iniziale e la causa profonda individuata consente di verificare se la valutazione iniziale indirizza correttamente i problemi ai team competenti. Perché è importante Consente di segmentare i dati in base alla tecnologia o al servizio aziendale. Dove reperirli Campi personalizzati dei ticket Zendesk Esempi DatabaseInterfaccia utente ed esperienza utenteInfrastruttura di rete
	Categoria della causa profonda RootCauseCategory	La causa profonda individuata del problema (ad es. difetto del codice, errore di configurazione).
Descrizione Questo attributo registra la diagnosi finale della causa del problema. In genere viene compilato durante l’attività «Causa profonda individuata». Nell’analisi viene utilizzato per generare il report «Precisione della classificazione dei problemi» e analizzare le tendenze dei guasti di sistema. Aiuta la direzione a capire se sia opportuno concentrarsi sulla qualità del codice, sulla stabilità dell’infrastruttura o sulla gestione dei fornitori. Perché è importante Consente di analizzare gli schemi ricorrenti dei guasti e orienta le iniziative di miglioramento a lungo termine. Dove reperirli Campi personalizzati dei ticket Zendesk Esempi Bug softwareErrore di configurazioneErrore dell’utente
	Gruppo di assistenza SupportGroup	Team o reparto a cui è attualmente assegnato il record del problema.
Descrizione Questo attributo identifica il gruppo specifico di agenti responsabile del problema in un determinato momento. Cambia quando il ticket viene trasferito da un team a un altro. Nell’analisi, è fondamentale per la Dashboard di analisi dei passaggi tra gruppi di assistenza. Consente di misurare le prestazioni di ciascun team, individuare i colli di bottiglia nei passaggi di consegne e analizzare la distribuzione del carico di lavoro. Perché è importante Consente di analizzare l’organizzazione e individuare i colli di bottiglia tra i reparti. Dove reperirli Oggetto Zendesk Ticket, campo 'group_id' (risolto nel nome) Esempi Assistenza di secondo livelloTeam databaseGestione delle reti
	Nome dell’assegnatario AssigneeName	Agente specifico incaricato di gestire il problema.
Descrizione Questo attributo contiene il nome dell’utente attualmente responsabile del record del problema. Consente di sapere con precisione chi ha eseguito determinate azioni. Nell’analisi, aiuta a comprendere il carico di lavoro e le prestazioni individuali. L’analisi a livello di gruppo è comune, ma i dati sui singoli assegnatari possono evidenziare esigenze di formazione o individuare chi è particolarmente efficace nel risolvere problemi complessi e risalire alle cause profonde. Perché è importante Consente di analizzare le risorse a livello individuale. Dove reperirli Oggetto Zendesk Ticket, campo 'assignee_id' (risolto nel nome) Esempi Mario RossiGiulia BianchiSistema
	Numero di incidenti correlati RelatedIncidentCount	Numero di ticket di incidente collegati a questo record del problema.
Descrizione Questo attributo conta i ticket di incidente associati al record del problema. In Zendesk, il collegamento viene gestito tramite il campo 'problem_id' dei ticket di incidente, che rimanda a questo record. Nell’analisi, è la metrica principale per la correlazione e l’impatto degli incidenti. Aiuta a dare priorità ai problemi che coinvolgono il maggior numero di utenti e orienta le decisioni strategiche sugli interventi che possono ridurre maggiormente il volume dei ticket rispetto all’investimento. Perché è importante Indica la portata del problema e il suo impatto sugli utenti. Dove reperirli Zendesk Tickets API, conteggio dei ticket con type='incident' e problem_id=ThisID Esempi 015342
	Priorità Priority	Livello di urgenza assegnato al record del problema.
Descrizione Questo attributo indica l’importanza relativa del problema, generalmente classificata come bassa, normale, alta o urgente. Determina i livelli di servizio previsti (SLA) e l’allocazione delle risorse. Nell’analisi, viene utilizzato per segmentare il processo e confrontare le prestazioni in base ai diversi livelli di urgenza. Ad esempio, consente di verificare se i problemi urgenti vengono effettivamente risolti più rapidamente di quelli a bassa priorità, come previsto dalla Dashboard sulla velocità delle indagini sulle cause profonde. Perché è importante È essenziale per segmentare i casi e analizzare il rispetto degli SLA e la definizione delle priorità nell’allocazione delle risorse. Dove reperirli Oggetto Zendesk Ticket, campo 'priority' Esempi UrgenteAltaNormaleBassa
	Scadenza SLA SlaDueDate	Data e ora entro cui il problema dovrebbe essere risolto.
Descrizione Questo attributo rappresenta la scadenza per la risoluzione, definita in base alla configurazione dell’accordo sul livello di servizio. Di solito viene calcolata in base alla priorità e all’ora di creazione del ticket. Nell’analisi, viene confrontato con il tempo effettivo di risoluzione per calcolare il tasso di rispetto degli SLA dei problemi. Alimenta la Dashboard sulle prestazioni e sul rischio SLA, evidenziando i casi prossimi alla scadenza o che hanno superato il tempo previsto. Perché è importante È fondamentale per misurare il rispetto degli accordi e le prestazioni contrattuali. Dove reperirli Endpoint delle metriche dei ticket o delle policy SLA di Zendesk Esempi 2023-12-01T17:00:00Z
	Stato del problema ProblemStatus	Stato corrente del record del problema nel suo ciclo di vita.
Descrizione Questo attributo mostra lo stato corrente del problema, ad esempio New, Open, Pending, Solved o Closed, e riflette l’avanzamento dell’indagine. Nell’analisi, viene utilizzato per filtrare i casi aperti e quelli chiusi. È fondamentale per la Dashboard di monitoraggio dei record dei problemi non aggiornati, che consente di individuare i casi attivi che non avanzano secondo il ciclo di vita previsto. Perché è importante Consente di filtrare i casi in base al loro stato di completamento. Dove reperirli Oggetto Zendesk Ticket, campo 'status' Esempi nuovoapertoin attesarisoltochiuso
	ID dell’articolo della knowledge base KnowledgeArticleId	L’ID dell’articolo della knowledge base creato o collegato al problema.
Descrizione Questo attributo memorizza il riferimento a un articolo di Zendesk Guide o a un contenuto informativo esterno. Indica che le conoscenze acquisite sul problema sono state documentate. Nell’analisi, la presenza di questo campo viene utilizzata per calcolare il «Tasso di integrazione della knowledge base». Verifica che l’organizzazione completi il ciclo di apprendimento documentando le soluzioni per poterle consultare in futuro. Perché è importante Misura l’efficacia dei processi di gestione delle conoscenze. Dove reperirli Campi personalizzati dei ticket Zendesk o contenuti collegati Esempi 360045889KB-2991
	ID della richiesta di modifica ChangeRequestId	L’identificativo della richiesta di modifica collegata all’implementazione della correzione.
Descrizione Questo attributo collega il record del problema a un record di Change Management, eventualmente presente in un altro sistema o in un diverso tipo di ticket. Indica che è stato avviato un processo formale di modifica. Nell’analisi supporta la Dashboard «Tasso di avvio delle richieste di modifica». Consente di monitorare il passaggio dalla diagnosi all’implementazione, verificando che le cause profonde individuate portino ad azioni formali di modifica. Perché è importante Collega il processo di gestione dei problemi a quello di gestione delle modifiche. Dove reperirli Campi personalizzati dei ticket Zendesk o ticket collegati Esempi CR-1002CHG00394
	Inattivo da tempo IsStale	Segnala se non si sono registrate attività sul problema da oltre 14 giorni.
Descrizione Questo attributo calcolato individua i record che non sono stati aggiornati di recente. Confronta la data corrente (o la data di analisi) con l’ora dell’ultima attività. Nell’analisi alimenta la Dashboard «Monitoraggio dei record di problemi inattivi». Aiuta i responsabili a individuare rapidamente i casi trascurati che appesantiscono l’arretrato e che potrebbero richiedere la chiusura amministrativa o una nuova assegnazione. Perché è importante Aiuta a individuare gli sprechi nel processo e le attività trascurate. Dove reperirli Calcolato nello strumento di Process Mining: (Now - LastDataUpdate) > 14 days Esempi truefalse
	Oggetto del problema ProblemSubject	Breve riepilogo o titolo del record del problema.
Descrizione Questo attributo contiene il riepilogo testuale inserito al momento della creazione del problema. In genere descrive il sintomo o il problema oggetto dell’indagine. Nell’analisi, fornisce all’analista il contesto necessario per approfondire i singoli casi. È inoltre possibile applicare tecniche di analisi testuale per raggruppare problemi simili o individuare temi ricorrenti non registrati nei campi strutturati delle categorie. Perché è importante Fornisce un contesto leggibile per i singoli casi. Dove reperirli Oggetto Zendesk Ticket, campo 'subject' Esempi Impossibile elaborare i pagamenti nella regione UEPicchi di latenza sul server di accessoEsportazione dei dati non riuscita per gli utenti amministratori
	Revisione post-implementazione presente HasPostImplementationReview	Segnala se è stata effettuata una revisione post-implementazione.
Descrizione Questo attributo indica se il processo di risoluzione del problema ha incluso una fase di revisione. Viene ricavato verificando la presenza dell’attività «Revisione post-implementazione effettuata» nella cronologia del caso. Nell’analisi supporta la Dashboard «Copertura delle revisioni post-implementazione». È una metrica di conformità che verifica se l’organizzazione trae insegnamenti dai problemi più rilevanti. Perché è importante Verifica la conformità ai processi di miglioramento continuo. Dove reperirli Ricavato dalla presenza dell’attività «Revisione post-implementazione effettuata» Esempi truefalse
	Soluzione temporanea attiva WorkaroundActive	Indicatore che segnala se è stata fornita o pubblicata una soluzione temporanea.
Descrizione Questo attributo booleano indica se per il problema è stata documentata una soluzione temporanea. Spesso viene ricavato dalla presenza dell’attività «Soluzione temporanea pubblicata» o da una casella di controllo specifica nel modulo. Nell’analisi viene utilizzato per la Dashboard «Conformità alla pubblicazione delle soluzioni temporanee». Misura la frequenza con cui il team di supporto offre agli utenti un sollievo immediato mentre prosegue l’indagine a lungo termine. Perché è importante È fondamentale per misurare la riduzione dell’impatto sugli utenti durante le indagini. Dove reperirli Ricavato dalla presenza dell’attività «Soluzione temporanea pubblicata» o di un campo personalizzato Esempi truefalse

Obbligatorio Consigliato Facoltativo

Attività di gestione dei problemi

Acquisisca questi passaggi essenziali del processo e le variazioni di stato per visualizzare il flusso completo, dall’identificazione iniziale del problema all’implementazione della soluzione definitiva.

8 Consigliato 4 Facoltativo

	Attività	Descrizione
	Applicazione della soluzione definitiva	Indica che la soluzione tecnica è stata distribuita nell’ambiente. Di solito viene rilevata tramite una transizione di stato personalizzata o un tag specifico, prima che il ticket venga risolto completamente.
Perché è importante È essenziale per la Dashboard sull’efficienza dell’implementazione delle correzioni, che misura il tempo dalla diagnosi alla distribuzione. Dove reperirli Dedotto dalla presenza di un tag specifico, ad esempio 'fix_deployed', o di un campo di stato personalizzato, se disponibile. Acquisizione Monitorare i tag o i menu a discesa degli stati personalizzati Tipo di evento inferred
	Assegnazione a un gruppo di assistenza	Instradamento del record del problema a uno specifico team tecnico o reparto. Viene rilevato quando si aggiorna il campo Group ID del ticket.
Perché è importante È essenziale per la Dashboard di analisi dei passaggi tra gruppi di assistenza, che misura i tempi di attesa tra i reparti. Dove reperirli Monitorare le modifiche al campo 'group_id' nel log di audit del ticket. Acquisizione Registrato all’esecuzione della transazione Group Assignment Change Tipo di evento explicit
	Avvio dell’indagine	Segna il passaggio dallo stato passivo 'New' a uno stato di lavoro attivo. Indica che un agente ha preso in carico il problema e ha avviato la diagnosi.
Perché è importante Viene utilizzato per calcolare le metriche dei record dei problemi non aggiornati e costituisce il punto di partenza del KPI sulla durata media dell’analisi delle cause profonde. Dove reperirli Dedotto quando lo stato del ticket passa da 'New' a 'Open' o 'Pending'. Acquisizione Confrontare il campo di stato prima e dopo la modifica Tipo di evento inferred
	Chiusura del record del problema	Evento finale del ciclo di vita, in cui il ticket viene bloccato e non può più essere modificato. In Zendesk, di solito avviene automaticamente 4 giorni dopo il passaggio allo stato Solved.
Perché è importante Segna la fine definitiva del ciclo di vita del record e viene utilizzato per la conservazione dei dati e la reportistica storica. Dove reperirli Ricavato dal passaggio dello stato del ticket a 'Closed'. Acquisizione Registrato quando lo stato passa a Closed Tipo di evento explicit
	Individuazione della causa profonda	Momento in cui viene determinata la causa sottostante del problema. In genere, l’evento viene registrato quando l’agente compila un campo di testo personalizzato 'Root Cause' o seleziona una categoria da un menu a discesa.
Perché è importante È una tappa fondamentale per la Dashboard sulla velocità delle indagini sulle cause profonde e per misurare l’efficienza della diagnosi. Dove reperirli Monitorare le modifiche ai campi personalizzati denominati 'Root Cause', 'RCA' o 'Problem Source' e verificare che contengano un valore. Acquisizione Confrontare i valori dei campi personalizzati per verificare che siano compilati Tipo di evento inferred
	Pubblicazione della soluzione temporanea	Documentazione e condivisione di una soluzione temporanea al problema. In Zendesk, l’evento viene spesso registrato tramite un tag specifico o un campo casella di controllo personalizzato che indica la disponibilità di una soluzione temporanea.
Perché è importante Supporta la Dashboard di conformità alla pubblicazione delle soluzioni temporanee, assicurando agli utenti un rimedio provvisorio durante le indagini più lunghe. Dove reperirli Monitorare l’aggiunta del tag 'workaround_published' o la modifica di un campo booleano personalizzato denominato 'Workaround'. Acquisizione Confrontare i valori dei campi personalizzati o dei tag Tipo di evento inferred
	Registrazione del record del problema	Creazione iniziale del ticket del problema in Zendesk Support. Questo evento registra il timestamp in cui il problema è stato inserito per la prima volta nel sistema e di norma avvia l’istanza del processo.
Perché è importante Definisce l’ora di inizio del ciclo di risoluzione end-to-end e costituisce la base di riferimento per tutte le successive metriche del tempo di attraversamento. Dove reperirli Ricavato dal timestamp 'created_at' nell’oggetto ticket o dalla prima voce del log di audit del ticket. Acquisizione Registrato all’esecuzione della transazione Ticket Created Tipo di evento explicit
	Verifica della risoluzione	Registrazione formale del problema come risolto. In Zendesk, avviene quando lo stato standard del sistema viene impostato su 'Solved', a indicare che la correzione è stata verificata e il caso è concluso.
Perché è importante È il punto finale di riferimento per il calcolo delle prestazioni e del rischio SLA e del tasso di rispetto degli SLA dei problemi. Dove reperirli Ricavato dal passaggio dello stato del ticket a 'Solved'. Acquisizione Registrato quando lo stato passa a Solved Tipo di evento explicit
	Avvio della richiesta di modifica	Indica l’avvio di un processo formale di gestione delle modifiche per risolvere il problema. L’evento viene spesso dedotto quando si compila un campo personalizzato 'Change Request ID' o si collega un ticket di tipo 'Change'.
Perché è importante Monitora il tasso di avvio delle richieste di modifica e collega la gestione dei problemi ai flussi di lavoro di gestione delle modifiche. Dove reperirli Monitorare gli aggiornamenti di un campo personalizzato come 'change_reference' o la creazione di un collegamento di tipo 'problem_change'. Acquisizione Monitorare l’inserimento di un ID esterno nel campo personalizzato Tipo di evento inferred
	Riapertura dell’indagine sul problema	Si verifica quando un record del problema precedentemente contrassegnato come risolto torna allo stato Open o a uno stato attivo. Può indicare una correzione inefficace o una risoluzione respinta.
Perché è importante Supporta il KPI sul tasso di riapertura dei problemi e aiuta a individuare problemi di qualità nel processo di risoluzione. Dove reperirli Dedotto quando lo stato passa da 'Solved' a 'Open', 'New' o 'Pending'. Acquisizione Confrontare il campo di stato prima e dopo la modifica Tipo di evento inferred
	Stesura della soluzione proposta	Creazione di un articolo della knowledge base sulla base dell’indagine sul problema. L’evento viene dedotto dall’utilizzo dell’app Zendesk Knowledge Capture o dal collegamento di un nuovo articolo.
Perché è importante Supporta il KPI sul tasso di integrazione con la knowledge base e favorisce l’apprendimento organizzativo. Dove reperirli Monitorare gli eventi relativi all’integrazione 'Knowledge Capture' o la presenza di tag come 'kcs_draft'. Acquisizione Ricavare l’evento da tag specifici del sistema o da eventi di collegamento Tipo di evento inferred
	Svolgimento della revisione successiva all’implementazione	Conferma del completamento di una revisione retrospettiva dopo la correzione. In genere, l’evento viene registrato tramite una casella di controllo o un campo data aggiornato dal coordinatore del processo.
Perché è importante È necessario per il KPI sulla frequenza delle revisioni successive all’implementazione e per garantire il rispetto degli standard di qualità. Dove reperirli Monitorare gli aggiornamenti della casella di controllo personalizzata 'PIR Completed' o del campo data 'PIR Date'. Acquisizione Monitorare il completamento tramite il campo personalizzato Tipo di evento inferred

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da Zendesk Support

Passaggi

Acceda alla Sua istanza Zendesk e apra l’interfaccia di reportistica Explore dal menu dei prodotti.
Faccia clic sulla cartella Queries (o Reports nelle versioni più recenti) e selezioni New query.
Quando Le viene chiesto di selezionare un dataset, scelga Support, quindi Updates History e infine Support: Updates History [default]. Questo dataset contiene i log degli eventi necessari per il Process Mining, non soltanto i dati sullo stato attuale.
Nel pannello Metrics, aggiunga Count (Tickets) o Count (Updates) per verificare che i dati vengano recuperati.
Nel pannello Filters, aggiunga un filtro per Ticket > Ticket type e selezioni Problem, così da limitare il dataset al processo di gestione dei problemi.
Nel pannello Rows, aggiunga i seguenti attributi nell’ordine indicato per definire la struttura dell’event log: Ticket > Ticket ID, Time - Timestamp > Update - Timestamp, Updater > Updater name e Changes > Changes - Field name.
Per creare la colonna Activity Name, deve creare un attributo calcolato standard. Faccia clic sull’icona Calculation nella barra laterale destra, selezioni Standard calculated attribute, lo denomini Activity Mapper e incolli il codice fornito nella sezione Query qui sotto.
Aggiunga il nuovo attributo Activity Mapper al pannello Rows. Imposti un filtro su questo attributo per escludere i valori NULL e rimuovere le informazioni di sistema non pertinenti.
Aggiunga al pannello Rows altri attributi utili per il contesto: Ticket > Priority, Ticket > Group, Ticket > Status e gli eventuali campi personalizzati necessari per analizzare le cause profonde o le categorie, ad esempio Ticket > Ticket tags o campi personalizzati specifici.
Nel pannello Filters, imposti l’intervallo di tempo usando Time - Timestamp > Update - Date, in modo da includere il periodo di analisi desiderato, ad esempio Last 6 Months.
Faccia clic sull’icona Visualization type e selezioni Table. Se disponibile, verifichi che la tabella sia non pivotata o piatta; in alternativa, si assicuri semplicemente che tutti gli attributi siano nella sezione Rows.
Esporti il risultato facendo clic su Export > CSV. Verifichi che sia selezionata la casella Keep attribute formatting, così da preservare i formati dei timestamp per ProcessMind.

Configurazione

Insieme di dati: Support: Updates History (importante: non utilizzi l’insieme di dati standard Tickets, perché mostra solo lo stato corrente).
Filtro temporale: Update - Date (intervallo consigliato: ultimi 90-180 giorni, in base al volume).
Tipo di ticket: Applichi un filtro che includa esclusivamente Problem, per evitare di mescolare Incident e Service Requests.
Limite di righe: Le esportazioni da Zendesk Explore sono spesso limitate a 50.000 righe. Se il dataset supera questo limite, utilizzi il filtro Update - Date per esportare i dati in blocchi mensili più piccoli e unirli esternamente.
Campi personalizzati: Individui gli ID specifici dei campi Root Cause, Change Request e Workaround nell’istanza Zendesk in uso, poiché non sono campi standard del sistema.
Autorizzazioni di sistema: È necessaria una licenza Explore Viewer o Explore Professional.

a Query di esempio config

IF ([Changes - Field name] = "status" AND [Changes - New value] = "New") THEN "Problem Record Logged"
ELIF ([Changes - Field name] = "group_id") THEN "Assigned to Support Group"
ELIF ([Changes - Field name] = "status" AND [Changes - Previous value] = "New" AND [Changes - New value] = "Open") THEN "Investigation Commenced"
ELIF ([Changes - Field name] = "tags" AND CONTAINS([Changes - New value], "workaround_available")) THEN "Workaround Published"
ELIF ([Changes - Field name] = "[Your Root Cause Field Name]") THEN "Root Cause Identified"
ELIF ([Changes - Field name] = "[Your Change Request ID Field Name]") OR ([Changes - Field name] = "type" AND [Changes - New value] = "change") THEN "Change Request Initiated"
ELIF ([Changes - Field name] = "tags" AND CONTAINS([Changes - New value], "fix_deployed")) THEN "Permanent Fix Applied"
ELIF ([Changes - Field name] = "[Your Knowledge Article Linked Field]") THEN "Proposed Solution Drafted"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "Solved") THEN "Resolution Verified"
ELIF ([Changes - Field name] = "status" AND [Changes - Previous value] = "Solved" AND [Changes - New value] = "Open") THEN "Problem Investigation Reopened"
ELIF ([Changes - Field name] = "[Your PIR Completed Checkbox Field]") THEN "Post-Implementation Review Conducted"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "Closed") THEN "Problem Record Closed"
ELSE NULL
ENDIF

Passaggi

Verifica dei prerequisiti: verifichi che nella Sua organizzazione sia attivo il componente aggiuntivo Zendesk Data Sharing. Si assicuri di disporre di credenziali di accesso in sola lettura al database Zendesk replicato, ospitato in genere su Snowflake o Amazon Redshift.
Connessione al database: utilizzi il client SQL che preferisce, ad esempio DBeaver, DataGrip o l’interfaccia web nativa di Snowflake/Redshift, per connettersi al data warehouse Zendesk con le credenziali fornite.
Individuazione dei campi personalizzati: prima di eseguire la query, individui gli ID univoci dei campi personalizzati utilizzati nel processo di gestione dei problemi. In Zendesk apra Admin Center e selezioni Objects and rules > Tickets > Fields. Individui i campi 'Root Cause', 'Change Request ID', 'Workaround Published', 'Permanent Fix Applied' e 'Post-Implementation Review' per recuperarne gli ID specifici. Questi ID serviranno a sostituire i segnaposto nella query.
Revisione della query SQL: la query fornita utilizza una Common Table Expression (CTE) denominata ProblemTickets per selezionare e filtrare inizialmente tutti i record relativi ai problemi. Questo migliora le prestazioni e la leggibilità. La query principale usa quindi UNION ALL per combinare i risultati di 12 istruzioni SELECT separate, una per ciascuna attività richiesta.
Personalizzazione della query: apra un nuovo editor di query e incolli lo script SQL completo. Modifichi i segnaposto nello script:
- Nella CTE ProblemTickets, imposti l’intervallo di date desiderato sostituendo '[YYYY-MM-DD]'.
- Per ogni attività che dipende da un campo personalizzato, sostituisca gli ID segnaposto, ad esempio [Your 'Root Cause Category' field_id] e [Your 'Change Request ID' field_id], con gli ID effettivi individuati al passaggio 3.
Esecuzione della query: esegua lo script SQL modificato sul database. Il tempo di esecuzione varia in base all’intervallo di date e al volume dei dati dei ticket.
Verifica della logica di 'Proposed Solution Drafted': la query presuppone che la stesura di una soluzione venga registrata compilando un campo personalizzato denominato [Your 'KB Article ID' field_id]. Se il Suo processo è diverso, ad esempio se utilizza un tag o un commento specifico, dovrà modificare di conseguenza questa parte della query.
Convalida dei dati: al termine della query, riveda brevemente i risultati. Verifichi che il numero di righe sia plausibile, che siano presenti tutte le colonne e che non vi siano valori NULL inattesi in colonne essenziali come ProblemRecordId e EventTimestamp.
Esportazione dell’event log: esporti l’intero set di risultati dal client SQL in un file CSV. Si assicuri che il file utilizzi la codifica UTF-8 e che le intestazioni delle colonne corrispondano ai nomi degli attributi richiesti dallo strumento di Process Mining.
Preparazione al caricamento: prima di caricare il file, controlli che il CSV non presenti problemi di formattazione. Verifichi che i valori di data e ora nella colonna EventTimestamp seguano un formato coerente, ad esempio YYYY-MM-DD HH24:MI:SS.

Configurazione

Prerequisiti: questa estrazione richiede il componente aggiuntivo Zendesk Data Sharing e l’accesso SQL diretto ai dati replicati in un’istanza Snowflake o Amazon Redshift.
Filtro per tipo di ticket: la query è già configurata per analizzare soltanto i ticket il cui type è 'problem'. Questo è essenziale per isolare il processo di gestione dei problemi da incidenti e altri tipi di ticket.
Filtro per intervallo di date: si consiglia vivamente di filtrare i dati per un periodo specifico, così da gestire le prestazioni. La query include nella CTE iniziale il segnaposto created_at >= '[YYYY-MM-DD]'. Per una prima analisi è in genere adatto un intervallo da 3 a 6 mesi.
Configurazione dei campi personalizzati: questa estrazione dipende in larga misura dalla configurazione specifica di Zendesk. Deve individuare e inserire il field_id corretto per i campi personalizzati che registrano attività come 'Root Cause Identified', 'Change Request Initiated' e 'Workaround Published'. Se gli ID segnaposto non vengono sostituiti, la query non funzionerà o non restituirà dati per queste attività.
Latenza dei dati: i dati nel database replicato non sono in tempo reale. In genere trascorrono alcune ore tra il verificarsi di un evento in Zendesk e la sua comparsa nel data warehouse. Ne tenga conto quando analizza attività molto recenti.

a Query di esempio sql

WITH ProblemTickets AS (
  SELECT
    t.id,
    t.created_at,
    t.updated_at,
    t.priority,
    g.name AS group_name,
    u.name AS assignee_name,
    t.status,
    (SELECT COUNT(*) FROM problem_incident_links pil WHERE pil.problem_id = t.id) AS related_incident_count,
    t.due_at AS sla_due_date,
    cf_cat.value AS problem_category,
    cf_root.value AS root_cause_category
  FROM tickets t
  LEFT JOIN users u ON t.assignee_id = u.id
  LEFT JOIN groups g ON t.group_id = g.id
  LEFT JOIN custom_field_values cf_cat ON t.id = cf_cat.ticket_id AND cf_cat.custom_field_id = [Your 'Problem Category' field_id]
  LEFT JOIN custom_field_values cf_root ON t.id = cf_root.ticket_id AND cf_root.custom_field_id = [Your 'Root Cause Category' field_id]
  WHERE t.type = 'problem'
  AND t.created_at >= '[YYYY-MM-DD]' -- Set start date for the extraction
)
-- 1. Problem Record Logged
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Record Logged' AS "ActivityName",
  pt.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'new' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ProblemTickets pt

UNION ALL

-- 2. Assigned to Support Group
SELECT
  pt.id AS "ProblemRecordId",
  'Assigned to Support Group' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'group'

UNION ALL

-- 3. Investigation Commenced
SELECT
  pt.id AS "ProblemRecordId",
  'Investigation Commenced' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'open' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'open' AND tme.previous_value = 'new'

UNION ALL

-- 4. Workaround Published
SELECT
  pt.id AS "ProblemRecordId",
  'Workaround Published' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Workaround Published'' custom field name]' AND tme.value IS NOT NULL -- Example: checkbox being checked or field being filled

UNION ALL

-- 5. Root Cause Identified
SELECT
  pt.id AS "ProblemRecordId",
  'Root Cause Identified' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Root Cause Category'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 6. Change Request Initiated
SELECT
  pt.id AS "ProblemRecordId",
  'Change Request Initiated' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Change Request ID'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 7. Permanent Fix Applied
SELECT
  pt.id AS "ProblemRecordId",
  'Permanent Fix Applied' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Permanent Fix Applied'' custom field name]' AND tme.value IS NOT NULL -- Assumes a custom field indicates this status

UNION ALL

-- 8. Proposed Solution Drafted
SELECT
  pt.id AS "ProblemRecordId",
  'Proposed Solution Drafted' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''KB Article ID'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 9. Resolution Verified
SELECT
  pt.id AS "ProblemRecordId",
  'Resolution Verified' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'solved' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'solved'

UNION ALL

-- 10. Problem Investigation Reopened
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Investigation Reopened' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'open' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'open' AND tme.previous_value IN ('pending', 'solved')

UNION ALL

-- 11. Post-Implementation Review Conducted
SELECT
  pt.id AS "ProblemRecordId",
  'Post-Implementation Review Conducted' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Post-Implementation Review'' custom field name]' AND tme.value IS NOT NULL -- Assumes a checkbox or date field

UNION ALL

-- 12. Problem Record Closed
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Record Closed' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'closed' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'closed' AND tme.previous_value = 'solved';

Passaggi

Prerequisiti: verifichi che sul Suo sistema sia installato Python 3.6 o versione successiva. Installi le librerie necessarie requests e pandas eseguendo pip install requests pandas nel terminale o nel prompt dei comandi.
Generazione del token API Zendesk: acceda a Zendesk Support come amministratore. Apra Admin Center > Apps and integrations > APIs > Zendesk API. Nella sezione Token Access, faccia clic su 'Add API token' per creare un nuovo token. Lo copi subito e lo conservi in un luogo sicuro, poiché non verrà mostrato di nuovo.
Configurazione dello script Python: crei un nuovo file Python, ad esempio extract_zendesk_problems.py, e vi copi lo script completo fornito nella sezione Query. Aggiorni le variabili segnaposto all’inizio dello script: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN e START_TIME. Per la prima esecuzione, imposti START_TIME sul timestamp Unix della data di inizio desiderata per l’estrazione.
Mappatura degli ID dei campi personalizzati: individui gli ID numerici dei campi personalizzati utilizzati nel processo di gestione dei problemi. Può trovarli in Admin Center > Objects and rules > Tickets > Fields, controllando l’URL o le proprietà dei campi. Aggiorni il dizionario CUSTOM_FIELD_MAPPING nello script con gli ID specifici della Sua istanza.
Esecuzione dello script: esegua lo script dal terminale con il comando python extract_zendesk_problems.py. Lo script inizierà a recuperare i dati da Zendesk Incremental Export API.
Monitoraggio dell’esecuzione: lo script mostrerà lo stato di avanzamento, compreso il numero di ticket elaborati e il timestamp dei dati recuperati. Gestirà automaticamente i limiti di frequenza dell’API, sospendendo l’esecuzione quando necessario.
Recupero e trasformazione dei dati: lo script recupera innanzitutto tutti i ticket relativi a problemi creati o aggiornati a partire da START_TIME. Per ciascun ticket, recupera quindi la cronologia completa delle verifiche, che contiene tutte le modifiche storiche.
Generazione dell’event log: lo script elabora ogni evento di verifica e associa le modifiche ai campi, come stato, gruppo o campi personalizzati, alle attività aziendali definite. Recupera inoltre i nomi di utenti e gruppi e li memorizza nella cache per arricchire i dati.
Gestione dei caricamenti incrementali: dopo il primo caricamento completo, per le esecuzioni successive aggiorni la variabile START_TIME con il valore end_time mostrato al termine dell’esecuzione precedente completata correttamente. In questo modo recupererà soltanto i dati nuovi e aggiornati, senza duplicati.
Revisione dei risultati: al termine dell’esecuzione, lo script genererà nella stessa cartella un file denominato zendesk_problem_event_log.csv. Il file CSV contiene l’event log strutturato, pronto per l’analisi.
Preparazione al caricamento: apra il file CSV con uno strumento per fogli di calcolo e ne verifichi il contenuto. Prima di caricarlo in ProcessMind, si assicuri che siano presenti e compilate correttamente tutte le colonne richieste (ProblemRecordId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate).

Configurazione

Credenziali API Zendesk: per l’autenticazione, lo script richiede il sottodominio Zendesk, l’indirizzo e-mail dell’utente associato al token API e il token stesso.
Ora di inizio: la variabile START_TIME è un timestamp Unix epoch che definisce il punto iniziale dell’estrazione dei dati. Per la prima esecuzione, imposti una data passata, ad esempio di 6 mesi prima, per recuperare i dati storici. Per le esecuzioni successive, utilizzi l’ora di fine dell’esecuzione precedente per recuperare i dati in modo incrementale.
Mappatura dei campi personalizzati: il dizionario CUSTOM_FIELD_MAPPING è essenziale. Deve sostituire gli ID segnaposto con gli ID effettivi dei campi personalizzati della Sua istanza Zendesk, così da acquisire correttamente attività come 'Workaround Published' e 'Root Cause Identified'.
Filtro per tipo di ticket: lo script è configurato per elaborare soltanto i ticket il cui type è 'problem'. In questo modo, incidenti, attività e domande vengono esclususi dall’event log della gestione dei problemi.
Limiti di frequenza dell’API: lo script include una funzione di base time.sleep(60) per gestire gli errori 429 'Too Many Requests'. Potrebbe essere necessario modificare la durata della pausa in base al piano Zendesk e al volume dei dati estratti.
Prerequisiti: per eseguire lo script è necessario un ambiente Python 3 con le librerie requests e pandas. Il token API deve essere associato a un account autorizzato a leggere i dati dei ticket.

a Query di esempio python

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

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk subdomain, email, and API token
ZENDESK_SUBDOMAIN = class="hl-string">'[your_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_email@example.com]'
ZENDESK_API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1641013200 is for Jan 1, 2022 00:00:00 GMT
START_TIME = 1641013200

class=class="hl-string">"hl-comment"># Map your custom field IDs to the corresponding activity names
class=class="hl-string">"hl-comment"># Find IDs in Admin Center > Objects and rules > Tickets > Fields
CUSTOM_FIELD_MAPPING = {
    class="hl-string">'[Your Workaround Published Field ID]': class="hl-string">'Workaround Published',
    class="hl-string">'[Your Root Cause Identified Field ID]': class="hl-string">'Root Cause Identified',
    class="hl-string">'[Your Change Request Initiated Field ID]': class="hl-string">'Change Request Initiated',
    class="hl-string">'[Your Permanent Fix Applied Field ID]': class="hl-string">'Permanent Fix Applied',
    class="hl-string">'[Your Proposed Solution Drafted Field ID]': class="hl-string">'Proposed Solution Drafted',
    class="hl-string">'[Your Post-Implementation Review Field ID]': class="hl-string">'Post-Implementation Review Conducted'
}

class=class="hl-string">"hl-comment"># --- SCRIPT --- 
BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
API_USER = fclass="hl-string">'{ZENDESK_EMAIL}/token'

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

session = requests.Session()
session.auth = (API_USER, ZENDESK_API_TOKEN)

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

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

def fetch_tickets(start_time):
    tickets_url = fclass="hl-string">'{BASE_URL}/incremental/tickets.json'
    params = {class="hl-string">'start_time': start_time, class="hl-string">'include': class="hl-string">'metric_sets'}
    all_tickets = []
    while tickets_url:
        try:
            print(fclass="hl-string">"Fetching from: {tickets_url}")
            response = session.get(tickets_url, params=params)
            class=class="hl-string">"hl-comment"># params are only needed for the first request
            params = {}
            if response.status_code == 429:
                print(class="hl-string">"Rate limit reached. Waiting for 60 seconds.")
                time.sleep(60)
                continue
            response.raise_for_status()
            data = response.json()
            all_tickets.extend(data.get(class="hl-string">'tickets', []))
            tickets_url = data.get(class="hl-string">'next_page')
            if not data.get(class="hl-string">'end_of_stream', True):
                 class=class="hl-string">"hl-comment"># Wait a moment before the next page request to be safe
                 time.sleep(1)
            else:
                print(fclass="hl-string">"End of stream reached. Final timestamp: {data.get('end_time')}")
                tickets_url = None
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching tickets: {e}")
            break
    return all_tickets

def process_ticket_audits(ticket, event_log):
    ticket_id = ticket[class="hl-string">'id']
    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', [])
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching audits for ticket {ticket_id}: {e}")
        return

    base_attributes = {
        class="hl-string">'ProblemRecordId': ticket_id,
        class="hl-string">'SourceSystem': class="hl-string">'Zendesk Support',
        class="hl-string">'LastDataUpdate': ticket[class="hl-string">'updated_at'],
        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'RelatedIncidentCount': ticket.get(class="hl-string">'metric_set', {}).get(class="hl-string">'replies', 0), class=class="hl-string">"hl-comment"># Using replies as a proxy if incident_count is not available
        class="hl-string">'SlaDueDate': ticket.get(class="hl-string">'due_at'),
        class="hl-string">'ProblemCategory': next((f[class="hl-string">'value'] for f in ticket.get(class="hl-string">'custom_fields', []) if f.get(class="hl-string">'id') == class="hl-string">'[Your Problem Category Field ID]'), None)
    }

    class=class="hl-string">"hl-comment"># 1. Problem Record Logged
    event_log.append({
        **base_attributes,
        class="hl-string">'ActivityName': class="hl-string">'Problem Record Logged',
        class="hl-string">'EventTimestamp': ticket[class="hl-string">'created_at'],
        class="hl-string">'SupportGroup': get_group_name(ticket.get(class="hl-string">'group_id')),
        class="hl-string">'AssigneeName': get_user_name(ticket.get(class="hl-string">'assignee_id')),
        class="hl-string">'ProblemStatus': class="hl-string">'new',
        class="hl-string">'RootCauseCategory': None
    })

    class=class="hl-string">"hl-comment"># Process audit trail for other activities
    for audit in audits:
        audit_ts = audit[class="hl-string">'created_at']
        for event in audit.get(class="hl-string">'events', []):
            activity_name = None
            field_name = event.get(class="hl-string">'field_name')
            value = event.get(class="hl-string">'value')
            previous_value = event.get(class="hl-string">'previous_value')

            class=class="hl-string">"hl-comment"># 2. Assigned to Support Group
            if field_name == class="hl-string">'group_id' and value is not None:
                activity_name = class="hl-string">'Assigned to Support Group'
            
            class=class="hl-string">"hl-comment"># 3. Investigation Commenced (New -> Open)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'open' and previous_value == class="hl-string">'new':
                activity_name = class="hl-string">'Investigation Commenced'

            class=class="hl-string">"hl-comment"># 4-9. Activities from Custom Fields
            elif str(field_name) in CUSTOM_FIELD_MAPPING and value is not None and value not in [False, class="hl-string">'0', class="hl-string">'']:
                activity_name = CUSTOM_FIELD_MAPPING[str(field_name)]

            class=class="hl-string">"hl-comment"># 10. Resolution Verified (Any -> Solved)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'solved':
                activity_name = class="hl-string">'Resolution Verified'
            
            class=class="hl-string">"hl-comment"># 11. Problem Investigation Reopened (Solved/Closed -> Open)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'open' and previous_value in [class="hl-string">'solved', class="hl-string">'closed']:
                activity_name = class="hl-string">'Problem Investigation Reopened'

            class=class="hl-string">"hl-comment"># 12. Problem Record Closed (Any -> Closed)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'closed':
                activity_name = class="hl-string">'Problem Record Closed'

            if activity_name:
                class=class="hl-string">"hl-comment"># Find the state of attributes at the time of the event
                temp_status = value if field_name == class="hl-string">'status' else None
                temp_group = get_group_name(value) if field_name == class="hl-string">'group_id' else None
                temp_assignee = get_user_name(value) if field_name == class="hl-string">'assignee_id' else None
                temp_root_cause = value if str(field_name) == class="hl-string">'[Your Root Cause Category Field ID]' else None

                event_log.append({
                    **base_attributes,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTimestamp': audit_ts,
                    class="hl-string">'SupportGroup': temp_group,
                    class="hl-string">'AssigneeName': temp_assignee,
                    class="hl-string">'ProblemStatus': temp_status,
                    class="hl-string">'RootCauseCategory': temp_root_cause
                })

def main():
    print(class="hl-string">"Starting Zendesk Problem ticket extraction...")
    tickets = fetch_tickets(START_TIME)
    problem_tickets = [t for t in tickets if t.get(class="hl-string">'type') == class="hl-string">'problem']
    print(fclass="hl-string">"Found {len(problem_tickets)} problem tickets to process.")

    event_log_data = []
    for i, ticket in enumerate(problem_tickets):
        print(fclass="hl-string">"Processing ticket {i+1}/{len(problem_tickets)}: ID {ticket['id']}")
        process_ticket_audits(ticket, event_log_data)

    if not event_log_data:
        print(class="hl-string">"No events were generated. Exiting.")
        return

    df = pd.DataFrame(event_log_data)

    class=class="hl-string">"hl-comment"># Post-processing to fill forward null values for state attributes
    df = df.sort_values(by=[class="hl-string">'ProblemRecordId', class="hl-string">'EventTimestamp']).reset_index(drop=True)
    df[class="hl-string">'SupportGroup'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'SupportGroup'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'AssigneeName'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'AssigneeName'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'ProblemStatus'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'ProblemStatus'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'RootCauseCategory'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'RootCauseCategory'].fillna(method=class="hl-string">'ffill')

    class=class="hl-string">"hl-comment"># Define column order
    column_order = [
        class="hl-string">'ProblemRecordId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'Priority', class="hl-string">'SupportGroup', class="hl-string">'AssigneeName', class="hl-string">'ProblemStatus', class="hl-string">'RelatedIncidentCount',
        class="hl-string">'SlaDueDate', class="hl-string">'ProblemCategory', class="hl-string">'RootCauseCategory'
    ]
    df = df[column_order]

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

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

È pronto a iniziare?

Migliori la stabilità IT applicando oggi stesso questo template al Suo ambiente Zendesk. Il nostro team è a disposizione per aiutarLa a perfezionare l’estrazione dei dati e ad avviare il Suo percorso di Process Mining.

Torna alla guida al miglioramento Scarica il template

Ottimizzi la gestione dei problemi per risolvere più rapidamente le criticità IT

Riduca del 30% i cicli di risoluzione e rimuova i colli di bottiglia IT.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. Configurazione in pochi minuti.

Il template dei dati per la gestione dei problemi

Il template dei dati per la gestione dei problemi

Attributi della gestione dei problemi

Attività di gestione dei problemi

Guide all’estrazione

Esportazione della cronologia degli aggiornamenti di Zendesk Explore

Passaggi

Configurazione

a Query di esempio config

Query SQL tramite Zendesk Data Sharing

Passaggi

Configurazione

a Query di esempio sql

Estrazione con Python tramite Incremental Export API

Passaggi

Configurazione

a Query di esempio python

È pronto a iniziare?

Ottimizzi la gestione dei problemi per risolvere più rapidamente le criticità IT

Il template dei dati per la gestione dei problemi

Il template dei dati per la gestione dei problemi

Attributi della gestione dei problemi

Attività di gestione dei problemi

Guide all’estrazione

Esportazione della cronologia degli aggiornamenti di Zendesk Explore

Passaggi

Configurazione

a Query di esempio config

Query SQL tramite Zendesk Data Sharing

Passaggi

Configurazione

a Query di esempio sql

Estrazione con Python tramite Incremental Export API

Passaggi

Configurazione

a Query di esempio python

È pronto a iniziare?

Ottimizzi la gestione dei problemi per risolvere più rapidamente le criticità IT

La Sua privacy è importante