> Continue verbetering > Incident Management > Zendesk Support > datatemplate

Uw `Incident Management-datatemplate`

Zendesk Support

Incident Management `Attributes` (24) Incident Management `Activities` (13) Extractie Guides (4)

Uw `Incident Management-datatemplate`

Deze template biedt een gestructureerd overzicht van de essentiële data die nodig is om uw incident management proces effectief te analyseren. Het schetst belangrijke attributes om te verzamelen, kritieke activiteiten om bij te houden, en bevat praktische leidraad voor het extraheren van deze data uit Zendesk Support. Gebruik deze om ervoor te zorgen dat uw process mining project start met een robuuste en complete dataset.

Aanbevolen attributen om vast te leggen
Belangrijkste activiteiten om te volgen voor procesmapping
Praktische handleiding voor data-extractie

Nieuw met event logs? Leer hoe je een process mining event log creëert.

Template downloaden

Incident Management `Attributes`

Dit zijn de aanbevolen data fields om in uw event log op te nemen voor een grondige analyse van uw incident management proces.

5 Verplicht 7 Aanbevolen 12 Optioneel

	Naam	Omschrijving
	Gebeurtenistijdstempel EventTimestamp	De exacte datum en tijd waarop de activiteit plaatsvond.
Omschrijving Deze timestamp registreert het exacte moment waarop een event plaatsvond in de incidentlifecycle, zoals wanneer een opmerking werd toegevoegd of de status werd gewijzigd. Het biedt de chronologische volgorde voor alle activiteiten binnen een case. Deze attribute is fundamenteel voor elke tijdsgebaseerde process mining analyse. Het wordt gebruikt om doorlooptijden tussen activiteiten te berekenen, wachttijden te identificeren, de totale case duration te meten en procesprestaties over verschillende tijdsperioden te analyseren. Nauwkeurige timestamps zijn essentieel voor het creëren van een geanimeerde procesmap die de stroom van cases over tijd toont en voor het bouwen van performance dashboards die KPI's zoals de gemiddelde oplossingstijd bijhouden. Het belang Timestamps bieden de chronologische context voor alle activiteiten, waardoor de berekening van duren, de identificatie van knelpunten en de analyse van procesprestaties over tijd mogelijk wordt. Vindplaats Zendesk Ticket Audits API (/api/v2/tickets/{ticket_id}/audits), veld created_at voor elke audit event. Voorbeelden 2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
	Incident ID TicketId	De unieke door het systeem gegenereerde identifier voor elk incident ticket.
Omschrijving De Incident ID is de primaire sleutel die elke incident case binnen Zendesk Support uniek identificeert. Het dient als de CaseId voor process mining, en koppelt alle gerelateerde activiteiten, statuswijzigingen en communicaties vanaf het moment dat het incident wordt aangemaakt totdat het wordt afgesloten. Bij analyse is deze ID cruciaal voor het reconstrueren van de end-to-end reis van elk incident. Het maakt de aggregatie van event data mogelijk om metrieken bij te houden zoals de totale oplossingstijd, het aantal overdrachten en de naleving van service level agreements voor individuele cases. Door events op deze ID te groeperen, kunnen analisten processtromen visualiseren, veelvoorkomende paden identificeren en afwijkingen van de standaardprocedure detecteren. Het belang Dit is de essentiële identifier die alle events verbindt met een enkel incident, waardoor het mogelijk wordt de gehele lifecycle te traceren en procesprestaties nauwkeurig te analyseren. Vindplaats Zendesk Tickets API (/api/v2/tickets/{id}), veld id. Voorbeelden 19428230113521941055
	Activiteit ActivityName	De naam van de bedrijfsactiviteit of event die op een specifiek punt in de incidentlifecycle plaatsvond.
Omschrijving Deze attribute beschrijft een specifieke stap of actie binnen het incident management proces, zoals 'Incident Aangemaakt', 'Ticket Toegewezen aan Agent' of 'Incident Opgelost'. Deze activiteiten zijn afgeleid van de event log of audit trail data van Zendesk, waar systeemwijzigingen worden vastgelegd. In process mining vormt de sequentie van deze activiteiten de process map, de basis voor alle analyse. Door de stroom van activiteiten te analyseren, kunnen organisaties de daadwerkelijke paden die incidenten afleggen ontdekken, knelpunten tussen stappen identificeren, herstelcycli meten (bijv. het heropenen van een opgelost ticket) en controleren op conformiteit met een gedefinieerd standaardproces. Het belang De sequentie van activiteiten definieert de processtroom, wat de kern is van process mining analyse voor het identificeren van inefficiënties, afwijkingen en verbetermogelijkheden. Vindplaats Afgeleid van gebeurtenissen in de Zendesk Ticket Audits API. Een wijzigingsgebeurtenis op het statusveld kan bijvoorbeeld worden toegewezen aan 'Status gewijzigd'. Voorbeelden Incident Aangemaakt`Ticket` Toegewezen aan `Agent`Status gewijzigd naar 'In afwachting'`Incident` opgelostIncident Gesloten
	Bronsysteem SourceSystem	Het systeem waaruit de incident data is geëxtraheerd.
Omschrijving Deze attribute identificeert de herkomst van de proces data. Voor deze weergave zou de waarde statisch zijn, bijvoorbeeld 'Zendesk Support', wat aangeeft dat alle events en attributes afkomstig waren van dat systeem. In omgevingen waar data van meerdere systemen wordt gecombineerd, is dit veld cruciaal voor het onderscheiden tussen verschillende databronnen. Het helpt de data-integriteit te waarborgen en maakt bron-specifieke analyse mogelijk, zoals het vergelijken van het incident management proces in Zendesk met een andere ITSM tool. Het belang Identificeert de oorsprong van de data, wat cruciaal is voor datagovernance en voor analyses die data uit meerdere bronsystemen combineren. Vindplaats Statische waarde ingesteld tijdens datatransformatie om de dataherkomst te identificeren. Voorbeelden Zendesk SupportZendesk
	Laatste data-update LastDataUpdate	De timestamp die aangeeft wanneer de data voor dit proces voor het laatst is ververst.
Omschrijving Deze attribute registreert de datum en tijd van de meest recente data-extractie of -update uit het bronsysteem. Het is doorgaans een enkele waarde die wordt toegepast op de gehele dataset van een gegeven refresh-cyclus. Deze informatie is essentieel voor datagovernance en voor gebruikers van de process mining analyse. Het biedt context over de actualiteit van de data, waardoor analisten begrijpen of zij de meest recente beschikbare informatie bekijken. Dit is bijzonder belangrijk voor het monitoren van operationele prestaties en het nemen van tijdige beslissingen op basis van de analyse. Het belang Biedt cruciale context over de actualiteit van de data, zodat gebruikers begrijpen hoe recent de analyse is en wanneer de data voor het laatst is opgehaald. Vindplaats Timestamp gegenereerd door het ETL/data pipeline proces na voltooiing van de data refresh. Voorbeelden 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Eindtijd van het event EventEndTime	De timestamp waarop een activiteit is afgerond.
Omschrijving De Event End Time markeert de conclusie van een activiteit. In event log data wordt de eindtijd van de ene activiteit vaak afgeleid als de starttijd van de volgende activiteit in de sequentie voor die case. Voor de allerlaatste activiteit in een case kan de eindtijd hetzelfde zijn als de starttijd. Deze attribute is essentieel voor het berekenen van de duur van individuele activiteiten (ProcessingTime) en de wachttijd tussen activiteiten. Deze informatie vormt de basis voor knelpuntanalyse, waardoor analisten niet alleen kunnen zien hoe lang een stap duurt, maar ook hoe lang de case inactief was voordat die stap begon. Het belang Maakt de berekening van activiteitsduren en wachttijden mogelijk, wat fundamenteel is voor het uitvoeren van gedetailleerde knelpuntanalyse en het identificeren van procesvertragingen. Vindplaats Berekend als de starttijd van de daaropvolgende gebeurtenis binnen dezelfde case. De eindtijd van de laatste gebeurtenis kan gelijk zijn aan de starttijd of de afsluitingstijd van de case. Voorbeelden 2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
	Prioriteit TicketPriority	Het prioriteitsniveau dat aan het incident is toegewezen, zoals 'Laag', 'Normaal', 'Hoog' of 'Urgent'.
Omschrijving De prioriteit van een incident bepaalt de vereiste urgentie voor een reactie en oplossing. Het is een sleutelfactor in werkprioritering en resource-allocatie binnen het supportteam. Bij procesanalyse wordt prioriteit gebruikt om incidenten te segmenteren om hun processtromen en prestaties te vergelijken. Analisten kunnen bijvoorbeeld controleren of 'Urgent' incidenten daadwerkelijk sneller worden opgelost dan incidenten met 'Lage' prioriteit. Het wordt ook gebruikt om SLA compliance te monitoren, aangezien SLA's vaak worden gedefinieerd op basis van prioriteitsniveaus. De 'Priority Change Rate' KPI is afhankelijk van het bijhouden van wijzigingen in dit veld. Het belang Deze attribute is cruciaal voor het segmenteren van analyses, het evalueren van de effectiviteit van prioritering en het monitoren van SLA compliance voor verschillende urgentieniveaus. Vindplaats Zendesk Tickets API, veld priority. Wijzigingen worden vastgelegd in de Ticket Audits API. Voorbeelden lownormalhighurgent
	Rapportagekanaal Channel	Het kanaal via welk het incident initieel werd gemeld, zoals 'E-mail', 'Web', of 'API'.
Omschrijving Deze attribute legt de methode vast die door de eindgebruiker of het systeem is gebruikt om het incident ticket aan te maken. Het begrijpen van het kanaal is belangrijk voor het analyseren van incidentbronnen en het dienovereenkomstig aanpassen van het supportproces. Het analyseren van incidenten per kanaal kan verschillende patronen onthullen. Incidenten die via de telefoon zijn gemeld, hebben bijvoorbeeld kortere oplossingstijden dan die via e-mail. Deze informatie ondersteunt het 'Incident Throughput Volume' dashboard en helpt bij resource planning en kanaaloptimalisatie-inspanningen. Het belang Helpt bij het analyseren van incidentvolumes en procesprestaties per bron, waardoor kanaalspecifieke procesverbeteringen en resourceplanning mogelijk worden. Vindplaats Zendesk Tickets API, veld via.channel. Voorbeelden webe-mailapitelefoon
	SLA-Status SlaStatus	De huidige status van de Service Level Agreement (SLA) voor het incident.
Omschrijving Deze attribute geeft aan of een incident op koers ligt om zijn gedefinieerde SLA-targets te halen, deze al heeft geschonden, of dat de SLA-timers zijn gepauzeerd. Zendesk houdt SLA metrics automatisch bij op basis van geconfigureerde policies. Dit is een kritieke attribute voor het 'SLA Compliance Monitoring' dashboard. Het biedt een directe maatstaf voor prestaties ten opzichte van serviceverplichtingen. Door te analyseren wanneer en waarom SLA's worden geschonden, kunnen organisaties proceszwaktes identificeren en de servicebetrouwbaarheid verbeteren. Het ondersteunt direct de 'Incident SLA Adherence Rate' KPI. Het belang Meet direct de prestaties ten opzichte van serviceafspraken, waardoor analyse van SLA-schendingen en proactieve monitoring mogelijk is om compliance te verbeteren. Vindplaats Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), afgeleid van velden zoals sla_policy, breached_at, etc. Voorbeelden ActiefGepauzeerdOverschredenAfgehandeld
	Ticketstatus TicketStatus	De status van het incident ticket op het moment van de event, zoals 'Open', 'Pending' of 'Solved'.
Omschrijving Deze attribute weerspiegelt de status van het incident ticket op verschillende punten in de lifecycle. Standaard Zendesk statussen zijn onder meer new, open, pending, on-hold, solved en closed. Het bijhouden van wijzigingen in dit veld is een primaire manier om activiteiten voor process mining te genereren. Het analyseren van de ticketstatus is fundamenteel voor het begrijpen van het proces. Het helpt bij het identificeren hoeveel tijd incidenten in bepaalde staten doorbrengen, zoals 'Pending', wat vaak duidt op wachten op klantreactie. Het is ook cruciaal voor het definiëren van case-voltooiing en het berekenen van oplossingstijden. Het belang Het bijhouden van statuswijzigingen is essentieel voor het begrijpen van procesvoortgang, het identificeren van wachttijden en het definiëren van de start- en eindpunten van de incidentlifecycle. Vindplaats Zendesk Tickets API, veld status. Wijzigingen worden vastgelegd in de Ticket Audits API. Voorbeelden newopenpendingsolvedclosed
	Toegewezen agent Assignee	De individuele support agent die momenteel is toegewezen om het incident af te handelen.
Omschrijving Deze attribute identificeert de specifieke agent die op een bepaald moment verantwoordelijk is voor het incident. Wijzigingen in de toegewezene zijn kritieke events die een overdracht van werk van de ene persoon naar de andere betekenen. Het analyseren van de toegewezen agent helpt bij het begrijpen van de werkverdeling, individuele prestaties en samenwerkingspatronen. Het bijhouden van wijzigingen in dit veld is essentieel voor het berekenen van de 'Gemiddelde Overdrachten per Incident' KPI en het identificeren van situaties waarin incidenten frequent worden doorgestuurd, wat kan duiden op kennislacunes of inefficiënte routering. Het belang Identificeert de verantwoordelijke agent, wat workload-analyse en het bijhouden van overdrachten mogelijk maakt, wat cruciaal is voor het identificeren van procesinefficiënties. Vindplaats Zendesk Tickets API, veld assignee_id. Wijzigingen worden vastgelegd in de Ticket Audits API. Voorbeelden John SmithJane DoeService Desk Automatisering
	Toegewezen groep AssignedGroup	Het supportteam of de groep die momenteel aan het incident is toegewezen.
Omschrijving Deze attribute geeft aan welk team verantwoordelijk is voor het incident. Incidenten bewegen vaak tussen verschillende supporttiers of gespecialiseerde groepen, bijvoorbeeld van 'L1 Support' naar het 'Netwerkteam'. Dit is een kritieke dimensie voor het analyseren van procesoverdrachten en het identificeren van knelpunten. Door te monitoren hoe incidenten tussen groepen stromen, kunnen analisten inter-teamafhankelijkheden meten, wachttijden voor specifieke teams berekenen en routeringsregels optimaliseren. Het ondersteunt direct het 'Handoffs and Rework Analysis' dashboard. Het belang Houdt team ownership bij, wat essentieel is voor het analyseren van inter-team overdrachten, het identificeren van teamspecifieke knelpunten en het meten van wachttijden. Vindplaats Zendesk Tickets API, veld group_id. Wijzigingen worden vastgelegd in de Ticket Audits API. Voorbeelden L1 SupportL2 Network TeamL3 InfrastructureFacturatie
	`Aantal handoffs` HandoffCount	Het totale aantal keren dat een incident opnieuw is toegewezen aan een andere agent of groep.
Omschrijving Deze berekende metriek kwantificeert het aantal keren dat de verantwoordelijkheid voor een incident werd overgedragen. Elke wijziging in het Assignee- of AssignedGroup-veld verhoogt deze telling voor de case. Overdrachten zijn een veelvoorkomende bron van inefficiëntie en vertraging in incident management. Een hoog aantal overdrachten kan duiden op onduidelijke routeringsregels, kennislacunes in supportteams of overmatig complexe processen. Deze metriek is de basis voor de 'Gemiddelde Overdrachten per Incident' KPI en is cruciaal voor het 'Handoffs and Rework Analysis' dashboard. Het belang Kwantificeert procesfrictie veroorzaakt door overdrachten, en helpt routeringsinefficiënties en kennislacunes aan te wijzen die de oplossingstijden verlengen. Vindplaats Berekend door het aantal keren te tellen dat het AssignedGroup- of Assignee-veld is gewijzigd voor een incident. Voorbeelden 0135
	Bewerkingstijd ProcessingTime	De duur van een enkele activiteit, wat de actief bestede tijd aan een taak representeert.
Omschrijving Deze metriek meet de verstreken tijd vanaf het begin van een activiteit tot het einde. Het wordt berekend als het verschil tussen de EventEndTime en de EventTimestamp voor elke rij in de event log. Processing time, ook wel activiteitsduur genoemd, helpt onderscheid te maken tussen actieve werktijd en inactiviteit of wachttijd. In het 'Bottleneck Activities Overview' dashboard kunnen hoge gemiddelde processing times voor bepaalde activiteiten duiden op complexe, tijdrovende taken. Dit verschilt van wachttijd, die vertragingen tussen taken representeert. Het belang Meet de actieve werktijd voor specifieke activiteiten, wat helpt bij het identificeren van taken die inherent tijdrovend zijn en kandidaten zijn voor vereenvoudiging of automatisering. Vindplaats Berekend als het verschil tussen EventEndTime en EventTimestamp voor elke activiteit. Voorbeelden 30018003600
	Doorlooptijd dossier CaseDuration	De totale verstreken tijd vanaf de aanmaak van het incident tot de definitieve afsluiting.
Omschrijving Deze berekende metriek representeert de end-to-end doorlooptijd voor een enkel incident. Het wordt berekend door het verschil te nemen tussen de timestamp van de allereerste event (bijv. 'Incident Aangemaakt') en de allerlaatste event (bijv. 'Incident Afgesloten'). Case Duration is een primaire Key Performance Indicator (KPI) voor algehele procesefficiëntie. Het wordt veel gebruikt in dashboards om gemiddelde doorlooptijden weer te geven, langlopende cases te identificeren en trends over tijd te analyseren. Het biedt een hoogwaardige maatstaf voor hoe snel het proces incidenten kan afhandelen en oplossen. Het belang Dit is een kritieke KPI voor het meten van de algehele procesnelheid en het identificeren van factoren die bijdragen aan lange oplossingstijden. Vindplaats Berekend door het verschil te vinden tussen de timestamp van de laatste gebeurtenis en de eerste gebeurtenis voor elk Incident ID. Voorbeelden 25920060480086400
	Ernst Severity	Het niveau van impact dat het incident heeft op de bedrijfsvoering.
Omschrijving Ernst definieert de zakelijke impact van een incident, vaak in combinatie met prioriteit om de algehele urgentie te bepalen. Het wordt doorgaans geconfigureerd als een custom field in Zendesk. Het analyseren van de ernst helpt bij het begrijpen van de kritische aard van afgehandelde incidenten. Het is een belangrijke dimensie voor het segmenteren van data in dashboards zoals 'SLA Compliance Monitoring' en 'Prioritization Effectiveness Metrics'. Het vergelijken van processtromen voor verschillende ernstniveaus kan onthullen of incidenten met hoge ernst met de juiste snelheid en middelen worden afgehandeld. Het belang Geeft de bedrijfsimpact van een incident aan, waardoor analyse gericht op de meest kritieke problemen mogelijk is en ervoor wordt gezorgd dat deze efficiënt worden opgelost. Vindplaats Dit is doorgaans een custom field. Controleer de Ticket Fields configuratie in het Zendesk Admin Center. Voorbeelden 1 - Kritiek2 - Hoog3 - Gemiddeld4 - Laag
	Indiener Submitter	De eindgebruiker of het systeem dat het incident oorspronkelijk heeft gemeld.
Omschrijving Deze attribute identificeert de persoon of entiteit die het ticket heeft aangemaakt. Dit verschilt van de aanvrager, aangezien een agent een ticket kan aanmaken namens iemand anders. Bij analyse kan de submitter worden gebruikt om te begrijpen wie problemen meldt. In combinatie met organisatie data kan het helpen te identificeren of specifieke klanten of gebruikersgroepen een groot aantal incidenten ervaren. Dit kan leiden tot proactieve supportinitiatieven of trainingsinspanningen. Het belang Identificeert de bron van het incidentrapport, die kan worden geanalyseerd om patronen te vinden met betrekking tot specifieke gebruikers, afdelingen of geautomatiseerde systemen. Vindplaats Zendesk Tickets API, veld submitter_id. Voorbeelden alice.jones@example.combob.williams@example.comSysteemmonitor
	Is `First Contact Resolution` IsFirstContactResolution	Een booleaanse vlag die 'true' is als het incident werd opgelost door de eerst toegewezen agent of groep zonder overdrachten.
Omschrijving First Contact Resolution (FCR) is een kritieke metric voor de efficiëntie van het supportcentrum en klanttevredenheid. Dit berekende attribuut markeert incidenten die zijn opgelost zonder te zijn toegewezen aan een andere agent of team. De logica controleert doorgaans of het ticket een 'Solved'-status bereikte terwijl het nog steeds was toegewezen aan de initiële agent en groep. In process mining maakt dit de directe berekening van het FCR-percentage mogelijk en het vergelijken van de procespaden van FCR-incidenten versus die welke escalatie vereisten, wat helpt bij het identificeren van kansen om de eerstelijns support te versterken. Het belang Meet direct de efficiëntie van het initiële supportcontactpunt en helpt kansen te identificeren om de oplossing eerder in het proces te verschuiven. Vindplaats Berekende booleaanse vlag. True als de ticketstatus 'solved' of 'closed' is en er gedurende de levenscyclus van het incident slechts één unieke toegewezen persoon of groep was. Voorbeelden truefalse
	Is Geautomatiseerd IsAutomated	Een booleaanse vlag die aangeeft of een activiteit werd uitgevoerd door een geautomatiseerd systeem of een menselijke agent.
Omschrijving Deze afgeleide attribute helpt onderscheid te maken tussen events die worden uitgevoerd door menselijke gebruikers en die welke worden uitgevoerd door systeemautomatiseringen, triggers of API-integraties. Het wordt doorgaans bepaald door te controleren of de auteur van een event een bekende systeemgebruiker is. Het begrijpen van het automatiseringsniveau is cruciaal voor moderne procesanalyse. Het helpt bij het evalueren van de effectiviteit van automatiseringsregels, het identificeren van handmatige taken die geautomatiseerd kunnen worden, en het meten van de impact van automatisering op efficiëntie en oplossingstijden. Deze attribute kan worden gebruikt om de processtromen van geautomatiseerde versus handmatige activiteiten te vergelijken. Het belang Onderscheidt menselijke en systeemacties, wat essentieel is voor het analyseren van de impact van automatisering op procesefficiëntie en het identificeren van nieuwe automatiseringskansen. Vindplaats Afgeleid door te controleren of de auteur van de gebeurtenis (author_id in de Ticket Audits API) overeenkomt met een bekend systeem- of automatiseringsgebruiker. Voorbeelden truefalse
	Klantorganisatie Organization	De organisatie of het bedrijf waartoe de aanvrager van het incident behoort.
Omschrijving Deze attribute koppelt een incident aan de organisatie van de klant. Het is essentieel voor B2B supportomgevingen waar serviceniveaus en supportprocessen per klant kunnen variëren. Het analyseren van incidenten per organisatie stelt supportteams in staat om de klantgezondheid te monitoren, terugkerende problemen die specifieke klanten treffen te identificeren, en ervoor te zorgen dat contractuele verplichtingen worden nagekomen. Het is een belangrijke dimensie voor het filteren van dashboards en rapporten om een klantgericht beeld van de prestaties te bieden. Het belang Maakt klantspecifieke analyse mogelijk, helpt bij het monitoren van serviceniveaus, het identificeren van trends voor belangrijke accounts en het effectief beheren van klantrelaties. Vindplaats Zendesk Tickets API, veld organization_id. Voorbeelden Global Tech Inc.Innoveer oplossingenData Corp
	Oorzaakcategorie RootCauseCategory	De hoofdcategorie van de onderliggende grondoorzaak van het incident.
Omschrijving Deze attribute wordt gebruikt om de fundamentele reden te classificeren waarom een incident heeft plaatsgevonden. Het wordt doorgaans vastgelegd tegen het einde van de incidentlifecycle, vaak als onderdeel van een post-mortem of problem management proces, en opgeslagen in een custom field. Deze data is essentieel voor het 'Root Cause Identification Accuracy' dashboard en de 'RCA Coverage' KPI. Het analyseren van incidenten op grondoorzaak helpt bij het identificeren van terugkerende problemen, en stuurt inspanningen om permanente oplossingen te implementeren en toekomstige incidentvolume te verminderen. Het verschuift de focus van reactief brandjes blussen naar proactieve probleempreventie. Het belang Maakt proactief probleembeheer mogelijk door incidentoorzaken te categoriseren, wat helpt bij het identificeren van trends en het voorkomen van toekomstige voorvallen. Vindplaats Dit is doorgaans een custom ticket field. Controleer de Ticket Fields configuratie in het Zendesk Admin Center. Voorbeelden `Software Bug`HardwarestoringGebruikersfoutNetwerkstoring
	Tags Tags	Een lijst met tags die zijn toegepast op het incident voor categorisering en context.
Omschrijving Tags zijn flexibele labels die aan tickets kunnen worden toegevoegd om extra context te bieden of te helpen bij categorisatie en routering. Ze kunnen handmatig door agents worden toegevoegd of automatisch via triggers en automations. Tags zijn een rijke bron van data voor process mining analyse. Ze kunnen worden gebruikt om fijnmazige segmenten voor analyse te creëren, zoals het filteren op incidenten gerelateerd aan een specifieke productlancering ('launch_q4') of een bekende storing ('outage_20231027'). Deze flexibiliteit maakt diepgaande onderzoeken mogelijk die verder gaan dan standaard ticketvelden. Het belang Biedt een flexibele manier om incidenten te categoriseren en te filteren, waardoor gedetailleerde, contextspecifieke analyse mogelijk is die met standaardvelden alleen wellicht niet haalbaar is. Vindplaats Zendesk Tickets API, veld tags. Voorbeelden vip_usernetwork_issueoutage_20231027billing_related
	Tevredenheidsbeoordeling SatisfactionRating	De tevredenheidsrating die door de eindgebruiker is gegeven nadat het incident was opgelost.
Omschrijving Deze attribute legt de feedback van de klant over hun supportervaring vast, doorgaans verzameld via een enquête nadat het ticket is opgelost. Veelvoorkomende ratings in Zendesk zijn 'Goed' of 'Slecht'. Hoewel geen directe maatstaf voor procesefficiëntie, bieden tevredenheidsratings een kritieke uitkomstmetriek. In process mining kan dit worden gecorreleerd met procesvarianten om te begrijpen welke oplossingstrajecten leiden tot hogere klanttevredenheid. Krijgen incidenten met meer overdrachten bijvoorbeeld lagere ratings? Het belang Biedt een belangrijke uitkomstmetriek die kan worden gecorreleerd met proceskenmerken om te begrijpen hoe procesprestaties de gebruikerstevredenheid beïnvloeden. Vindplaats Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), veld satisfaction_rating.score. Voorbeelden goodbadaangebodenunoffered
	Tickettype TicketType	De classificatie van het ticket, zoals 'Incident', 'Problem', 'Question' of 'Task'.
Omschrijving Dit veld categoriseert het ticket op basis van de aard van de aanvraag. Het incident management proces richt zich specifiek op tickets waarvan het type 'Incident' is, wat een ongeplande onderbreking of vermindering van de kwaliteit van een IT-service representeert. Bij analyse wordt deze attribute primair gebruikt als filter om ervoor te zorgen dat alleen incidenten worden opgenomen in de procesweergave. Het kan ook worden gebruikt voor bredere ITSM-analyse om de processen voor het afhandelen van incidenten versus problemen of serviceaanvragen te vergelijken. Het belang Maakt het filteren van data mogelijk om specifiek te focussen op incidenten, waardoor de procesanalyse relevant is voor de incidentbeheerlevenscyclus. Vindplaats Zendesk Tickets API, veld type. Voorbeelden incidentproblemquestiontask

Verplicht Aanbevolen Optioneel

Incident Management `Activities`

Dit zijn de kritieke processtappen en mijlpalen die u in uw event log moet vastleggen voor nauwkeurige ontdekking en analyse.

6 Aanbevolen 7 Optioneel

	Activiteit	Omschrijving
	`Incident` opgelost	Deze belangrijke mijlpaal vindt plaats wanneer een agent een oplossing heeft geïmplementeerd en het ticket als 'solved' markeert. Dit is een expliciete actie, vastgelegd als een statuswijziging in de ticket audit log.
Het belang Dit is de primaire oplossingsactiviteit en een kritiek punt voor het meten van de time-to-resolution. De tijd tussen deze event en 'Incident Afgesloten' representeert de periode van gebruikersbevestiging of automatische afsluiting. Vindplaats Vastgelegd vanuit de ticket audit log via een 'Wijzigings'-gebeurtenis waarbij de nieuwe waarde van het 'status'-veld 'solved' wordt. Vastleggen Geïdentificeerd door een 'Wijzigings'-gebeurtenis voor het 'status'-veld naar 'solved'. Gebeurtenistype explicit
	`Ticket` Toegewezen aan `Agent`	Deze activiteit vindt plaats wanneer een ticket wordt toegewezen aan een specifieke agent voor afhandeling. Dit is een expliciete event die wordt vastgelegd in de audit history van het ticket en betekent dat een individu eigendom heeft genomen.
Het belang Deze mijlpaal is essentieel voor het meten van de tijd tot eerste toewijzing en vormt de basis voor het analyseren van overdrachten, herstelwerk en First Contact Resolution rates. Vindplaats Vastgelegd vanuit de ticket audit log wanneer het 'assignee_id'-veld wordt ingevuld of gewijzigd. De eerste toewijzing is een belangrijke mijlpaal voor KPI-berekening. Vastleggen Geïdentificeerd door een 'Wijzigings'-gebeurtenis voor het 'assignee_id'-veld in de ticket audit log. Gebeurtenistype explicit
	Incident Aangemaakt	Markeert het begin van de incidentlevenscyclus wanneer een nieuw ticket wordt aangemaakt in Zendesk. Deze gebeurtenis wordt expliciet vastgelegd via Zendesk's ticketcreatie-auditlog, dienend als startpunt voor elke case.
Het belang Dit is de primaire startactiviteit. Het analyseren van de tijd van deze event tot andere is cruciaal voor het meten van de totale ticket lifecycle duur en de initiële responstijden. Vindplaats Dit is een expliciete event vastgelegd in de Zendesk ticket audit logs. Elk nieuw ticket genereert een 'Create' event met een corresponderende timestamp. Vastleggen Direct vanuit de ticketcreatie-gebeurtenis in de auditlog. Gebeurtenistype explicit
	Incident Gesloten	Markeert het definitieve einde van de incidentlevenscyclus wanneer het ticket permanent wordt gesloten. In Zendesk gebeurt dit vaak automatisch na een ingestelde periode na het oplossen, en wordt vastgelegd als een definitieve statuswijziging.
Het belang Dit is de definitieve eindactiviteit voor het proces. De totale procesduur wordt berekend van 'Incident Aangemaakt' tot deze event, wat een end-to-end weergave van de doorlooptijd biedt. Vindplaats Vastgelegd vanuit de ticket audit log via een 'Wijzigings'-gebeurtenis waarbij de nieuwe waarde van het 'status'-veld 'closed' wordt. Vastleggen Geïdentificeerd door een 'Wijzigings'-gebeurtenis voor het 'status'-veld naar 'closed'. Gebeurtenistype explicit
	Status gewijzigd naar Open	Geeft aan dat een agent actief aan het incident is begonnen te werken. Deze activiteit wordt doorgaans afgeleid uit de wijziging van het 'status'-veld van het ticket van 'new' naar 'open', wat het begin van de onderzoeks- en diagnosefase markeert.
Het belang Deze event markeert de overgang van queuing naar actief werk. De duur die tickets in 'new' status doorbrengen voordat ze naar 'open' gaan, is een belangrijke metriek voor de initiële responstijd. Vindplaats Afgeleid uit de ticket audit log door een 'Wijzigings'-gebeurtenis te identificeren waarbij de nieuwe waarde van het 'status'-veld 'open' is en de vorige waarde 'new' was. Vastleggen Afgeleid uit een statusveld-wijziging van 'new' naar 'open'. Gebeurtenistype inferred
	Ticket Opnieuw Toegewezen	Treedt op wanneer het ticketbezit wordt overgedragen van de ene agent of groep naar de andere na de initiële toewijzing. Dit is een expliciete gebeurtenis die wordt bijgehouden in de audithistorie van het ticket.
Het belang Hertoezendingen zijn cruciaal voor het analyseren van overdrachten en herstelwerk. Een hoge frequentie van hertoezendingen wijst vaak op een onjuiste initiële routering, complexe problemen of knelpunten in het proces. Vindplaats Vastgelegd vanuit de ticket audit log door een 'Wijzigings'-gebeurtenis op het 'assignee_id'- of 'group_id'-veld te identificeren nadat het voor het eerst was ingevuld. Vastleggen Geïdentificeerd door een daaropvolgende 'Wijzigings'-gebeurtenis voor het 'assignee_id'- of 'group_id'-veld. Gebeurtenistype explicit
	`Prioriteit` Ingesteld	Het prioriteitsniveau van een incident (bijv. Laag, Normaal, Hoog, Urgent) wordt gedefinieerd. Dit wordt vastgelegd als een expliciete wijzigingsgebeurtenis en bepaalt de urgentie en de vereiste reactietijd voor het ticket.
Het belang Het bijhouden van wanneer en hoe prioriteit wordt ingesteld, is van vitaal belang voor het 'Prioritization Effectiveness Metrics' dashboard, en zorgt ervoor dat kritieke problemen snel worden aangepakt. Vindplaats Vastgelegd vanuit een 'Wijzigings'-gebeurtenis op het 'priority'-veld binnen de ticket audit log. Latere wijzigingen kunnen ook worden bijgehouden om de KPI voor het 'Prioriteitswijzigingspercentage' te meten. Vastleggen Geïdentificeerd door een 'Wijzigings'-gebeurtenis voor het 'priority'-veld in de ticket audit log. Gebeurtenistype explicit
	Gebruikerstevredenheid Beoordeeld	Representeert het moment waarop de eindgebruiker een tevredenheidsrating geeft voor de ontvangen support. Dit is een expliciete event die in Zendesk wordt vastgelegd nadat een ticket is opgelost.
Het belang Het analyseren van tevredenheidsscores biedt cruciale feedback over de prestaties van agenten en de effectiviteit van processen, waarbij procesmetrics worden gekoppeld aan klantresultaten. Vindplaats Vastgelegd vanuit de tevredenheidsscores data die aan het ticket gekoppeld is. Dit omvat doorgaans een score ('good' of 'bad') en een optionele opmerking. Vastleggen Gebeurtenis vastgelegd wanneer een tevredenheidsscore voor het ticket wordt ingediend. Gebeurtenistype explicit
	Interne Notitie Toegevoegd	Deze activiteit duidt op interne samenwerking, waarbij een agent een privénotitie aan het ticket toevoegt voor andere teamleden. Dit wordt expliciet vastgelegd wanneer een opmerking als niet-openbaar wordt gemarkeerd.
Het belang Het analyseren van interne notities kan inzichten verschaffen in complexe problemen die samenwerking vereisen, maar een overmatig aantal kan wijzen op kennishiaten of procesinefficiënties. Vindplaats Vastgelegd vanuit de ticket-opmerkingen data. Een opmerking wordt geïdentificeerd als een interne notitie wanneer het 'public'-attribuut 'false' is. Vastleggen Gebeurtenis vastgelegd wanneer een nieuwe opmerking met 'public: false' aan het ticket wordt toegevoegd. Gebeurtenistype explicit
	Openbaar Antwoord Verzonden	Representeert een communicatie die van een support agent naar de eindgebruiker is gestuurd. Dit is een expliciete event in Zendesk, vastgelegd telkens wanneer een openbare opmerking aan het ticket wordt toegevoegd.
Het belang Het bijhouden van openbare antwoorden is belangrijk voor het begrijpen van de communicatiefrequentie en kan een belangrijk onderdeel van de tijdlijn zijn bij het analyseren van vertragingen in gebruikersbevestigingen. Vindplaats Vastgelegd vanuit de ticket-opmerkingen data. Een opmerking wordt geïdentificeerd als openbaar wanneer het 'public'-attribuut 'true' is. Vastleggen Gebeurtenis vastgelegd wanneer een nieuwe opmerking met 'public: true' aan het ticket wordt toegevoegd. Gebeurtenistype explicit
	SLA-doelstelling overschreden	Markeert het moment dat een ticket niet heeft voldaan aan een gedefinieerde Service Level Agreement, zoals de eerste reactietijd of oplossingstijd. Deze gebeurtenis wordt berekend op basis van SLA-beleidsdefinities en ticket-update-timestamps.
Het belang Deze event ondersteunt direct de SLA compliance monitoring. Het identificeren van wanneer en waarom schendingen optreden is fundamenteel voor het verbeteren van de servicebetrouwbaarheid en het klantvertrouwen. Vindplaats Dit is een berekende event. Het kan worden afgeleid door de 'sla_policy_metrics' data die aan een ticket is gekoppeld te analyseren, met behulp van de 'breached_at' timestamp voor elke SLA-target. Vastleggen Afgeleid van de 'breached_at' timestamp binnen de SLA-metric data van het ticket. Gebeurtenistype calculated
	Status gewijzigd naar 'In afwachting'	Geeft aan dat het proces is gepauzeerd in afwachting van een reactie van de aanvrager. Deze gebeurtenis wordt afgeleid uit de wijziging van het 'status'-veld van het ticket naar 'pending'.
Het belang Deze activiteit is cruciaal voor het berekenen van de wachttijd voor gebruikersbevestiging. Lange duur in deze status kan de totale oplossingstijd aanzienlijk verhogen en communicatievertragingen benadrukken. Vindplaats Afgeleid uit de ticket audit log door een 'Wijzigings'-gebeurtenis te identificeren waarbij de nieuwe waarde van het 'status'-veld 'pending' is. Vastleggen Afgeleid uit een statusveld-wijziging naar 'pending'. Gebeurtenistype inferred
	Ticket Toegewezen aan Groep	Representeert de initiële routering of triage van een incident naar een specifieke supportgroep. Dit is doorgaans de eerste stap in het toewijzen van verantwoordelijkheid en wordt vastgelegd als een expliciete wijzigings-event in de audit history van het ticket.
Het belang Het bijhouden van groepstoewijzingen helpt bij het analyseren van de efficiëntie van het initiële triageproces en het identificeren van vertragingen voordat een ticket naar het juiste team wordt gerouteerd. Vindplaats Vastgelegd vanuit de ticket audit log telkens wanneer het 'group_id'-veld wordt ingesteld of gewijzigd. De eerste keer dat deze wijziging na creatie plaatsvindt, is de initiële toewijzing. Vastleggen Geïdentificeerd door een 'Wijzigings'-gebeurtenis voor het 'group_id'-veld in de ticket audit log. Gebeurtenistype explicit

Aanbevolen Optioneel

Extractie Guides

Hoe u uw data uit Zendesk Support haalt

Stappen

Access Zendesk Explore: Log in bij uw Zendesk Support-instantie met een gebruikersaccount dat rechten heeft om rapporten te creëren en te beheren in Zendesk Explore.
Create a New Report: Navigeer naar de Explore-module. Klik op het 'Rapporten'-icoon in de linkernavigatiebalk en klik vervolgens op de knop 'Nieuw rapport'.
Select the Dataset: In het venster 'Kies een dataset', selecteer de Support: Ticket updates [default] dataset. Deze dataset bevat het audit trail voor elke ticketwijziging, wat essentieel is voor het creëren van een event log.
Add Initial Attributes (Columns): Ga in de rapportbuilder naar de sectie 'Rijen'. Klik op 'Toevoegen' en selecteer de volgende attributen. Deze vormen de kolommen van uw event log: Ticket ID, Update - Timestamp, Ticket status, Assignee name, Ticket group, Ticket priority, Ticket channel, Changes - Field name, Changes - Previous value, Changes - New value, Comment public.
Create Calculated Attributes: Dit is de meest cruciale stap. Ga naar het 'Berekeningen'-menu (het bekerglas-icoon) en selecteer 'Standaard berekend attribuut'. Creëer de drie attributen die hieronder in de sectie 'Query' zijn gedefinieerd: ActivityName, SourceSystem en LastDataUpdate. U moet de opgegeven formules exact kopiëren.
Refine Report Columns: Voeg uw nieuw gecreëerde berekende attributen (ActivityName, SourceSystem, LastDataUpdate) toe aan de sectie 'Rijen'. U kunt nu de ruwe velden die werden gebruikt om ActivityName te creëren (Changes - Field name, Changes - Previous value, Changes - New value, Comment public) verwijderen om het overzicht op te schonen.
Add Report Filters: Ga naar de sectie 'Filters' en klik op 'Toevoegen'. Voeg een filter toe voor Update - Date en selecteer een passend datumbereik (bijv. de laatste 3 maanden). Voeg een ander filter toe op uw berekende attribuut ActivityName en sluit null-waarden uit om ticketupdates te verwijderen die niet overeenkomen met een gewenste activiteit.
Run and Review the Report: Zendesk Explore werkt het rapport automatisch bij terwijl u attributen en filters toevoegt. Controleer de datatabel om ervoor te zorgen dat de rijen en kolommen verschijnen zoals verwacht. Het rapport moet één rij per event tonen.
Export the Data to CSV: Zodra het rapport is afgerond, klikt u op de knop 'Exporteren' in de rechterbovenhoek en selecteert u 'CSV'. Zendesk genereert en downloadt het CSV-bestand.
Prepare for Upload: Open het geëxporteerde CSV-bestand. Hernoem de kolomheaders zodat ze overeenkomen met de vereiste attribuutnamen voor uw process mining tool (bijv. hernoem 'Ticket ID' naar TicketId, 'Update - Timestamp' naar EventTimestamp). Zorg ervoor dat het datumformaat voor timestamps ISO 8601-conform is. Het bestand is nu klaar voor upload.

Configuratie

Zendesk Dataset: Het rapport moet gebaseerd zijn op de Support: Ticket updates [default] dataset. Dit is de enige standaard dataset die het gedetailleerde audit trail biedt dat nodig is om het proces gebeurtenis voor gebeurtenis te reconstrueren.
Date Range Filtering: Het is cruciaal om een datumfilter toe te passen om het datavolume te beperken. Gebruik het Update - Date attribuut als uw primaire filter. Een bereik van 3-6 maanden aan data wordt doorgaans aanbevolen voor een initiële analyse.
Activity Filter: Na het creëren van het ActivityName berekende attribuut, moet u het rapport filteren om rijen uit te sluiten waar deze waarde null is. Dit verwijdert irrelevante ticketwijzigingen (bijv. systeemupdates, tagwijzigingen) uit uw event log.
Calculated Attributes: De logica van deze extractie is sterk afhankelijk van een standaard berekend attribuut om ruwe ticketveld-wijzigingen te vertalen naar leesbare activiteitsnamen. Precisie in de formule is essentieel.
Prerequisites: De gebruiker die het rapport uitvoert, heeft minimaal een 'Viewer'-rol nodig in Zendesk Explore. Om het rapport te maken en op te slaan, zijn 'Editor'- of 'Admin'-rechten vereist.

a Voorbeeldquery config

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

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

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

**3. Standard Calculated Attribute Formulas:**

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

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

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

Stappen

Prerequisites: Zorg ervoor dat u Python 3.6+ op uw systeem hebt geïnstalleerd, samen met de requests- en pandas-bibliotheken. U kunt deze installeren via pip: pip install requests pandas.
Generate Zendesk API Token: Log in bij uw Zendesk Support-instantie als beheerder. Navigeer naar Admin Center > Apps en integraties > APIs > Zendesk APIs. Onder de sectie "API Tokens" voegt u een nieuwe actieve API-token toe en slaat u de gegenereerde tokenreeks veilig op.
Configure the Python Script: Maak een nieuw Python-bestand (bijv. extract_zendesk_logs.py) en kopieer het meegeleverde script erin. Werk de placeholder-variabelen bovenaan het script bij: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL en ZENDESK_API_TOKEN met uw specifieke inloggegevens. Stel de START_TIMESTAMP in om het begin van uw gewenste data-extractieperiode te definiëren (een Unix epoch timestamp).
Understand API Endpoints: Het script gebruikt voornamelijk twee Zendesk API-endpoints. Het incremental/tickets/cursor.json-endpoint wordt gebruikt om efficiënt alle tickets op te halen die zijn bijgewerkt sinds de START_TIMESTAMP. Voor elk ticket roept het script vervolgens het tickets/{ticket_id}/audits.json-endpoint aan om een gedetailleerde geschiedenis van elke wijziging en gebeurtenis te verkrijgen.
Execute the Script: Voer het script uit vanuit uw terminal met het commando: python extract_zendesk_logs.py. Het script begint data op te halen van de Zendesk API.
Monitor Script Progress: Het script print het aantal verwerkte tickets naar de console, waardoor u de voortgang kunt monitoren. Afhankelijk van het datumbereik en het volume aan tickets, kan dit aanzienlijke tijd in beslag nemen.
Data Retrieval and Pagination: Het script verwerkt automatisch de API-paginatie. Het begint met de initiële ticket-export-URL en volgt de after_url die in elke API-respons wordt gegeven totdat alle tickets voor de periode zijn opgehaald.
Event Transformation: Voor elk ticket doorloopt het script de audithistorie. Het parseert elke auditgebeurtenis, en koppelt Zendesk's interne gebeurtenistypen (zoals Create, Change, Comment) aan de vereiste bedrijfsactiviteiten (zoals Incident Created, Status Changed to Open, Public Reply Sent).
Handling SLA Data: Het script bevat een speciale functie, get_sla_breach_events, om SLA metrics op te halen voor elk opgelost ticket. Dit is nodig omdat SLA-schendingen geen standaard gebeurtenissen zijn in het audit log. Deze functie doet een aanvullende API-aanroep om details over de toepassing van SLA-beleid te verkrijgen.
Generate the Event Log: Zodra alle tickets zijn verwerkt, compileert het script de geëxtraheerde gebeurtenissen in een pandas DataFrame en slaat het uiteindelijke event log op als een CSV-bestand met de naam zendesk_incident_event_log.csv in dezelfde map waar het script is uitgevoerd.
Prepare for Upload: Controleer het gegenereerde CSV-bestand op correctheid. Dit bestand heeft nu het vereiste formaat om direct in ProcessMind te worden geüpload voor analyse.

Configuratie

Zendesk API Credentials: U moet uw Zendesk-subdomein, het e-mailadres gekoppeld aan een admin- of agentaccount, en een geldige API-token opgeven. Bewaar deze inloggegevens veilig en codeer ze niet direct in versiebeheerde scripts voor productiegebruik.
Start Timestamp (START_TIMESTAMP): Deze integer-waarde bepaalt het startpunt voor de data-extractie. Het moet een Unix epoch timestamp zijn. Een aanbevolen startpunt is 3-6 maanden in het verleden om een significante hoeveelheid data te verzamelen zonder het systeem te overbelasten. U kunt een online converter gebruiken om de juiste timestamp voor een specifieke datum te verkrijgen.
API Rate Limiting: Het script doet talrijke API-aanroepen. Zendesk handhaaft rate limits, die per plan variëren. Hoewel het script functioneel is voor gemiddelde datavolumes, is het voor zeer grote omgevingen mogelijk nodig om time.sleep()-aanroepen toe te voegen binnen de loops om te voorkomen dat de rate limit wordt overschreden en een 429-fout optreedt.
Required Python Libraries: Het script is afhankelijk van de requests-bibliotheek voor API-aanroepen en de pandas-bibliotheek voor datamanipulatie en CSV-export. Zorg ervoor dat deze geïnstalleerd zijn in uw Python-omgeving.
User Permissions: Het gebruikersaccount gekoppeld aan de API-token moet voldoende rechten hebben om ticketdata te lezen, inclusief audits en ticket metrics.

a Voorbeeldquery python

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

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

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

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

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

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

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

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

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

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

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

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

    return all_events

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

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

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

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

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

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

Stappen

Prerequisites: Zorg ervoor dat u Python 3.6+ op uw systeem hebt geïnstalleerd, samen met de requests- en pandas-bibliotheken. U kunt deze installeren via pip: pip install requests pandas.
Generate Zendesk API Token: Log in bij uw Zendesk Support-instantie als beheerder. Navigeer naar Admin Center > Apps en integraties > APIs > Zendesk APIs. Onder de sectie "API Tokens" voegt u een nieuwe actieve API-token toe en slaat u de gegenereerde tokenreeks veilig op.
Configure the Python Script: Maak een nieuw Python-bestand (bijv. extract_zendesk_logs.py) en kopieer het meegeleverde script erin. Werk de placeholder-variabelen bovenaan het script bij: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL en ZENDESK_API_TOKEN met uw specifieke inloggegevens. Stel de START_TIMESTAMP in om het begin van uw gewenste data-extractieperiode te definiëren (een Unix epoch timestamp).
Understand API Endpoints: Het script gebruikt voornamelijk twee Zendesk API-endpoints. Het incremental/tickets/cursor.json-endpoint wordt gebruikt om efficiënt alle tickets op te halen die zijn bijgewerkt sinds de START_TIMESTAMP. Voor elk ticket roept het script vervolgens het tickets/{ticket_id}/audits.json-endpoint aan om een gedetailleerde geschiedenis van elke wijziging en gebeurtenis te verkrijgen.
Execute the Script: Voer het script uit vanuit uw terminal met het commando: python extract_zendesk_logs.py. Het script begint data op te halen van de Zendesk API.
Monitor Script Progress: Het script print het aantal verwerkte tickets naar de console, waardoor u de voortgang kunt monitoren. Afhankelijk van het datumbereik en het volume aan tickets, kan dit aanzienlijke tijd in beslag nemen.
Data Retrieval and Pagination: Het script verwerkt automatisch de API-paginatie. Het begint met de initiële ticket-export-URL en volgt de after_url die in elke API-respons wordt gegeven totdat alle tickets voor de periode zijn opgehaald.
Event Transformation: Voor elk ticket doorloopt het script de audithistorie. Het parseert elke auditgebeurtenis, en koppelt Zendesk's interne gebeurtenistypen (zoals Create, Change, Comment) aan de vereiste bedrijfsactiviteiten (zoals Incident Created, Status Changed to Open, Public Reply Sent).
Handling SLA Data: Het script bevat een speciale functie, get_sla_breach_events, om SLA metrics op te halen voor elk opgelost ticket. Dit is nodig omdat SLA-schendingen geen standaard gebeurtenissen zijn in het audit log. Deze functie doet een aanvullende API-aanroep om details over de toepassing van SLA-beleid te verkrijgen.
Generate the Event Log: Zodra alle tickets zijn verwerkt, compileert het script de geëxtraheerde gebeurtenissen in een pandas DataFrame en slaat het uiteindelijke event log op als een CSV-bestand met de naam zendesk_incident_event_log.csv in dezelfde map waar het script is uitgevoerd.
Prepare for Upload: Controleer het gegenereerde CSV-bestand op correctheid. Dit bestand heeft nu het vereiste formaat om direct in ProcessMind te worden geüpload voor analyse.

Configuratie

Zendesk API Credentials: U moet uw Zendesk-subdomein, het e-mailadres gekoppeld aan een admin- of agentaccount, en een geldige API-token opgeven. Bewaar deze inloggegevens veilig en codeer ze niet direct in versiebeheerde scripts voor productiegebruik.
Start Timestamp (START_TIMESTAMP): Deze integer-waarde bepaalt het startpunt voor de data-extractie. Het moet een Unix epoch timestamp zijn. Een aanbevolen startpunt is 3-6 maanden in het verleden om een significante hoeveelheid data te verzamelen zonder het systeem te overbelasten. U kunt een online converter gebruiken om de juiste timestamp voor een specifieke datum te verkrijgen.
API Rate Limiting: Het script doet talrijke API-aanroepen. Zendesk handhaaft rate limits, die per plan variëren. Hoewel het script functioneel is voor gemiddelde datavolumes, is het voor zeer grote omgevingen mogelijk nodig om time.sleep()-aanroepen toe te voegen binnen de loops om te voorkomen dat de rate limit wordt overschreden en een 429-fout optreedt.
Required Python Libraries: Het script is afhankelijk van de requests-bibliotheek voor API-aanroepen en de pandas-bibliotheek voor datamanipulatie en CSV-export. Zorg ervoor dat deze geïnstalleerd zijn in uw Python-omgeving.
User Permissions: Het gebruikersaccount gekoppeld aan de API-token moet voldoende rechten hebben om ticketdata te lezen, inclusief audits en ticket metrics.

a Voorbeeldquery python

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

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

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

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

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

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

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

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

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

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

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

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

    return all_events

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

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

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

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

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

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

Stappen

Access Zendesk Explore: Log in bij uw Zendesk Support-instantie met een gebruikersaccount dat rechten heeft om rapporten te creëren en te beheren in Zendesk Explore.
Create a New Report: Navigeer naar de Explore-module. Klik op het 'Rapporten'-icoon in de linkernavigatiebalk en klik vervolgens op de knop 'Nieuw rapport'.
Select the Dataset: In het venster 'Kies een dataset', selecteer de Support: Ticket updates [default] dataset. Deze dataset bevat het audit trail voor elke ticketwijziging, wat essentieel is voor het creëren van een event log.
Add Initial Attributes (Columns): Ga in de rapportbuilder naar de sectie 'Rijen'. Klik op 'Toevoegen' en selecteer de volgende attributen. Deze vormen de kolommen van uw event log: Ticket ID, Update - Timestamp, Ticket status, Assignee name, Ticket group, Ticket priority, Ticket channel, Changes - Field name, Changes - Previous value, Changes - New value, Comment public.
Create Calculated Attributes: Dit is de meest cruciale stap. Ga naar het 'Berekeningen'-menu (het bekerglas-icoon) en selecteer 'Standaard berekend attribuut'. Creëer de drie attributen die hieronder in de sectie 'Query' zijn gedefinieerd: ActivityName, SourceSystem en LastDataUpdate. U moet de opgegeven formules exact kopiëren.
Refine Report Columns: Voeg uw nieuw gecreëerde berekende attributen (ActivityName, SourceSystem, LastDataUpdate) toe aan de sectie 'Rijen'. U kunt nu de ruwe velden die werden gebruikt om ActivityName te creëren (Changes - Field name, Changes - Previous value, Changes - New value, Comment public) verwijderen om het overzicht op te schonen.
Add Report Filters: Ga naar de sectie 'Filters' en klik op 'Toevoegen'. Voeg een filter toe voor Update - Date en selecteer een passend datumbereik (bijv. de laatste 3 maanden). Voeg een ander filter toe op uw berekende attribuut ActivityName en sluit null-waarden uit om ticketupdates te verwijderen die niet overeenkomen met een gewenste activiteit.
Run and Review the Report: Zendesk Explore werkt het rapport automatisch bij terwijl u attributen en filters toevoegt. Controleer de datatabel om ervoor te zorgen dat de rijen en kolommen verschijnen zoals verwacht. Het rapport moet één rij per event tonen.
Export the Data to CSV: Zodra het rapport is afgerond, klikt u op de knop 'Exporteren' in de rechterbovenhoek en selecteert u 'CSV'. Zendesk genereert en downloadt het CSV-bestand.
Prepare for Upload: Open het geëxporteerde CSV-bestand. Hernoem de kolomheaders zodat ze overeenkomen met de vereiste attribuutnamen voor uw process mining tool (bijv. hernoem 'Ticket ID' naar TicketId, 'Update - Timestamp' naar EventTimestamp). Zorg ervoor dat het datumformaat voor timestamps ISO 8601-conform is. Het bestand is nu klaar voor upload.

Configuratie

Zendesk Dataset: Het rapport moet gebaseerd zijn op de Support: Ticket updates [default] dataset. Dit is de enige standaard dataset die het gedetailleerde audit trail biedt dat nodig is om het proces gebeurtenis voor gebeurtenis te reconstrueren.
Date Range Filtering: Het is cruciaal om een datumfilter toe te passen om het datavolume te beperken. Gebruik het Update - Date attribuut als uw primaire filter. Een bereik van 3-6 maanden aan data wordt doorgaans aanbevolen voor een initiële analyse.
Activity Filter: Na het creëren van het ActivityName berekende attribuut, moet u het rapport filteren om rijen uit te sluiten waar deze waarde null is. Dit verwijdert irrelevante ticketwijzigingen (bijv. systeemupdates, tagwijzigingen) uit uw event log.
Calculated Attributes: De logica van deze extractie is sterk afhankelijk van een standaard berekend attribuut om ruwe ticketveld-wijzigingen te vertalen naar leesbare activiteitsnamen. Precisie in de formule is essentieel.
Prerequisites: De gebruiker die het rapport uitvoert, heeft minimaal een 'Viewer'-rol nodig in Zendesk Explore. Om het rapport te maken en op te slaan, zijn 'Editor'- of 'Admin'-rechten vereist.

a Voorbeeldquery config

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

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

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

**3. Standard Calculated Attribute Formulas:**

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

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

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

Uw `Incident Management-datatemplate`

Uw `Incident Management-datatemplate`

Incident Management `Attributes`

Incident Management `Activities`

Extractie Guides

Zendesk Explore UI Rapport naar CSV Bestand Export

Stappen

Configuratie

a Voorbeeldquery config

Python Script via de Zendesk Support REST API

Stappen

Configuratie

a Voorbeeldquery python

Zendesk Incrementele Export API voor Bulk Data Sync

Stappen

Configuratie

a Voorbeeldquery python

Derden ETL Tool met Zendesk API Connector

Stappen

Configuratie

a Voorbeeldquery config

Klaar om te starten?

Optimaliseer Incident Management, Los Vandaag Nog Sneller Op

Uw Incident Management-datatemplate

Uw Incident Management-datatemplate

Incident Management Attributes

Incident Management Activities

Extractie Guides

Zendesk Explore UI Rapport naar CSV Bestand Export

Stappen

Configuratie

a Voorbeeldquery config

Python Script via de Zendesk Support REST API

Stappen

Configuratie

a Voorbeeldquery python

Zendesk Incrementele Export API voor Bulk Data Sync

Stappen

Configuratie

a Voorbeeldquery python

Derden ETL Tool met Zendesk API Connector

Stappen

Configuratie

a Voorbeeldquery config

Wij hechten veel waarde aan je privacy

Klaar om te starten?

Optimaliseer Incident Management, Los Vandaag Nog Sneller Op

Uw `Incident Management-datatemplate`

Uw `Incident Management-datatemplate`

Incident Management `Attributes`

Incident Management `Activities`