> Miglioramento continuo dei processi > Assistenza clienti > Zendesk Support > Template dei dati

Il template dei dati per il servizio clienti

Zendesk Support

Attributi del servizio clienti (18) Attività del servizio clienti (14) Guide all’estrazione (4)

Il template dei dati per il servizio clienti

Questo template La aiuta a raccogliere i dati necessari per analizzare il processo di assistenza clienti. Indica gli attributi essenziali da acquisire e le attività principali da monitorare, oltre a fornire indicazioni pratiche per estrarre queste informazioni. Seguendo questa guida, potrà creare un Event Log completo da cui ricavare informazioni utili e migliorare le operazioni di assistenza.

Attributi consigliati da raccogliere
Attività principali da monitorare nel processo di assistenza clienti
Indicazioni per l’estrazione dei dati da Zendesk Support

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

Scarica il template

Attributi del servizio clienti

Questi sono i campi dati consigliati da includere nell’Event Log per un’analisi completa del servizio clienti.

5 Obbligatorio 6 Consigliato 7 Facoltativo

	Nome	Descrizione
	Ora di inizio StartTime	La data e l’ora che indicano quando è iniziata un’attività o si è verificato un evento.
Descrizione L’ora di inizio, o data e ora dell’evento, registra il momento esatto in cui si è verificata una specifica attività. Per esempio, indica quando è stato aggiunto un commento del cliente, quando è stato assegnato un operatore o quando lo stato del ticket è passato a 'Resolved'. Questa data e ora sono fondamentali per il Process Mining, perché stabiliscono l’ordine cronologico degli eventi. Servono a calcolare la durata tra le attività, misurare i tempi di ciclo, valutare le prestazioni rispetto agli SLA e comprendere la dinamica temporale del processo di assistenza. Perché è importante Questa data e ora è essenziale per ordinare gli eventi, calcolare le durate e analizzare la sequenza temporale del processo di assistenza. Dove reperirli API Zendesk Ticket Audits, campo `created_at` di ciascun evento nella traccia di audit. Esempi 2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
	Richiesta di assistenza ServiceRequest	Identificativo univoco di ogni richiesta di assistenza clienti, detta anche ticket o caso.
Descrizione La richiesta di assistenza è l’identificativo principale del caso e collega tutte le attività relative a una singola domanda o a un singolo problema del cliente, dalla creazione alla risoluzione definitiva. Ogni interazione, aggiornamento o azione interna è associata a questo ID univoco. Nel Process Mining, raggruppare gli eventi per richiesta di assistenza consente di ricostruire l’intero percorso del cliente. È la base per calcolare metriche importanti, come il tempo totale di risoluzione, individuare deviazioni del processo e comprendere il ciclo di vita di ogni problema segnalato. Perché è importante È l’ID del caso essenziale che collega tutti i passaggi del processo e consente di ricostruire e analizzare ogni singolo percorso di assistenza clienti. Dove reperirli API Zendesk Tickets, campo `id`. Esempi 102451287415332
	Nome dell’attività ActivityName	Il nome dell’evento o dell’attività specifica che si è verificata durante il ciclo di vita della richiesta di assistenza.
Descrizione Il nome dell’attività descrive un singolo passaggio o una tappa del processo di assistenza clienti, come 'Richiesta di assistenza creata', 'Richiesta assegnata a un operatore' o 'Richiesta di assistenza risolta'. A ciascun evento è associata una data e un’ora; insieme, gli eventi formano la sequenza di azioni di ogni richiesta di assistenza. Questo attributo è fondamentale per visualizzare il flusso del processo, individuare le varianti e analizzare la frequenza e l’ordine degli eventi. Consente agli analisti di capire quali azioni vengono svolte e di individuare i percorsi più comuni, i colli di bottiglia e le deviazioni dalla procedura standard. Perché è importante Questo attributo definisce i passaggi del processo e consente di visualizzare la mappa del processo e analizzare i flussi e le varianti. Dove reperirli Derivato dai log di audit dei ticket Zendesk o dai flussi di eventi che registrano modifiche e azioni. Esempi Richiesta di assistenza creataRichiesta assegnata a un operatorePrima risposta pubblica dell’operatore inviataRichiesta di assistenza risolta
	Sistema di origine SourceSystem	Il sistema di registrazione da cui sono stati estratti i dati.
Descrizione Questo attributo indica il sistema di origine dei dati delle richieste di assistenza, in questo caso Zendesk Support. È utile per la governance e la tracciabilità dei dati, soprattutto quando si combinano dati provenienti da più sistemi. Nell’analisi, assicura che i dati siano attribuiti correttamente alla fonte, un aspetto importante per mantenerne l’integrità e comprendere il contesto del processo, in particolare negli ambienti con più sistemi. Perché è importante Identifica l’origine dei dati, un’informazione essenziale per la governance e per distinguere i dati di processo negli ambienti integrati. Dove reperirli È un valore statico aggiunto durante l’estrazione dei dati per indicarne l’origine. Esempi Zendesk Support
	Ultimo aggiornamento dei dati LastDataUpdate	La data e l’ora dell’ultimo aggiornamento o dell’ultima estrazione dei dati dal sistema di origine.
Descrizione Questo attributo indica l’ultima volta in cui il dataset è stato aggiornato da Zendesk Support. Fornisce un’indicazione sull’attualità dei dati analizzati. Conoscere la data e l’ora dell’ultimo aggiornamento è fondamentale affinché analisti e utenti aziendali sappiano se stanno consultando le informazioni più recenti sul processo. Aiuta a definire le aspettative sull’aggiornamento dei dati ed è importante per la reportistica e il monitoraggio. Perché è importante Indica quanto sono recenti i dati, così gli utenti possono valutare l’attualità dell’analisi del processo. Dove reperirli È un campo di metadati generato e memorizzato durante l’estrazione dei dati, che registra la data e l’ora dell’operazione. Esempi 2023-10-27T02:00:00Z
	Canale di comunicazione CommunicationChannel	Il canale attraverso il quale è stata inviata la richiesta di assistenza o è avvenuta la comunicazione.
Descrizione Questo attributo identifica il canale di comunicazione utilizzato, ad esempio e-mail, modulo web, chat o telefono, e indica come i clienti interagiscono con il Service Desk. Conoscere l’utilizzo dei diversi canali è importante per pianificare le risorse e migliorare l’esperienza dei clienti. La Dashboard «Panoramica sull’utilizzo dei canali di comunicazione» analizza questi dati per individuare i canali più utilizzati e verificare se alcuni sono associati a tempi di risoluzione più lunghi o a percorsi di processo diversi. Queste informazioni possono aiutare a decidere dove investire per migliorare il servizio o introdurre l’automazione. Perché è importante Mostra come interagiscono clienti e agenti, consentendo di analizzare l’efficienza dei canali e il loro impatto sul processo e sull’esperienza dei clienti. Dove reperirli API Zendesk Tickets, campo `via.channel`. Esempi webe-mailapichat
	Operatore assegnato AssignedAgent	Il nome o l’ID dell’operatore del servizio clienti incaricato della richiesta di assistenza.
Descrizione Questo attributo identifica l’operatore responsabile di un’attività o della richiesta di assistenza in un determinato momento. Può cambiare nel corso del ciclo di vita della richiesta, se questa viene riassegnata. Analizzare i dati per operatore assegnato è fondamentale per comprendere il carico di lavoro, le prestazioni e l’efficienza degli operatori. La Dashboard 'Carico di lavoro ed efficienza degli operatori' consente di confrontare i tempi di gestione e il numero di casi tra operatori diversi, individuare opportunità di formazione e distribuire il carico di lavoro in modo equilibrato. Perché è importante Indica quale operatore ha svolto un’azione e consente di analizzare le prestazioni individuali, la distribuzione del carico di lavoro e l’assegnazione delle risorse. Dove reperirli API Zendesk Tickets, campo `assignee_id`. I dettagli degli utenti si possono recuperare dall’API Users. Esempi John SmithJane DoeSupportBot
	Priorità Priority	Il livello di priorità assegnato alla richiesta di assistenza, ad esempio 'Bassa', 'Normale', 'Alta' o 'Urgente'.
Descrizione La priorità indica l’urgenza di una richiesta di assistenza e spesso ne determina la posizione in coda e il tempo di risoluzione previsto. Aiuta gli operatori a concentrarsi prima sui problemi più critici. Questo attributo è essenziale per analizzare le prestazioni e gli SLA. La Dashboard 'Analisi dei tempi di risoluzione delle richieste di assistenza' utilizza la priorità per segmentare i dati e mostrare se le richieste ad alta priorità vengono gestite più rapidamente di quelle a priorità inferiore e se le risorse sono assegnate in modo efficace in base alle esigenze aziendali. Perché è importante Indica l’urgenza di una richiesta, un dato essenziale per analizzare il rispetto degli SLA e garantire che i problemi critici vengano gestiti tempestivamente. Dove reperirli API Zendesk Tickets, campo `priority`. Esempi BassaNormaleAltaUrgente
	SLA non rispettato IsSlaBreached	Indicatore booleano che segnala se il tempo di risoluzione della richiesta di assistenza ha superato l’obiettivo SLA.
Descrizione Questo attributo calcolato è un semplice indicatore vero/falso che segnala se una richiesta di assistenza non ha rispettato il tempo di risoluzione previsto dall’accordo sul livello di servizio. Si ottiene confrontando la durata effettiva della risoluzione con l’obiettivo SLA stabilito. L’indicatore semplifica l’analisi della conformità agli SLA. È il dato centrale della Dashboard «Prestazioni di conformità agli SLA» e del KPI «Tasso di conformità agli SLA», che consentono di aggregare e visualizzare rapidamente quante richieste rispettano gli obiettivi di servizio e quante no. Perché è importante Fornisce un esito chiaro, binario, sulle prestazioni SLA di ogni caso e semplifica il monitoraggio e la rendicontazione della conformità. Dove reperirli Calcolato durante la trasformazione dei dati confrontando il tempo totale di risoluzione con SlaTargetResolutionTime. Esempi truefalse
	Tempo obiettivo di risoluzione SLA SlaTargetResolutionTime	La durata entro cui si prevede di risolvere una richiesta di assistenza, in base alla relativa policy SLA.
Descrizione Questo attributo definisce l’obiettivo dello SLA per la risoluzione di un ticket. Spesso l’obiettivo varia in base a fattori quali la priorità e il tipo di richiesta o il piano di assistenza del cliente. È un attributo fondamentale per la Dashboard «Prestazioni di conformità agli SLA», perché costituisce il valore di riferimento con cui confrontare il tempo effettivo di risoluzione. L’analisi delle prestazioni rispetto a questo obiettivo consente di misurare la qualità del servizio e verificare il rispetto degli impegni contrattuali nei confronti dei clienti. Perché è importante Definisce il livello di servizio promesso al cliente e costituisce il valore di riferimento per misurare il rispetto dei tempi e degli SLA. Dove reperirli Deriva dalle policy SLA applicate al ticket. Queste informazioni sono disponibili tramite l’API Zendesk Ticket Metrics. Esempi 144002880086400
	Tipo di richiesta di assistenza ServiceRequestType	La classificazione della richiesta di assistenza, ad esempio 'Domanda', 'Incidente', 'Problema' o 'Attività'.
Descrizione Questo attributo classifica la richiesta di assistenza in base alla sua natura. In genere viene impostato al momento della creazione o della classificazione iniziale e aiuta a determinare il flusso di lavoro e la priorità più adatti. Nell’analisi, segmentare i dati per tipo di richiesta di assistenza è fondamentale. Consente di confrontare i tempi di risoluzione, i tassi di escalation e i flussi di processo per diverse tipologie di problema, come nelle Dashboard 'Analisi dei tempi di risoluzione delle richieste di assistenza' e 'Tasso e cause delle escalation interne'. In questo modo è possibile capire se alcune richieste sono più problematiche o meno efficienti da gestire. Perché è importante Classifica le richieste per confrontare e analizzare le prestazioni in base alle diverse tipologie di problema, un passaggio essenziale per migliorare i processi in modo mirato. Dove reperirli API Zendesk Tickets, campo `type`. Esempi DomandaIncidenteProblemaTask
	Categoria di prodotto o servizio ProductServiceCategory	Il prodotto, il servizio o la funzionalità specifica a cui si riferisce la richiesta del cliente.
Descrizione Questo attributo fornisce informazioni dettagliate classificando la richiesta di assistenza in base all’area di prodotto o servizio. La categoria viene spesso assegnata manualmente da un agente oppure determinata automaticamente in base al contenuto della richiesta. Questa classificazione è fondamentale per le Dashboard «Precisione della classificazione delle richieste» e «Analisi dei tempi di ciclo delle indagini». Consente di approfondire quali prodotti generano più richieste di assistenza, quali sono più complessi da gestire e se la classificazione iniziale corrisponde alla soluzione finale, aiutando a migliorare l’instradamento delle richieste e la formazione degli agenti. Perché è importante Collega le richieste a specifiche aree aziendali, prodotti o servizi e consente di analizzare in modo mirato le aree problematiche e il loro impatto sul processo. Dove reperirli In genere si tratta di un campo personalizzato del ticket in Zendesk. Il nome esatto dipende dalla configurazione specifica di Zendesk. Esempi App mobileGestione degli abbonamentiIntegrazione APIHardware
	Codice di risoluzione ResolutionCode	Codice o categoria che indica il motivo della risoluzione finale o della chiusura della richiesta.
Descrizione Il codice di risoluzione fornisce informazioni strutturate sull’esito di una richiesta di assistenza. Alcuni esempi sono «Risolto dall’agente», «Duplicato», «Nessuna azione necessaria» o «Problema noto». Offre più contesto rispetto al semplice stato «Chiuso». Questo attributo è particolarmente utile per l’analisi delle cause profonde. Nella Dashboard «Andamento delle richieste di assistenza riaperte», analizzare le riaperture in base al codice di risoluzione può rivelare se alcune soluzioni sono meno efficaci e portano i clienti a ricontattare il supporto. Perché è importante Fornisce informazioni sull’esito di una richiesta di assistenza, essenziali per analizzare le cause profonde e capire perché le richieste vengono riaperte. Dove reperirli In genere si tratta di un campo personalizzato del ticket in Zendesk. Il nome esatto dipende dalla configurazione specifica di Zendesk. Esempi Risoluzione al primo contattoInoltrato al livello 2In attesa del clienteErrore del prodotto
	Gruppo di agenti AgentGroup	Il gruppo o il team di supporto a cui è assegnata la richiesta di assistenza.
Descrizione Questo attributo identifica il team di agenti responsabile della richiesta di assistenza. Spesso le richieste vengono indirizzate a gruppi specifici in base alle competenze, all’area di prodotto o alla lingua. L’analisi per gruppo di agenti aiuta a comprendere le prestazioni dei team, la distribuzione del carico di lavoro e le modalità di escalation tra i gruppi. Offre una visione più ampia rispetto all’analisi dei singoli agenti e può aiutare a individuare problemi sistemici in reparti o funzioni specifici. Perché è importante Indica il team responsabile e consente di analizzare le prestazioni dei gruppi, i passaggi di consegne tra team e l’allocazione delle risorse tra diversi livelli di supporto o specializzazioni. Dove reperirli API Zendesk Tickets, campo `group_id`. I dettagli dei gruppi sono disponibili tramite l’API Groups. Esempi Supporto di livello 1Supporto tecnicoFatturazione
	Numero di richieste di informazioni InformationRequestCount	Numero totale di volte in cui, per una singola richiesta di assistenza, sono state chieste informazioni al cliente.
Descrizione Questa metrica calcolata conta quante volte si verifica l’attività «Informazioni richieste al cliente» per ciascuna richiesta di assistenza. Un numero elevato suggerisce che gli agenti non raccolgono subito tutte le informazioni necessarie. L’attributo viene utilizzato nella Dashboard «Analisi delle richieste ripetute di informazioni». Monitorare questo dato aiuta a individuare inefficienze di processo e aree in cui è utile formare gli agenti. Ridurre il numero di richieste di informazioni può abbreviare notevolmente i tempi di risoluzione e migliorare l’esperienza dei clienti. Perché è importante Quantifica gli scambi di comunicazione con il cliente, mettendo in evidenza le inefficienze che allungano i tempi di risoluzione e peggiorano l’esperienza dei clienti. Dove reperirli Calcolato contando, per ogni richiesta di assistenza, gli eventi in cui ActivityName è «Information Requested From Customer». Esempi 013
	Ora di fine EndTime	La data e l’ora che indicano quando è stata completata un’attività o si è concluso un evento.
Descrizione L’ora di fine indica quando si conclude un’attività. In molte strutture di Event Log, l’ora di inizio dell’attività successiva può essere utilizzata come ora di fine di quella corrente. Per le attività basate su uno stato, come 'Operatore analizza il problema', indica quando lo stato è terminato. Questo attributo è essenziale per calcolare con precisione la durata delle attività, un elemento centrale nell’analisi delle prestazioni. Aiuta a individuare i passaggi che richiedono più tempo e costituisce la base per analizzare nel dettaglio i colli di bottiglia e l’efficienza delle risorse. Perché è importante Consente di calcolare la durata delle attività, un dato fondamentale per individuare i colli di bottiglia e misurare le prestazioni. Dove reperirli Spesso si ricava dall’ora di inizio dell’evento successivo nella sequenza per una determinata richiesta di assistenza. Esempi 2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z
	Richiesta riaperta IsReopened	Indicatore booleano che segnala se una richiesta di assistenza è stata riaperta dopo essere stata contrassegnata come risolta.
Descrizione Questo attributo è un indicatore che assume il valore vero quando una richiesta di assistenza torna allo stato aperto dopo essere stata contrassegnata come risolta o chiusa. Segnala che la risoluzione iniziale non è stata sufficiente. È fondamentale per monitorare le rilavorazioni e i casi non risolti al primo contatto. Supporta direttamente la Dashboard «Andamento delle richieste di assistenza riaperte» e il KPI «Tasso di riapertura delle richieste di assistenza», facilitando il conteggio e l’analisi dei casi che richiedono ulteriore attenzione e che spesso indicano problemi più profondi. Perché è importante Individua le rilavorazioni e le risoluzioni non riuscite, aiutando a misurare la qualità e l’efficacia delle soluzioni fornite. Dove reperirli Calcolato durante la trasformazione dei dati verificando se lo stato di un ticket passa da «resolved» o «closed» a «open». Esempi truefalse
	Valutazione della soddisfazione SatisfactionRating	Il punteggio di soddisfazione fornito dal cliente dopo la risoluzione della richiesta di assistenza.
Descrizione Questo attributo raccoglie il feedback del cliente sulla propria esperienza di assistenza, in genere tramite un sondaggio inviato dopo la risoluzione del ticket. Le valutazioni più comuni sono «Buono», «Insoddisfacente» o un punteggio numerico. È una misura diretta della percezione del cliente e un indicatore chiave dei risultati. Viene utilizzato per calcolare il KPI «Punteggio di soddisfazione dei clienti». Analizzare le valutazioni insieme ai dati di processo, come i tempi di risoluzione o il numero di interazioni con gli agenti, può rivelare quali modalità operative portano a risultati migliori per i clienti. Perché è importante Misura direttamente il feedback dei clienti sul servizio ricevuto e collega le prestazioni del processo ai risultati per i clienti. Dove reperirli API Zendesk Tickets, campo `satisfaction_rating.score`. Esempi buonoinsoddisfacenteproposto

Obbligatorio Consigliato Facoltativo

Attività del servizio clienti

Questi sono i passaggi e i traguardi principali da registrare nell’Event Log per individuare con precisione il processo di assistenza clienti.

6 Consigliato 8 Facoltativo

	Attività	Descrizione
	Informazioni richieste al cliente	Si verifica quando un operatore ha bisogno di ulteriori informazioni dal cliente per procedere e imposta lo stato del ticket su 'pending'. Questa modifica indica esplicitamente che il processo è in attesa di una risposta esterna.
Perché è importante Questa attività evidenzia la dipendenza dal cliente e sospende il conteggio degli SLA interni. Se si verifica spesso o più volte per lo stesso ticket, può indicare che la raccolta iniziale delle informazioni è incompleta e allungare i tempi di risoluzione. Dove reperirli È una modifica esplicita dello stato registrata nell’API Ticket Audits di Zendesk. Viene rilevata quando il campo 'status' passa a 'pending'. Acquisizione Individui gli eventi 'Change' in Ticket Audits in cui lo stato del ticket viene impostato su 'pending'. Tipo di evento explicit
	Richiesta assegnata a un operatore	Questo evento indica che la richiesta di assistenza è stata assegnata a un operatore specifico. L’assegnazione può avvenire automaticamente in base alle regole di instradamento oppure manualmente da parte di un responsabile del team o di un operatore.
Perché è importante L’assegnazione è un passaggio fondamentale per definire responsabilità chiare e gestire i carichi di lavoro. Analizzare il tempo necessario per l’assegnazione e le modalità di riassegnazione permette di individuare i colli di bottiglia nella classificazione e distribuzione delle richieste. Dove reperirli È un evento 'Change' esplicito nell’API Ticket Audits di Zendesk, registrato ogni volta che il campo 'assignee_id' viene compilato o modificato. Acquisizione Monitori le modifiche al campo 'assignee_id' nel log Ticket Audits. Tipo di evento explicit
	Richiesta di assistenza chiusa	Questa è l’attività finale, che segna la chiusura definitiva della richiesta di assistenza. In genere avviene automaticamente dopo un periodo prestabilito da quando il ticket è stato contrassegnato come 'solved', se nel frattempo il cliente non ha inviato altre risposte.
Perché è importante In quanto evento finale definitivo, conclude il ciclo di vita del ticket. Il tempo che intercorre tra 'solved' e 'closed' rappresenta l’intervallo in cui il ticket può essere riaperto, mentre l’evento 'closed' conferma che la soluzione è stata accettata. Dove reperirli È una modifica esplicita dello stato registrata nell’API Ticket Audits di Zendesk quando il campo 'status' viene impostato su 'closed'. Acquisizione Individui gli eventi 'Change' in Ticket Audits in cui lo stato del ticket viene impostato su 'closed'. Tipo di evento explicit
	Richiesta di assistenza creata	Questa attività segna l’inizio del processo di assistenza clienti, quando in Zendesk viene creato un nuovo ticket da un canale qualsiasi, come e-mail, modulo web o chat. Al momento della creazione, il sistema registra esplicitamente l’evento con un ID ticket univoco e una data e ora.
Perché è importante In quanto evento iniziale principale, è essenziale per calcolare la durata complessiva del caso e analizzare nel tempo il volume delle richieste in entrata. Costituisce la base di riferimento per misurare KPI importanti, come il tempo alla prima risposta e il tempo totale di risoluzione. Dove reperirli È un evento esplicito registrato nell’API Ticket Audits di Zendesk. Corrisponde all’evento 'Create' del ticket e fornisce la data e l’ora iniziali di creazione. Acquisizione Rilevato dall’evento di creazione del ticket nel log Ticket Audits. Tipo di evento explicit
	Richiesta di assistenza riaperta	Questa attività si verifica quando un cliente risponde a un ticket con stato 'solved'. Zendesk modifica automaticamente lo stato riportandolo a 'open', segnalando che il problema non è stato risolto del tutto.
Perché è importante Le riaperture sono un indicatore importante di mancata risoluzione al primo contatto e di scarsa qualità della soluzione. Analizzare la frequenza e i motivi dei ticket riaperti aiuta a individuare come migliorare la formazione degli operatori e le procedure di risoluzione. Dove reperirli È una modifica esplicita dello stato nell’API Ticket Audits, rilevata quando 'status' passa da 'solved' a 'open'. Acquisizione Monitori gli eventi 'Change' dello stato da 'solved' a 'open'. Tipo di evento explicit
	Richiesta di assistenza risolta	Un operatore contrassegna la richiesta di assistenza come 'solved' dopo aver fornito una soluzione al cliente. Si tratta di uno stato temporaneo: il ticket può essere riaperto se il cliente risponde prima della chiusura definitiva.
Perché è importante È il passaggio principale per misurare il tempo di risoluzione e l’efficienza degli operatori. Indica il momento in cui l’operatore considera concluso il lavoro e fornisce una base per analizzare le rilavorazioni nel caso in cui il ticket venga riaperto. Dove reperirli È una modifica esplicita dello stato registrata nell’API Ticket Audits di Zendesk quando il campo 'status' viene impostato su 'solved'. Acquisizione Individui gli eventi 'Change' in Ticket Audits in cui lo stato del ticket viene impostato su 'solved'. Tipo di evento explicit
	Escalation interna avviata	Indica il trasferimento di una richiesta di assistenza a un altro team interno o a un livello di supporto superiore. In genere si deduce dalla modifica del gruppo assegnato al ticket.
Perché è importante Monitorare le escalation è fondamentale per individuare debolezze del processo, lacune nelle conoscenze del supporto di primo livello e richieste complesse. Un tasso elevato di escalation può indicare la necessità di migliorare la formazione o la documentazione dei processi. Dove reperirli Si deduce da un evento 'Change' nell’API Ticket Audits in cui viene modificato il campo 'group_id'. Il cambio di gruppo indica il passaggio della richiesta da un team a un altro. Acquisizione Monitori le modifiche al campo 'group_id' nel log Ticket Audits. Tipo di evento inferred
	Il cliente ha risposto	L’evento si attiva quando un cliente risponde a un ticket, in genere con stato 'pending'. Zendesk modifica automaticamente lo stato del ticket da 'pending' a 'open', segnalando che l’operatore può riprendere il lavoro.
Perché è importante Questa attività segna la fine dell’attesa e consente al processo di proseguire. Analizzare i tempi di risposta dei clienti può fornire indicazioni sulla chiarezza delle richieste degli operatori. Dove reperirli L’evento corrisponde a un nuovo commento pubblico dell’utente finale, che nell’API Ticket Audits attiva una modifica esplicita dello stato da 'pending' a 'open'. Acquisizione Monitori gli eventi 'Change' dello stato da 'pending' a 'open' oppure individui i nuovi commenti pubblici degli utenti finali. Tipo di evento explicit
	Prima conferma inviata	Indica la prima risposta automatica inviata al cliente per confermare la ricezione della richiesta. In genere è gestita da un trigger di Zendesk che invia un’e-mail predefinita subito dopo la creazione del ticket.
Perché è importante Monitorare questa attività è fondamentale per misurare la tempestività della prima risposta e gestire le aspettative dei clienti. Il tempo che intercorre tra la creazione della richiesta e questa conferma è un indicatore importante della soddisfazione dei clienti. Dove reperirli Si deduce dal primo commento pubblico sul ticket se l’autore è un utente automatizzato o se il commento viene pubblicato pochi secondi dopo la creazione del ticket. È possibile individuarlo analizzando il flusso Ticket Comments. Acquisizione Individui il primo commento pubblico creato da un’automazione o da un trigger subito dopo la creazione del ticket. Tipo di evento inferred
	Prima risposta pubblica dell’operatore inviata	Questa attività segna la prima volta in cui un operatore invia un commento pubblico al cliente, distinto dalla conferma automatica. È un indicatore importante del primo intervento dell’operatore sul problema del cliente.
Perché è importante È un passaggio fondamentale per misurare lo SLA 'First Reply Time', un indicatore essenziale della tempestività del servizio. Distingue le comunicazioni automatiche dall’inizio dell’analisi e dell’assistenza svolte da una persona. Dove reperirli Si individua cercando nel flusso Ticket Comments il primo commento pubblico scritto da un operatore umano, anziché da un utente di sistema automatizzato. Acquisizione Esamini i commenti dei ticket, filtrando quelli pubblici degli operatori e selezionando quello con la data e l’ora più vicine all’inizio. Tipo di evento inferred
	Richiesta classificata e definita per priorità	Questa attività si verifica quando un operatore o un’automazione imposta o aggiorna campi del ticket, come tipo, categoria e priorità. Il passaggio viene registrato come evento di modifica nella cronologia del ticket.
Perché è importante Una classificazione e una definizione delle priorità corrette sono essenziali per instradare le richieste e assegnare le risorse in modo efficiente. Analizzare questa attività aiuta a valutare l’accuratezza della classificazione iniziale e il suo impatto sui tempi di risoluzione. Dove reperirli Rilevato nell’API Ticket Audits di Zendesk come evento 'Change'. È possibile individuarlo cercando il primo aggiornamento di campi come 'priority', 'type' o dei campi personalizzati relativi alla classificazione. Acquisizione Filtri i log Ticket Audit per individuare il primo evento 'Change' sui campi principali di classificazione dopo la creazione. Tipo di evento explicit
	Sondaggio di soddisfazione inviato	Indica il momento in cui al cliente viene inviato automaticamente un sondaggio sulla soddisfazione (CSAT). Di solito avviene poco dopo che il ticket è stato contrassegnato come 'solved'.
Perché è importante Questa attività avvia la raccolta dei commenti dei clienti. Sapere quando e se vengono inviati i sondaggi è importante per interpretare i punteggi di soddisfazione e misurare l’efficacia del programma di feedback. Dove reperirli È possibile dedurlo da un log di automazione o dall’aggiunta di un tag specifico al ticket. Anche la sezione 'satisfaction_rating' dell’API Ticket Audits registra quando è stato proposto il sondaggio. Acquisizione Cerchi tag come 'csat_sent' oppure utilizzi la data e l’ora in cui è stata proposta la valutazione della soddisfazione. Tipo di evento inferred
	Valutazione della soddisfazione ricevuta	L’evento si verifica quando il cliente invia la risposta al sondaggio sulla soddisfazione, assegnando una valutazione come 'Buono' o 'Negativo'. La valutazione e gli eventuali commenti associati vengono registrati nel ticket.
Perché è importante Il feedback diretto dei clienti è prezioso per misurare la qualità del servizio e il loro giudizio. Analizzare le valutazioni nel contesto del flusso del processo aiuta a mettere in relazione specifiche attività o operatori con i risultati. Dove reperirli Rilevato come evento 'Change' nell’API Ticket Audits quando il campo 'satisfaction_rating' viene compilato con il punteggio e il commento del cliente. Acquisizione Filtri i log Ticket Audit per individuare le modifiche al campo 'satisfaction_rating'. Tipo di evento explicit
	Violazione SLA rilevata	Questa attività segna il momento in cui una richiesta di assistenza non rispetta un accordo sul livello del servizio definito, per esempio per il tempo alla prima risposta o il tempo di risoluzione. L’evento viene calcolato confrontando le date e gli orari delle attività del ticket con le politiche SLA.
Perché è importante Le violazioni degli SLA incidono direttamente sulla soddisfazione dei clienti e sul rispetto degli obblighi contrattuali. Analizzare quando e perché si verificano è fondamentale per individuare ritardi sistematici, carenza di risorse o obiettivi di prestazione irrealistici. Dove reperirli Il dato può provenire dall’API Ticket Metrics di Zendesk, che registra le date e le ore delle violazioni SLA ('breached_at'). In alternativa, è possibile calcolarlo confrontando le date e le ore degli eventi del ticket con le regole SLA definite. Acquisizione Utilizzi la data e l’ora 'breached_at' dell’API Ticket Metrics oppure calcoli la violazione confrontando il tempo di risoluzione con quello previsto dalla politica SLA. Tipo di evento calculated

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da Zendesk Support

Passaggi

Acceda a Zendesk Explore: acceda alla Sua istanza Zendesk e apra Explore facendo clic sull’icona di avvio delle applicazioni nella barra superiore, quindi selezioni Explore.
Crei una nuova query: in Explore, faccia clic sull’icona Queries nella barra laterale sinistra, quindi sul pulsante "New query" in alto a destra.
Selezioni il Dataset: nella finestra "Choose a dataset", selezioni il Dataset Support: Tickets. Contiene gli attributi principali dei ticket e le relative date e ore degli eventi.
Aggiunga le metriche: nel generatore di query, apra il pannello "Metrics" e faccia clic su "Add". Selezioni COUNT(Tickets) per verificare il volume dei dati.
Aggiunga gli attributi alle righe: apra il pannello "Rows" e faccia clic su "Add". Aggiunga gli attributi seguenti, che costituiranno le colonne di base dell’esportazione in formato largo.
- Ticket ID (identificativo del caso, ServiceRequest)
- Assignee name (AssignedAgent)
- Ticket type (ServiceRequestType)
- Ticket priority (Priority)
- Ticket channel (CommunicationChannel)
- SLA resolution time (SlaTargetResolutionTime)
- SLA breach status (IsSlaBreached)
- Full resolution time (min) (ServiceRequestResolutionTime)
Aggiunga alle righe le date e le ore delle attività: aggiunga al pannello "Rows" gli attributi temporali seguenti. Ognuno corrisponde a una possibile attività. Per alcune attività è necessario creare un attributo calcolato personalizzato.
- Ticket created - Timestamp: per Service Request Created e Initial Acknowledgment Sent.
- Ticket assigned - Timestamp: per Request Assigned To Agent.
- First reply time - Timestamp: per First Agent Public Reply Sent.
- Ticket solved - Timestamp: per Service Request Resolved e Satisfaction Survey Sent.
- Ticket reopened - Timestamp: per Service Request Reopened.
- Satisfaction rating received - Timestamp: per Satisfaction Rating Received.
- Ticket closed - Timestamp: per Service Request Closed.
Crei attributi calcolati personalizzati per le altre attività: alcune attività dipendono da modifiche specifiche dei campi; per acquisirne la data e l’ora, occorre creare attributi personalizzati. Apra il menu Calculations (icona della calcolatrice) e selezioni "Standard calculated attribute". Crei un attributo per ciascuna delle attività seguenti. Dovrà individuare i nomi esatti dei campi e dei valori nella Sua istanza Zendesk.
- Nome: Timestamp - Categorized and Prioritized. Formula: IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF. Dopo averlo creato, aggiunga il nuovo attributo al pannello "Rows" e imposti l’aggregatore su MIN.
- Nome: Timestamp - Info Requested. Formula: IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF. Lo aggiunga a "Rows" e imposti l’aggregatore su MIN.
- Nome: Timestamp - Customer Responded. Formula: IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF. Lo aggiunga a "Rows" e imposti l’aggregatore su MIN.
- Nome: Timestamp - Escalated. Formula: IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF. Lo aggiunga a "Rows" e imposti l’aggregatore su MIN.
- Nome: Timestamp - SLA Breach. Formula: IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF. Lo aggiunga a "Rows" e imposti l’aggregatore su MIN.
Filtri i dati: apra il pannello "Filters" e faccia clic su "Add". Aggiunga un filtro per Ticket created - Date e selezioni un intervallo adeguato, ad esempio gli ultimi 3-6 mesi, per mantenere gestibile il Dataset.
Esegua ed esporti il report: faccia clic su "Save" per eseguire la query. Quando la tabella mostra i dati, faccia clic su "Export" e scelga il formato desiderato, ad esempio CSV o Excel.
Trasformi i dati nel formato Event Log: il file esportato è in formato "largo": ogni riga corrisponde a un ticket e ogni colonna a una data e ora di un evento. Per il Process Mining, deve trasformarlo in formato "lungo". Può usare Microsoft Excel (con la funzione Annulla pivot di Power Query), Python o un altro strumento di preparazione dei dati.
- Per ogni riga (ticket), crei più righe, una per ciascuna colonna temporale non vuota.
- La tabella finale dovrebbe contenere colonne come ServiceRequest, ActivityName, StartTime e gli altri attributi, che verranno ripetuti per ogni attività relativa alla stessa richiesta di assistenza.

Configurazione

Insieme di dati: L’insieme di dati principale da utilizzare è Support: Tickets, che consente di accedere in un’unica query alla maggior parte delle proprietà dei ticket e ai timestamp principali.
Autorizzazioni: Per creare e salvare query in Zendesk Explore, è necessario disporre almeno del ruolo Editor o Admin.
Intervallo di date: È fondamentale applicare un filtro per intervallo di date a Ticket created - Date. Per bilanciare la quantità di informazioni e le prestazioni, è consigliabile utilizzare dati relativi a un periodo di 3-6 mesi. L’esportazione di milioni di ticket può richiedere molto tempo o non riuscire.
Filtri delle query: Valuti di aggiungere filtri per proprietà specifiche dei ticket, come Ticket brand, Ticket form o Ticket group, per concentrare l’analisi su un servizio o un team specifico.
Attributi calcolati: Questo metodo si basa in larga misura sulla creazione di attributi calcolati standard per acquisire i timestamp degli eventi che non corrispondono ad attributi predefiniti, come le modifiche di stato o le escalation. Verifichi di disporre delle autorizzazioni necessarie per creare questi attributi.

a Query di esempio config

This extraction is configured through the Zendesk Explore graphical user interface. There is no single script to execute. The configuration below outlines the components to add in the query builder.

**Dataset**: `Support: Tickets`

**Metrics**:
1.  `COUNT(Tickets)`

**Rows (Attributes)**:
1.  `Ticket ID`
2.  `Assignee name`
3.  `Ticket type`
4.  `Ticket priority`
5.  `Ticket channel`
6.  `SLA resolution time`
7.  `SLA breach status`
8.  `Full resolution time (min)`
9.  `MIN(Ticket created - Timestamp)`
10. `MIN(Ticket assigned - Timestamp)`
11. `MIN(First reply time - Timestamp)`
12. `MIN(Ticket solved - Timestamp)`
13. `MIN(Ticket reopened - Timestamp)`
14. `MIN(Satisfaction rating received - Timestamp)`
15. `MIN(Ticket closed - Timestamp)`
16. `MIN(Timestamp - Categorized and Prioritized)` (Custom calculated attribute)
17. `MIN(Timestamp - Info Requested)` (Custom calculated attribute)
18. `MIN(Timestamp - Customer Responded)` (Custom calculated attribute)
19. `MIN(Timestamp - Escalated)` (Custom calculated attribute)
20. `MIN(Timestamp - SLA Breach)` (Custom calculated attribute)

**Filters**:
1.  `Ticket created - Date`: Select a date range (e.g., last 180 days)

**Standard Calculated Attribute Formulas**:
*   `Timestamp - Categorized and Prioritized`: `IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Info Requested`: `IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Customer Responded`: `IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Escalated`: `IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - SLA Breach`: `IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF`

Passaggi

Prepari l’accesso all’API Zendesk: acceda a Zendesk come amministratore. Apra l’Admin Center, quindi vada in Apps and integrations > APIs > Zendesk API. Nella scheda Settings, verifichi che Token Access sia abilitato. Faccia clic su 'Add API token' per creare un nuovo token. Copi il token generato e lo conservi in modo sicuro, perché non verrà mostrato di nuovo.
Configuri l’ambiente Python: verifichi di avere installato Python 3.6 o una versione successiva. Installi la libreria requests, necessaria per inviare richieste HTTP all’API Zendesk. Può installarla dalla riga di comando con pip install requests.
Configuri lo script Python: salvi lo script Python fornito in un file, ad esempio extract_zendesk_log.py. Apra il file con un editor di testo e sostituisca le variabili segnaposto iniziali ZENDESK_SUBDOMAIN, ZENDESK_EMAIL e API_TOKEN con i dati e le credenziali della Sua istanza Zendesk.
Definisca il periodo di estrazione: individui nello script la variabile START_TIMESTAMP, che determina la data iniziale dei dati storici da estrarre. Il valore deve essere un timestamp Unix. Per un’analisi iniziale, si consiglia di impostare una data corrispondente agli ultimi 3-6 mesi.
Esegua lo script: apra un terminale o il prompt dei comandi, raggiunga la cartella in cui ha salvato lo script e lo esegua con il comando python extract_zendesk_log.py.
Controlli l’esecuzione: lo script mostrerà nella console gli aggiornamenti sullo stato di avanzamento e il numero di ticket elaborati. La durata complessiva dipende dal volume dei dati estratti e dai limiti di frequenza imposti dall’API Zendesk. Lo script include una logica di base per gestire le risposte che segnalano il raggiungimento di tali limiti.
Recuperi l’Event Log: al termine dell’esecuzione, nella stessa cartella verrà creato il file zendesk_event_log.csv, che contiene l’Event Log strutturato e pronto per l’analisi.
Prepari il caricamento: apra zendesk_event_log.csv e verifichi che sia stato generato correttamente. Controlli che le colonne corrispondano agli attributi richiesti: ServiceRequest, ActivityName, StartTime, SourceSystem e LastDataUpdate. Il file è pronto per essere caricato nello strumento di Process Mining.

Configurazione

Credenziali API: lo script richiede un sottodominio Zendesk valido, l’indirizzo e-mail di un operatore o amministratore e un token API attivo. L’utente associato alle credenziali deve poter leggere ticket, audit dei ticket, utenti e metriche dei ticket.
Intervallo di date: la data iniziale dell’estrazione è definita dalla variabile START_TIMESTAMP nello script e deve essere un timestamp Unix. Prima di estrarre un periodo storico più ampio, è consigliabile iniziare con un intervallo più breve, ad esempio 3 mesi, per verificare l’output e le prestazioni dello script.
API di esportazione incrementale: questa soluzione utilizza l’Incremental Export API di Zendesk, il metodo più efficiente e consigliato per recuperare un numero elevato di ticket, poiché è progettato per l’esportazione in blocco e riduce i problemi comuni legati alla paginazione.
Prestazioni e limiti di frequenza: Zendesk applica limiti di frequenza API che variano in base al piano di abbonamento. Quando viene raggiunto un limite, lo script sospende l’esecuzione in base all’intestazione Retry-After restituita dall’API. Nelle istanze molto grandi, l’estrazione può richiedere diverse ore.
Prerequisiti: questo metodo richiede un ambiente Python 3.6 o successivo funzionante e la libreria esterna requests. Per generare il token API necessario, occorre disporre dell’accesso amministrativo all’istanza Zendesk di destinazione.

a Query di esempio python

import requests
import json
import time
import datetime
import csv

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">'[your_zendesk_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_zendesk_login_email]'
API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Set the start time for the export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is Jan 1, 2023 00:00:00 GMT
START_TIMESTAMP = 1672531200

class=class="hl-string">"hl-comment"># --- Script --- 

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

CSV_FILENAME = class="hl-string">'zendesk_event_log.csv'
CSV_HEADERS = [
    class="hl-string">'ServiceRequest', class="hl-string">'ActivityName', class="hl-string">'StartTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
    class="hl-string">'AssignedAgent', class="hl-string">'ServiceRequestType', class="hl-string">'Priority', class="hl-string">'CommunicationChannel',
    class="hl-string">'SlaTargetResolutionTime', class="hl-string">'IsSlaBreached', class="hl-string">'ServiceRequestResolutionTime'
]

def get_user_name(user_id, users_cache, session):
    if user_id in users_cache:
        return users_cache[user_id]
    if user_id is None:
        return None
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_name = response.json().get(class="hl-string">'user', {}).get(class="hl-string">'name')
        users_cache[user_id] = user_name
        return user_name
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Warning: Could not fetch user {user_id}. Error: {e}')
        users_cache[user_id] = str(user_id)
        return str(user_id)

def format_duration(seconds):
    if seconds is None:
        return None
    return str(datetime.timedelta(seconds=seconds))

def main():
    session = requests.Session()
    session.auth = AUTH
    users_cache = {}
    event_log = []

    class=class="hl-string">"hl-comment"># Fetch tickets using the incremental export API
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}'
    ticket_count = 0

    while url:
        print(fclass="hl-string">'Fetching tickets from: {url}')
        try:
            response = session.get(url)

            if response.status_code == 429:
                retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
                print(fclass="hl-string">'Rate limit hit. Retrying after {retry_after} seconds.')
                time.sleep(retry_after)
                continue

            response.raise_for_status()
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])

            for ticket in tickets:
                ticket_count += 1
                ticket_id = ticket[class="hl-string">'id']
                print(fclass="hl-string">'Processing ticket {ticket_id} ({ticket_count} total)...')

                class=class="hl-string">"hl-comment"># Fetch ticket metrics for SLA and resolution time
                metrics_response = session.get(fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json')
                ticket_metrics = metrics_response.json().get(class="hl-string">'ticket_metric', {}) if metrics_response.ok else {}

                resolution_time_seconds = ticket_metrics.get(class="hl-string">'full_resolution_time_in_minutes', {}).get(class="hl-string">'business')
                if resolution_time_seconds:
                    resolution_time_seconds *= 60

                class=class="hl-string">"hl-comment"># Fetch ticket audits for events
                audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
                audits_response = session.get(audits_url)
                audits = audits_response.json().get(class="hl-string">'audits', []) if audits_response.ok else []

                first_agent_reply_sent = False

                for audit in audits:
                    audit_created_at = audit[class="hl-string">'created_at']
                    base_event = {
                        class="hl-string">'ServiceRequest': ticket_id,
                        class="hl-string">'StartTime': audit_created_at,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'AssignedAgent': get_user_name(ticket.get(class="hl-string">'assignee_id'), users_cache, session),
                        class="hl-string">'ServiceRequestType': ticket.get(class="hl-string">'type'),
                        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'CommunicationChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaTargetResolutionTime': None, class=class="hl-string">"hl-comment"># Requires parsing SLA policies, complex
                        class="hl-string">'IsSlaBreached': ticket_metrics.get(class="hl-string">'sla_breach_at') is not None,
                        class="hl-string">'ServiceRequestResolutionTime': format_duration(resolution_time_seconds)
                    }

                    for event in audit.get(class="hl-string">'events', []):
                        event_type = event.get(class="hl-string">'type')
                        class=class="hl-string">"hl-comment"># Service Request Created
                        if event_type == class="hl-string">'Create' and event.get(class="hl-string">'field_name') == class="hl-string">'id':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Created'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Initial Acknowledgment Sent (Proxy by Notification event)
                        if event_type == class="hl-string">'Notification':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Initial Acknowledgment Sent'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Request Categorized And Prioritized, Assigned, Status Changes
                        if event_type == class="hl-string">'Change':
                            field = event.get(class="hl-string">'field_name')
                            if field in [class="hl-string">'type', class="hl-string">'priority', class="hl-string">'custom_field_[your_category_field_id]']:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Categorized And Prioritized'
                                event_log.append(new_event)
                            
                            if field == class="hl-string">'assignee_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Assigned To Agent'
                                new_event[class="hl-string">'AssignedAgent'] = get_user_name(event.get(class="hl-string">'value'), users_cache, session)
                                event_log.append(new_event)

                            if field == class="hl-string">'group_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Internal Escalation Triggered'
                                event_log.append(new_event)

                            if field == class="hl-string">'status':
                                new_status = event.get(class="hl-string">'value')
                                if new_status == class="hl-string">'pending':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Information Requested From Customer'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'solved':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Resolved'
                                    event_log.append(new_event)
                                    class=class="hl-string">"hl-comment"># Satisfaction Survey Sent (Proxy: occurs after solve)
                                    solve_time = datetime.datetime.fromisoformat(audit_created_at.replace(class="hl-string">'Z', class="hl-string">'+00:00'))
                                    survey_time = solve_time + datetime.timedelta(hours=1)
                                    survey_event = new_event.copy()
                                    survey_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Survey Sent'
                                    survey_event[class="hl-string">'StartTime'] = survey_time.isoformat().replace(class="hl-string">'+00:00', class="hl-string">'Z')
                                    event_log.append(survey_event)
                                elif new_status == class="hl-string">'closed':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Closed'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'open' and event.get(class="hl-string">'previous_value') in [class="hl-string">'solved', class="hl-string">'pending']:
                                    activity = class="hl-string">'Service Request Reopened' if event.get(class="hl-string">'previous_value') == class="hl-string">'solved' else class="hl-string">'Customer Responded'
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = activity
                                    event_log.append(new_event)
                            
                            if field == class="hl-string">'satisfaction_score':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Rating Received'
                                event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># First Agent Public Reply Sent & Customer Responded
                        if event_type == class="hl-string">'Comment':
                            author_id = event.get(class="hl-string">'author_id')
                            author_details_response = session.get(fclass="hl-string">'{BASE_URL}/users/{author_id}.json')
                            author_role = author_details_response.json().get(class="hl-string">'user',{}).get(class="hl-string">'role', class="hl-string">'end-user') if author_details_response.ok else class="hl-string">'end-user'

                            if author_role in [class="hl-string">'agent', class="hl-string">'admin'] and event.get(class="hl-string">'public') and not first_agent_reply_sent:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'First Agent Public Reply Sent'
                                event_log.append(new_event)
                                first_agent_reply_sent = True

                class=class="hl-string">"hl-comment"># SLA Breach Occurred
                if ticket_metrics.get(class="hl-string">'sla_breach_at'):
                    sla_breach_time = ticket_metrics.get(class="hl-string">'sla_breach_at')
                    new_event = base_event.copy()
                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'SLA Breach Occurred'
                    new_event[class="hl-string">'StartTime'] = sla_breach_time
                    event_log.append(new_event)

            url = data.get(class="hl-string">'after_url')
            if not data.get(class="hl-string">'end_of_stream', False):
                time.sleep(1) class=class="hl-string">"hl-comment"># Be a good API citizen
            else:
                url = None

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'An error occurred: {e}')
            break

    class=class="hl-string">"hl-comment"># Write to CSV
    print(fclass="hl-string">'Writing {len(event_log)} events to {CSV_FILENAME}...')
    with open(CSV_FILENAME, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
        writer = csv.DictWriter(csvfile, fieldnames=CSV_HEADERS)
        writer.writeheader()
        class=class="hl-string">"hl-comment"># Sort events by ticket and then by time for chronological order
        sorted_log = sorted(event_log, key=lambda x: (x[class="hl-string">'ServiceRequest'], x[class="hl-string">'StartTime']))
        for row in sorted_log:
            writer.writerow(row)
    print(class="hl-string">'Extraction complete.')

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

Passaggi

Verifichi che l’account Zendesk Support consenta l’accesso all’Incremental Exports API e che l’identità usata per l’integrazione possa leggere ticket, eventi dei ticket, utenti, gruppi, commenti, valutazioni di soddisfazione e dati SLA, se queste funzionalità sono abilitate. Verifichi il sottodominio dell’account e il metodo di autenticazione in base alla configurazione approvata dall’organizzazione.
Scelga un orario iniziale di estrazione che copra il periodo di analisi richiesto. Le esportazioni incrementali dei ticket utilizzano un timestamp Unix e restituiscono i record creati o aggiornati a partire da quel momento. Per caricare l’intero storico, usi [Configure based on your system] come orario iniziale e salvi l’orario finale restituito per le successive esecuzioni incrementali. Per le analisi periodiche, è sufficiente un intervallo di 3-6 mesi se lo storico operativo è adeguato.
Esegua lo script Python di estrazione dopo aver configurato il sottodominio Zendesk, le credenziali di autenticazione, il timestamp iniziale e gli eventuali filtri specifici dell’azienda. Lo script richiede i dati incrementali dei ticket, gestisce la paginazione e salva i record grezzi dei ticket e i dettagli degli eventi disponibili prima della trasformazione.
Recuperi lo storico degli audit o degli eventi di ciascun ticket quando la risposta incrementale non contiene informazioni sufficienti sulle modifiche dei campi, le assegnazioni, i commenti o gli stati. Utilizzi solo le risorse API Zendesk abilitate e autorizzate nell’account. Conservi, se restituiti, l’ID del ticket di origine, l’ID dell’audit, l’ID del commento, la data e ora dell’evento, l’autore, il nome del campo, il valore precedente e quello nuovo.
Normalizzi i timestamp in UTC e converta i timestamp Unix o i valori ISO 8601 in un formato data e ora uniforme. Ordini i record di origine per ServiceRequest, data e ora dell’evento e identificativo dell’evento di origine. Rimuova i duplicati usando l’identificativo stabile più specifico disponibile, ad esempio quello di un audit o di un commento.
Crei righe esplicite nell’Event Log per tutte le 14 attività richieste. Non presuma che ProcessMind deduca le attività dalle modifiche di stato o dai valori dei campi. Generi Service Request Created dalla creazione del ticket, Initial Acknowledgment Sent da una prima risposta automatica verificata, Request Categorized And Prioritized dalle modifiche di categoria, tipo o priorità, Request Assigned To Agent dalle modifiche dell’assegnatario, First Agent Public Reply Sent dal primo commento pubblico idoneo dell’operatore, Information Requested From Customer da una transizione a pending associata a una richiesta di informazioni, Customer Responded da una risposta idonea del cliente, Internal Escalation Triggered da una modifica del gruppo assegnato, SLA Breach Occurred da una data e ora di violazione SLA verificata o calcolata esplicitamente, Service Request Resolved da una transizione a solved, Service Request Reopened da una transizione da solved a open causata da una risposta del cliente, Satisfaction Survey Sent da un invio verificato del sondaggio, Satisfaction Rating Received da una valutazione inviata e Service Request Closed da una transizione a closed o da un evento verificato di chiusura definitiva.
Compili le colonne obbligatorie ServiceRequest, ActivityName, StartTime, SourceSystem e LastDataUpdate. Compili le colonne consigliate AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime e IsSlaBreached quando la fonte fornisce valori affidabili. Per gli attributi facoltativi non disponibili, usi valori null anziché inventare dati.
Applichi gli eventuali filtri specifici dell’azienda approvati dopo l’estrazione e prima dell’esportazione. Conservi una copia interna di staging con gli identificativi e i timestamp originali, così da poter verificare e ripetere l’elaborazione degli eventi.
Convalidi il numero di righe, la copertura delle attività, l’ordine dei timestamp, la gestione dei duplicati e la compilazione degli attributi. Verifichi che ogni riga generata contenga ServiceRequest, ActivityName, StartTime, SourceSystem e LastDataUpdate.
Esporti l’Event Log trasformato in formato CSV UTF-8 o in un altro formato tabellare supportato da ProcessMind. Verifichi che i nomi delle colonne corrispondano esattamente agli attributi richiesti, che ogni occorrenza di attività sia su una riga distinta e carichi il file tramite il processo di importazione ProcessMind configurato.

Configurazione

Metodo di estrazione: utilizzi l’API Zendesk Incremental Exports per estrarre grandi volumi di ticket. Lo script deve richiedere i dati a partire da un timestamp Unix salvato, gestire la paginazione, rispettare i limiti di frequenza e salvare il timestamp finale restituito per l’esecuzione successiva.
Autenticazione: configuri il metodo di autenticazione Zendesk approvato, il sottodominio dell’account, le credenziali e le autorizzazioni API in base alle norme di sicurezza dell’organizzazione. Non inserisca le credenziali direttamente nel sistema di controllo del codice sorgente.
Intervallo di date: per le analisi periodiche dei processi, utilizzi un intervallo di 3-6 mesi. Per il caricamento iniziale, scelga un orario iniziale precedente al periodo di processo richiesto, poiché le attività dei ticket creati in precedenza potrebbero ricadere nell’intervallo di analisi. Per i caricamenti incrementali, riparta dal punto di controllo dell’ultima estrazione riuscita, includendo un breve intervallo di sovrapposizione per gestire gli aggiornamenti tardivi, quindi rimuova i duplicati in base agli identificativi di origine.
Filtri: applichi solo filtri supportati dalle risorse Zendesk disponibili nell’account, ad esempio quelli approvati per organizzazione, gruppo, brand, tipo di ticket, stato o campi personalizzati. I filtri specifici dell’azienda devono essere configurati in base al sistema in uso. Non presuma che in Zendesk esistano campi Company Code o Document Type.
Colonne obbligatorie nell’output: ServiceRequest, ActivityName, StartTime, SourceSystem e LastDataUpdate.
Colonne consigliate nell’output: AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime e IsSlaBreached.
Dettagli degli eventi: i soli record incrementali dei ticket potrebbero non mostrare tutte le transizioni storiche. Se necessario, recuperi gli audit dei ticket, i commenti, i dati di soddisfazione e gli eventi SLA autorizzati. Generi esplicitamente una riga per ogni attività richiesta.
Configurazione SLA: utilizzi, se disponibili, la policy SLA effettiva e i timestamp delle violazioni restituiti dall’account. Se calcola lo stato di violazione, documenti la policy, l’orario lavorativo, le sospensioni e il fuso orario utilizzati. Se si applicano regole basate sull’orario lavorativo, non calcoli la violazione basandosi solo sul tempo trascorso secondo l’orologio.
Prestazioni: elabori le pagine in modo incrementale, trasmettendo i record in flussi o in blocchi, memorizzi nella cache i dettagli dei ticket, limiti le operazioni simultanee, rispetti le risposte Zendesk relative ai limiti di frequenza e salvi i progressi dopo ogni pagina elaborata correttamente. Eviti di richiedere ripetutamente l’intero storico.
Conservazione dei dati: conservi le risposte API grezze, i punti di controllo delle estrazioni, i metadati delle richieste e i log delle trasformazioni per le verifiche e le successive rielaborazioni.
Prerequisiti: accesso all’API Zendesk, autorizzazione a leggere le risorse pertinenti relative a ticket ed eventi, audit dei ticket e commenti abilitati ove necessari, accesso ai dati di soddisfazione se sono richieste attività CSAT e accesso ai dati SLA se sono richieste attività relative alle violazioni SLA. La disponibilità delle funzionalità dipende dal piano Zendesk e dalla configurazione dell’account.

a Query di esempio python

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

import requests

ZENDESK_SUBDOMAIN = os.environ.get(class="hl-string">"ZENDESK_SUBDOMAIN", class="hl-string">"[Configure based on your system]")
ZENDESK_EMAIL = os.environ.get(class="hl-string">"ZENDESK_EMAIL", class="hl-string">"[Configure based on your system]")
ZENDESK_API_TOKEN = os.environ.get(class="hl-string">"ZENDESK_API_TOKEN", class="hl-string">"[Configure based on your system]")
START_TIME = os.environ.get(class="hl-string">"START_TIME", class="hl-string">"[Configure based on your system]")
OUTPUT_FILE = os.environ.get(class="hl-string">"OUTPUT_FILE", class="hl-string">"zendesk_processmind_event_log.csv")
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"

REQUIRED_COLUMNS = [
    class="hl-string">"ServiceRequest",
    class="hl-string">"ActivityName",
    class="hl-string">"StartTime",
    class="hl-string">"SourceSystem",
    class="hl-string">"LastDataUpdate",
]
RECOMMENDED_COLUMNS = [
    class="hl-string">"AssignedAgent",
    class="hl-string">"ServiceRequestType",
    class="hl-string">"Priority",
    class="hl-string">"CommunicationChannel",
    class="hl-string">"SlaTargetResolutionTime",
    class="hl-string">"IsSlaBreached",
]
ALL_COLUMNS = REQUIRED_COLUMNS + RECOMMENDED_COLUMNS


def fail(message: str) -> None:
    raise RuntimeError(message)


def parse_start_time(value: str) -> int:
    if value.isdigit():
        return int(value)
    try:
        return int(datetime.fromisoformat(value.replace(class="hl-string">"Z", class="hl-string">"+00:00")).timestamp())
    except ValueError as exc:
        raise RuntimeError(class="hl-string">"START_TIME must be a Unix timestamp or ISO 8601 timestamp") from exc


def iso_timestamp(value: Any) -> Optional[str]:
    if value is None or value == class="hl-string">"":
        return None
    if isinstance(value, (int, float)):
        return datetime.fromtimestamp(value, tz=timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z")
    text = str(value)
    if text.isdigit():
        return datetime.fromtimestamp(int(text), tz=timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z")
    return text


def now_utc() -> str:
    return datetime.now(timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z")


def api_get(session: requests.Session, path: str, params: Optional[Dict[str, Any]] = None) -> Dict[str, Any]:
    url = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com{path}"
    while True:
        response = session.get(url, params=params, timeout=60)
        if response.status_code == 429:
            retry_after = int(response.headers.get(class="hl-string">"Retry-After", class="hl-string">"5"))
            time.sleep(max(retry_after, 1))
            continue
        response.raise_for_status()
        return response.json()


def paged_get(session: requests.Session, path: str, params: Optional[Dict[str, Any]] = None) -> Iterable[Dict[str, Any]]:
    next_url: Optional[str] = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com{path}"
    next_params = params
    while next_url:
        while True:
            response = session.get(next_url, params=next_params, timeout=60)
            if response.status_code == 429:
                retry_after = int(response.headers.get(class="hl-string">"Retry-After", class="hl-string">"5"))
                time.sleep(max(retry_after, 1))
                continue
            response.raise_for_status()
            payload = response.json()
            break
        for item in payload.get(class="hl-string">"tickets", payload.get(class="hl-string">"audits", payload.get(class="hl-string">"comments", payload.get(class="hl-string">"results", [])))):
            yield item
        next_url = payload.get(class="hl-string">"next_page")
        next_params = None


def get_user_name(session: requests.Session, user_id: Any, cache: Dict[str, str]) -> Optional[str]:
    if not user_id:
        return None
    key = str(user_id)
    if key in cache:
        return cache[key]
    try:
        user = api_get(session, fclass="hl-string">"/api/v2/users/{key}.json").get(class="hl-string">"user", {})
        name = user.get(class="hl-string">"name") or user.get(class="hl-string">"email") or key
        cache[key] = str(name)
        return cache[key]
    except requests.HTTPError:
        cache[key] = key
        return key


def get_group_name(session: requests.Session, group_id: Any, cache: Dict[str, str]) -> Optional[str]:
    if not group_id:
        return None
    key = str(group_id)
    if key in cache:
        return cache[key]
    try:
        group = api_get(session, fclass="hl-string">"/api/v2/groups/{key}.json").get(class="hl-string">"group", {})
        name = group.get(class="hl-string">"name") or key
        cache[key] = str(name)
        return cache[key]
    except requests.HTTPError:
        cache[key] = key
        return key


def ticket_field(ticket: Dict[str, Any], names: List[str]) -> Any:
    for name in names:
        if ticket.get(name) is not None:
            return ticket.get(name)
    return None


def base_row(ticket: Dict[str, Any], activity: str, event_time: Any, last_update: str, user_cache: Dict[str, str]) -> Dict[str, Any]:
    return {
        class="hl-string">"ServiceRequest": str(ticket.get(class="hl-string">"id")),
        class="hl-string">"ActivityName": activity,
        class="hl-string">"StartTime": iso_timestamp(event_time),
        class="hl-string">"SourceSystem": SOURCE_SYSTEM,
        class="hl-string">"LastDataUpdate": last_update,
        class="hl-string">"AssignedAgent": get_user_name(session, ticket.get(class="hl-string">"assignee_id"), user_cache),
        class="hl-string">"ServiceRequestType": ticket.get(class="hl-string">"type"),
        class="hl-string">"Priority": ticket.get(class="hl-string">"priority"),
        class="hl-string">"CommunicationChannel": ticket.get(class="hl-string">"via", {}).get(class="hl-string">"channel") if isinstance(ticket.get(class="hl-string">"via"), dict) else ticket.get(class="hl-string">"via"),
        class="hl-string">"SlaTargetResolutionTime": ticket.get(class="hl-string">"sla_target_resolution_time"),
        class="hl-string">"IsSlaBreached": ticket.get(class="hl-string">"is_sla_breached"),
    }


def add_event(events: List[Dict[str, Any]], seen: set, ticket: Dict[str, Any], activity: str, event_time: Any, last_update: str, user_cache: Dict[str, str], source_key: str) -> None:
    if event_time is None:
        return
    key = (str(ticket.get(class="hl-string">"id")), activity, source_key, str(event_time))
    if key in seen:
        return
    seen.add(key)
    events.append(base_row(ticket, activity, event_time, last_update, user_cache))


def audit_events(session: requests.Session, ticket_id: Any) -> List[Dict[str, Any]]:
    return list(paged_get(session, fclass="hl-string">"/api/v2/tickets/{ticket_id}/audits.json"))


def audit_events_for_field(audit: Dict[str, Any], field_names: List[str]) -> List[Tuple[str, Any, Any]]:
    output: List[Tuple[str, Any, Any]] = []
    for event in audit.get(class="hl-string">"events", []):
        if event.get(class="hl-string">"type") != class="hl-string">"Change":
            continue
        field = str(event.get(class="hl-string">"field_name") or event.get(class="hl-string">"field") or class="hl-string">"")
        if field in field_names:
            output.append((field, event.get(class="hl-string">"previous_value"), event.get(class="hl-string">"value")))
    return output


def is_customer_actor(audit: Dict[str, Any], ticket: Dict[str, Any]) -> bool:
    author_id = audit.get(class="hl-string">"author_id")
    requester_id = ticket.get(class="hl-string">"requester_id")
    return author_id is not None and requester_id is not None and str(author_id) == str(requester_id)


def is_public_comment(event: Dict[str, Any]) -> bool:
    return event.get(class="hl-string">"type") in {class="hl-string">"Comment", class="hl-string">"VoiceComment"} and event.get(class="hl-string">"public") is not False


def is_automated_acknowledgment(event: Dict[str, Any]) -> bool:
    body = str(event.get(class="hl-string">"body") or event.get(class="hl-string">"html_body") or class="hl-string">"").lower()
    marker = str(event.get(class="hl-string">"via", {}).get(class="hl-string">"channel") if isinstance(event.get(class="hl-string">"via"), dict) else event.get(class="hl-string">"via") or class="hl-string">"").lower()
    return class="hl-string">"acknowledg" in body or class="hl-string">"received your request" in body or marker in {class="hl-string">"trigger", class="hl-string">"automation", class="hl-string">"system"}


def extract_ticket_events(session: requests.Session, ticket: Dict[str, Any], last_update: str, user_cache: Dict[str, str], group_cache: Dict[str, str], seen: set) -> List[Dict[str, Any]]:
    events: List[Dict[str, Any]] = []
    ticket_id = ticket.get(class="hl-string">"id")
    audits = audit_events(session, ticket_id)
    audits.sort(key=lambda item: (str(item.get(class="hl-string">"created_at") or class="hl-string">""), str(item.get(class="hl-string">"id") or class="hl-string">"")))
    add_event(events, seen, ticket, class="hl-string">"Service Request Created", ticket.get(class="hl-string">"created_at"), last_update, user_cache, class="hl-string">"ticket_created")
    first_public_agent_reply = False
    first_ack = False
    for audit in audits:
        audit_time = audit.get(class="hl-string">"created_at")
        audit_id = str(audit.get(class="hl-string">"id") or audit_time)
        for event in audit.get(class="hl-string">"events", []):
            event_type = event.get(class="hl-string">"type")
            if event_type in {class="hl-string">"Comment", class="hl-string">"VoiceComment"} and is_public_comment(event):
                if not first_ack and is_automated_acknowledgment(event):
                    add_event(events, seen, ticket, class="hl-string">"Initial Acknowledgment Sent", audit_time, last_update, user_cache, audit_id + class="hl-string">":ack")
                    first_ack = True
                if not is_customer_actor(audit, ticket) and not first_public_agent_reply and not is_automated_acknowledgment(event):
                    add_event(events, seen, ticket, class="hl-string">"First Agent Public Reply Sent", audit_time, last_update, user_cache, audit_id + class="hl-string">":first_agent_reply")
                    first_public_agent_reply = True
                if is_customer_actor(audit, ticket):
                    add_event(events, seen, ticket, class="hl-string">"Customer Responded", audit_time, last_update, user_cache, audit_id + class="hl-string">":customer_reply")
            if event_type == class="hl-string">"Change":
                field = str(event.get(class="hl-string">"field_name") or event.get(class="hl-string">"field") or class="hl-string">"")
                previous = event.get(class="hl-string">"previous_value")
                value = event.get(class="hl-string">"value")
                if field in {class="hl-string">"type", class="hl-string">"priority", class="hl-string">"custom_fields"}:
                    add_event(events, seen, ticket, class="hl-string">"Request Categorized And Prioritized", audit_time, last_update, user_cache, audit_id + class="hl-string">":category_priority:" + field)
                if field in {class="hl-string">"assignee_id", class="hl-string">"assignee"} and value not in (None, class="hl-string">"", 0, class="hl-string">"0"):
                    add_event(events, seen, ticket, class="hl-string">"Request Assigned To Agent", audit_time, last_update, user_cache, audit_id + class="hl-string">":assignee")
                if field in {class="hl-string">"group_id", class="hl-string">"group"} and previous not in (None, class="hl-string">"", 0, class="hl-string">"0") and value not in (None, class="hl-string">"", 0, class="hl-string">"0") and str(previous) != str(value):
                    get_group_name(session, value, group_cache)
                    add_event(events, seen, ticket, class="hl-string">"Internal Escalation Triggered", audit_time, last_update, user_cache, audit_id + class="hl-string">":group")
                if field == class="hl-string">"status":
                    old_status = str(previous or class="hl-string">"").lower()
                    new_status = str(value or class="hl-string">"").lower()
                    if new_status == class="hl-string">"pending":
                        add_event(events, seen, ticket, class="hl-string">"Information Requested From Customer", audit_time, last_update, user_cache, audit_id + class="hl-string">":pending")
                    if new_status == class="hl-string">"solved":
                        add_event(events, seen, ticket, class="hl-string">"Service Request Resolved", audit_time, last_update, user_cache, audit_id + class="hl-string">":solved")
                    if old_status == class="hl-string">"solved" and new_status == class="hl-string">"open":
                        add_event(events, seen, ticket, class="hl-string">"Service Request Reopened", audit_time, last_update, user_cache, audit_id + class="hl-string">":reopened")
                    if new_status == class="hl-string">"closed":
                        add_event(events, seen, ticket, class="hl-string">"Service Request Closed", audit_time, last_update, user_cache, audit_id + class="hl-string">":closed")
                if field in {class="hl-string">"satisfaction_survey_sent", class="hl-string">"csat_survey_sent"} and str(value).lower() in {class="hl-string">"true", class="hl-string">"1", class="hl-string">"yes", class="hl-string">"sent"}:
                    add_event(events, seen, ticket, class="hl-string">"Satisfaction Survey Sent", audit_time, last_update, user_cache, audit_id + class="hl-string">":survey_sent")
                if field in {class="hl-string">"sla_breached", class="hl-string">"is_sla_breached"} and str(value).lower() in {class="hl-string">"true", class="hl-string">"1", class="hl-string">"yes"}:
                    row = base_row(ticket, class="hl-string">"SLA Breach Occurred", audit_time, last_update, user_cache)
                    row[class="hl-string">"IsSlaBreached"] = True
                    key = (str(ticket_id), class="hl-string">"SLA Breach Occurred", audit_id, str(audit_time))
                    if key not in seen:
                        seen.add(key)
                        events.append(row)
    try:
        satisfaction = api_get(session, fclass="hl-string">"/api/v2/tickets/{ticket_id}/satisfaction_rating.json").get(class="hl-string">"satisfaction_rating")
    except requests.HTTPError:
        satisfaction = None
    if satisfaction:
        add_event(events, seen, ticket, class="hl-string">"Satisfaction Rating Received", satisfaction.get(class="hl-string">"created_at") or satisfaction.get(class="hl-string">"updated_at"), last_update, user_cache, str(satisfaction.get(class="hl-string">"id") or class="hl-string">"rating"))
    return events


def validate_rows(rows: List[Dict[str, Any]]) -> None:
    activities = {
        class="hl-string">"Service Request Created",
        class="hl-string">"Initial Acknowledgment Sent",
        class="hl-string">"Request Categorized And Prioritized",
        class="hl-string">"Request Assigned To Agent",
        class="hl-string">"First Agent Public Reply Sent",
        class="hl-string">"Information Requested From Customer",
        class="hl-string">"Customer Responded",
        class="hl-string">"Internal Escalation Triggered",
        class="hl-string">"SLA Breach Occurred",
        class="hl-string">"Service Request Resolved",
        class="hl-string">"Service Request Reopened",
        class="hl-string">"Satisfaction Survey Sent",
        class="hl-string">"Satisfaction Rating Received",
        class="hl-string">"Service Request Closed",
    }
    missing_columns = [column for column in ALL_COLUMNS if column not in rows[0]] if rows else ALL_COLUMNS
    if missing_columns:
        fail(class="hl-string">"Missing output columns: " + class="hl-string">", ".join(missing_columns))
    invalid = [row for row in rows if not row.get(class="hl-string">"ServiceRequest") or not row.get(class="hl-string">"ActivityName") or not row.get(class="hl-string">"StartTime") or not row.get(class="hl-string">"SourceSystem") or not row.get(class="hl-string">"LastDataUpdate")]
    if invalid:
        fail(fclass="hl-string">"{len(invalid)} rows are missing required values")
    unexpected = sorted({row[class="hl-string">"ActivityName"] for row in rows} - activities)
    if unexpected:
        fail(class="hl-string">"Unexpected activity names: " + class="hl-string">", ".join(unexpected))


def main() -> None:
    global session
    if ZENDESK_SUBDOMAIN.startswith(class="hl-string">"[") or ZENDESK_EMAIL.startswith(class="hl-string">"[") or ZENDESK_API_TOKEN.startswith(class="hl-string">"[") or START_TIME.startswith(class="hl-string">"["):
        fail(class="hl-string">"Configure ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN, and START_TIME")
    start_time = parse_start_time(START_TIME)
    session = requests.Session()
    session.auth = (fclass="hl-string">"{ZENDESK_EMAIL}/token", ZENDESK_API_TOKEN)
    session.headers.update({class="hl-string">"Accept": class="hl-string">"application/json"})
    last_update = now_utc()
    user_cache: Dict[str, str] = {}
    group_cache: Dict[str, str] = {}
    seen = set()
    rows: List[Dict[str, Any]] = []
    tickets = paged_get(session, class="hl-string">"/api/v2/incremental/tickets/cursor.json", {class="hl-string">"start_time": start_time})
    for ticket in tickets:
        rows.extend(extract_ticket_events(session, ticket, last_update, user_cache, group_cache, seen))
    rows.sort(key=lambda row: (row[class="hl-string">"ServiceRequest"], row[class="hl-string">"StartTime"], row[class="hl-string">"ActivityName"]))
    validate_rows(rows)
    with open(OUTPUT_FILE, class="hl-string">"w", newline=class="hl-string">"", encoding=class="hl-string">"utf-8") as output:
        writer = csv.DictWriter(output, fieldnames=ALL_COLUMNS, extrasaction=class="hl-string">"ignore")
        writer.writeheader()
        writer.writerows(rows)
    print(json.dumps({class="hl-string">"output_file": OUTPUT_FILE, class="hl-string">"rows": len(rows), class="hl-string">"last_data_update": last_update}))


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

Passaggi

Scelga una piattaforma ETL o ELT commerciale con un connettore supportato per Zendesk Support e verifichi che possa replicare ticket, eventi o audit dei ticket, commenti, utenti, gruppi, valutazioni di soddisfazione, dati SLA e risultati di trigger o automazioni disponibili nell’account Zendesk.
Crei un’integrazione API Zendesk usando il metodo di autenticazione approvato dall’organizzazione e supportato dal connettore scelto. Conceda solo le autorizzazioni di lettura necessarie per ticket, audit, commenti, utenti, gruppi, dati di soddisfazione e dati SLA. Conservi la stringa di connessione e le credenziali nell’archivio sicuro dello strumento.
Configuri il connettore per replicare gli oggetti Zendesk richiesti nel data warehouse di destinazione. Utilizzi gli oggetti di origine generati dal connettore, senza presupporre nomi fissi per tabelle o colonne. Nella documentazione del progetto, registri gli effettivi mapping di oggetti e campi come [Your table name] e [Your column name] quando il connettore usa nomi specifici dell’account.
Configuri l’estrazione incrementale usando il timestamp di aggiornamento, il cursore o il meccanismo di rilevamento delle modifiche supportato dal sistema di origine. Includa i dati storici del periodo di analisi selezionato, in genere da tre a sei mesi, e conservi l’identificativo dell’evento o dell’audit di origine per rimuovere i duplicati dovuti ad aggiornamenti ripetuti.
Crei un modello di staging normalizzato che unisca i record dei ticket con lo storico dei ticket, i record di audit o degli eventi, i commenti, gli utenti, i gruppi, le valutazioni di soddisfazione, i record SLA e gli eventuali record specifici del connettore relativi a trigger o automazioni. Quando disponibili, conservi il timestamp originale, l’identificativo del record di origine, l’identificativo del ticket, quello dell’autore, il tipo di evento, il nome del campo e i valori precedente e nuovo.
Crei una trasformazione degli eventi che generi una riga per ogni attività osservata esplicitamente. Mappi la creazione del ticket su Service Request Created, la prima risposta automatica idonea su Initial Acknowledgment Sent, le modifiche di tipo, categoria o priorità su Request Categorized And Prioritized, le modifiche dell’assegnatario su Request Assigned To Agent, la prima risposta pubblica idonea dell’operatore su First Agent Public Reply Sent, una transizione a pending associata a una richiesta di informazioni su Information Requested From Customer, una risposta del cliente su Customer Responded, le modifiche del gruppo su Internal Escalation Triggered, un record o evento di violazione SLA osservato su SLA Breach Occurred, le transizioni a solved su Service Request Resolved, le transizioni da solved a open causate da una risposta del cliente su Service Request Reopened, l’invio osservato di un sondaggio su Satisfaction Survey Sent, una valutazione inviata su Satisfaction Rating Received e una transizione definitiva a closed su Service Request Closed.
Non generi righe dedotte esclusivamente dallo stato corrente del ticket o dal tempo trascorso. Se la fonte non espone esplicitamente l’invio di un sondaggio, una violazione SLA, una conferma automatica o un evento di chiusura definitiva, ometta l’attività oppure utilizzi un flusso di dati separato e documentato che la registri esplicitamente. ProcessMind legge l’Event Log così com’è e non ricava gli eventi mancanti.
Rimuova i duplicati usando, quando disponibile, l’identificativo dell’evento o dell’audit di origine. Se non esiste un identificativo stabile, utilizzi una chiave composta documentata che includa ServiceRequest, ActivityName, StartTime, autore e identificativo del record di origine. Conservi le occorrenze legittime multiple di attività come Customer Responded, Information Requested From Customer, Internal Escalation Triggered e Service Request Reopened.
Compili le colonne obbligatorie ServiceRequest, ActivityName, StartTime, SourceSystem e LastDataUpdate. Aggiunga AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime e IsSlaBreached quando la fonte le fornisce. Utilizzi timestamp UTC uniformi e conservi la regola di conversione dal fuso orario di origine.
Esporti l’Event Log finale in formato CSV compatibile con ProcessMind oppure lo carichi nella posizione di acquisizione ProcessMind configurata. Verifichi che ogni occorrenza di attività sia rappresentata da una riga, che ServiceRequest identifichi il caso, che ActivityName contenga le etichette esatte delle attività, che StartTime sia un timestamp valido e che gli attributi obbligatori siano presenti in ogni riga dell’output, ove tecnicamente disponibili.

Configurazione

Connettore e ambito delle fonti: configuri lo strumento ETL o ELT commerciale scelto per Zendesk Support e selezioni gli oggetti di origine che espongono ticket, audit o eventi dei ticket, commenti, utenti, gruppi, valutazioni di soddisfazione, informazioni SLA e risultati di automazioni o trigger. I nomi degli oggetti variano in base al connettore e all’account: utilizzi il catalogo effettivo del connettore, senza presupporre nomi di tabelle.
Autenticazione e autorizzazioni: utilizzi l’opzione di autenticazione Zendesk approvata dall’organizzazione. Conceda l’accesso in lettura a tutti gli oggetti di origine selezionati, compresi gli eventi storici dei ticket e i dati di soddisfazione dei clienti. Verifichi che siano abilitati l’accesso API, le funzionalità richieste dal piano Zendesk e le eventuali licenze del connettore.
Intervallo di date: inizi con uno storico di tre-sei mesi. Estenda l’intervallo solo dopo aver verificato le quote API, la capacità del data warehouse, il volume degli eventi e la disponibilità dei record storici di audit, SLA e soddisfazione.
Caricamento incrementale: preferisca il cursore nativo del connettore, il rilevamento delle modifiche o il timestamp di aggiornamento del sistema di origine. Pianifichi un caricamento storico iniziale seguito da caricamenti incrementali frequenti. Includa un intervallo di recupero per commenti, valutazioni, esiti SLA e aggiornamenti dei ticket ricevuti in ritardo.
Filtri delle attività: limiti i record di origine al periodo di analisi selezionato e all’istanza Zendesk Support pertinente. Non filtri solo in base allo stato corrente del ticket, perché le attività storiche possono riguardare ticket il cui stato è cambiato.
Filtri per azienda o account: se il connettore espone più istanze Zendesk, brand, organizzazioni o unità aziendali, applichi il filtro aziendale o dell’account approvato usando il campo effettivo del connettore. Non presuma che esista un campo Company Code.
Mapping degli eventi: mantenga una tabella di mapping esplicita tra tipo di evento di origine, nome del campo, transizione di stato, tipo di autore e indicatore di automazione e i 14 valori richiesti di ActivityName. Generi una riga solo in presenza di prove esplicite nella fonte.
Identificazione della conferma: configuri il mapping di Initial Acknowledgment Sent solo quando la fonte identifica una prima risposta automatica o una notifica equivalente generata da un trigger. Non classifichi la risposta di un operatore come conferma automatica senza prove nella fonte.
Gestione SLA: utilizzi i record espliciti delle violazioni SLA o gli esiti SLA esposti dal connettore. Memorizzi la durata prevista in SlaTargetResolutionTime e l’esito della violazione in IsSlaBreached. Non calcoli una violazione in base al solo tempo trascorso, a meno che siano disponibili il calendario SLA, la policy, l’orario lavorativo e l’obiettivo, e che il calcolo sia documentato.
Prestazioni: limiti il caricamento iniziale in base alle date, selezioni solo le colonne necessarie, utilizzi la replica incrementale, abiliti il partizionamento o il clustering del data warehouse su ServiceRequest e StartTime, se supportati, e materializzi il modello normalizzato degli eventi dopo l’acquisizione dei dati grezzi. Eviti di eseguire ripetutamente scansioni dell’intero storico dei ticket.
Qualità dei dati: conservi gli identificativi e i timestamp di origine, normalizzi i timestamp in UTC, uniformi i valori booleani e mantenga i valori null quando la fonte non fornisce un attributo. Non sostituisca i dati mancanti relativi a operatori, categorie, priorità, SLA o canali con valori inventati.
Timestamp di aggiornamento: imposti LastDataUpdate sul timestamp del completamento dell’estrazione o della trasformazione, utilizzando un fuso orario e un formato uniformi in tutto l’Event Log.

a Query di esempio config

WITH source_data AS (
    SELECT
        [Your ticket identifier column] AS service_request,
        [Your source event identifier column] AS source_event_id,
        [Your event type column] AS source_event_type,
        [Your field name column] AS source_field_name,
        [Your previous value column] AS previous_value,
        [Your new value column] AS new_value,
        [Your event timestamp column] AS event_time,
        [Your actor type column] AS actor_type,
        [Your actor identifier column] AS actor_id,
        [Your assigned agent column] AS assigned_agent,
        [Your request type column] AS service_request_type,
        [Your priority column] AS priority,
        [Your communication channel column] AS communication_channel,
        [Your SLA target resolution time column] AS sla_target_resolution_time,
        [Your SLA breached flag column] AS is_sla_breached,
        [Your automated response flag column] AS is_automated_response,
        [Your public comment flag column] AS is_public_comment,
        [Your customer reply flag column] AS is_customer_reply,
        [Your survey sent flag column] AS is_survey_sent,
        [Your satisfaction rating column] AS satisfaction_rating,
        [Your source system value] AS source_system,
        [Your extraction timestamp column] AS last_data_update
    FROM [Your normalized Zendesk event source]
    WHERE [Your event timestamp column] >= [Your start date parameter]
      AND [Your event timestamp column] < [Your end date parameter]
),
activity_events AS (
    SELECT service_request, 'Service Request Created' AS activity_name, event_time AS start_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_created'
    UNION ALL
    SELECT service_request, 'Initial Acknowledgment Sent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'comment_added' AND is_automated_response = TRUE AND is_public_comment = TRUE
    UNION ALL
    SELECT service_request, 'Request Categorized And Prioritized', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_field_changed' AND source_field_name IN ('type', 'category', 'priority')
    UNION ALL
    SELECT service_request, 'Request Assigned To Agent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_field_changed' AND source_field_name IN ('assignee', 'assigned_agent')
    UNION ALL
    SELECT service_request, 'First Agent Public Reply Sent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'comment_added' AND is_public_comment = TRUE AND actor_type = 'agent' AND is_automated_response = FALSE
    UNION ALL
    SELECT service_request, 'Information Requested From Customer', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND new_value = 'pending'
    UNION ALL
    SELECT service_request, 'Customer Responded', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'comment_added' AND is_public_comment = TRUE AND is_customer_reply = TRUE
    UNION ALL
    SELECT service_request, 'Internal Escalation Triggered', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_field_changed' AND source_field_name IN ('group', 'assigned_group')
    UNION ALL
    SELECT service_request, 'SLA Breach Occurred', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, TRUE, source_system, last_data_update
    FROM source_data
    WHERE source_event_type IN ('sla_breach', 'sla_breached') OR is_sla_breached = TRUE
    UNION ALL
    SELECT service_request, 'Service Request Resolved', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND new_value = 'solved'
    UNION ALL
    SELECT service_request, 'Service Request Reopened', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND previous_value = 'solved' AND new_value = 'open' AND is_customer_reply = TRUE
    UNION ALL
    SELECT service_request, 'Satisfaction Survey Sent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type IN ('satisfaction_survey_sent', 'csat_survey_sent') OR is_survey_sent = TRUE
    UNION ALL
    SELECT service_request, 'Satisfaction Rating Received', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type IN ('satisfaction_rating_received', 'csat_rating_received') OR satisfaction_rating IS NOT NULL
    UNION ALL
    SELECT service_request, 'Service Request Closed', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND new_value = 'closed'
),
deduplicated_events AS (
    SELECT
        service_request,
        activity_name,
        start_time,
        assigned_agent,
        service_request_type,
        priority,
        communication_channel,
        sla_target_resolution_time,
        is_sla_breached,
        source_system,
        last_data_update,
        ROW_NUMBER() OVER (PARTITION BY service_request, activity_name, source_event_id ORDER BY start_time) AS event_rank
    FROM activity_events
)
SELECT
    service_request AS ServiceRequest,
    activity_name AS ActivityName,
    start_time AS StartTime,
    source_system AS SourceSystem,
    last_data_update AS LastDataUpdate,
    assigned_agent AS AssignedAgent,
    service_request_type AS ServiceRequestType,
    priority AS Priority,
    communication_channel AS CommunicationChannel,
    sla_target_resolution_time AS SlaTargetResolutionTime,
    is_sla_breached AS IsSlaBreached
FROM deduplicated_events
WHERE event_rank = 1
ORDER BY service_request, start_time, activity_name;

È pronto a iniziare?

Inizi oggi a ottimizzare il servizio clienti preparando i dati con questo template. Ottenga informazioni utili e migliori l’efficienza delle attività di Zendesk Support.

Torna alla guida al miglioramento Scarica il template

Elimini i colli di bottiglia nell’assistenza clienti e migliori subito il CSAT

Riduca i contatti ripetuti. Raggiunga un FCR dell’80% e migliori la soddisfazione dei clienti.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito

Il template dei dati per il servizio clienti

Il template dei dati per il servizio clienti

Attributi del servizio clienti

Attività del servizio clienti

Guide all’estrazione

Interfaccia di Zendesk Explore per la creazione di report e l’esportazione dei dati

Passaggi

Configurazione

a Query di esempio config

Script Python con l’API REST di Zendesk Support

Passaggi

Configurazione

a Query di esempio python

API Zendesk Incremental Exports per l’esportazione in blocco dei dati

Passaggi

Configurazione

a Query di esempio python

Connettore Zendesk per strumenti ETL di terze parti

Passaggi

Configurazione

a Query di esempio config

È pronto a iniziare?

Elimini i colli di bottiglia nell’assistenza clienti e migliori subito il CSAT

Il template dei dati per il servizio clienti

Il template dei dati per il servizio clienti

Attributi del servizio clienti

Attività del servizio clienti

Guide all’estrazione

Interfaccia di Zendesk Explore per la creazione di report e l’esportazione dei dati

Passaggi

Configurazione

a Query di esempio config

Script Python con l’API REST di Zendesk Support

Passaggi

Configurazione

a Query di esempio python

API Zendesk Incremental Exports per l’esportazione in blocco dei dati

Passaggi

Configurazione

a Query di esempio python

Connettore Zendesk per strumenti ETL di terze parti

Passaggi

Configurazione

a Query di esempio config

È pronto a iniziare?

Elimini i colli di bottiglia nell’assistenza clienti e migliori subito il CSAT

La Sua privacy è importante