> Miglioramento Continuo dei Processi > Gestione dei Problemi > Zendesk Support > Template Dati

Il Suo `Template` Dati di Gestione dei Problemi

Zendesk Support

Attributi di Gestione dei Problemi (20) Attività di Gestione dei Problemi (12) Guide all'Estrazione (3)

Il Suo `Template` Dati di Gestione dei Problemi

Questo `template` fornisce un quadro completo per la mappatura del Suo ciclo di vita di gestione dei problemi all'interno di Zendesk Support. Delinea gli attributi essenziali, le `milestone` di processo e la logica di estrazione necessari per identificare i `bottleneck` nell'analisi della causa radice. Seguendo questa struttura, può costruire un `Event Log` di alta qualità per approfondire le intuizioni di processo.

Attributi raccomandati per un'analisi dettagliata
Attività chiave del processo e transizioni di stato
Guida all'estrazione per i data di Zendesk Support

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

Scarica Template

Attributi di Gestione dei Problemi

Questi campi dati raccomandati forniscono il contesto necessario per analizzare le categorie dei ticket, i livelli di priorità e la responsabilità attraverso l'intero ciclo di vita della risoluzione dei problemi.

5 Obbligatorio 8 Consigliato 7 Facoltativo

	Nome	Descrizione
	Activity ActivityName	Il nome dell'evento o dell'azione eseguita sul record di problema.
Descrizione Questo attributo cattura il passaggio o l'azione specifica intrapresa durante il ciclo di vita del record di problema. Gli esempi includono modifiche di stato come da 'Aperto' a 'In Sospeso', modifiche di assegnazione o passaggi di `workflow` specifici come 'Workaround Pubblicato'. In analisi, questo forma i nodi della mappa di processo. La sequenza di queste attività consente agli analisti di visualizzare il flusso di lavoro, identificare i `bottleneck` e misurare il tempo impiegato tra passaggi specifici del processo. Perché è importante Definisce il 'cosa' del processo, abilitando la visualizzazione del flusso di processo e l'analisi delle varianti. Dove trovare Derivato da Zendesk Ticket Audits o Ticket Metrics Esempi Record del Problema RegistratoIndagine Avviata`Workaround` Pubblicato
	Ora di Inizio EventTimestamp	La data e l'ora specifiche in cui si è verificata un'attività.
Descrizione Questo attributo registra il momento esatto in cui un'attività ha avuto luogo all'interno del sistema Zendesk. Fornisce la dimensione temporale necessaria per sequenziare correttamente gli eventi e calcolare le durate tra i passaggi. In analisi, questo è critico per il calcolo dei tempi di ciclo, l'identificazione dei ritardi, la verifica della conformità agli SLA e la visualizzazione del processo nel tempo. Senza `timestamp` accurati, è impossibile comprendere la velocità del processo di risoluzione dei problemi. Perché è importante Consente l'ordinamento delle attività e il calcolo di tutti i KPI basati sul tempo. Dove trovare Audit Ticket Zendesk, campo 'created_at' Esempi 2023-10-12T08:30:00Z2023-10-12T09:15:22Z
	Record del Problema ProblemRecordId	L'identificatore numerico univoco assegnato al ticket di problema in Zendesk.
Descrizione Questo attributo rappresenta la chiave univoca per il record di problema all'interno del sistema Zendesk Support. Serve come `Case ID` centrale per il `Process Mining`, consentendo che tutti gli eventi, gli aggiornamenti e le interazioni successive siano raggruppati in una singola istanza di processo. In analisi, questo ID è utilizzato per identificare distintamente ogni percorso di indagine di problema dalla creazione alla chiusura. Permette la correlazione di incidenti correlati e il tracciamento del ciclo di vita del problema attraverso vari livelli di supporto. Perché è importante È la chiave fondamentale obbligatoria richiesta per raggruppare gli `event` in `case` per qualsiasi analisi di Process Mining. Dove trovare Oggetto Ticket Zendesk, campo 'id' dove il tipo è 'problem' Esempi 1045293849921
	Sistema di Origine SourceSystem	Il nome del sistema da cui provengono i dati.
Descrizione Questo attributo identifica la piattaforma `software` da cui sono stati estratti i dati di processo. In questo contesto, si popolerà costantemente con 'Zendesk Support'. In analisi, in particolare quando si combinano dati da più sistemi (ad esempio, Zendesk e Jira), questo campo permette agli analisti di filtrare o raggruppare i dati per la loro provenienza. Garantisce la `data lineage` e la tracciabilità nelle viste di processo multisistema. Perché è importante Assicura la `data lineage` e supporta configurazioni di Process Mining multisistema. Dove trovare Codificato manualmente durante l'estrazione Esempi Zendesk Support
	Ultimo `Data Update` LastDataUpdate	Il `timestamp` che indica l'ultima modifica del record di problema.
Descrizione Questo attributo riflette l'ora più recente in cui i dati del record di problema sono stati aggiornati nel sistema sorgente. È distinto dal `timestamp` dell'evento, in quanto si riferisce al livello del record anziché al livello dell'attività. In analisi, questo aiuta a determinare la freschezza dei dati. È utilizzato per identificare se il `dataset` è attuale o se ci sono ritardi di sincronizzazione tra il sistema sorgente e l'ambiente di `Process Mining`. Perché è importante Traccia la freschezza dei data e assiste nelle strategie di caricamento incrementale dei data. Dove trovare Oggetto Ticket Zendesk, campo 'updated_at' Esempi 2023-11-01T14:20:00Z
	Categoria della causa radice RootCauseCategory	La causa sottostante identificata del problema (ad es., Difetto di Codice, Errore di Configurazione).
Descrizione Questo attributo cattura la diagnosi finale di ciò che ha causato il problema. Solitamente viene compilato durante l'attività 'Causa Radice Identificata'. In analisi, questo è utilizzato per generare il report 'Accuratezza Categorizzazione Problemi' e per analizzare le tendenze nei guasti di sistema. Aiuta la direzione a comprendere se debbano concentrarsi sulla qualità del codice, sulla stabilità dell'infrastruttura o sulla gestione dei fornitori. Perché è importante Consente l'analisi dei modelli di fallimento e dirige gli sforzi di miglioramento a lungo termine. Dove trovare Campi Personalizzati Ticket Zendesk Esempi Bug SoftwareErrore di configurazioneErrore dell'utente
	Categoria Problema ProblemCategory	La classificazione del problema (ad es., Software, Hardware, Rete).
Descrizione Questo attributo categorizza il problema in base al servizio o allo `stack` tecnologico interessato. È tipicamente un campo `dropdown` personalizzato nei moduli Zendesk. In analisi, questo è utilizzato per la `dashboard` 'Accuratezza Categorizzazione Problemi'. Confrontare questa categoria iniziale con la causa radice finale aiuta a identificare se il triage iniziale sta instradando accuratamente i problemi ai team corretti. Perché è importante Consente la segmentazione per tecnologia o servizio aziendale. Dove trovare Campi Personalizzati Ticket Zendesk Esempi DatabaseUI/UXInfrastruttura di Rete
	Conteggio Incidenti Correlati RelatedIncidentCount	Il numero di ticket di incidente collegati a questo record di problema.
Descrizione Questo attributo conta quanti singoli ticket di incidente sono associati a questo record di problema. In Zendesk, questo è gestito tramite il campo 'problem_id' sui ticket di incidente che si collegano a questo record. In analisi, questa è la metrica primaria per la 'Correlazione e Impatto degli Incidenti'. Aiuta a prioritizzare i problemi che stanno influenzando il maggior numero di utenti, guidando le decisioni strategiche su quali correzioni produrranno il ROI più elevato in termini di riduzione del volume dei ticket. Perché è importante Indica la magnitudo e l'impatto utente del problema. Dove trovare API Ticket Zendesk, conteggio dei ticket dove type='incident' e problem_id=ThisID Esempi 015342
	Data di scadenza dell'SLA SlaDueDate	La data e l'ora target entro cui il problema dovrebbe essere risolto.
Descrizione Questo attributo rappresenta la scadenza per la risoluzione basata sulla configurazione del Service Level Agreement. Di solito viene calcolato in base alla priorità e all'ora di creazione del ticket. In analisi, questo è confrontato con il tempo di risoluzione effettivo per calcolare il 'Tasso di Adesione SLA del Problema'. Alimenta la `dashboard` 'Performance SLA e Rischio' evidenziando i casi che si stanno avvicinando o hanno superato il tempo loro assegnato. Perché è importante È fondamentale per misurare la conformità e le prestazioni contrattuali. Dove trovare Endpoint Metriche Ticket Zendesk o Politiche SLA Esempi 2023-12-01T17:00:00Z
	Gruppo di supporto SupportGroup	Il team o il dipartimento attualmente assegnato al record di problema.
Descrizione Questo attributo identifica lo specifico gruppo di agenti responsabile del problema in un dato momento. Cambia man mano che il ticket viene passato da un team all'altro. In analisi, questo è cruciale per la `dashboard` 'Analisi Passaggio di Consegne del Gruppo di Supporto'. Permette la misurazione delle prestazioni per team, l'identificazione di `bottleneck` durante i passaggi di consegne e l'analisi della distribuzione del carico di lavoro delle risorse. Perché è importante Consente l'analisi organizzativa e l'identificazione dei bottleneck tra i dipartimenti. Dove trovare Oggetto Ticket Zendesk, campo 'group_id' (risolto a nome) Esempi Supporto L2Team del DatabaseOperazioni di Rete
	Nome dell'Assegnatario AssigneeName	L'agente specifico assegnato a lavorare sul problema.
Descrizione Questo attributo contiene il nome dell'utente individuale che è attualmente responsabile del record di problema. Fornisce una visibilità granulare su chi ha eseguito azioni specifiche. In analisi, questo aiuta a comprendere il carico di lavoro e le prestazioni individuali. Mentre l'analisi a livello di gruppo è comune, i dati a livello di assegnatario possono evidenziare le esigenze di formazione o gli individui particolarmente efficaci nella risoluzione di cause radice complesse. Perché è importante Consente l'analisi delle risorse a livello individuale. Dove trovare Oggetto Ticket Zendesk, campo 'assignee_id' (risolto a nome) Esempi John DoeJane SmithSistema
	Priorità Priority	Il livello di urgenza assegnato al record di problema.
Descrizione Questo attributo indica l'importanza relativa del problema, tipicamente categorizzato come Basso, Normale, Alto o Urgente. Determina gli accordi sul livello di servizio (SLA) attesi e l'allocazione delle risorse. In analisi, questo è utilizzato per segmentare il processo e confrontare le prestazioni tra diversi livelli di urgenza. Ad esempio, aiuta a verificare se i problemi 'Urgenti' vengono effettivamente risolti più velocemente di quelli a priorità 'Bassa', come richiesto dalla `dashboard` 'Velocità di Indagine Causa Radice'. Perché è importante È essenziale per segmentare i `case` al fine di analizzare l'aderenza agli SLA e la prioritizzazione delle risorse. Dove trovare Oggetto Ticket Zendesk, campo 'priority' Esempi UrgenteElevatoNormaleBasso
	Stato del Problema ProblemStatus	Lo stato attuale del record di problema nel suo ciclo di vita.
Descrizione Questo attributo mostra lo stato attuale del problema, come Nuovo, Aperto, In Sospeso, Risolto o Chiuso. Riflette il progresso dell'indagine. In analisi, questo è utilizzato per filtrare i casi aperti rispetto a quelli chiusi. È vitale per la `dashboard` 'Monitoraggio Record di Problema Inattivi' per identificare quali casi attivi non stanno progredendo attraverso il ciclo di vita di stato atteso. Perché è importante Consente di filtrare i `case` in base al loro stato di completamento. Dove trovare Oggetto Ticket Zendesk, campo 'status' Esempi newapertoin sospesorisoltoclosed
	`Workaround` Attivo WorkaroundActive	Un `flag` che indica se una soluzione temporanea (workaround) è stata fornita/pubblicata.
Descrizione Questo attributo booleano indica se una correzione temporanea è stata documentata per il problema. Spesso è derivato dalla presenza di un'attività 'Workaround Pubblicato' o di una `checkbox` specifica sul modulo. In analisi, questo è utilizzato per la `dashboard` 'Conformità alla Pubblicazione di `Workaround`'. Misura la frequenza con cui il team di supporto fornisce un sollievo immediato agli utenti mentre l'indagine a lungo termine prosegue. Perché è importante È fondamentale per misurare la mitigazione dell'impatto utente durante le indagini. Dove trovare Derivato dalla presenza dell'attività 'Soluzione Temporanea Pubblicata' o del Campo Personalizzato Esempi truefalse
	Durata Indagine InvestigationDuration	Il tempo impiegato dall'inizio dell'indagine all'identificazione della causa radice.
Descrizione Questo attributo calcolato misura la durata della fase di diagnosi centrale. Calcola la differenza di tempo tra l'attività 'Indagine Avviata' e l'attività 'Causa Radice Identificata'. In analisi, questa è la metrica primaria per la 'Durata Media Analisi Causa Radice'. Permette il `benchmarking` della velocità diagnostica tra diversi gruppi di supporto e categorie di problemi. Perché è importante Misura l'efficienza del processo diagnostico. Dove trovare Calcolato nello strumento di Process Mining: Timestamp(Causa Principale) - Timestamp(Inizio Indagine) Esempi 48 ore5 giorni
	È Obsoleto IsStale	Segnala se il problema non ha avuto alcuna attività per oltre 14 giorni.
Descrizione Questo attributo calcolato identifica i record che non sono stati aggiornati di recente. Confronta la data corrente (o la data di analisi) con il `timestamp` dell'ultima attività. In analisi, questo alimenta la `dashboard` 'Monitoraggio Record di Problema Inattivi'. Aiuta i manager a isolare rapidamente i casi trascurati che ingombrano il `backlog` e potrebbero richiedere una chiusura amministrativa o una riassegnazione. Perché è importante Aiuta a identificare gli sprechi di processo e gli elementi di lavoro trascurati. Dove trovare Calcolato nello strumento di Process Mining: (Ora - LastDataUpdate) > 14 giorni Esempi truefalse
	Ha PIR HasPostImplementationReview	Segnala se è stata condotta una Revisione Post-Implementazione.
Descrizione Questo attributo indica se il processo di risoluzione del problema ha incluso una fase di revisione. È derivato controllando se l'attività 'Revisione Post-Implementazione Condotta' esiste nella cronologia del caso. In analisi, questo supporta la `dashboard` 'Copertura Revisione Post-Implementazione'. È una metrica di conformità che assicura che l'organizzazione stia imparando dai suoi problemi maggiori. Perché è importante Valida la conformità con i processi di miglioramento continuo. Dove trovare Derivato dalla presenza dell'attività 'Revisione Post-Implementazione Condotta' Esempi truefalse
	ID 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 elemento di conoscenza esterno. Indica che la conoscenza acquisita dal problema è stata catturata. In analisi, la presenza di questo campo viene utilizzata per calcolare il 'Tasso di Integrazione della `Knowledge Base`'. Verifica che l'organizzazione stia chiudendo il ciclo di apprendimento documentando le soluzioni per riferimento futuro. Perché è importante Misura l'efficacia dei processi di `knowledge management`. Dove trovare Campi Personalizzati Ticket Zendesk o Contenuti Collegati Esempi 360045889KB-2991
	ID Richiesta di Cambiamento ChangeRequestId	L'identificatore della richiesta di modifica collegata per implementare la correzione.
Descrizione Questo attributo collega il record di problema a un record di `Change Management` (potenzialmente in un altro sistema o un tipo di ticket diverso). Significa che è stato avviato un processo di modifica formale. In analisi, questo supporta la `dashboard` 'Tasso di Avvio Richieste di Modifica'. Aiuta a tracciare la transizione dalla diagnosi all'implementazione, assicurando che le cause radice identificate si traducano in azioni di modifica formali. Perché è importante Collega il processo del problema al processo di `change management`. Dove trovare Campi Personalizzati Ticket Zendesk o Ticket Collegati Esempi CR-1002CHG00394
	Oggetto del Problema ProblemSubject	Il breve riepilogo o titolo del record di problema.
Descrizione Questo attributo contiene il riepilogo testuale inserito quando il problema è stato creato. Di solito descrive il sintomo o il problema in fase di indagine. In analisi, questo fornisce contesto all'analista durante l'analisi approfondita di casi specifici. Le tecniche di `text mining` possono anche essere applicate qui per raggruppare problemi simili o identificare argomenti ricorrenti che non sono catturati dai campi di categoria strutturati. Perché è importante Fornisce un contesto leggibile dall'uomo per i `case` individuali. Dove trovare Oggetto Ticket Zendesk, campo 'subject' Esempi Impossibile elaborare i pagamenti nella regione UEPicchi di latenza sul server di `login`Esportazione data non riuscita per gli utenti admin

Obbligatorio Consigliato Facoltativo

Attività di Gestione dei Problemi

Catturi questi passaggi di processo essenziali e i cambiamenti di stato per visualizzare il flusso end-to-end dall'identificazione iniziale del problema all'implementazione della soluzione permanente.

8 Consigliato 4 Facoltativo

	Activity	Descrizione
	`Workaround` Pubblicato	L'azione di documentare e condividere una correzione temporanea per il problema. In Zendesk, questo è spesso catturato tramite un tag specifico o un campo `checkbox` personalizzato che indica la disponibilità di un `workaround`.
Perché è importante Supporta la `dashboard` di conformità alla pubblicazione di `workaround`, assicurando che venga fornito un sollievo temporaneo agli utenti durante lunghe indagini. Dove trovare Monitorare l'aggiunta del tag 'workaround_published' o una modifica a un campo booleano personalizzato chiamato 'Workaround'. Acquisisci Confrontare i valori dei campi personalizzati o dei tag Tipo di evento inferred
	Assegnato al Gruppo di Supporto	L'instradamento del record del problema a un team tecnico o dipartimento specifico. Questo viene tracciato quando il campo ID Gruppo sul ticket viene aggiornato.
Perché è importante Critico per la `dashboard` di Analisi del Passaggio di Consegne del Gruppo di Supporto per misurare i tempi di attesa tra i dipartimenti. Dove trovare Monitorare il campo 'group_id' nel log di audit del ticket per le modifiche. Acquisisci Registrato quando viene eseguita la transazione Modifica Assegnazione Gruppo Tipo di evento explicit
	Causa radice identificata	Il punto in cui viene determinata la causa sottostante del problema. Questo viene tipicamente catturato quando un campo di testo personalizzato 'Causa Radice' o una categoria a discesa viene popolata dall'agente.
Perché è importante Una pietra miliare cruciale per la `dashboard` di Velocità di Indagine della Causa Principale e per misurare l'efficienza della diagnosi. Dove trovare Monitorare le modifiche ai campi personalizzati etichettati 'Causa Radice', 'RCA' o 'Fonte del Problema' per valori non nulli. Acquisisci Confrontare i valori dei campi personalizzati per la popolazione Tipo di evento inferred
	Correzione Permanente Applicata	Significa che la soluzione tecnica è stata distribuita nell'ambiente. Questo è solitamente tracciato tramite una transizione di stato personalizzata o un tag specifico prima che il ticket sia completamente risolto.
Perché è importante Essenziale per la `dashboard` di Efficienza dell'Implementazione della Correzione per misurare il tempo dalla diagnosi alla distribuzione. Dove trovare Dedotto da un `tag` specifico (es., 'fix_deployed') o da un campo di stato personalizzato, se esistente. Acquisisci Monitorare tag o menu a discesa di stato personalizzati Tipo di evento inferred
	Indagine Avviata	Segna la transizione da uno stato passivo 'Nuovo' a uno stato di lavoro attivo. Ciò indica che un agente ha preso in carico il problema e iniziato la diagnosi.
Perché è importante Utilizzato per calcolare le metriche dei Record di Problema Inattivi ed è il punto di partenza per il KPI Durata Media Analisi Causa Radice. Dove trovare Dedotto quando lo stato del ticket cambia da 'Nuovo' a 'Aperto' o 'In Sospeso'. Acquisisci Confrontare il campo stato prima/dopo Tipo di evento inferred
	Record del Problema Chiuso	L'evento finale del ciclo di vita in cui il ticket viene bloccato e non è possibile apportare ulteriori modifiche. In Zendesk, questo di solito avviene automaticamente 4 giorni dopo lo stato Risolto.
Perché è importante Segna la fine assoluta della vita del record ed è utilizzato per la conservazione dei dati e la reportistica storica. Dove trovare Derivato dal cambiamento di stato del ticket a 'Chiuso'. Acquisisci Registrato quando lo stato cambia in Chiuso Tipo di evento explicit
	Record del Problema Registrato	La creazione iniziale del ticket di problema all'interno di Zendesk Support. Questo evento cattura il `timestamp` di quando il problema è stato registrato per la prima volta nel sistema, solitamente attivando l'istanza di processo.
Perché è importante Stabilisce l'ora di inizio per il Ciclo di Risoluzione End To End e serve come base per tutte le metriche di tempo di avvio successive. Dove trovare Derivato dal `timestamp` 'created_at' nell'oggetto ticket o dalla prima voce nell'`audit log` del ticket. Acquisisci Registrato quando viene eseguita la transazione Ticket Creato Tipo di evento explicit
	Risoluzione Verificata	La marcatura formale del problema come Risolto. In Zendesk, ciò avviene quando lo stato di sistema standard è impostato su 'Solved', indicando che la correzione è verificata e il caso è completo.
Perché è importante L'endpoint primario per i calcoli delle Performance e del Rischio SLA e del Tasso di Adesione SLA del Problema. Dove trovare Derivato dal cambiamento di stato del ticket a 'Risolto'. Acquisisci Registrato quando lo stato cambia a Risolto Tipo di evento explicit
	Indagine Problema Riaperta	Si verifica quando un record di problema precedentemente contrassegnato come Risolto viene riportato a uno stato Aperto o attivo. Ciò indica una correzione fallita o una risoluzione rifiutata.
Perché è importante Supporta il KPI Tasso di Riapertura dei Problemi e aiuta a identificare problemi di qualità nel processo di risoluzione. Dove trovare Dedotto quando lo stato passa da 'Risolto' nuovamente a 'Aperto', 'Nuovo' o 'In Sospeso'. Acquisisci Confrontare il campo stato prima/dopo Tipo di evento inferred
	Revisione Post-Implementazione Condotta	Confermare che una revisione retrospettiva è stata completata dopo la correzione. Si tratta tipicamente di una casella di controllo o di un campo data aggiornato dal coordinatore di processo.
Perché è importante Richiesto per il KPI Frequenza Revisione Post-Implementazione per garantire la conformità agli standard di qualità. Dove trovare Monitorare gli aggiornamenti di una `checkbox` personalizzata 'PIR Completato' o del campo data 'Data PIR'. Acquisisci Monitorare il campo personalizzato per il completamento Tipo di evento inferred
	Richiesta di Modifica Avviata	Indica che un processo formale di `change management` è stato attivato per risolvere il problema. Questo è spesso dedotto quando viene popolato un campo personalizzato 'ID Richiesta di Modifica' o viene collegato un ticket di tipo 'Modifica'.
Perché è importante Traccia il Tasso di Avvio della Richiesta di Modifica e collega la Gestione dei Problemi ai `workflow` di `Change Management`. Dove trovare Monitorare gli aggiornamenti di un campo personalizzato come 'change_reference' o la creazione di un tipo di collegamento 'problem_change'. Acquisisci Monitorare il campo personalizzato per l'inserimento di ID esterni Tipo di evento inferred
	Soluzione Proposta Redatta	La creazione di un articolo della `Knowledge Base` basato sull'indagine del problema. Questo è inferito dall'uso dell'app Zendesk Knowledge Capture o dal collegamento di un nuovo articolo.
Perché è importante Supporta il KPI Tasso di Integrazione della `Knowledge Base`, garantendo l'apprendimento organizzativo. Dove trovare Monitorare gli eventi relativi all'integrazione 'Knowledge Capture' o a tag come 'kcs_draft'. Acquisisci Derivare da `tag` di sistema specifici o `event` di collegamento Tipo di evento inferred

Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i vostri `dati` da Zendesk Support.

Fasi

Effettui il login alla sua istanza Zendesk e navighi all'interfaccia di reporting Explore tramite la barra dei prodotti.
Clicchi sulla cartella Query (o Report nelle versioni più recenti) e selezioni Nuova query.
Quando le viene richiesto di selezionare un dataset, scelga Support seguito da Storico degli Aggiornamenti seguito da Support: Storico degli Aggiornamenti [default]. Questo dataset contiene gli event log richiesti per il Process Mining piuttosto che solo i data dello stato attuale.
Nel pannello Metriche, aggiunga Conteggio (Ticket) o Conteggio (Aggiornamenti) per assicurarsi che i data vengano estratti.
Nel pannello Filtri, aggiunga un filtro per Ticket > Tipo di ticket e selezioni Problema per restringere il dataset al processo di Problem Management.
Nel pannello Righe, aggiunga i seguenti attributi in quest'ordine specifico per definire la struttura dell'event log: Ticket > ID Ticket, Ora - Timestamp > Aggiornamento - Timestamp, Aggiornatore > Nome aggiornatore e Modifiche > Modifiche - Nome campo.
Per creare la colonna Nome Attività, deve creare un Attributo Calcolato Standard. Clicchi sull'icona Calcolo nella barra laterale destra, selezioni Attributo calcolato standard, lo nomini Activity Mapper e incolli il codice fornito nella sezione Query sottostante.
Aggiunga questo nuovo attributo Activity Mapper al pannello Righe. Filtri questo attributo per escludere i valori NULL e rimuovere il rumore di sistema irrilevante.
Aggiunga attributi aggiuntivi al pannello Righe per il contesto: Ticket > Priorità, Ticket > Gruppo, Ticket > Stato e qualsiasi campo personalizzato richiesto per l'analisi della causa principale o della categoria (es., Ticket > Tag ticket o Campi Personalizzati specifici).
Imposti l'intervallo di tempo nel pannello Filtri usando Ora - Timestamp > Aggiornamento - Data per coprire la sua finestra di analisi desiderata (es., Ultimi 6 Mesi).
Clicchi sull'icona Tipo di visualizzazione e selezioni Tabella. Si assicuri che la tabella sia non pivottata o piatta, se questa opzione è disponibile, o semplicemente si assicuri che tutti gli attributi siano nella sezione Righe.
Esporti il risultato cliccando Esporta > CSV. Si assicuri che la casella Mantieni formattazione attributi sia spuntata per preservare i formati dei timestamp per ProcessMind.

Configurazione

Dataset: Support: Storico degli Aggiornamenti (Critico: non utilizzi il dataset standard Ticket poiché mostra solo lo stato attuale).
Filtro Temporale: Aggiornamento - Data (Consigliato: ultimi 90-180 giorni a seconda del volume).
Tipo di Ticket: Filtri rigorosamente per Problema per evitare di mescolare Incidenti e Richieste di Servizio.
Limite Righe: Le esportazioni di Zendesk Explore sono spesso limitate a 50.000 righe. Se il suo dataset supera questo limite, utilizzi il filtro Aggiornamento - Data per esportare in blocchi mensili più piccoli e unirli esternamente.
Campi Personalizzati: Identifichi gli ID di Campo specifici per la Causa Principale, la Richiesta di Modifica e la Soluzione Temporanea nella sua istanza Zendesk, poiché questi non sono campi di sistema standard.
Permessi di Sistema: Richiede 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

Fasi

Conferma dei Prerequisiti: Si assicuri che la sua organizzazione abbia l'add-on Zendesk Data Sharing abilitato. Confermi di avere le credenziali di accesso in sola lettura per il database Zendesk replicato, che è tipicamente ospitato su Snowflake o Amazon Redshift.
Connessione al Database: Utilizzi il suo client SQL preferito (come DBeaver, DataGrip o l'interfaccia web nativa di Snowflake/Redshift) per stabilire una connessione al suo data warehouse Zendesk utilizzando le credenziali fornite.
Identificare i Campi Personalizzati: Prima di eseguire la query, deve identificare gli ID unici per i campi personalizzati utilizzati nel suo processo di Problem Management. Navighi in Admin Center di Zendesk, vada su Oggetti e regole > Ticket > Campi. Trovi i campi per 'Causa Principale', 'ID Richiesta di Modifica', 'Soluzione Temporanea Pubblicata', 'Correzione Permanente Applicata' e 'Revisione Post-Implementazione' per ottenere i loro ID di campo specifici. Questi verranno utilizzati per sostituire i segnaposto nella query.
Revisionare la Query SQL: La query fornita utilizza una Common Table Expression (CTE) chiamata ProblemTickets per selezionare e filtrare inizialmente tutti i record di problema. Questo migliora le prestazioni e la leggibilità. La parte principale della query utilizza quindi UNION ALL per combinare i risultati di 12 istruzioni SELECT separate, una per ogni attività richiesta.
Personalizzare la Query: Apra un nuovo editor di query e incolli lo script SQL completo. Modifichi i segnaposto all'interno dello script:
- Nel CTE ProblemTickets, imposti l'intervallo di date desiderato sostituendo '[YYYY-MM-DD]'.
- Per ogni attività che si basa su un campo personalizzato, sostituisca gli ID segnaposto (es., [Your 'Root Cause Category' field_id], [Your 'Change Request ID' field_id]) con gli ID effettivi che ha identificato nel passo 3.
Eseguire la Query: Esegua lo script SQL modificato sul database. Il tempo di esecuzione varierà a seconda dell'intervallo di date e del volume dei data dei ticket.
Investigare la Logica di 'Soluzione Proposta Redatta': La query presuppone che la redazione di una soluzione sia catturata popolando un campo personalizzato denominato [Your 'KB Article ID' field_id]. Se il suo processo differisce, ad esempio, utilizzando un tag o un commento specifico, dovrà adeguare questa parte della query di conseguenza.
Validazione dei Data: Una volta completata la query, esegua una breve revisione dei risultati. Verifichi un numero ragionevole di righe, si assicuri che tutte le colonne siano presenti e cerchi eventuali valori NULL inaspettati in colonne critiche come ProblemRecordId e EventTimestamp.
Esportare l'Event Log: Esporti l'intero set di risultati dal suo 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 dal suo strumento di Process Mining.
Preparare per il Caricamento: Prima di caricare, controlli il file CSV per eventuali problemi di formattazione. Si assicuri che i valori di data e ora nella colonna EventTimestamp siano in un formato coerente, come YYYY-MM-DD HH24:MI:SS.

Configurazione

Prerequisiti: Questa estrazione richiede l'add-on Zendesk Data Sharing e l'accesso SQL diretto ai data replicati in un'istanza Snowflake o Amazon Redshift.
Filtro Tipo di Ticket: La query è pre-configurata per analizzare solo i ticket dove il type è 'problema'. Questo è fondamentale per isolare il processo di Problem Management dagli incidenti e da altri tipi di ticket.
Filtro Intervallo di Date: Si raccomanda vivamente di filtrare i data per un periodo specifico per gestire le prestazioni. La query include un segnaposto created_at >= '[YYYY-MM-DD]' nel CTE iniziale. Per una prima analisi, un intervallo di 3-6 mesi è tipico.
Configurazione Campi Personalizzati: Questa estrazione dipende fortemente dalla sua configurazione specifica di Zendesk. Deve identificare e inserire il field_id corretto per i campi personalizzati che tracciano attività come 'Causa Principale Identificata', 'Richiesta di Modifica Avviata' e 'Soluzione Temporanea Pubblicata'. La query fallirà o non restituirà data per queste attività se gli ID segnaposto non vengono sostituiti.
Latenza dei Data: I data nel database replicato non sono in tempo reale. Tipicamente c'è un ritardo di alcune ore tra un evento che si verifica 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';

Fasi

Prerequisiti: Si assicuri di avere Python 3.6+ installato sul suo sistema. Installi le librerie requests e pandas richieste eseguendo pip install requests pandas nel suo terminale o prompt dei comandi.
Generare Token API Zendesk: Effettui il login a Zendesk Support come amministratore. Navighi in Admin Center > App e integrazioni > API > Zendesk API. Nella sezione Accesso Token, clicchi su 'Aggiungi token API' per creare un nuovo token. Copi immediatamente questo token e lo conservi in modo sicuro, poiché non verrà mostrato di nuovo.
Configurare lo Script Python: Crei un nuovo file Python (es., extract_zendesk_problems.py) e copi lo script completo fornito nella sezione Query in questo file. 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 al timestamp Unix epoch della data di inizio desiderata per la sua estrazione.
Mappatura ID Campi Personalizzati: Identifichi gli ID numerici per i campi personalizzati utilizzati nel suo processo di Problem Management. Può trovarli navigando in Admin Center > Oggetti e regole > Ticket > Campi e ispezionando l'URL o le proprietà del campo. Aggiorni il dizionario CUSTOM_FIELD_MAPPING nello script con i suoi ID specifici.
Eseguire lo Script: Esegua lo script dal suo terminale utilizzando il comando python extract_zendesk_problems.py. Lo script inizierà a recuperare data dalla Zendesk Incremental Export API.
Monitorare l'Esecuzione: Lo script stamperà il suo progresso, incluso il numero di ticket elaborati e il timestamp corrente che sta recuperando. Gestirà automaticamente i limiti di rate dell'API mettendo in pausa quando necessario.
Recupero e Trasformazione dei Data: Lo script recupera prima tutti i ticket di problema creati o aggiornati da START_TIME. Per ogni ticket di problema, recupera quindi il audit trail completo, che contiene tutte le modifiche storiche.
Generazione dell'Event Log: Lo script elabora ogni event di audit, mappando i cambiamenti di campo (come stato, gruppo o aggiornamenti di campo personalizzati) alle attività aziendali definite. Recupera e memorizza nella cache anche i nomi utente e di gruppo per arricchire i data.
Gestione dei Caricamenti Incrementali: Dopo il caricamento completo iniziale, per le esecuzioni successive, aggiorni la variabile START_TIME all'end_time stampata alla fine dell'esecuzione precedente riuscita. Questo assicura che vengano estratti solo data nuovi e aggiornati senza duplicazioni.
Revisionare l'Output: Una volta completato lo script, genererà un file denominato zendesk_problem_event_log.csv nella stessa directory. Questo file CSV contiene l'event log strutturato pronto per l'analisi.
Preparare per il Caricamento: Prima di caricare, apra il file CSV in uno strumento per fogli di calcolo per verificarne il contenuto. Si assicuri che i valori di data e ora nella colonna EventTimestamp siano in un formato coerente, come YYYY-MM-DD HH24:MI:SS prima di caricarli su ProcessMind.

Configurazione

Credenziali API Zendesk: Lo script richiede il suo sottodominio Zendesk, l'indirizzo email dell'utente associato al token API e il token API stesso per l'autenticazione.
Ora di Inizio: La variabile START_TIME è un timestamp Unix epoch che definisce il punto di partenza per l'estrazione dei data. Per la prima esecuzione, la imposti su una data passata (es. 6 mesi fa) per ottenere data storici. Per le esecuzioni successive, utilizzi l'ora di fine della precedente esecuzione per recuperare i data in modo incrementale.
Mappatura Campi Personalizzati: Il dizionario CUSTOM_FIELD_MAPPING è critico. Deve aggiornare gli ID segnaposto con gli ID dei campi personalizzati effettivi della sua istanza Zendesk per catturare correttamente attività come 'Soluzione Temporanea Pubblicata' e 'Causa Principale Identificata'.
Filtro Tipo di Ticket: Lo script è hardcoded per elaborare solo i ticket dove il type è 'problema'. Ciò assicura che incidenti, attività e domande siano esclusi dall'event log del Problem Management.
Limitazione del Tasso API: Lo script include una funzione time.sleep(60) di base per gestire errori 429 'Too Many Requests'. La durata di questa pausa potrebbe dover essere regolata in base al suo piano Zendesk e al volume dei data estratti.
Prerequisiti: Un ambiente Python 3 con le librerie requests e pandas è necessario per eseguire lo script. Il token API deve essere associato a un account con il permesso di leggere i data 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()

Il Suo `Template` Dati di Gestione dei Problemi

Il Suo `Template` Dati di Gestione dei Problemi

Attributi di Gestione dei Problemi

Attività di Gestione dei Problemi

Guide all'Estrazione

Esportazione Cronologia Aggiornamenti Zendesk Explore

Fasi

Configurazione

a Query di Esempio config

Query SQL tramite Condivisione Dati Zendesk

Fasi

Configurazione

a Query di Esempio sql

Estrazione Python tramite API di Esportazione Incrementale

Fasi

Configurazione

a Query di Esempio python

Pronto per iniziare?

Ottimizza la Sua Gestione dei Problemi per Correzioni IT più Veloci

Il Suo Template Dati di Gestione dei Problemi

Il Suo Template Dati di Gestione dei Problemi

Attributi di Gestione dei Problemi

Attività di Gestione dei Problemi

Guide all'Estrazione

Esportazione Cronologia Aggiornamenti Zendesk Explore

Fasi

Configurazione

a Query di Esempio config

Query SQL tramite Condivisione Dati Zendesk

Fasi

Configurazione

a Query di Esempio sql

Estrazione Python tramite API di Esportazione Incrementale

Fasi

Configurazione

a Query di Esempio python

Abbiamo a cuore la Sua privacy

Pronto per iniziare?

Ottimizza la Sua Gestione dei Problemi per Correzioni IT più Veloci

Il Suo `Template` Dati di Gestione dei Problemi

Il Suo `Template` Dati di Gestione dei Problemi