> Continue verbetering > Incidentbeheer > Zendesk Support > datatemplate

Je Incidentbeheer-datatemplate

Zendesk Support

Incidentbeheer Attributen (23) Incidentbeheer Activities (13) Extractiegidsen (4)

Je Incidentbeheer-datatemplate

Deze template biedt een gestructureerd overzicht van de data die nodig is om je incidentmanagementproces effectief te analyseren. Het schetst belangrijke attributen om te verzamelen, belangrijke activiteiten om bij te houden, en bevat praktische handvaten voor het extraheren van deze data uit Zendesk Support. Gebruik deze om ervoor te zorgen dat jew process mining-project start met een betrouwbare en complete dataset.

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

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

Template downloaden

Incidentbeheer Attributen

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

5 Verplicht 7 Aanbevolen 11 Optioneel

	Naam	Omschrijving
	Incident-ID TicketId	De unieke door het systeem gegenereerde kenmerk voor elk incident ticket.
Omschrijving De Incident-ID is de primary key 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 belangrijk voor het reconstrueren van de volledige procesgang van elk incident. Het maakt de aggregatie van gebeurtenis 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 gebeurtenissen op deze ID te groeperen, kunnen analysesten processtromen visualiseren, veelvoorkomende paden vinden en afwijkingen van de standaardprocedure detecteren. Het belang Dit is de essentiële kenmerk die alle gebeurtenissen verbindt met een enkel incident, waardoor het mogelijk wordt de gehele levenscyclus te traceren en procesprestaties nauwkeurig te analyseren. Vindplaats Zendesk Tickets API (/api/v2/tickets/{id}), veld id. Voorbeelden 19428230113521941055
	Tijdstempel EventTimestamp	De exacte datum en tijd waarop de activiteit plaatsvond.
Omschrijving Deze timestamp registreert het exacte moment waarop een gebeurtenis plaatsvond in de incidentlevenscyclus, zoals wanneer een opmerking werd toegevoegd of de status werd gewijzigd. Het biedt de chronologische volgorde voor alle activiteiten binnen een case. Dit attribuut is onmisbaar voor elke tijdsgebaseerde process mining-analyse. Het wordt gebruikt om doorlooptijden tussen activiteiten te berekenen, wachttijden te vinden, de totale case duur te meten en procesprestaties over verschillende tijdsperioden te analyseren. Nauwkeurige tijdstempels zijn belangrijk voor het creëren van een geanimeerde procesmap die de stroom van cases over tijd toont en voor het bouwen van prestaties 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 worden. Vindplaats Zendesk Ticket Audits API (/api/v2/tickets/{ticket_id}/audits), veld created_at voor elke audit gebeurtenis. Voorbeelden 2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
	Activiteit ActivityName	De naam van de bedrijfsactiviteit of gebeurtenis die op een specifiek punt in de incidentlevenscyclus plaatsvond.
Omschrijving Dit attribuut 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 volgorde van deze activiteiten de procesmap, de basis voor alle analyse. Door de stroom van activiteiten te analyseren, kunnen organisaties de daadwerkelijke paden die incidenten afleggen bekijken, knelpunten tussen stappen vinden, herstelcycli meten (bijv. het heropenen van een opgelost ticket) en controleren op conformiteit met een gedefinieerd standaardproces. Het belang De volgorde van activiteiten definieert de processtroom, wat de kern is van process mining-analyse voor het vinden van knelpunten, 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 incidentdata is opgehaald.
Omschrijving Dit attribuut identificeert de herkomst van de procesdata. Voor deze weergave zou de waarde statisch zijn, bijvoorbeeld 'Zendesk Support', wat aangeeft dat alle gebeurtenissen en attributen afkomstig waren van dat systeem. In omgevingen waar data van meerdere systemen wordt gecombineerd, is dit veld belangrijk 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 belangrijk is voor data-governance en voor analyses die data uit meerdere bronsystemen combineren. Vindplaats Statische waarde ingesteld tijdens datatransformatie om de dataherkomst te vinden. Voorbeelden Zendesk SupportZendesk
	Tijdstip van extractie LastDataUpdate	De timestamp die aangeeft wanneer de data voor dit proces voor het voor het laatst is bijgewerkt.
Omschrijving Dit attribuut 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 belangrijk voor data-governance en voor gebruikers van de process mining-analyse. Het biedt context over de relevantie van de data, waardoor analysesten 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 belangrijke context over de relevantie 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 pijplijn proces na voltooiing van de data refresh. Voorbeelden 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Eindtijd van het gebeurtenis EventEndTime	De timestamp waarop een activiteit is afgerond.
Omschrijving De Event End Time markeert de conclusie van een activiteit. In gebeurtenislog-data wordt de eindtijd van de ene activiteit vaak afgeleid als de starttijd van de volgende activiteit in de volgorde voor die case. Voor de allerlaatste activiteit in een case kan de eindtijd hetzelfde zijn als de starttijd. Dit attribuut is belangrijk voor het berekenen van de duur van individuele activiteiten (ProcessingTime) en de wachttijd tussen activiteiten. Deze Informatie vormt de basis voor knelpuntanalyse, waardoor analysesten 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 activiteitstijdsduur en wachttijden mogelijk, wat fundamenteel is voor het uitvoeren van gedetailleerde knelpuntanalyse en het vinden 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 toewijzing van middelen 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 Dit attribuut is belangrijk voor het segmenteren van analyses, het ewaarderen 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 eerste werd gemeld, zoals 'E-mail', 'Web', of 'API'.
Omschrijving Dit attribuut 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 zichtbaar maken. 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 bron planning en kanaaloptimalisatie-inspanningen. Het belang Helpt bij het analyseren van incidentvolumes en procesprestaties per bron, waardoor kanaalspecifieke procesverbeteringen en bronplanning mogelijk worden. Vindplaats Zendesk Tickets API, veld via.channel. Voorbeelden webemailapitelefoon
	SLA-Status SlaStatus	De huidige status van de Service Level Agreement (SLA) voor het incident.
Omschrijving Dit attribuut 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 meetwaarden automatisch bij op basis van geconfigureerde policies. Dit is een kritieke attribuut 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 vinden 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-overschrijdingen en proactieve monitoring mogelijk is om compliance te verbeteren. Vindplaats Zendesk Ticket Kengetallen API (/api/v2/ticket_meetwaarden.json), afgeleid van velden zoals sla_policy, breached_at, etc. Voorbeelden ActiefGepauzeerdOverschredenAfgehandeld
	Ticket Status TicketStatus	De status van het incident ticket op het moment van de gebeurtenis, zoals 'Open', 'Pending' of 'Solved'.
Omschrijving Dit attribuut weerspiegelt de status van het incident ticket op verschillende punten in de levenscyclus. 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 onmisbaar voor het begrijpen van het proces. Het helpt bij het vinden hoeveel tijd incidenten in bepaalde staten doorbrengen, zoals 'Pending', wat vaak duidt op wachten op klantreactie. Het is ook belangrijk voor het definiëren van case-voltooiing en het berekenen van oplossingstijden. Het belang Het bijhouden van statuswijzigingen is belangrijk voor het begrijpen van procesvoortgang, het vinden van wachttijden en het definiëren van de start- en eindpunten van de incidentlevenscyclus. 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 Dit attribuut identificeert de specifieke agent die op een bepaald moment verantwoordelijk is voor het incident. Wijzigingen in de toegewezene zijn kritieke gebeurtenissen die een overdracht van werk van de ene persoon naar de andere betekenen. Het analyseren van de toegewezen medewerker helpt bij het begrijpen van de werkverdeling, individuele prestaties en samenwerkingspatronen. Het bijhouden van wijzigingen in dit veld is belangrijk voor het berekenen van de 'Gemiddelde Overdrachten per Incident' KPI en het vinden 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 belangrijk is voor het vinden 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 Dit attribuut geeft aan welk team verantwoordelijk is voor het incident. Incidenten bewegen vaak tussen verschillende supportpakkets of gespecialiseerde groepen, bijvoorbeeld van 'L1 Support' naar het 'Netwerkteam'. Dit is een kritieke dimensie voor het analyseren van procesoverdrachten en het vinden van knelpunten. Door te monitoren hoe incidenten tussen groepen stromen, kunnen analysesten 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 belangrijk is voor het analyseren van inter-team overdrachten, het vinden 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 overdrachten 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 belangrijk voor het 'Handoffs and Rework Analysis' dashboard. Het belang Kwantificeert procesknelpunten 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
	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 gebeurtenis (bijv. 'Incident Aangemaakt') en de allerlaatste gebeurtenis (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 vinden 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 vinden 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 aangepast veld 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 Kengetallen'. Het vergelijken van processtromen voor verschillende ernstniveaus kan zichtbaar maken 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 aangepast veld. 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 Dit attribuut 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 vinden 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 voor 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 medewerker of groep zonder overdrachten.
Omschrijving First Contact Resolution (FCR) is een kritieke metriek 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 vinden van kansen om de eerstelijns support te versterken. Het belang Meet direct de efficiëntie van het initiële supportcontactpunt en helpt kansen te vinden 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 attribuut helpt onderscheid te maken tussen gebeurtenissen 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 gebeurtenis een bekende systeemgebruiker is. Het begrijpen van het automatiseringsniveau is belangrijk voor moderne procesanalyse. Het helpt bij het ewaarderen van de effectiviteit van automatiseringsregels, het vinden van handmatige taken die geautomatiseerd kunnen worden, en het meten van de impact van automatisering op efficiëntie en oplossingstijden. Dit attribuut kan worden gebruikt om de processtromen van geautomatiseerde versus handmatige activiteiten te vergelijken. Het belang Onderscheidt menselijke en systeemacties, wat belangrijk is voor het analyseren van de impact van automatisering op procesefficiëntie en het vinden 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 Dit attribuut koppelt een incident aan de organisatie van de klant. Het is belangrijk 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 vinden, 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 vinden van trends voor belangrijke accounts en het effectief beheren van klantrelaties. Vindplaats Zendesk Tickets API, veld organization_id. Voorbeelden Wereldwijd Tech Inc.Innoveer oplossingenData Corp
	Oorzaakcategorie RootCauseCategory	De hoofdcategorie van de onderliggende grondoorzaak van het incident.
Omschrijving Dit attribuut wordt gebruikt om de fundamentele reden te classificeren waarom een incident heeft plaatsgevonden. Het wordt doorgaans vastgelegd tegen het einde van de incidentlevenscyclus, vaak als onderdeel van een post-mortem of problem management proces, en opgeslagen in een aangepast veld. Deze gegevens zijn belangrijk voor het 'Root Cause Identification Accuracy' dashboard en de 'RCA Coverage' KPI. Het analyseren van incidenten op grondoorzaak helpt bij het vinden 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 vinden van trends en het voorkomen van toekomstige voorvallen. Vindplaats Dit is doorgaans een custom ticket veld. Controleer de Ticket Fields configuratie in het Zendesk Admin Center. Voorbeelden Software BugHardwarestoringGebruikersfoutNetwerkstoring
	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 medewerkers worden toegevoegd of automatisch via triggers en automatiserings. 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
	Tevredenheidsscore SatisfactionRating	De tevredenheidsrating die door de eindgebruiker is gegeven nadat het incident was opgelost.
Omschrijving Dit attribuut 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 Kengetallen API (/api/v2/ticket_meetwaarden.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 attribuut 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 incidentproblemquestiontaak

Verplicht Aanbevolen Optioneel

Incidentbeheer Activities

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

6 Aanbevolen 7 Optioneel

	Activiteit	Omschrijving
	`Ticket` Toegewezen aan `Agent`	Deze activiteit vindt plaats wanneer een ticket wordt toegewezen aan een specifieke agent voor afhandeling. Dit is een expliciete gebeurtenis die wordt vastgelegd in de audit history van het ticket en betekent dat een individu eigendom heeft genomen.
Het belang Deze mijlpaal is belangrijk 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 auditlog 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 auditlog. 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 gebeurtenis tot andere is belangrijk voor het meten van de totale ticket levenscyclus duur en de initiële responstijden. Vindplaats Dit is een expliciete gebeurtenis vastgelegd in de Zendesk ticket auditlogs. Elk nieuw ticket genereert een 'Create' gebeurtenis 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 gebeurtenis, wat een end-to-end weergave van de doorlooptijd biedt. Vindplaats Vastgelegd vanuit de ticket auditlog 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
	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 auditlog.
Het belang Dit is de primaire oplossingsactiviteit en een kritiek punt voor het meten van de time-to-resolution. De tijd tussen deze gebeurtenis en 'Incident Afgesloten' representeert de periode van gebruikersbevestiging of automatische afsluiting. Vindplaats Vastgelegd vanuit de ticket auditlog 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
	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 gebeurtenis 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 auditlog door een 'Wijzigings'-gebeurtenis te vinden 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 belangrijk 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 auditlog door een 'Wijzigings'-gebeurtenis op het 'assignee_id'- of 'group_id'-veld te vinden 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 belangrijk voor het 'Prioritization Effectiveness Kengetallen' dashboard, en zorgt ervoor dat kritieke problemen snel worden aangepakt. Vindplaats Vastgelegd vanuit een 'Wijzigings'-gebeurtenis op het 'priority'-veld binnen de ticket auditlog. 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 auditlog. Gebeurtenistype explicit
	Gebruikerstevredenheid Beoordeeld	Representeert het moment waarop de eindgebruiker een tevredenheidsrating geeft voor de ontvangen support. Dit is een expliciete gebeurtenis die in Zendesk wordt vastgelegd nadat een ticket is opgelost.
Het belang Het analyseren van tevredenheidsscores biedt belangrijke feedback over de prestaties van agenten en de effectiviteit van processen, waarbij procesmeetwaarden 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 gebeurtenis 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-tijdstempels.
Het belang Deze gebeurtenis ondersteunt direct de SLA-compliance monitoring. Het vinden van wanneer en waarom schendingen optreden is onmisbaar voor het verbeteren van de servicebetrouwbaarheid en het klantvertrouwen. Vindplaats Dit is een berekende gebeurtenis. Het kan worden afgeleid door de 'sla_policy_meetwaarden' 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-metriek 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 belangrijk 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 auditlog door een 'Wijzigings'-gebeurtenis te vinden 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-gebeurtenis 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 vinden van vertragingen voordat een ticket naar het juiste team wordt gerouteerd. Vindplaats Vastgelegd vanuit de ticket auditlog 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 auditlog. Gebeurtenistype explicit

Aanbevolen Optioneel

Extractiegidsen

Hoe u je 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 belangrijk is voor het creëren van een event log.
Add Initial Attributen (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 waarde, Changes - New waarde, Comment public.
Create Calculated Attributen: Dit is de meest belangrijke 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: ActiviteitNaam, Bronsysteem en LastDataUpdate. U moet de opgegeven formules exact kopiëren.
Refine Report Columns: Voeg uw nieuw gecreëerde berekende attributen (ActiviteitNaam, Bronsysteem, LastDataUpdate) toe aan de sectie 'Rijen'. U kunt nu de ruwe velden die werden gebruikt om ActiviteitNaam te creëren (Changes - Field name, Changes - Previous waarde, Changes - New waarde, 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 ActiviteitNaam 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 gebeurtenis 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 attributenamen voor uw process mining-tool (bijv. hernoem 'Ticket ID' naar TicketId, 'Update - Timestamp' naar EventTimestamp). Zorg ervoor dat het datumformaat voor tijdstempels 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 belangrijk 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.
Activiteit Filter: Na het creëren van het ActiviteitNaam 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 Attributen: 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 belangrijk.
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 'Bewerkenor'- 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 je 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 > API's > Zendesk API's. 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_gebeurtenissen, om SLA meetwaarden op te halen voor elk opgelost ticket. Dit is nodig omdat SLA-overschrijdingen geen standaard gebeurtenissen zijn in het auditlog. 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 opgehaalde gebeurtenissen in een pandas DataFrame en slaat het uiteindelijke event log op als een CSV-bestand met de naam zendesk_incident_gebeurtenis_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.
Starttijdstamp (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.
Gebruiker Permissions: Het gebruikersaccount gekoppeld aan de API-token moet voldoende rechten hebben om ticketdata te lezen, inclusief audits en ticket meetwaarden.

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 je 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 > API's > Zendesk API's. 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_gebeurtenissen, om SLA meetwaarden op te halen voor elk opgelost ticket. Dit is nodig omdat SLA-overschrijdingen geen standaard gebeurtenissen zijn in het auditlog. 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 opgehaalde gebeurtenissen in een pandas DataFrame en slaat het uiteindelijke event log op als een CSV-bestand met de naam zendesk_incident_gebeurtenis_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.
Starttijdstamp (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.
Gebruiker Permissions: Het gebruikersaccount gekoppeld aan de API-token moet voldoende rechten hebben om ticketdata te lezen, inclusief audits en ticket meetwaarden.

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 belangrijk is voor het creëren van een event log.
Add Initial Attributen (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 waarde, Changes - New waarde, Comment public.
Create Calculated Attributen: Dit is de meest belangrijke 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: ActiviteitNaam, Bronsysteem en LastDataUpdate. U moet de opgegeven formules exact kopiëren.
Refine Report Columns: Voeg uw nieuw gecreëerde berekende attributen (ActiviteitNaam, Bronsysteem, LastDataUpdate) toe aan de sectie 'Rijen'. U kunt nu de ruwe velden die werden gebruikt om ActiviteitNaam te creëren (Changes - Field name, Changes - Previous waarde, Changes - New waarde, 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 ActiviteitNaam 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 gebeurtenis 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 attributenamen voor uw process mining-tool (bijv. hernoem 'Ticket ID' naar TicketId, 'Update - Timestamp' naar EventTimestamp). Zorg ervoor dat het datumformaat voor tijdstempels 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 belangrijk 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.
Activiteit Filter: Na het creëren van het ActiviteitNaam 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 Attributen: 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 belangrijk.
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 'Bewerkenor'- 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()
```

Je Incidentbeheer-datatemplate

Je Incidentbeheer-datatemplate

Incidentbeheer Attributen

Incidentbeheer Activities

Extractiegidsen

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 Incidentbeheer, Los Vandaag Nog Sneller Op

Je Incidentbeheer-datatemplate

Je Incidentbeheer-datatemplate

Incidentbeheer Attributen

Incidentbeheer Activities

Extractiegidsen

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 Incidentbeheer, Los Vandaag Nog Sneller Op