> Continu verbeteren van processen > Incidentbeheer > Zendesk Support > Datatemplate

Datatemplate voor incidentbeheer

Zendesk Support

Attributen voor incidentbeheer(23) Activiteiten voor incidentbeheer(13) Extractiegidsen(4)

Datatemplate voor incidentbeheer

Deze template geeft een gestructureerd overzicht van de data die nodig is om het incidentbeheerproces goed te analyseren. Je vindt er de belangrijkste attributen om te verzamelen, de activiteiten om bij te houden en praktische aanwijzingen voor het ophalen van deze data uit Zendesk Support. Zo begin je je process mining-project met een volledige dataset.

Aanbevolen attributen om te verzamelen
Belangrijke activiteiten voor procesmapping
Praktische aanwijzingen voor data-extractie

Nieuw met event logs? Lees hoe je een event log voor process mining maakt.

Template downloaden

Attributen voor incidentbeheer

Dit zijn de aanbevolen datavelden voor je event log, zodat je het incidentbeheerproces grondig kunt analyseren.

5 Verplicht 7 Aanbevolen 11 Optioneel

	Naam	Beschrijving
	Incident-ID TicketId	De unieke identificatiecode die het systeem voor elk incidentticket aanmaakt.
Beschrijving Het incident-ID is de primaire sleutel waarmee elke incidentcase in Zendesk Support uniek wordt geïdentificeerd. Bij process mining dient het als CaseId en koppelt het alle bijbehorende activiteiten, statuswijzigingen en communicatie vanaf het aanmaken tot het sluiten van het incident. Deze ID is essentieel om het volledige verloop van elk incident te reconstrueren. Je kunt er gebeurtenisgegevens mee samenvoegen en maatstaven volgen, zoals de totale doorlooptijd tot oplossing, het aantal overdrachten en de naleving van service level agreements per case. Door gebeurtenissen op deze ID te groeperen, kunnen analisten processtromen visualiseren, veelvoorkomende routes herkennen en afwijkingen van de standaardprocedure opsporen. Waarom dit belangrijk is Deze identificatiecode koppelt alle gebeurtenissen aan één incident. Zo kun je het volledige verloop volgen en de procesprestaties nauwkeurig analyseren. Waar vind je dit? Zendesk Tickets API (/api/v2/tickets/{id}), veld id. Voorbeelden 19428230113521941055
	Timestamp van gebeurtenis EventTimestamp	De exacte datum en tijd waarop de activiteit plaatsvond.
Beschrijving Deze timestamp legt het exacte moment vast waarop een gebeurtenis in de levenscyclus van een incident plaatsvond, bijvoorbeeld wanneer een opmerking werd toegevoegd of de status veranderde. Hiermee bepaal je de chronologische volgorde van alle activiteiten binnen een case. Dit attribuut is nodig voor process mining-analyses op basis van tijd. Je gebruikt het om doorlooptijden tussen activiteiten te berekenen, wachttijden op te sporen, de totale duur van een case te meten en procesprestaties over verschillende perioden te analyseren. Nauwkeurige timestamps zijn essentieel voor een geanimeerde proceskaart die laat zien hoe cases zich in de tijd ontwikkelen en voor dashboards met KPI’s zoals de gemiddelde doorlooptijd tot oplossing. Waarom dit belangrijk is Timestamps geven alle activiteiten een chronologische volgorde. Daarmee kun je doorlooptijden berekenen, bottlenecks opsporen en procesprestaties in de tijd analyseren. Waar vind je dit? Zendesk Ticket Audits API (/api/v2/tickets/{ticket_id}/audits), veld created_at voor elke auditgebeurtenis. 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 bepaald moment in de levenscyclus van een incident plaatsvond.
Beschrijving Dit attribuut beschrijft een specifieke stap of handeling in het incidentbeheerproces, zoals ‘Incident aangemaakt’, ‘Ticket toegewezen aan agent’ of ‘Incident opgelost’. Deze activiteiten zijn afgeleid uit de event log- of auditspoorgegevens van Zendesk, waarin systeemwijzigingen worden vastgelegd. Bij process mining vormt de volgorde van activiteiten de proceskaart, de basis voor alle analyses. Door de activiteitenstroom te analyseren, kunnen organisaties ontdekken welke routes incidenten daadwerkelijk volgen, bottlenecks tussen stappen opsporen, herstelwerk meten, bijvoorbeeld wanneer een opgelost ticket opnieuw wordt geopend, en controleren of het proces overeenkomt met een vastgestelde standaard. Waarom dit belangrijk is De volgorde van activiteiten bepaalt de processtroom. Die vormt de kern van process mining-analyses waarmee je inefficiënties, afwijkingen en verbeterkansen opspoort. Waar vind je dit? Afgeleid uit gebeurtenissen in de Zendesk Ticket Audits API. Een Change-gebeurtenis voor het statusveld kan bijvoorbeeld worden gekoppeld aan ‘Status gewijzigd’. Voorbeelden Incident aangemaaktTicket toegewezen aan agentStatus gewijzigd naar In afwachtingIncident opgelostIncident gesloten
	Bronsysteem SourceSystem	Het systeem waaruit de incidentgegevens zijn gehaald.
Beschrijving Dit attribuut geeft aan waar de procesgegevens vandaan komen. In deze weergave is de waarde bijvoorbeeld altijd ‘Zendesk Support’. Dat betekent dat alle gebeurtenissen en attributen uit dat systeem komen. In omgevingen waar gegevens uit meerdere systemen worden gecombineerd, maakt dit veld onderscheid tussen de verschillende bronnen. Het helpt de data-integriteit te bewaken en analyses per bron uit te voeren, bijvoorbeeld door incidentbeheer in Zendesk te vergelijken met dat in een andere ITSM-tool. Waarom dit belangrijk is Geeft aan waar de data vandaan komt. Dat is belangrijk voor gegevensbeheer en voor analyses waarin data uit meerdere bronsystemen wordt gecombineerd. Waar vind je dit? Statische waarde die tijdens de datatransformatie wordt ingesteld om de herkomst van de data aan te geven. Voorbeelden Zendesk SupportZendesk
	Laatste data-update LastDataUpdate	De timestamp die aangeeft wanneer de data voor dit proces voor het laatst is bijgewerkt.
Beschrijving Dit attribuut registreert de datum en tijd van de meest recente data-extractie of update uit het bronsysteem. Meestal geldt één waarde voor de volledige dataset van een vernieuwingscyclus. Deze informatie is belangrijk voor het gegevensbeheer en voor gebruikers van de process mining-analyse. Je ziet eraan hoe actueel de data is en of je de meest recente beschikbare informatie bekijkt. Dat is vooral belangrijk om de prestaties van de bedrijfsvoering te bewaken en op tijd beslissingen te nemen op basis van de analyse. Waarom dit belangrijk is Geeft aan hoe actueel de data is en wanneer die voor het laatst uit de bron is opgehaald. Waar vind je dit? Timestamp die de ETL-/datapijplijn genereert wanneer de data-update is afgerond. Voorbeelden 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Eindtijd gebeurtenis EventEndTime	De timestamp waarop een activiteit is afgerond.
Beschrijving De eindtijd van een gebeurtenis geeft aan wanneer een activiteit is afgerond. In event log-data wordt de eindtijd vaak afgeleid van de starttijd van de volgende activiteit in dezelfde case. Voor de laatste activiteit in een case kan de eindtijd gelijk zijn aan de starttijd. Met dit attribuut bereken je de duur van afzonderlijke activiteiten (ProcessingTime) en de wachttijd tussen activiteiten. Die informatie vormt de basis voor bottleneckanalyse. Je ziet niet alleen hoelang een stap duurt, maar ook hoelang de case heeft stilgelegen voordat die stap begon. Waarom dit belangrijk is Maakt het mogelijk om de duur van activiteiten en wachttijden te berekenen. Dat is nodig voor een gedetailleerde bottleneckanalyse en om vertragingen in het proces te herkennen. Waar vind je dit? Berekend als de starttijd van de volgende gebeurtenis in dezelfde case. De eindtijd van de laatste gebeurtenis kan gelijk zijn aan de starttijd of aan het moment waarop de case wordt afgesloten. Voorbeelden 2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
	Meldingskanaal Channel	Het kanaal waarlangs het incident is gemeld, bijvoorbeeld ‘E-mail’, ‘Web’ of ‘API’.
Beschrijving Dit attribuut legt vast hoe de eindgebruiker of het systeem het incidentticket heeft aangemaakt. Inzicht in het kanaal helpt om te bepalen waar incidenten vandaan komen en het supportproces daarop af te stemmen. Een analyse per kanaal kan verschillen in het proces aan het licht brengen. Incidenten die telefonisch worden gemeld, zijn bijvoorbeeld soms sneller opgelost dan incidenten die per e-mail binnenkomen. Deze informatie ondersteunt het dashboard ‘Volume incidenten’ en helpt bij het plannen van middelen en het verbeteren van kanalen. Waarom dit belangrijk is Helpt om incidentvolumes en procesprestaties per bron te analyseren, zodat je processen en de inzet van middelen per kanaal kunt verbeteren. Waar vind je dit? Zendesk Tickets API, veld via.channel. Voorbeelden webe-mailapitelefoon
	Prioriteit TicketPriority	De prioriteit van het incident, bijvoorbeeld ‘Laag’, ‘Normaal’, ‘Hoog’ of ‘Urgent’.
Beschrijving De prioriteit van een incident bepaalt hoe snel er moet worden gereageerd en een oplossing moet worden gevonden. Dit is een belangrijke factor bij het verdelen van werk en middelen binnen het supportteam. Bij procesanalyse kun je incidenten op basis van prioriteit indelen en hun procesverloop en prestaties vergelijken. Zo kun je nagaan of urgente incidenten inderdaad sneller worden opgelost dan incidenten met een lage prioriteit. De prioriteit wordt ook gebruikt om SLA-compliance te bewaken, omdat SLA’s vaak per prioriteitsniveau zijn vastgesteld. Voor de KPI ‘Wijzigingspercentage prioriteit’ worden wijzigingen in dit veld bijgehouden. Waarom dit belangrijk is Met dit attribuut kun je analyses opdelen, de effectiviteit van prioritering beoordelen en SLA-compliance per urgentieniveau bewaken. Waar vind je dit? Zendesk Tickets API, veld priority. Wijzigingen worden vastgelegd in de Ticket Audits API. Voorbeelden laagnormaalhoogurgent
	SLA-status SlaStatus	De huidige status van de Service Level Agreement (SLA) voor het incident.
Beschrijving Dit attribuut geeft aan of een incident op koers ligt om de SLA-doelen te halen, deze al heeft overschreden of dat de SLA-timers zijn gepauzeerd. Zendesk houdt SLA-metrieken automatisch bij op basis van ingestelde beleidsregels. Dit attribuut is belangrijk voor het dashboard ‘SLA-compliance bewaken’. Het laat zien hoe de prestaties zich verhouden tot de serviceafspraken. Door te analyseren wanneer en waarom SLA’s worden overschreden, kunnen organisaties zwakke plekken in het proces herkennen en de betrouwbaarheid van de dienstverlening verbeteren. Het ondersteunt de KPI ‘Nalevingspercentage incident-SLA’. Waarom dit belangrijk is Meet hoe de prestaties zich verhouden tot de serviceafspraken. Zo kun je SLA-overschrijdingen analyseren en de compliance bewaken. Waar vind je dit? Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), afgeleid van velden zoals sla_policy, breached_at enzovoort. Voorbeelden ActiefGepauzeerdOverschredenVoldaan
	Ticketstatus TicketStatus	De status van het incidentticket op het moment van de gebeurtenis, bijvoorbeeld ‘Open’, ‘In afwachting’ of ‘Opgelost’.
Beschrijving Dit attribuut geeft de status van het incidentticket op verschillende momenten in de levenscyclus weer. De standaardstatussen in Zendesk zijn new, open, pending, on-hold, solved en closed. Wijzigingen in dit veld vormen een belangrijke bron voor het afleiden van activiteiten voor process mining. Analyse van de ticketstatus helpt je het proces te begrijpen. Je ziet hoeveel tijd incidenten in bepaalde statussen doorbrengen. De status ‘Pending’ betekent bijvoorbeeld vaak dat er op een reactie van de klant wordt gewacht. De status is ook belangrijk om te bepalen wanneer een case is afgerond en om de doorlooptijd tot oplossing te berekenen. Waarom dit belangrijk is Het bijhouden van statuswijzigingen is belangrijk om het verloop van het proces te begrijpen, wachttijden te herkennen en het begin en einde van de incidentlevenscyclus vast te stellen. Waar vind je dit? Zendesk Tickets API, veld status. Wijzigingen worden vastgelegd in de Ticket Audits API. Voorbeelden nieuwopenin afwachtingopgelostgesloten
	Toegewezen groep AssignedGroup	Het supportteam of de groep die op dit moment aan het incident is toegewezen.
Beschrijving Dit attribuut geeft aan welk team verantwoordelijk is voor het incident. Incidenten gaan vaak van het ene supportniveau of gespecialiseerde team naar het andere, bijvoorbeeld van ‘L1 Support’ naar het ‘Network Team’. Dit is een belangrijke dimensie om overdrachten tussen teams en bottlenecks te analyseren. Door te volgen hoe incidenten tussen groepen worden doorgegeven, kunnen analisten afhankelijkheden tussen teams meten, wachttijden per team berekenen en routeringsregels verbeteren. Dit attribuut ondersteunt het dashboard ‘Analyse van overdrachten en herhaalwerk’. Waarom dit belangrijk is Houdt bij welk team verantwoordelijk is. Zo kun je overdrachten tussen teams en bottlenecks per team analyseren en wachttijden meten. Waar vind je dit? Zendesk Tickets API, veld group_id. Wijzigingen worden vastgelegd in de Ticket Audits API. Voorbeelden L1 SupportL2 Network TeamL3 InfrastructureFacturering
	Toegewezen medewerker Assignee	De supportmedewerker die op dit moment aan het incident is toegewezen.
Beschrijving Dit attribuut geeft aan welke medewerker op een bepaald moment verantwoordelijk is voor het incident. Een wijziging van de toegewezen medewerker is een belangrijke gebeurtenis: het werk wordt overgedragen aan iemand anders. Met de toegewezen medewerker kun je de werkverdeling, individuele prestaties en samenwerking analyseren. Het bijhouden van wijzigingen in dit veld is nodig om de KPI ‘Gemiddeld aantal overdrachten per incident’ te berekenen en situaties te herkennen waarin incidenten vaak worden doorgegeven. Dat kan wijzen op kennislacunes of een inefficiënte routering. Waarom dit belangrijk is Geeft aan welke medewerker verantwoordelijk is. Zo kun je de werkverdeling en overdrachten analyseren en inefficiënties in het proces herkennen. Waar vind je dit? Zendesk Tickets API, veld assignee_id. Wijzigingen worden vastgelegd in de Ticket Audits API. Voorbeelden John SmithJane DoeServicedeskautomatisering
	Aantal overdrachten HandoffCount	Het totale aantal keren dat een incident aan een andere medewerker of groep is toegewezen.
Beschrijving Deze berekende metriek telt hoe vaak de verantwoordelijkheid voor een incident is overgedragen. Elke wijziging in het veld Assignee of AssignedGroup verhoogt de telling voor de case. Overdrachten leiden bij incidentbeheer vaak tot inefficiëntie en vertraging. Een hoog aantal overdrachten kan wijzen op onduidelijke routeringsregels, kennislacunes bij supportteams of onnodig ingewikkelde processen. Deze metriek vormt de basis voor de KPI ‘Gemiddeld aantal overdrachten per incident’ en is belangrijk voor het dashboard ‘Analyse van overdrachten en herhaalwerk’. Waarom dit belangrijk is Maakt zichtbaar hoeveel vertraging overdrachten veroorzaken. Zo kun je inefficiënte routering en kennislacunes opsporen die de doorlooptijd verlengen. Waar vind je dit? Berekend door te tellen hoe vaak het veld AssignedGroup of Assignee voor een incident is gewijzigd. Voorbeelden 0135
	Categorie hoofdoorzaak RootCauseCategory	De hoofdcategorie van de onderliggende oorzaak van het incident.
Beschrijving Met dit attribuut classificeer je de belangrijkste oorzaak van een incident. Deze wordt meestal aan het einde van de incidentlevenscyclus vastgelegd, bijvoorbeeld tijdens een evaluatie achteraf of als onderdeel van probleembeheer. Vaak staat de informatie in een aangepast veld. Deze data is belangrijk voor het dashboard ‘Nauwkeurigheid van oorzaakanalyse’ en de KPI ‘Dekking van oorzaakanalyse’. Door incidenten op oorzaak te analyseren, herken je terugkerende problemen. Dat helpt om blijvende oplossingen door te voeren en toekomstige incidenten te voorkomen. Zo verschuift de aandacht van brandjes blussen naar problemen voorkomen. Waarom dit belangrijk is Ondersteunt proactief probleembeheer. Door oorzaken van incidenten in te delen, kun je trends herkennen en nieuwe incidenten voorkomen. Waar vind je dit? Dit is meestal een aangepast ticketveld. Bekijk de configuratie van Ticket Fields in Zendesk Admin Center. Voorbeelden SoftwarefoutHardwarestoringGebruikersfoutNetwerkstoring
	Duur case CaseDuration	De totale tijd vanaf het aanmaken van het incident tot de definitieve afsluiting.
Beschrijving Deze berekende metriek geeft de totale doorlooptijd van één incident weer. Je berekent de duur door de timestamp van de eerste gebeurtenis, bijvoorbeeld ‘Incident aangemaakt’, af te trekken van die van de laatste gebeurtenis, bijvoorbeeld ‘Incident gesloten’. De duur van een case is een belangrijke KPI voor de algehele procesefficiëntie. Dashboards gebruiken deze metriek om gemiddelde doorlooptijden te tonen, langlopende cases te herkennen en trends in de tijd te analyseren. Zo krijg je op hoofdlijnen zicht op hoe snel het proces incidenten afhandelt en oplost. Waarom dit belangrijk is Deze KPI is belangrijk om de algehele snelheid van het proces te meten en factoren te herkennen die bijdragen aan lange doorlooptijden. Waar vind je dit? Berekend door voor elke Incident ID het verschil te bepalen tussen de timestamp van de laatste en de eerste gebeurtenis. Voorbeelden 25920060480086400
	Ernst Severity	De impact van het incident op de bedrijfsvoering.
Beschrijving De ernst geeft aan wat de impact van een incident op de bedrijfsvoering is. Vaak wordt deze samen met de prioriteit gebruikt om de totale urgentie te bepalen. Meestal stel je dit in als een aangepast veld in Zendesk. Met een analyse van de ernst zie je hoe zwaar de incidenten zijn die worden afgehandeld. Dit is een belangrijke dimensie voor het opdelen van data in dashboards zoals ‘SLA-compliance bewaken’ en ‘Metrieken voor effectieve prioritering’. Door procesverlopen voor verschillende ernstniveaus te vergelijken, kun je nagaan of ernstige incidenten snel genoeg worden afgehandeld en de juiste middelen krijgen. Waarom dit belangrijk is Geeft de impact van een incident op de bedrijfsvoering aan. Zo kun je de ernstigste problemen analyseren en zorgen dat ze efficiënt worden opgelost. Waar vind je dit? Dit is meestal een aangepast veld. Bekijk de configuratie van Ticket Fields in Zendesk Admin Center. Voorbeelden 1 - Kritiek2 - Hoog3 - Gemiddeld4 - Laag
	Indiener Submitter	De eindgebruiker of het systeem dat het incident oorspronkelijk heeft gemeld.
Beschrijving Dit attribuut geeft aan wie het ticket heeft aangemaakt. Dat is niet altijd de aanvrager: een medewerker kan bijvoorbeeld namens iemand anders een ticket aanmaken. Met de indiener kun je analyseren wie problemen meldt. In combinatie met organisatiegegevens helpt dit om te zien of bepaalde klanten of gebruikersgroepen veel incidenten melden. Dat kan aanleiding zijn voor proactieve support of training. Waarom dit belangrijk is Geeft aan waar de incidentmelding vandaan komt. Zo kun je patronen herkennen bij specifieke gebruikers, afdelingen of geautomatiseerde systemen. Waar vind je dit? Zendesk Tickets API, veld submitter_id. Voorbeelden alice.jones@example.combob.williams@example.comSysteemmonitor
	Is geautomatiseerd IsAutomated	Een booleaanse waarde die aangeeft of een activiteit is uitgevoerd door een geautomatiseerd systeem of een menselijke medewerker.
Beschrijving Met dit afgeleide attribuut kun je onderscheid maken tussen gebeurtenissen die door gebruikers zijn uitgevoerd en gebeurtenissen van systeemautomatiseringen, triggers of API-integraties. Meestal wordt hiervoor gecontroleerd of de auteur van een gebeurtenis een bekende systeemgebruiker is. Inzicht in de mate van automatisering is belangrijk voor procesanalyse. Je kunt beoordelen hoe goed automatiseringsregels werken, handmatige taken herkennen die geautomatiseerd kunnen worden en meten wat automatisering doet met de efficiëntie en doorlooptijden. Ook kun je procesverlopen met geautomatiseerde activiteiten vergelijken met die van handmatige activiteiten. Waarom dit belangrijk is Maakt onderscheid tussen acties van mensen en systemen. Zo kun je het effect van automatisering op de procesefficiëntie analyseren en nieuwe kansen voor automatisering herkennen. Waar vind je dit? Afgeleid door te controleren of de auteur van de gebeurtenis (author_id in de Ticket Audits API) overeenkomt met een bekende systeem- of automatiseringsgebruiker. Voorbeelden truefalse
	Klantorganisatie Organization	De organisatie of het bedrijf waartoe de aanvrager van het incident behoort.
Beschrijving Dit attribuut koppelt een incident aan de organisatie van de klant. Dat is belangrijk voor B2B-support, waar serviceniveaus en supportprocessen per klant kunnen verschillen. Door incidenten per organisatie te analyseren, kunnen supportteams de klantrelatie bewaken, terugkerende problemen bij specifieke klanten herkennen en controleren of contractuele afspraken worden nagekomen. Je kunt dit attribuut gebruiken om dashboards en rapporten te filteren en de prestaties vanuit het perspectief van de klant te bekijken. Waarom dit belangrijk is Maakt analyses per klant mogelijk. Zo kun je serviceniveaus bewaken, trends bij belangrijke klanten herkennen en klantrelaties goed beheren. Waar vind je dit? Zendesk Tickets API, veld organization_id. Voorbeelden Global Tech Inc.Innovate SolutionsData Corp
	Opgelost bij eerste contact IsFirstContactResolution	Een booleaanse waarde die waar is als de eerste toegewezen medewerker of groep het incident heeft opgelost zonder overdrachten.
Beschrijving Oplossing bij het eerste contact (FCR) is een belangrijke metriek voor de efficiëntie van een supportcentrum en de klanttevredenheid. Dit berekende attribuut markeert incidenten die zijn opgelost zonder ze aan een andere medewerker of een ander team toe te wijzen. Meestal controleert de logica of de ticketstatus ‘Opgelost’ werd terwijl het ticket nog aan de eerste medewerker en groep was toegewezen. Met process mining kun je het FCR-percentage berekenen en de procesroutes vergelijken van incidenten die bij het eerste contact zijn opgelost met incidenten waarvoor escalatie nodig was. Zo herken je kansen om eerstelijnssupport meer bevoegdheden te geven. Waarom dit belangrijk is Meet rechtstreeks hoe efficiënt het eerste supportcontact verloopt en helpt kansen te herkennen om incidenten eerder in het proces op te lossen. Waar vind je dit? Berekende booleaanse waarde. Waar als de ticketstatus ‘opgelost’ of ‘gesloten’ is en het incident gedurende de hele levenscyclus maar één unieke toegewezen medewerker of groep had. Voorbeelden truefalse
	Tags Tags	Een lijst met tags die aan het incident zijn toegevoegd voor categorisering en context.
Beschrijving Tags zijn flexibele labels die je aan tickets kunt toevoegen voor extra context, categorisering of routering. Medewerkers kunnen ze handmatig toevoegen, maar dat kan ook automatisch via triggers en automatiseringen. Tags leveren waardevolle data op voor process mining. Je kunt ze gebruiken om analyses nauwkeurig af te bakenen, bijvoorbeeld door incidenten rond een productlancering (‘launch_q4’) of een bekende storing (‘outage_20231027’) te filteren. Zo kun je ook onderzoek doen dat verder gaat dan de standaardticketvelden. Waarom dit belangrijk is Biedt een flexibele manier om incidenten in te delen en te filteren. Zo kun je analyses afstemmen op specifieke context die niet met alleen standaardvelden te onderzoeken is. Waar vind je dit? Zendesk Tickets API, veld tags. Voorbeelden vip_usernetwork_issueoutage_20231027billing_related
	Tevredenheidsscore SatisfactionRating	De tevredenheidsscore die de eindgebruiker geeft nadat het incident is opgelost.
Beschrijving Dit attribuut bevat de feedback van de klant over de supportervaring. Die wordt meestal verzameld via een enquête nadat het ticket is opgelost. Veelgebruikte scores in Zendesk zijn ‘Goed’ en ‘Slecht’. De tevredenheidsscore meet de procesefficiëntie niet rechtstreeks, maar geeft wel een belangrijke uitkomstmaat. Met process mining kun je de score vergelijken met procesvarianten en zien welke afhandelingsroutes tot meer klanttevredenheid leiden. Krijgen incidenten met meer overdrachten bijvoorbeeld lagere scores? Waarom dit belangrijk is Geeft een belangrijke uitkomstmaat die je kunt vergelijken met proceskenmerken. Zo zie je hoe de procesprestaties de gebruikerstevredenheid beïnvloeden. Waar vind je dit? Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), veld satisfaction_rating.score. Voorbeelden goedslechtaangebodenniet aangeboden
	Tickettype TicketType	De classificatie van het ticket, bijvoorbeeld ‘Incident’, ‘Probleem’, ‘Vraag’ of ‘Taak’.
Beschrijving Dit veld deelt tickets in op basis van het soort verzoek. Het incidentbeheerproces richt zich specifiek op tickets van het type ‘Incident’: een ongeplande onderbreking of kwaliteitsvermindering van een IT-dienst. Bij analyses gebruik je dit attribuut vooral als filter, zodat alleen incidenten in de procesweergave staan. Je kunt het ook gebruiken voor bredere ITSM-analyses, bijvoorbeeld om de afhandeling van incidenten te vergelijken met die van problemen of serviceverzoeken. Waarom dit belangrijk is Hiermee kun je de data filteren op incidenten, zodat de procesanalyse aansluit op de levenscyclus van incidentbeheer. Waar vind je dit? Zendesk Tickets API, veld type. Voorbeelden incidentprobleemvraagtaak

Verplicht Aanbevolen Optioneel

Activiteiten voor incidentbeheer

Leg deze belangrijke processtappen en mijlpalen vast in je event log voor een nauwkeurige ontdekking en analyse.

6 Aanbevolen 7 Optioneel

	Activiteit	Beschrijving
	Incident aangemaakt	Dit markeert het begin van de levenscyclus van een incident, wanneer in Zendesk een nieuw ticket wordt aangemaakt. De gebeurtenis staat expliciet in het auditlog voor ticketaanmaak van Zendesk en is het startpunt van elke case.
Waarom dit belangrijk is Dit is de eerste activiteit in het proces. De tijd tussen deze gebeurtenis en andere gebeurtenissen is belangrijk om de totale levenscyclus van een ticket en de eerste reactietijd te meten. Waar vind je dit? Deze gebeurtenis wordt expliciet vastgelegd in de auditlogs van Zendesk-tickets. Bij elk nieuw ticket hoort een ‘Create’-gebeurtenis met een bijbehorende timestamp. Vastleggen Rechtstreeks afkomstig uit de gebeurtenis voor het aanmaken van een ticket in het auditlog. Gebeurtenistype explicit
	Incident gesloten	Dit markeert het definitieve einde van de levenscyclus van een incident, wanneer het ticket permanent wordt gesloten. In Zendesk gebeurt dit vaak automatisch na een vaste periode vanaf het moment dat het ticket is opgelost. De afsluiting wordt vastgelegd als de laatste statuswijziging.
Waarom dit belangrijk is Dit is de definitieve eindactiviteit van het proces. De totale procesduur wordt berekend vanaf ‘Incident aangemaakt’ tot deze gebeurtenis. Zo krijg je zicht op de volledige doorlooptijd. Waar vind je dit? Afkomstig uit het auditlog van het ticket via een ‘Change’-gebeurtenis waarbij de nieuwe waarde van het veld ‘status’ ‘closed’ wordt. Vastleggen Herkenbaar aan een ‘Change’-gebeurtenis waarbij het veld ‘status’ de waarde ‘closed’ krijgt. Gebeurtenistype explicit
	Incident opgelost	Dit belangrijke moment vindt plaats wanneer een agent een oplossing heeft uitgevoerd en het ticket de status ‘solved’ krijgt. De statuswijziging wordt expliciet vastgelegd in het auditlog van het ticket.
Waarom dit belangrijk is Dit is de belangrijkste activiteit voor het oplossen van een incident en een belangrijk meetpunt voor de doorlooptijd tot oplossing. De tijd tussen deze gebeurtenis en ‘Incident gesloten’ is de periode waarin de gebruiker de oplossing bevestigt of het ticket automatisch wordt gesloten. Waar vind je dit? Afkomstig uit het auditlog van het ticket via een ‘Change’-gebeurtenis waarbij de nieuwe waarde van het veld ‘status’ ‘solved’ wordt. Vastleggen Herkenbaar aan een ‘Change’-gebeurtenis waarbij het veld ‘status’ de waarde ‘solved’ krijgt. Gebeurtenistype explicit
	Status gewijzigd naar Open	Dit geeft aan dat een agent actief aan het incident is gaan werken. Meestal wordt deze activiteit afgeleid uit een wijziging van het ticketveld ‘status’ van ‘new’ naar ‘open’. Daarmee begint de onderzoeks- en diagnosefase.
Waarom dit belangrijk is Deze gebeurtenis markeert de overgang van wachten naar actief werk. De tijd dat tickets de status ‘new’ hebben voordat ze naar ‘open’ gaan, is een belangrijke maatstaf voor de eerste reactietijd. Waar vind je dit? Afgeleid uit het auditlog van het ticket: een ‘Change’-gebeurtenis waarbij de nieuwe waarde van het veld ‘status’ ‘open’ is en de vorige waarde ‘new’ was. Vastleggen Afgeleid uit een statuswijziging van ‘new’ naar ‘open’. Gebeurtenistype inferred
	Ticket opnieuw toegewezen	Dit gebeurt wanneer de verantwoordelijkheid voor een ticket na de eerste toewijzing overgaat naar een andere agent of groep. De gebeurtenis wordt expliciet bijgehouden in de auditgeschiedenis van het ticket.
Waarom dit belangrijk is Opnieuw toewijzen is belangrijk bij het analyseren van overdrachten en herstelwerk. Veel nieuwe toewijzingen wijzen vaak op een verkeerde eerste routering, complexe problemen of bottlenecks in het proces. Waar vind je dit? Afkomstig uit het auditlog van het ticket. Hiervoor wordt gezocht naar een ‘Change’-gebeurtenis voor het veld ‘assignee_id’ of ‘group_id’ nadat het veld voor het eerst is ingevuld. Vastleggen Herkenbaar aan een volgende ‘Change’-gebeurtenis voor het veld ‘assignee_id’ of ‘group_id’. Gebeurtenistype explicit
	Ticket toegewezen aan agent	Deze activiteit vindt plaats wanneer een ticket aan een specifieke agent wordt toegewezen. De toewijzing wordt expliciet vastgelegd in de auditgeschiedenis van het ticket en geeft aan dat een medewerker de verantwoordelijkheid op zich neemt.
Waarom dit belangrijk is Dit moment is belangrijk om de tijd tot de eerste toewijzing te meten. Het vormt ook de basis voor analyses van overdrachten, herstelwerk en het percentage incidenten dat bij het eerste contact wordt opgelost. Waar vind je dit? Afkomstig uit het auditlog van het ticket wanneer het veld ‘assignee_id’ wordt ingevuld of gewijzigd. De eerste toewijzing is een belangrijk moment voor de berekening van KPI’s. Vastleggen Herkenbaar aan een ‘Change’-gebeurtenis voor het veld ‘assignee_id’ in het auditlog van het ticket. Gebeurtenistype explicit
	Gebruikerstevredenheid beoordeeld	Dit is het moment waarop de eindgebruiker de ontvangen ondersteuning beoordeelt. In Zendesk wordt deze gebeurtenis expliciet vastgelegd nadat een ticket is opgelost.
Waarom dit belangrijk is Analyse van tevredenheidsscores geeft belangrijke feedback over de prestaties van agents en de effectiviteit van het proces. Zo kun je procesmaatstaven koppelen aan resultaten voor klanten. Waar vind je dit? Afkomstig uit de tevredenheidsscoregegevens van het ticket. Deze bevatten meestal een score (‘good’ of ‘bad’) en eventueel een opmerking. Vastleggen Vastgelegd wanneer een tevredenheidsscore voor het ticket wordt ingediend. Gebeurtenistype explicit
	Interne notitie toegevoegd	Deze activiteit staat voor interne samenwerking: een agent voegt een privénotitie aan het ticket toe voor andere teamleden. Dit wordt expliciet vastgelegd wanneer een opmerking als niet-openbaar is gemarkeerd.
Waarom dit belangrijk is Analyse van interne notities kan inzicht geven in complexe problemen waarvoor samenwerking nodig is. Een groot aantal notities kan wijzen op kennishiaten of inefficiënte processen. Waar vind je dit? Afkomstig uit de opmerkingen bij het ticket. Een opmerking is een interne notitie wanneer het attribuut ‘public’ de waarde false heeft. Vastleggen Vastgelegd wanneer een nieuwe opmerking met ‘public: false’ aan het ticket wordt toegevoegd. Gebeurtenistype explicit
	Openbaar antwoord verzonden	Dit is een bericht van een supportagent aan de eindgebruiker. In Zendesk wordt deze gebeurtenis expliciet vastgelegd wanneer een openbare opmerking aan het ticket wordt toegevoegd.
Waarom dit belangrijk is Door openbare antwoorden te volgen, krijg je inzicht in de frequentie van communicatie. Ze kunnen ook een belangrijk moment vormen bij het analyseren van vertragingen in de bevestiging door gebruikers. Waar vind je dit? Afkomstig uit de opmerkingen bij het ticket. Een opmerking is openbaar wanneer het attribuut ‘public’ de waarde true heeft. Vastleggen Vastgelegd wanneer een nieuwe opmerking met ‘public: true’ aan het ticket wordt toegevoegd. Gebeurtenistype explicit
	Prioriteit ingesteld	Het prioriteitsniveau van een incident wordt bepaald, bijvoorbeeld Laag, Normaal, Hoog of Urgent. Dit wordt expliciet vastgelegd als wijziging en bepaalt hoe dringend het ticket is en binnen welke tijd een reactie nodig is.
Waarom dit belangrijk is Door te volgen wanneer en hoe de prioriteit wordt ingesteld, kun je het dashboard ‘Effectiviteit van prioritering’ vullen en ervoor zorgen dat kritieke problemen snel worden opgepakt. Waar vind je dit? Afkomstig uit een ‘Change’-gebeurtenis voor het veld ‘priority’ in het auditlog van het ticket. Ook latere wijzigingen zijn te volgen om de KPI voor het aantal prioriteitswijzigingen te meten. Vastleggen Herkenbaar aan een ‘Change’-gebeurtenis voor het veld ‘priority’ in het auditlog van het ticket. Gebeurtenistype explicit
	SLA-doel niet gehaald	Dit markeert het moment waarop een ticket niet binnen de afgesproken Service Level Agreement is afgehandeld, bijvoorbeeld wat betreft de eerste reactietijd of de doorlooptijd tot oplossing. De gebeurtenis wordt berekend op basis van het SLA-beleid en de timestamps van ticketupdates.
Waarom dit belangrijk is Deze gebeurtenis helpt om de naleving van SLA’s te bewaken. Weten wanneer en waarom SLA’s niet worden gehaald, is belangrijk om de dienstverlening betrouwbaarder te maken en het vertrouwen van klanten te behouden. Waar vind je dit? Dit is een berekende gebeurtenis. Je kunt deze afleiden uit de gegevens in ‘sla_policy_metrics’ die bij een ticket horen, met de timestamp ‘breached_at’ voor elk SLA-doel. Vastleggen Afgeleid uit de timestamp ‘breached_at’ in de SLA-maatstafgegevens van het ticket. Gebeurtenistype calculated
	Status gewijzigd naar In afwachting	Dit geeft aan dat het proces is gepauzeerd omdat er op een reactie van de aanvrager wordt gewacht. De gebeurtenis wordt afgeleid uit een wijziging van het ticketveld ‘status’ naar ‘pending’.
Waarom dit belangrijk is Deze activiteit is belangrijk voor de berekening van de wachttijd op bevestiging door de gebruiker. Een lange wachttijd in deze status kan de totale doorlooptijd tot oplossing flink verlengen en wijst mogelijk op vertraging in de communicatie. Waar vind je dit? Afgeleid uit het auditlog van het ticket: een ‘Change’-gebeurtenis waarbij de nieuwe waarde van het veld ‘status’ ‘pending’ is. Vastleggen Afgeleid uit een wijziging van het statusveld naar ‘pending’. Gebeurtenistype inferred
	Ticket toegewezen aan groep	Dit is de eerste routering of triage van een incident naar een specifieke supportgroep. Meestal is dit de eerste stap in het toewijzen van de verantwoordelijkheid. De wijziging wordt expliciet vastgelegd in de auditgeschiedenis van het ticket.
Waarom dit belangrijk is Door groepstoewijzingen te volgen, kun je de efficiëntie van de eerste triage analyseren en vertragingen opsporen voordat een ticket bij het juiste team terechtkomt. Waar vind je dit? Afkomstig uit het auditlog van het ticket wanneer het veld ‘group_id’ wordt ingevuld of gewijzigd. De eerste wijziging na het aanmaken is de eerste toewijzing. Vastleggen Herkenbaar aan een ‘Change’-gebeurtenis voor het veld ‘group_id’ in het auditlog van het ticket. Gebeurtenistype explicit

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data op uit Zendesk Support

Stappen

Open Zendesk Explore: Meld je aan bij Zendesk Support met een gebruikersaccount dat rapporten mag maken en beheren in Zendesk Explore.
Maak een nieuw rapport: Ga naar de Explore-module. Klik in de navigatiebalk links op het pictogram 'Reports' en daarna op de knop 'New report'.
Selecteer de dataset: Kies in het venster 'Choose a dataset' de dataset Support: Ticket updates [default]. Deze dataset bevat het auditspoor van elke ticketwijziging, wat nodig is om een event log te maken.
Voeg de eerste attributen (kolommen) toe: Ga in de rapportbouwer naar het gedeelte 'Rows'. Klik op 'Add' en selecteer de volgende attributen. Deze vormen de kolommen van je 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.
Maak berekende attributen: Dit is de belangrijkste stap. Ga naar het menu 'Calculations' (het pictogram met de erlenmeyer) en selecteer 'Standard calculated attribute'. Maak de drie attributen uit het gedeelte 'Query': ActivityName, SourceSystem en LastDataUpdate. Kopieer de opgegeven formules exact.
Pas de rapportkolommen aan: Voeg de berekende attributen ActivityName, SourceSystem en LastDataUpdate toe aan het gedeelte 'Rows'. Je kunt de bronvelden waarmee ActivityName is gemaakt nu verwijderen (Changes - Field name, Changes - Previous value, Changes - New value, Comment public) om het overzicht op te schonen.
Voeg rapportfilters toe: Ga naar het gedeelte 'Filters' en klik op 'Add'. Voeg een filter toe voor Update - Date en kies een geschikte periode, bijvoorbeeld de afgelopen drie maanden. Voeg ook een filter toe voor het berekende attribuut ActivityName en sluit lege waarden uit. Zo verwijder je ticketupdates die niet bij een gewenste activiteit horen.
Voer het rapport uit en controleer het: Zendesk Explore werkt het rapport automatisch bij wanneer je attributen en filters toevoegt. Controleer in de datatabel of de rijen en kolommen kloppen. Het rapport moet één rij per event tonen.
Exporteer de data naar CSV: Klik na afronding van het rapport rechtsboven op 'Export' en selecteer 'CSV'. Zendesk maakt het CSV-bestand en downloadt het.
Maak het bestand klaar om te uploaden: Open het geëxporteerde CSV-bestand. Hernoem de kolomkoppen zodat ze overeenkomen met de vereiste attribuutnamen voor je process mining-tool, bijvoorbeeld 'Ticket ID' naar TicketId en 'Update - Timestamp' naar EventTimestamp. Gebruik voor timestamps de ISO 8601-datumnotatie. Het bestand is nu klaar om te uploaden.

Configuratie

Zendesk-dataset: Bouw het rapport op de dataset Support: Ticket updates [default]. Dit is de enige standaarddataset met het gedetailleerde auditspoor dat nodig is om het proces event voor event te reconstrueren.
Filter op datumbereik: Pas een datumfilter toe om de hoeveelheid data te beperken. Gebruik Update - Date als primair filter. Voor een eerste analyse wordt meestal een periode van 3 tot 6 maanden aanbevolen.
Activiteitenfilter: Sluit na het maken van het berekende attribuut ActivityName de rijen uit waarvoor de waarde leeg is. Zo verwijder je irrelevante ticketwijzigingen, zoals systeemupdates en tagwijzigingen, uit het event log.
Berekende attributen: Deze extractie is grotendeels afhankelijk van een standaard berekend attribuut dat ruwe wijzigingen in ticketvelden omzet in begrijpelijke activiteitsnamen. De formule moet precies kloppen.
Vereisten: De gebruiker die het rapport uitvoert, heeft minimaal de rol 'Viewer' in Zendesk Explore nodig. Voor het maken en opslaan van het rapport zijn rechten als 'Editor' of 'Admin' vereist.

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

Vereisten: Zorg dat Python 3.6 of hoger en de bibliotheken requests en pandas op je systeem zijn geïnstalleerd. Installeer ze zo nodig met pip: pip install requests pandas.
Maak een Zendesk API-token aan: Meld je als beheerder aan bij Zendesk Support. Ga naar Admin Center > Apps and integrations > APIs > Zendesk APIs. Voeg onder "API Tokens" een nieuw actief API-token toe en bewaar de gegenereerde tokenstring veilig.
Configureer het Python-script: Maak een Python-bestand, bijvoorbeeld extract_zendesk_logs.py, en kopieer het opgegeven script erin. Vul bovenaan de placeholders ZENDESK_SUBDOMAIN, ZENDESK_EMAIL en ZENDESK_API_TOKEN in met je eigen gegevens. Stel START_TIMESTAMP in op het begin van de gewenste periode voor data-extractie, als Unix-epochtimestamp.
Bekijk de API-eindpunten: Het script gebruikt vooral twee Zendesk API-eindpunten. Het eindpunt incremental/tickets/cursor.json haalt efficiënt alle tickets op die sinds START_TIMESTAMP zijn bijgewerkt. Voor elk ticket roept het script vervolgens tickets/{ticket_id}/audits.json aan om de volledige geschiedenis van wijzigingen en events op te halen.
Voer het script uit: Start het script vanuit de terminal met de opdracht python extract_zendesk_logs.py. Het script haalt vervolgens data op via de Zendesk API.
Houd de voortgang bij: Het script toont in de console hoeveel tickets zijn verwerkt. Zo kun je de voortgang volgen. Afhankelijk van de periode en het aantal tickets kan dit behoorlijk wat tijd kosten.
Data ophalen en pagineren: Het script verwerkt API-paginering automatisch. Het begint met de URL voor de eerste ticketexport en volgt de after_url uit elke API-respons totdat alle tickets uit de periode zijn opgehaald.
Events omzetten: Het script doorloopt de auditgeschiedenis van elk ticket. Het leest elk audit-event uit en zet interne Zendesk-eventtypen, zoals Create, Change en Comment, om in de vereiste bedrijfsactiviteiten, zoals Incident Created, Status Changed to Open en Public Reply Sent.
SLA-data verwerken: Het script bevat de aparte functie get_sla_breach_events om SLA-metrieken op te halen voor elk opgelost ticket. Dit is nodig omdat SLA-overschrijdingen geen standaardevents in het auditlog zijn. De functie doet een extra API-aanroep om details over de toepassing van het SLA-beleid op te halen.
Maak het event log: Nadat alle tickets zijn verwerkt, zet het script de opgehaalde events in een pandas DataFrame en slaat het uiteindelijke event log op als zendesk_incident_event_log.csv in dezelfde map als het script.
Maak het bestand klaar om te uploaden: Controleer of het gegenereerde CSV-bestand klopt. Het heeft nu de juiste indeling om rechtstreeks naar ProcessMind te uploaden voor analyse.

Configuratie

Zendesk API-inloggegevens: Je hebt het Zendesk-subdomein, het e-mailadres van een beheerder- of agentaccount en een geldig API-token nodig. Bewaar deze gegevens veilig. Zet ze bij productiegebruik niet rechtstreeks in scripts die onder versiebeheer staan.
Starttimestamp (START_TIMESTAMP): Deze gehele waarde bepaalt vanaf welk moment data wordt opgehaald. De waarde moet een Unix-epochtimestamp zijn. Een aanbevolen startpunt is 3 tot 6 maanden geleden. Zo verzamel je voldoende data zonder het systeem te overbelasten. Gebruik een online converter om de juiste timestamp voor een specifieke datum te vinden.
API-snelheidslimieten: Het script doet veel API-aanroepen. Zendesk hanteert snelheidslimieten die per abonnement verschillen. Voor middelgrote hoeveelheden data werkt het script zoals bedoeld. Bij zeer grote Zendesk-omgevingen kun je binnen de lussen time.sleep() toevoegen om te voorkomen dat je de limiet overschrijdt en een 429-fout krijgt.
Vereiste Python-bibliotheken: Het script gebruikt requests voor API-aanroepen en pandas voor dataverwerking en CSV-export. Zorg dat beide in je Python-omgeving zijn geïnstalleerd.
Gebruikersrechten: Het account bij het API-token moet voldoende rechten hebben om ticketdata te lezen, inclusief auditgegevens en ticketmetriek.

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

Maak een Zendesk API-client met leesrechten voor tickets, ticketaudits, gebruikers, groepen, tevredenheidsscores en incrementele exports. Gebruik een API-token of OAuth-inloggegevens die zijn ingesteld voor je Zendesk Support-omgeving. Bewaar het subdomein, de inloggegevens en de extractiewatermark als beveiligde configuratiewaarden.
Gebruik de Zendesk Incremental Ticket Export API om tickets op te halen die zijn bijgewerkt na de vorige succesvolle watermark. Het onderstaande script gebruikt het gedocumenteerde patroon voor het eindpunt, https://[Your Zendesk subdomain].zendesk.com/api/v2/incremental/tickets/cursor.json, en doorloopt de cursorpaginering totdat de API aangeeft dat alle resultaten zijn opgehaald.
Vraag voor elk opgehaald ticket de auditgeschiedenis op via het ticketaudit-eindpunt. Auditgegevens zijn nodig omdat ProcessMind het event log ongewijzigd inleest en geen activiteiten afleidt uit de uiteindelijke ticketstatus. Bewaar de audittimestamp, actor, ticket-ID en audit-events.
Zet audit-events om in expliciete eventrijen. Haal het aanmaken van tickets, groepstoewijzingen, agenttoewijzingen, prioriteitswijzigingen, statuswijzigingen naar open, openbare reacties, interne notities, herindelingen, statuswijzigingen naar in behandeling, opgeloste status en gesloten status eruit. Voeg tevredenheidsscores als aparte rijen toe wanneer de score beschikbaar is. Bereken SLA-overschrijdingen alleen als de vereiste SLA-doelstelling en eventtimestamps beschikbaar zijn, en documenteer de gebruikte invoer voor de berekening.
Bewaar de laatst succesvol verwerkte updatetimestamp of cursor. Werk de watermark pas bij nadat alle pagina’s, ticketaudits en eventuele tevredenheidsgegevens succesvol zijn opgeslagen. Gebruik voor de eerste run een afgebakende starttijd, zoals [Start date in ISO 8601 format], doorgaans voor een periode van drie tot zes maanden.
Vul de verplichte kolommen TicketId, ActivityName, EventTimestamp, SourceSystem en LastDataUpdate. Vul de aanbevolen kolommen TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus en EventEndTime in wanneer de brondata dit ondersteunt. Laat waarden alleen leeg als Zendesk het attribuut niet voor het event aanlevert.
Verwijder dubbele records op basis van TicketId, ActivityName, EventTimestamp en, indien beschikbaar, een stabiele bron-event-ID. Behoud meerdere geldige voorkomens van dezelfde activiteit, zoals verschillende openbare reacties, interne notities, toewijzingen of statuswijzigingen.
Schrijf de resulterende rijen naar CSV of een ander door ProcessMind ondersteund eventlogformaat. Gebruik timestamps in ISO 8601 met een expliciete UTC-offset, zorg voor een consistent gegevenstype voor TicketId en gebruik ActivityName-waarden die exact overeenkomen met de gedocumenteerde activiteitsnamen. Geef alle rijen in dezelfde extractiebatch dezelfde waarde voor LastDataUpdate.
Upload het event log naar ProcessMind en stel Incident ID in als case-ID, Activity als activiteitskolom en Event Timestamp als tijdskolom voor events. Controleer of elke vereiste activiteit als expliciete rij aanwezig is en niet pas tijdens de visualisatie wordt afgeleid.

Configuratie

API-methode: Zendesk Incremental Ticket Export API met cursorpaginering. Gebruik het ticketaudit-eindpunt om events op te halen en het tevredenheidseindpunt wanneer tevredenheidsscores zijn ingeschakeld en toegankelijk zijn.
Vereiste configuratie: Zendesk-subdomein, API-authenticatie, initiële startdatum, extractiewatermark, time-out voor verzoeken, beleid voor nieuwe pogingen en uitvoerlocatie. Vervang [Your Zendesk subdomain], [Your API email] en [Your API token] door beveiligde waarden voor de implementatie.
Datumbereik: Gebruik voor de eerste keer drie tot zes maanden, tenzij een langere historie nodig is. Vraag bij terugkerende extracties records op na de laatste succesvolle watermark en neem een korte overlappende periode mee om vertraagde updates op te vangen. Verwijder daarna dubbele records.
Filters: Filter op bedrijf, merk, groep, organisatie, ticketformulier, kanaal of aangepast veld alleen als dit expliciet binnen de procesafbakening valt. Zendesk Support gebruikt geen filters voor Company Code of Document Type zoals SAP, tenzij die begrippen zijn vastgelegd in geconfigureerde Zendesk-velden.
Betekenis van events: Gebruik audit-events als gezaghebbende bron voor expliciete wijzigingen. Maak geen statuswijzigingsevent aan alleen omdat het ticket nu een bepaalde status heeft. Een statusevent moet afkomstig zijn uit een audit-event of een andere gedocumenteerde brongebeurtenis.
SLA-configuratie: Voor SLA Target Breached zijn het toepasselijke SLA-beleid, de doelduur, de kalender met kantooruren en de benodigde timestamps vereist. Gebruik een bron-event of metriek als Zendesk die beschikbaar stelt. Bereken de overschrijding anders alleen met gedocumenteerde beleidsgegevens en bewaar de basis van de berekening.
Configuratie voor tevredenheidsscores: Voor User Satisfaction Rated moeten tevredenheidsscores zijn ingeschakeld en moet de score via de API beschikbaar zijn. Voeg geen fictief score-event toe voor een opgelost ticket zonder score.
Prestaties: Gebruik cursorpaginering, beperk het aantal gelijktijdige verzoeken om ticketaudits op te halen, hergebruik verbindingen, pas exponentiële wachttijden toe bij snelheidslimieten en sla controlepunten op na succesvolle batches. Haal niet bij elke run opnieuw alle ticketaudits op.
Volledigheid: Incrementele exports kunnen tickets bevatten die na de opgegeven tijd zijn bijgewerkt. Het ophalen van audits en het verwerken van late updates moet je apart afhandelen. Gebruik een overlappende periode en stabiele sleutels om dubbele records te verwijderen.
Vereisten: API-toegang, leesrechten voor tickets en audits, toegang tot gebruikers en groepen om namen op te zoeken, toegang tot tevredenheidsgegevens indien nodig en toegang tot SLA-data als je overschrijdingen wilt berekenen. Welke audit-eventtypen beschikbaar zijn, kan afhangen van de Zendesk-configuratie en het abonnement.

Voorbeeldquery python

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

import requests

ZENDESK_SUBDOMAIN = os.getenv(class="hl-string">"ZENDESK_SUBDOMAIN", class="hl-string">"[Your Zendesk subdomain]")
API_EMAIL = os.getenv(class="hl-string">"ZENDESK_API_EMAIL", class="hl-string">"[Your API email]")
API_TOKEN = os.getenv(class="hl-string">"ZENDESK_API_TOKEN", class="hl-string">"[Your API token]")
START_DATE = os.getenv(class="hl-string">"START_DATE", class="hl-string">"[Start date in ISO 8601 format]")
OUTPUT_FILE = os.getenv(class="hl-string">"OUTPUT_FILE", class="hl-string">"incident_event_log.csv")
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"
LAST_DATA_UPDATE = datetime.now(timezone.utc).isoformat()

if class="hl-string">"[" in ZENDESK_SUBDOMAIN or class="hl-string">"[" in API_EMAIL or class="hl-string">"[" in API_TOKEN or class="hl-string">"[" in START_DATE:
    raise ValueError(class="hl-string">"Set ZENDESK_SUBDOMAIN, ZENDESK_API_EMAIL, ZENDESK_API_TOKEN, and START_DATE before running")

BASE_URL = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2"
SESSION = requests.Session()
SESSION.auth = (fclass="hl-string">"{API_EMAIL}/token", API_TOKEN)
SESSION.headers.update({class="hl-string">"Accept": class="hl-string">"application/json"})

FIELDS = [
    class="hl-string">"TicketId", class="hl-string">"ActivityName", class="hl-string">"EventTimestamp", 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", class="hl-string">"EventEndTime"
]


def parse_time(value: Optional[str]) -> Optional[datetime]:
    if not value:
        return None
    return datetime.fromisoformat(value.replace(class="hl-string">"Z", class="hl-string">"+00:00"))


def iso(value: Any) -> str:
    if isinstance(value, datetime):
        return value.astimezone(timezone.utc).isoformat()
    if value is None:
        return class="hl-string">""
    return str(value)


def get_json(url: str, params: Optional[Dict[str, Any]] = None) -> Dict[str, Any]:
    for attempt in range(6):
        response = SESSION.get(url, params=params, timeout=60)
        if response.status_code == 429:
            retry_after = int(response.headers.get(class="hl-string">"Retry-After", class="hl-string">"5"))
            time.sleep(max(retry_after, 2 ** attempt))
            continue
        response.raise_for_status()
        return response.json()
    raise RuntimeError(fclass="hl-string">"Request failed after retries: {url}")


def incremental_tickets(start_time: str) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json"
    params: Optional[Dict[str, Any]] = {class="hl-string">"start_time": int(parse_time(start_time).timestamp())}
    while url:
        payload = get_json(url, params)
        for ticket in payload.get(class="hl-string">"tickets", []):
            yield ticket
        if payload.get(class="hl-string">"end_of_stream"):
            break
        url = payload.get(class="hl-string">"after_url")
        params = None


def ticket_audits(ticket_id: int) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    while url:
        payload = get_json(url)
        for audit in payload.get(class="hl-string">"audits", []):
            yield audit
        url = payload.get(class="hl-string">"next_page")


def satisfaction_for_ticket(ticket_id: int) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/satisfaction_ratings.json"
    try:
        payload = get_json(url)
    except requests.HTTPError as error:
        if error.response is not None and error.response.status_code in (403, 404):
            return
        raise
    for rating in payload.get(class="hl-string">"satisfaction_ratings", []):
        yield rating


def user_name(user_id: Any, cache: Dict[str, str]) -> str:
    if not user_id:
        return class="hl-string">""
    key = str(user_id)
    if key not in cache:
        payload = get_json(fclass="hl-string">"{BASE_URL}/users/{user_id}.json")
        user = payload.get(class="hl-string">"user", {})
        cache[key] = user.get(class="hl-string">"name") or user.get(class="hl-string">"email") or key
    return cache[key]


def group_name(group_id: Any, cache: Dict[str, str]) -> str:
    if not group_id:
        return class="hl-string">""
    key = str(group_id)
    if key not in cache:
        payload = get_json(fclass="hl-string">"{BASE_URL}/groups/{group_id}.json")
        cache[key] = payload.get(class="hl-string">"group", {}).get(class="hl-string">"name") or key
    return cache[key]


def ticket_context(ticket: Dict[str, Any], users: Dict[str, str], groups: Dict[str, str]) -> Dict[str, str]:
    assignee = user_name(ticket.get(class="hl-string">"assignee_id"), users)
    group = group_name(ticket.get(class="hl-string">"group_id"), groups)
    return {
        class="hl-string">"TicketStatus": str(ticket.get(class="hl-string">"status") or class="hl-string">""),
        class="hl-string">"Assignee": assignee,
        class="hl-string">"AssignedGroup": group,
        class="hl-string">"TicketPriority": str(ticket.get(class="hl-string">"priority") or class="hl-string">""),
        class="hl-string">"Channel": str((ticket.get(class="hl-string">"via") or {}).get(class="hl-string">"channel") or class="hl-string">""),
        class="hl-string">"SlaStatus": class="hl-string">"",
    }


def make_row(ticket_id: Any, activity: str, event_time: Any, context: Dict[str, str], end_time: Any = class="hl-string">"") -> Dict[str, str]:
    row = {
        class="hl-string">"TicketId": str(ticket_id),
        class="hl-string">"ActivityName": activity,
        class="hl-string">"EventTimestamp": iso(event_time),
        class="hl-string">"SourceSystem": SOURCE_SYSTEM,
        class="hl-string">"LastDataUpdate": LAST_DATA_UPDATE,
        class="hl-string">"TicketStatus": context.get(class="hl-string">"TicketStatus", class="hl-string">""),
        class="hl-string">"Assignee": context.get(class="hl-string">"Assignee", class="hl-string">""),
        class="hl-string">"AssignedGroup": context.get(class="hl-string">"AssignedGroup", class="hl-string">""),
        class="hl-string">"TicketPriority": context.get(class="hl-string">"TicketPriority", class="hl-string">""),
        class="hl-string">"Channel": context.get(class="hl-string">"Channel", class="hl-string">""),
        class="hl-string">"SlaStatus": context.get(class="hl-string">"SlaStatus", class="hl-string">""),
        class="hl-string">"EventEndTime": iso(end_time),
    }
    return row


def audit_value(audit_event: Dict[str, Any], field: str) -> Any:
    for change in audit_event.get(class="hl-string">"changes", []):
        if change.get(class="hl-string">"field") == field:
            return change
    return None


def append_audit_rows(ticket: Dict[str, Any], audit: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    ticket_id = ticket.get(class="hl-string">"id")
    event_time = audit.get(class="hl-string">"created_at")
    context = ticket_context(ticket, users, groups)
    author = user_name(audit.get(class="hl-string">"author_id"), users)
    for change in audit.get(class="hl-string">"events", []):
        event_type = change.get(class="hl-string">"type")
        field = change.get(class="hl-string">"field")
        value = change.get(class="hl-string">"value")
        previous = change.get(class="hl-string">"previous_value")
        if event_type == class="hl-string">"Create" or field == class="hl-string">"created_at":
            rows.append(make_row(ticket_id, class="hl-string">"Incident Created", event_time, context))
        if field == class="hl-string">"group_id" and value is not None:
            context[class="hl-string">"AssignedGroup"] = group_name(value, groups)
            if previous not in (None, class="hl-string">"", value):
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Reassigned", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Assigned to Group", event_time, context))
        if field == class="hl-string">"assignee_id" and value is not None:
            context[class="hl-string">"Assignee"] = user_name(value, users)
            if previous not in (None, class="hl-string">"", value):
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Reassigned", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Assigned to Agent", event_time, context))
        if field == class="hl-string">"priority" and value is not None:
            context[class="hl-string">"TicketPriority"] = str(value)
            rows.append(make_row(ticket_id, class="hl-string">"Priority Set", event_time, context))
        if field == class="hl-string">"status":
            context[class="hl-string">"TicketStatus"] = str(value or class="hl-string">"")
            if value == class="hl-string">"open":
                rows.append(make_row(ticket_id, class="hl-string">"Status Changed to Open", event_time, context))
            if value == class="hl-string">"pending":
                rows.append(make_row(ticket_id, class="hl-string">"Status Changed to Pending", event_time, context))
            if value == class="hl-string">"solved":
                rows.append(make_row(ticket_id, class="hl-string">"Incident Resolved", event_time, context))
            if value == class="hl-string">"closed":
                rows.append(make_row(ticket_id, class="hl-string">"Incident Closed", event_time, context))
        if event_type == class="hl-string">"Comment":
            if bool(change.get(class="hl-string">"public")):
                rows.append(make_row(ticket_id, class="hl-string">"Public Reply Sent", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Internal Note Added", event_time, context))


def append_satisfaction_rows(ticket: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    context = ticket_context(ticket, users, groups)
    for rating in satisfaction_for_ticket(ticket.get(class="hl-string">"id")):
        rated_at = rating.get(class="hl-string">"created_at") or rating.get(class="hl-string">"updated_at")
        if rated_at:
            rows.append(make_row(ticket.get(class="hl-string">"id"), class="hl-string">"User Satisfaction Rated", rated_at, context))


def append_sla_breach_rows(ticket: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    context = ticket_context(ticket, users, groups)
    sla_breach_time = ticket.get(class="hl-string">"sla_breach_at")
    if sla_breach_time:
        context[class="hl-string">"SlaStatus"] = class="hl-string">"Breached"
        rows.append(make_row(ticket.get(class="hl-string">"id"), class="hl-string">"SLA Target Breached", sla_breach_time, context))


def extract() -> List[Dict[str, str]]:
    rows: List[Dict[str, str]] = []
    users: Dict[str, str] = {}
    groups: Dict[str, str] = {}
    seen = set()
    for ticket in incremental_tickets(START_DATE):
        for audit in ticket_audits(ticket.get(class="hl-string">"id")):
            append_audit_rows(ticket, audit, rows, users, groups)
        append_satisfaction_rows(ticket, rows, users, groups)
        append_sla_breach_rows(ticket, rows, users, groups)
    unique_rows: List[Dict[str, str]] = []
    for row in rows:
        key = (row[class="hl-string">"TicketId"], row[class="hl-string">"ActivityName"], row[class="hl-string">"EventTimestamp"], row[class="hl-string">"Assignee"], row[class="hl-string">"AssignedGroup"])
        if key not in seen:
            seen.add(key)
            unique_rows.append(row)
    unique_rows.sort(key=lambda item: (item[class="hl-string">"TicketId"], item[class="hl-string">"EventTimestamp"], item[class="hl-string">"ActivityName"]))
    return unique_rows


if __name__ == class="hl-string">"__main__":
    event_rows = extract()
    with open(OUTPUT_FILE, class="hl-string">"w", newline=class="hl-string">"", encoding=class="hl-string">"utf-8") as output:
        writer = csv.DictWriter(output, fieldnames=FIELDS)
        writer.writeheader()
        writer.writerows(event_rows)
    print(json.dumps({class="hl-string">"output_file": OUTPUT_FILE, class="hl-string">"rows": len(event_rows), class="hl-string">"last_data_update": LAST_DATA_UPDATE}))

Stappen

Kies een commerciële ETL- of dataintegratietool met een gecontroleerde Zendesk Support-connector. De connector moet ticketauditgeschiedenis en reacties kunnen ophalen en data kunnen wegschrijven naar het gewenste datawarehouse of bestandssysteem. Controleer of incrementele extractie, paginering, verwerking van snelheidslimieten en behoud van brontimestamps worden ondersteund.
Maak in de gekozen tool een verbinding met Zendesk. Vul via de configuratie-interface het Zendesk-subdomein, de authenticatiemethode, inloggegevens of token en eventuele andere verbindingsinstellingen in. Geef toegang tot tickets, ticketaudits, reacties, gebruikers, groepen, tevredenheidsscores en SLA-data als deze objecten beschikbaar zijn binnen je Zendesk-abonnement en connector.
Stel de extractieperiode in. Gebruik voor de eerste keer een voortschrijdende periode van 3 tot 6 maanden. Stel daarna incrementele extracties in op basis van de updatetimestamp of audittimestamp die de connector ondersteunt. Bewaar de laatste succesvolle extractiewatermark buiten het event log, zodat volgende runs geen events overslaan of dubbel opnemen.
Haal de ticketgegevens op die nodig zijn voor de context van de case, waaronder de ticket-ID, huidige status of status per event, toegewezen medewerker, groep, prioriteit, rapportagekanaal, SLA-status en relevante updatetimestamps. Haal ook ticketaudits op, zodat wijzigingen in toewijzing, prioriteit, status en andere velden als expliciete eventrijen worden vastgelegd.
Haal ticketreacties op en maak onderscheid tussen openbare reacties en interne notities met de indicator voor openbaarmaking of zichtbaarheid van de connector. Haal reactietimestamps, ticket-ID’s, auteurs-ID’s en eventuele beschikbare eind- of voltooiingstimestamps op. Maak voor openbare reacties rijen met Public Reply Sent en voor privénotities rijen met Internal Note Added.
Haal tevredenheidsscores en SLA-overschrijdingen op als de connector deze beschikbaar stelt. Als de connector SLA-overschrijdingen niet rechtstreeks aanlevert, stel de ETL-tool dan zo in dat deze ze berekent op basis van de beschikbare SLA-doelstelling, het beleid, de kantooruren en de eventtimestamps van tickets. Maak alleen een rij voor een overschrijding als de brondata of de ingestelde berekening bevestigt dat de doelstelling is overschreden.
Zet de opgehaalde bronrecords om naar een genormaliseerd event log. Maak één rij per expliciete activiteit. Koppel het aanmaken van een ticket aan Incident Created, wijzigingen in groepstoewijzing aan Ticket Assigned to Group of Ticket Reassigned, wijzigingen in agenttoewijzing aan Ticket Assigned to Agent of Ticket Reassigned, prioriteitswijzigingen aan Priority Set, statusovergangen aan de bijbehorende statusactiviteit, reacties aan Public Reply Sent of Internal Note Added, een opgeloste status aan Incident Resolved, tevredenheidsgegevens aan User Satisfaction Rated en een gesloten status aan Incident Closed.
Pas de regels voor eventclassificatie in een vaste volgorde toe. Gebruik waar mogelijk de vorige en nieuwe waarden uit de auditgeschiedenis. Classificeer de eerste toewijzing aan een groep als Ticket Assigned to Group, de eerste toewijzing aan een medewerker als Ticket Assigned to Agent en latere wijzigingen in eigenaarschap als Ticket Reassigned. Maak een rij voor elke relevante wijziging, niet alleen voor de meest recente ticketstatus.
Vul de verplichte kolommen TicketId, ActivityName, EventTimestamp, SourceSystem en LastDataUpdate. Vul de aanbevolen kolommen TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus en EventEndTime in op basis van de eventcontext of de dichtstbijzijnde geldige bronrecord. Gebruik een consistente tijdzone voor brontimestamps, bij voorkeur UTC, en behoud de oorspronkelijke precisie die de connector ondersteunt.
Controleer de getransformeerde uitvoer. Kijk of elke TicketId een Incident Created-rij heeft, of eventtimestamps waar van toepassing binnen de extractieperiode vallen, of alle 13 vereiste activiteitsnamen voorkomen wanneer de brondata beschikbaar is en of dubbele event-sleutels worden afgehandeld met de bron-audit-ID of een gedocumenteerde samengestelde sleutel.
Schrijf het event log naar de doeltabel of het doelbestand in een tabelindeling die compatibel is met ProcessMind, zoals CSV of een ondersteunde datawarehouse-connector. Gebruik één kopregel, vaste kolomnamen, UTF-8-codering, ISO 8601-timestamps en geen geneste JSON in de uiteindelijke eventkolommen. Upload het event log naar ProcessMind of maak er verbinding mee. Vertrouw niet op afgeleide activiteiten, want ProcessMind leest de opgehaalde rijen ongewijzigd in.

Configuratie

Connector en licentie: Gebruik een commerciële ETL- of dataintegratietool met een Zendesk Support-connector die tickets, ticketaudits, reacties, gebruikers, groepen, tevredenheidsscores en SLA-informatie beschikbaar maakt, voor zover het Zendesk-abonnement en de connecterversie dit ondersteunen.
Authenticatie en autorisatie: Configureer het Zendesk-subdomein en een goedgekeurde authenticatiemethode. Geef alleen de rechten die nodig zijn om tickets, audits, reacties, gebruikers, groepen, tevredenheidsgegevens en SLA-data op te halen. Controleer of het integratieaccount historische records kan lezen.
Datumbereik: Begin met 3 tot 6 maanden voor de controle en eerste gegevenslading. Vergroot de periode pas nadat je het aantal rijen, de paginering en de werking van snelheidslimieten hebt gecontroleerd. Gebruik voor geplande runs een incrementele watermark.
Vereiste filters: Pas alleen filters toe die aantoonbaar in de bronconfiguratie zijn ingesteld, zoals een specifiek Zendesk-subdomein, merk, organisatie, groep of ticketbereik. Filter niet op Company Code of Document Type, tenzij deze velden in het geconfigureerde Zendesk-datamodel bestaan.
Auditgeschiedenis: Schakel het ophalen van ticketaudit-events in en bewaar waar mogelijk de bron-audit-ID om dubbele events bij incrementele extracties te voorkomen.
Reacties: Haal zowel openbare als privéreacties op. Gebruik de zichtbaarheidsindicator uit de bron om Public Reply Sent en Internal Note Added te classificeren. Leid de zichtbaarheid niet af uit de tekst van de reactie.
Classificatie van toewijzingen: Vergelijk de vorige en nieuwe groeps- of medewerkerwaarden. Classificeer de eerste relevante toewijzing apart van latere wijzigingen en maak voor volgende wijzigingen in eigenaarschap een Ticket Reassigned-event.
Classificatie van statussen: Maak alleen rijen voor expliciete statusovergangen. Koppel de waarden new, open, pending, solved en closed aan de juiste activiteiten volgens het ingestelde Zendesk-statusmodel. Documenteer de koppeling voordat je data laadt als er aangepaste statussen worden gebruikt.
SLA-verwerking: Gebruik bij voorkeur bron-events voor SLA-overschrijdingen. Als die ontbreken, stel dan een gedocumenteerde berekening in op basis van de beschikbare SLA-doelstelling, het beleid, de kantooruren en eventtimestamps. Leg de basis van de berekening vast in de ETL-metadata. Verzin hiervoor geen bronvelden.
Timestamps verwerken: Zet EventTimestamp en EventEndTime om naar UTC of een andere gedocumenteerde tijdzone. Behoud de brontimestamp en vervang de eventtijd niet door de extractietijd.
LastDataUpdate: Stel LastDataUpdate in op de timestamp van de succesvolle ETL-verversing. Gebruik voor alle rijen in die gegevenslading dezelfde waarde.
Prestaties: Gebruik paginering, incrementele extractie, partitionering op ticketupdate- of audittimestamp, gecontroleerde parallelle verwerking, nieuwe pogingen en wachttijden bij snelheidslimieten. Haal niet bij elke geplande run opnieuw de volledige tickethistorie op.
Doelschema: Configureer een platte eventtabel of een plat bestand met de verplichte kolommen TicketId, ActivityName, EventTimestamp, SourceSystem en LastDataUpdate, plus de aanbevolen attributen als die beschikbaar zijn.
Werking van ProcessMind: Verwacht niet dat ProcessMind statuswijzigingen, toewijzingen, reacties, notities, SLA-overschrijdingen of mijlpalen in de levenscyclus afleidt. Elke activiteit moet vóór het uploaden al als eventrij aanwezig zijn.

Voorbeeldquery config

-- Configure this transformation in the selected ETL tool using its Zendesk connector.
-- Replace bracketed connection, credential, date, and company-specific values in the tool configuration.
-- The connector source objects and field mappings must be selected from the tool's verified Zendesk schema.

WITH
source_tickets AS (
    SELECT
        ticket_id,
        created_at,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        updated_at
    FROM [Your Zendesk tickets source]
    WHERE updated_at >= [Start date parameter]
      AND updated_at < [End date parameter]
),
source_audits AS (
    SELECT
        ticket_id,
        audit_id,
        event_timestamp,
        event_type,
        previous_value,
        new_value,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk ticket audits source]
    WHERE event_timestamp >= [Start date parameter]
      AND event_timestamp < [End date parameter]
),
source_comments AS (
    SELECT
        ticket_id,
        comment_id,
        event_timestamp,
        is_public,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk ticket comments source]
    WHERE event_timestamp >= [Start date parameter]
      AND event_timestamp < [End date parameter]
),
source_sla_breaches AS (
    SELECT
        ticket_id,
        breach_timestamp,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk SLA breach source]
    WHERE breach_timestamp >= [Start date parameter]
      AND breach_timestamp < [End date parameter]
),
source_satisfaction AS (
    SELECT
        ticket_id,
        rating_timestamp,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk satisfaction rating source]
    WHERE rating_timestamp >= [Start date parameter]
      AND rating_timestamp < [End date parameter]
),
classified_audits AS (
    SELECT
        a.*,
        ROW_NUMBER() OVER (
            PARTITION BY a.ticket_id, a.event_type
            ORDER BY a.event_timestamp, a.audit_id
        ) AS event_sequence
    FROM source_audits a
),
event_log AS (
    SELECT
        CAST(t.ticket_id AS VARCHAR(255)) AS TicketId,
        'Incident Created' AS ActivityName,
        t.created_at AS EventTimestamp,
        'Zendesk Support' AS SourceSystem,
        [ETL refresh timestamp] AS LastDataUpdate,
        t.status AS TicketStatus,
        t.assignee AS Assignee,
        t.assigned_group AS AssignedGroup,
        t.priority AS TicketPriority,
        t.channel AS Channel,
        t.sla_status AS SlaStatus,
        CAST(NULL AS TIMESTAMP) AS EventEndTime
    FROM source_tickets t

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Assigned to Group',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'group_assignment'
      AND a.event_sequence = 1
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Assigned to Agent',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'assignee_assignment'
      AND a.event_sequence = 1
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Priority Set',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.new_value,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'priority_change'
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Status Changed to Open',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.previous_value = 'new'
      AND a.new_value = 'open'

    UNION ALL

    SELECT
        CAST(c.ticket_id AS VARCHAR(255)),
        'Public Reply Sent',
        c.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        c.status,
        c.assignee,
        c.assigned_group,
        c.priority,
        c.channel,
        c.sla_status,
        c.event_end_time
    FROM source_comments c
    WHERE c.is_public = TRUE

    UNION ALL

    SELECT
        CAST(c.ticket_id AS VARCHAR(255)),
        'Internal Note Added',
        c.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        c.status,
        c.assignee,
        c.assigned_group,
        c.priority,
        c.channel,
        c.sla_status,
        c.event_end_time
    FROM source_comments c
    WHERE c.is_public = FALSE

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Reassigned',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type IN ('group_assignment', 'assignee_assignment')
      AND a.event_sequence > 1
      AND COALESCE(a.previous_value, '') <> COALESCE(a.new_value, '')

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Status Changed to Pending',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'pending'

    UNION ALL

    SELECT
        CAST(s.ticket_id AS VARCHAR(255)),
        'SLA Target Breached',
        s.breach_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        s.status,
        s.assignee,
        s.assigned_group,
        s.priority,
        s.channel,
        s.sla_status,
        s.event_end_time
    FROM source_sla_breaches s
    WHERE s.breach_timestamp IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Incident Resolved',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'solved'

    UNION ALL

    SELECT
        CAST(s.ticket_id AS VARCHAR(255)),
        'User Satisfaction Rated',
        s.rating_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        s.status,
        s.assignee,
        s.assigned_group,
        s.priority,
        s.channel,
        s.sla_status,
        s.event_end_time
    FROM source_satisfaction s
    WHERE s.rating_timestamp IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Incident Closed',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'closed'
)
SELECT
    TicketId,
    ActivityName,
    EventTimestamp,
    SourceSystem,
    LastDataUpdate,
    TicketStatus,
    Assignee,
    AssignedGroup,
    TicketPriority,
    Channel,
    SlaStatus,
    EventEndTime
FROM event_log
WHERE TicketId IS NOT NULL
  AND ActivityName IS NOT NULL
  AND EventTimestamp IS NOT NULL
ORDER BY TicketId, EventTimestamp, ActivityName;

Klaar om te beginnen?

Gebruik deze template om de datavoorbereiding eenvoudiger te maken en inzicht te krijgen in de prestaties van incidentbeheer. Begin vandaag met het verbeteren van het proces.

Terug naar de verbetergids

Template downloaden

Verbeter incidentbeheer en los incidenten sneller op

Verlaag de MTTR met 35%, voorkom terugkerende incidenten en verhoog de klanttevredenheid.

Start je gratis proefperiode

Geen creditcard nodig. Begin binnen enkele minuten met verbeteren.

Datatemplate voor incidentbeheer

Datatemplate voor incidentbeheer

Attributen voor incidentbeheer

Activiteiten voor incidentbeheer

Extractiegidsen

Zendesk Explore: rapport exporteren naar CSV via de interface

Stappen

Configuratie

Voorbeeldquery config

Python-script met de Zendesk Support REST API

Stappen

Configuratie

Voorbeeldquery python

Zendesk Incremental Export API voor bulksynchronisatie van data

Stappen

Configuratie

Voorbeeldquery python

ETL-tool van derden met Zendesk API-connector

Stappen

Configuratie

Voorbeeldquery config

Klaar om te beginnen?

Verbeter incidentbeheer en los incidenten sneller op