> Continue procesverbetering > Incidentbeheer > Zendesk Support > Datatemplate

Jouw datatemplate voor incidentbeheer

Zendesk Support

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

Jouw datatemplate voor incidentbeheer

Deze template geeft een gestructureerd overzicht van de essentiële data die je nodig hebt om je incidentbeheerproces goed te analyseren. Je ziet welke belangrijke attributen je verzamelt, welke activiteiten je bijhoudt en hoe je deze data uit Zendesk Support haalt. Gebruik de template om je process mining-project met een volledige dataset te starten.

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

Nieuw met event logs? Leer hoe je een process mining-event log maakt.

Template downloaden

Attributen voor incidentbeheer

Dit zijn de aanbevolen datavelden voor je event log voor een grondige analyse van je incidentbeheerproces.

5 Verplicht 7 Aanbevolen 11 Optioneel

	Naam	Beschrijving
	Incident-ID TicketId	De unieke, door het systeem gegenereerde identificatie voor elk incidentticket.
Beschrijving De Incident ID is de primaire sleutel waarmee elke incidentcase binnen Zendesk Support uniek wordt geïdentificeerd. De ID fungeert als CaseId voor process mining en koppelt alle gerelateerde activiteiten, statuswijzigingen en communicatie vanaf het aanmaken van het incident tot het sluiten ervan. In analyses is deze ID essentieel om de volledige reis van elk incident te reconstrueren. Je kunt er eventdata mee samenvoegen om metingen te volgen zoals de totale oplostijd, het aantal overdrachten en de naleving van serviceniveaus per case. Door gebeurtenissen op deze ID te groeperen, kunnen analisten procesflows visualiseren, veelvoorkomende paden herkennen en afwijkingen van de standaardprocedure opsporen. Waarom dit belangrijk is Dit is de essentiële identificatie die alle gebeurtenissen aan één incident koppelt. Zo kun je de volledige levenscyclus volgen en de procesprestaties nauwkeurig analyseren. Waar je het vindt 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 precieze moment vast waarop een gebeurtenis in de levenscyclus van het incident plaatsvond, bijvoorbeeld wanneer een opmerking werd toegevoegd of de status werd gewijzigd. Zo ontstaat de chronologische volgorde van alle activiteiten binnen een case. Dit attribuut is de basis voor elke tijdsgebonden process-mininganalyse. 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 nodig voor een geanimeerde proceskaart die laat zien hoe cases zich in de tijd door het proces bewegen en voor procesdashboards met KPI's zoals de gemiddelde oplostijd. Waarom dit belangrijk is Timestamps geven alle activiteiten een chronologische context. Daarmee kun je doorlooptijden berekenen, knelpunten opsporen en procesprestaties door de tijd heen analyseren. Waar je het vindt 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 het incident plaatsvond.
Beschrijving Dit attribuut beschrijft een specifieke stap of actie binnen het incidentbeheerproces, zoals 'Incident Created', 'Ticket Assigned to Agent' of 'Incident Resolved'. Deze activiteiten zijn afgeleid uit het event log of de audittraildata van Zendesk, waarin systeemwijzigingen worden vastgelegd. Bij process mining vormt de volgorde van deze activiteiten de proceskaart, de basis voor alle analyses. Door de activiteitenstroom te analyseren, kunnen organisaties de werkelijke paden van incidenten ontdekken, knelpunten tussen stappen opsporen, lussen met herhaald werk meten, bijvoorbeeld wanneer een opgelost ticket opnieuw wordt geopend, en de conformiteit met een vastgesteld standaardproces controleren. Waarom dit belangrijk is De volgorde van activiteiten bepaalt de procesflow. Die vormt de kern van process-mininganalyse om inefficiënties, afwijkingen en verbetermogelijkheden op te sporen. Waar je het vindt Afgeleid uit gebeurtenissen in de Zendesk Ticket Audits API. Zo kan een Change-gebeurtenis voor het statusveld worden gekoppeld aan 'Status Changed'. Voorbeelden Incident aangemaaktTicket toegewezen aan agentStatus gewijzigd naar PendingIncident opgelostIncident gesloten
	Bronsysteem SourceSystem	Het systeem waaruit de incidentdata is geëxtraheerd.
Beschrijving Dit attribuut geeft de herkomst van de procesdata aan. In deze weergave is de waarde bijvoorbeeld statisch 'Zendesk Support', wat betekent dat alle gebeurtenissen en attributen uit dat systeem afkomstig zijn. Wanneer data uit meerdere systemen wordt gecombineerd, is dit veld belangrijk om verschillende bronnen van elkaar te onderscheiden. Het helpt de dataintegriteit te bewaken en maakt bron specifieke analyses mogelijk, zoals een vergelijking van het incidentbeheerproces in Zendesk met dat in een andere ITSM-tool. Waarom dit belangrijk is Geeft de herkomst van de data aan. Dat is belangrijk voor datagovernance en analyses waarin data uit meerdere bronsystemen wordt gecombineerd. Waar je het vindt 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 vernieuwd.
Beschrijving Dit attribuut legt de datum en tijd vast van de meest recente data-extractie of update uit het bronsysteem. Meestal is dit één waarde voor de volledige dataset uit een bepaalde vernieuwingscyclus. Deze informatie is belangrijk voor datagovernance en voor gebruikers van de process-mininganalyse. Je ziet hoe actueel de data is en kunt beter beoordelen of je de meest recente beschikbare informatie bekijkt. Dat is vooral relevant bij het monitoren van prestaties in de bedrijfsvoering en het nemen van tijdige beslissingen op basis van de analyse. Waarom dit belangrijk is Geeft belangrijke context over de actualiteit van de data. Zo weten gebruikers hoe actueel de analyse is en wanneer de data voor het laatst uit de bron is opgehaald. Waar je het vindt Timestamp die door het ETL-/datapipelineproces wordt gegenereerd nadat de data is vernieuwd. Voorbeelden 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Eindtijd van event EventEndTime	De timestamp die aangeeft wanneer een activiteit is voltooid.
Beschrijving De eindtijd van een event markeert het einde van een activiteit. In event log-data wordt de eindtijd van een activiteit vaak afgeleid van de starttijd van de volgende activiteit in de reeks voor die case. Bij de laatste activiteit in een case kan de eindtijd gelijk zijn aan de starttijd. Dit attribuut is nodig om de duur van afzonderlijke activiteiten (ProcessingTime) en de wachttijd tussen activiteiten te berekenen. Deze informatie vormt de basis voor bottleneckanalyse. Je ziet dan niet alleen hoe lang een stap duurt, maar ook hoe lang de case inactief was voordat die stap begon. Waarom dit belangrijk is Maakt het mogelijk om activiteitenduren en wachttijden te berekenen. Dat is nodig voor een gedetailleerde bottleneckanalyse en het vinden van vertragingen in het proces. Waar je het vindt Berekend als de starttijd van het volgende event binnen dezelfde case. De eindtijd van het laatste event kan gelijk zijn aan de starttijd of aan het moment waarop de case wordt gesloten. Voorbeelden 2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
	Meldingskanaal Channel	Het kanaal waarlangs het incident oorspronkelijk is gemeld, zoals 'E-mail', 'Web' of 'API'.
Beschrijving Dit attribuut legt vast hoe de eindgebruiker of het systeem het incidentticket heeft aangemaakt. Inzicht in het kanaal is belangrijk om de bronnen van incidenten te analyseren en het supportproces daarop af te stemmen. Door incidenten per kanaal te analyseren, kunnen verschillende patronen zichtbaar worden. Incidenten die telefonisch worden gemeld, hebben bijvoorbeeld mogelijk een kortere oplostijd dan incidenten die per e-mail binnenkomen. Deze informatie ondersteunt het dashboard 'Incident Throughput Volume' en helpt bij capaciteitsplanning en het verbeteren van kanalen. Waarom dit belangrijk is Helpt incidentvolumes en procesprestaties per bron te analyseren, zodat je processen en de inzet van bronnen per kanaal kunt verbeteren. Waar je het vindt Zendesk Tickets API, veld via.channel. Voorbeelden WebE-mailAPITelefoon
	Prioriteit TicketPriority	Het prioriteitsniveau dat aan het incident is toegewezen, zoals 'Low', 'Normal', 'High' of 'Urgent'.
Beschrijving De prioriteit van een incident bepaalt hoe snel je moet reageren en het incident moet oplossen. Het is een belangrijke factor bij het prioriteren van werk en verdelen van bronnen binnen het supportteam. In procesanalyses gebruik je prioriteit om incidenten te segmenteren en hun procesflows en prestaties te vergelijken. Analisten kunnen bijvoorbeeld controleren of 'Urgent'-incidenten inderdaad sneller worden opgelost dan incidenten met prioriteit 'Low'. Prioriteit wordt ook gebruikt om SLA-compliance te monitoren, omdat SLA's vaak op prioriteitsniveaus zijn gebaseerd. De KPI 'Priority Change Rate' is gebaseerd op wijzigingen in dit veld. Waarom dit belangrijk is Dit attribuut is belangrijk voor het segmenteren van analyses, het beoordelen van de effectiviteit van prioritering en het monitoren van SLA-compliance voor verschillende urgentieniveaus. Waar je het vindt 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 schema ligt om de vastgestelde SLA-doelen te halen, deze al heeft overschreden of dat de SLA-timers zijn gepauzeerd. Zendesk houdt SLA-statistieken automatisch bij op basis van geconfigureerde beleidsregels. Dit is een belangrijk attribuut voor het dashboard 'SLA Compliance Monitoring'. Het geeft een directe maatstaf voor prestaties ten opzichte van serviceverplichtingen. Door te analyseren wanneer en waarom SLA's worden overschreden, kunnen organisaties zwakke plekken in het proces vinden en de betrouwbaarheid van de service verbeteren. Het ondersteunt rechtstreeks de KPI 'Incident SLA Adherence Rate'. Waarom dit belangrijk is Meet rechtstreeks de prestaties ten opzichte van serviceverplichtingen. Zo kun je SLA-overschrijdingen analyseren en compliance proactief bewaken. Waar je het vindt Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), afgeleid van velden zoals sla_policy en breached_at. Voorbeelden ActiefGepauzeerdSLA overschredenAfgehandeld
	Ticketstatus TicketStatus	De status van het incidentticket op het moment van de gebeurtenis, zoals 'Open', 'Pending' of 'Solved'.
Beschrijving Dit attribuut laat de status van het incidentticket op verschillende momenten in de levenscyclus zien. Standaardstatussen in Zendesk zijn new, open, pending, on-hold, solved en closed. Door wijzigingen in dit veld te volgen, kun je activiteiten voor process mining genereren. Door de ticketstatus te analyseren, zie je beter hoe het proces verloopt. Je ontdekt hoeveel tijd incidenten in bepaalde statussen doorbrengen, zoals 'Pending', wat vaak betekent dat je op een reactie van de klant wacht. De status is ook belangrijk om het einde van een case te bepalen en oplostijden te berekenen. Waarom dit belangrijk is Het volgen van statuswijzigingen is belangrijk om de voortgang van het proces en wachttijden te begrijpen en de begin- en eindpunten van de levenscyclus van een incident vast te stellen. Waar je het vindt Zendesk Tickets API, veld status. Wijzigingen worden vastgelegd in de Ticket Audits API. Voorbeelden NieuwOpenIn afwachtingOpgelostGesloten
	Toegewezen agent Assignee	De individuele supportagent die op dat moment verantwoordelijk is voor de afhandeling van het incident.
Beschrijving Dit attribuut identificeert de agent die op een bepaald moment verantwoordelijk is voor het incident. Wijzigingen in de toegewezen agent zijn belangrijke gebeurtenissen, omdat ze aangeven dat het werk van de ene persoon naar de andere wordt overgedragen. Door de toegewezen agent te analyseren, krijg je inzicht in de verdeling van de werklast, individuele prestaties en samenwerkingspatronen. Het volgen van wijzigingen in dit veld is nodig om de KPI 'Average Handoffs per Incident' te berekenen en situaties op te sporen waarin incidenten vaak worden doorgegeven. Dat kan wijzen op kennishiaten of inefficiënte routering. Waarom dit belangrijk is Identificeert de verantwoordelijke agent. Zo kun je de werklast analyseren en overdrachten volgen, wat belangrijk is om inefficiënties in het proces op te sporen. Waar je het vindt Zendesk Tickets API, veld assignee_id. Wijzigingen worden vastgelegd in de Ticket Audits API. Voorbeelden John SmithJane DoeServicedeskautomatisering
	Toegewezen groep AssignedGroup	Het supportteam of de groep die op dat moment verantwoordelijk is voor het incident.
Beschrijving Dit attribuut geeft aan welk team verantwoordelijk is voor het incident. Incidenten gaan vaak tussen verschillende supportniveaus of gespecialiseerde groepen heen en weer, bijvoorbeeld van 'L1 Support' naar het 'Network Team'. Dit is een belangrijke dimensie voor het analyseren van procesoverdrachten en het opsporen van knelpunten. Door te volgen hoe incidenten tussen groepen bewegen, kunnen analisten afhankelijkheden tussen teams meten, wachttijden per team berekenen en routeringsregels verbeteren. Het ondersteunt rechtstreeks het dashboard 'Handoffs and Rework Analysis'. Waarom dit belangrijk is Volgt welk team verantwoordelijk is. Dat is belangrijk voor het analyseren van overdrachten tussen teams, het opsporen van teamspecifieke knelpunten en het meten van wachttijden. Waar je het vindt Zendesk Tickets API, veld group_id. Wijzigingen worden vastgelegd in de Ticket Audits API. Voorbeelden Ondersteuning niveau 1Netwerkteam niveau 2Infrastructuur niveau 3Facturatie
	Aantal overdrachten HandoffCount	Het totale aantal keer dat een incident opnieuw aan een andere agent of groep is toegewezen.
Beschrijving Deze berekende maatstaf telt hoe vaak de verantwoordelijkheid voor een incident is overgedragen. Elke wijziging in het veld Assignee of AssignedGroup verhoogt deze teller voor de case. Overdrachten veroorzaken vaak inefficiëntie en vertraging in incidentbeheer. Een hoog aantal overdrachten kan wijzen op onduidelijke routeringsregels, kennishiaten in supportteams of onnodig complexe processen. Deze maatstaf vormt de basis voor de KPI 'Average Handoffs per Incident' en is belangrijk voor het dashboard 'Handoffs and Rework Analysis'. Waarom dit belangrijk is Maakt procesfrictie door overdrachten meetbaar. Zo kun je inefficiënte routering en kennishiaten vinden die de oplostijd verlengen. Waar je het vindt Berekend door te tellen hoe vaak het veld AssignedGroup of Assignee voor een incident is gewijzigd. Voorbeelden 0135
	Categorie van de hoofdoorzaak RootCauseCategory	De hoofdcategorie van de onderliggende oorzaak van het incident.
Beschrijving Met dit attribuut classificeer je de fundamentele reden waarom een incident is ontstaan. Het wordt meestal tegen het einde van de levenscyclus van een incident vastgelegd, vaak als onderdeel van een post-mortem of probleembeheerproces, en opgeslagen in een aangepast veld. Deze data is belangrijk voor het dashboard 'Root Cause Identification Accuracy' en de KPI 'RCA Coverage'. Door incidenten op hoofdoorzaak te analyseren, vind je terugkerende problemen. Dat helpt bij het invoeren van permanente oplossingen en het verminderen van het aantal toekomstige incidenten. De focus verschuift zo van reactief brandjes blussen naar het proactief voorkomen van problemen. Waarom dit belangrijk is Ondersteunt proactief probleembeheer door incidentoorzaken te categoriseren. Zo kun je trends herkennen en toekomstige incidenten voorkomen. Waar je het vindt Dit is meestal een aangepast ticketveld. Controleer de configuratie van Ticket Fields in het Zendesk Admin Center. Voorbeelden SoftwarebugHardwarestoringGebruikersfoutNetwerkstoring
	Duur van de case CaseDuration	De totale verstreken tijd vanaf het aanmaken van het incident tot de definitieve sluiting.
Beschrijving Deze berekende maatstaf geeft de end-to-end-doorlooptijd van één incident weer. Je berekent deze door het verschil te nemen tussen de timestamp van het eerste event, bijvoorbeeld 'Incident Created', en die van het laatste event, bijvoorbeeld 'Incident Closed'. Case Duration is een belangrijke KPI voor de efficiëntie van het totale proces. Je gebruikt deze veel in dashboards om gemiddelde doorlooptijden te tonen, langlopende cases te vinden en trends in de tijd te analyseren. De maatstaf geeft op hoofdlijnen aan hoe snel het proces incidenten kan afhandelen en oplossen. Waarom dit belangrijk is Dit is een belangrijke KPI om de snelheid van het totale proces te meten en factoren te vinden die bijdragen aan lange oplostijden. Waar je het vindt Berekend door voor elke Incident ID het verschil te bepalen tussen de timestamp van het laatste en het eerste event. Voorbeelden 25920060480086400
	Ernst Severity	De impact die het incident op de bedrijfsvoering heeft.
Beschrijving De ernst bepaalt de impact van een incident op de bedrijfsvoering. Vaak wordt deze samen met de prioriteit gebruikt om de totale urgentie te bepalen. In Zendesk is dit meestal een aangepast veld. Door de ernst te analyseren, krijg je inzicht in de kritieke aard van de afgehandelde incidenten. Het is een belangrijke dimensie voor het segmenteren van data in dashboards zoals 'SLA Compliance Monitoring' en 'Prioritization Effectiveness Metrics'. Door processtromen voor verschillende ernstniveaus te vergelijken, zie je of incidenten met een hoge ernst snel genoeg en met de juiste bronnen worden afgehandeld. Waarom dit belangrijk is Geeft de impact van een incident op de bedrijfsvoering aan. Zo kun je de meest kritieke problemen analyseren en zorgen dat ze efficiënt worden opgelost. Waar je het vindt Dit is meestal een aangepast veld. Controleer de configuratie van Ticket Fields in het 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 identificeert de persoon of entiteit die het ticket heeft aangemaakt. Dat is niet hetzelfde als de aanvrager, omdat een agent namens iemand anders een ticket kan aanmaken. In analyses kun je de indiener gebruiken om te begrijpen wie problemen meldt. In combinatie met organisatiegegevens helpt dit om vast te stellen of specifieke klanten of gebruikersgroepen veel incidenten veroorzaken. Dat kan richting geven aan proactieve support of trainingen. Waarom dit belangrijk is Identificeert de bron van de incidentmelding. Je kunt deze analyseren om patronen bij specifieke gebruikers, afdelingen of geautomatiseerde systemen te vinden. Waar je het vindt Zendesk Tickets API, veld submitter_id. Voorbeelden alice.jones@example.combob.williams@example.comSysteembewaking
	Is geautomatiseerd IsAutomated	Een boolean-vlag die aangeeft of een activiteit door een geautomatiseerd systeem of een menselijke agent is uitgevoerd.
Beschrijving Met dit afgeleide attribuut maak je onderscheid tussen events die door menselijke gebruikers zijn uitgevoerd en events die afkomstig zijn van systeemautomatiseringen, triggers of API-integraties. Meestal bepaal je dit door te controleren of de auteur van een event een bekende systeemgebruiker is. Inzicht in de mate van automatisering is belangrijk voor moderne procesanalyse. Je kunt hiermee de effectiviteit van automatiseringsregels beoordelen, handmatige taken vinden die je kunt automatiseren en het effect van automatisering op efficiëntie en oplostijden meten. Ook kun je de processtromen van geautomatiseerde en handmatige activiteiten vergelijken. Waarom dit belangrijk is Maakt onderscheid tussen menselijke en systeemacties. Dat is belangrijk om het effect van automatisering op procesefficiëntie te analyseren en nieuwe mogelijkheden voor automatisering te vinden. Waar je het vindt Afgeleid door te controleren of de auteur van het event (author_id in de Ticket Audits API) overeenkomt met een bekende systeem- of automatiseringsgebruiker. Voorbeelden truefalse
	Is opgelost bij eerste contact IsFirstContactResolution	Een boolean-vlag die waar is als het incident door de eerst toegewezen agent of groep is opgelost, zonder overdrachten.
Beschrijving First Contact Resolution (FCR) is een belangrijke maatstaf voor de efficiëntie van een supportcenter en de klanttevredenheid. Dit berekende attribuut markeert incidenten die zijn opgelost zonder toewijzing aan een andere agent of een ander team. De logica controleert meestal of het ticket de status 'Solved' kreeg terwijl het nog aan de oorspronkelijke agent en groep was toegewezen. In process mining kun je hiermee het FCR-percentage rechtstreeks berekenen. Ook kun je de procesroutes van FCR-incidenten vergelijken met incidenten waarvoor escalatie nodig was. Zo vind je mogelijkheden om eerstelijnssupport meer bevoegdheden te geven. Waarom dit belangrijk is Meet rechtstreeks de efficiëntie van het eerste supportcontact en helpt mogelijkheden te vinden om de oplossing eerder in het proces te realiseren. Waar je het vindt Berekende boolean-vlag. Waar als de ticketstatus 'solved' of 'closed' is en er gedurende de levenscyclus van het incident slechts één unieke toegewezen agent of groep was. 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. Het is belangrijk in B2B-supportomgevingen waar serviceniveaus en supportprocessen per klant kunnen verschillen. Door incidenten per organisatie te analyseren, kunnen supportteams de klantgezondheid volgen, terugkerende problemen bij specifieke klanten opsporen en controleren of contractuele verplichtingen worden nagekomen. Het is een belangrijke dimensie voor filters in dashboards en rapporten, zodat je prestaties vanuit het perspectief van de klant kunt bekijken. Waarom dit belangrijk is Maakt klantspecifieke analyses mogelijk. Zo kun je serviceniveaus volgen, trends bij belangrijke accounts herkennen en klantrelaties effectief beheren. Waar je het vindt Zendesk Tickets API, veld organization_id. Voorbeelden Global Tech Inc.Innovate SolutionsData Corp
	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. Agents kunnen ze handmatig toevoegen, maar triggers en automatiseringen kunnen dit ook automatisch doen. Tags zijn een waardevolle bron voor process mining-analyses. Je kunt ze gebruiken om zeer specifieke segmenten te maken, bijvoorbeeld door te filteren op incidenten rond een specifieke productlancering ('launch_q4') of een bekende storing ('outage_20231027'). Zo kun je gerichte onderzoeken uitvoeren die verder gaan dan de standaardticketvelden. Waarom dit belangrijk is Biedt een flexibele manier om incidenten te categoriseren en filteren. Zo kun je gedetailleerde analyses uitvoeren die rekening houden met de specifieke context en die met alleen standaardvelden misschien niet mogelijk zijn. Waar je het vindt 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 legt de feedback van de klant over de supportervaring vast. Die feedback wordt meestal verzameld via een enquête nadat het ticket is opgelost. Veelgebruikte beoordelingen in Zendesk zijn 'Good' en 'Bad'. Tevredenheidsscores meten niet rechtstreeks de efficiëntie van het proces, maar geven wel een belangrijke uitkomstmaatstaf. In process mining kun je deze scores koppelen aan procesvarianten om te zien welke oplossingsroutes tot een hogere klanttevredenheid leiden. Krijgen incidenten met meer overdrachten bijvoorbeeld lagere beoordelingen? Waarom dit belangrijk is Geeft een belangrijke uitkomstmaatstaf die je kunt koppelen aan proceskenmerken. Zo zie je hoe de procesprestaties de tevredenheid van gebruikers beïnvloeden. Waar je het vindt Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), veld satisfaction_rating.score. Voorbeelden GoedSlechtAangebodenNiet aangeboden
	Tickettype TicketType	De classificatie van het ticket, zoals 'Incident', 'Probleem', 'Vraag' of 'Taak'.
Beschrijving Dit veld deelt het ticket in op basis van de aard van het verzoek. Het incidentbeheerproces richt zich specifiek op tickets met het type 'Incident'. Dit staat voor een ongeplande onderbreking of kwaliteitsvermindering van een IT-service. In analyses gebruik je dit attribuut vooral als filter, zodat alleen incidenten in de procesweergave worden opgenomen. Je kunt het ook gebruiken voor bredere ITSM-analyses, bijvoorbeeld om de processen voor incidenten, problemen en serviceverzoeken met elkaar te vergelijken. Waarom dit belangrijk is Hiermee kun je de data filteren op incidenten, zodat de procesanalyse aansluit op de levenscyclus van incidentbeheer. Waar je het vindt Zendesk Tickets API, veldtype. Voorbeelden IncidentProbleemVraagTaak

Verplicht Aanbevolen Optioneel

Incidentbeheeractiviteiten

Dit zijn de essentiële processtappen en mijlpalen die je in je event log moet vastleggen 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. Deze gebeurtenis wordt expliciet vastgelegd in het auditlog voor het aanmaken van tickets in Zendesk en vormt het startpunt van elke case.
Waarom dit belangrijk is Dit is de primaire startactiviteit. Door de tijd tussen deze gebeurtenis en andere gebeurtenissen te analyseren, meet je de totale duur van de ticketlevenscyclus en de eerste responstijd. Waar je het vindt Dit is een expliciete gebeurtenis in de auditlogs van Zendesk-tickets. Elk nieuw ticket genereert een 'Create'-gebeurtenis met een bijbehorende timestamp. Vastleggen Rechtstreeks afkomstig uit de gebeurtenis voor het aanmaken van het ticket in het auditlog. Eventtype 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 bepaalde periode nadat het ticket is opgelost. Het wordt vastgelegd als een laatste statuswijziging.
Waarom dit belangrijk is Dit is de definitieve eindactiviteit van het proces. De totale procesduur wordt berekend van 'Incident Created' tot deze gebeurtenis, zodat je de doorlooptijd van begin tot eind ziet. Waar je het vindt 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. Eventtype explicit
	Incident opgelost	Deze belangrijke mijlpaal vindt plaats wanneer een agent een oplossing heeft geïmplementeerd en het ticket als 'solved' markeert. Dit is een expliciete actie die als statuswijziging in het auditlog van het ticket wordt vastgelegd.
Waarom dit belangrijk is Dit is de primaire oplossingsactiviteit en een belangrijk meetpunt voor de oplostijd. De tijd tussen deze gebeurtenis en 'Incident Closed' staat voor de periode waarin de gebruiker bevestigt of het ticket automatisch wordt gesloten. Waar je het vindt 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. Eventtype explicit
	Status gewijzigd naar Open	Dit geeft aan dat een agent actief aan het incident is begonnen te werken. De activiteit wordt meestal afgeleid uit een wijziging van het veld 'status' van 'new' naar 'open'. Daarmee begint de onderzoeks- en diagnosefase.
Waarom dit belangrijk is Deze gebeurtenis markeert de overgang van wachten in de wachtrij naar actief werk. De tijd die tickets in de status 'new' doorbrengen voordat ze naar 'open' gaan, is een belangrijke maatstaf voor de eerste responstijd. Waar je het vindt Afgeleid uit het auditlog van het ticket door een 'Change'-gebeurtenis te herkennen waarbij de nieuwe waarde van het veld 'status' 'open' is en de vorige waarde 'new' was. Vastleggen Afgeleid uit een wijziging van het statusveld van 'new' naar 'open'. Eventtype inferred
	Ticket opnieuw toegewezen	Dit gebeurt wanneer het eigenaarschap van een ticket na de eerste toewijzing van de ene agent of groep naar een andere wordt overgedragen. Het is een expliciete gebeurtenis in de auditgeschiedenis van het ticket.
Waarom dit belangrijk is Nieuwe toewijzingen zijn belangrijk voor het analyseren van overdrachten en herhaald werk. Een hoge frequentie wijst vaak op een onjuiste eerste routering, complexe problemen of knelpunten in het proces. Waar je het vindt Afkomstig uit het auditlog van het ticket door een 'Change'-gebeurtenis voor het veld 'assignee_id' of 'group_id' te herkennen nadat het veld voor het eerst was ingevuld. Vastleggen Herkenbaar aan een volgende 'Change'-gebeurtenis voor het veld 'assignee_id' of 'group_id'. Eventtype explicit
	Ticket toegewezen aan agent	Deze activiteit vindt plaats wanneer een ticket aan een specifieke agent wordt toegewezen. Het is een expliciete gebeurtenis in de auditgeschiedenis van het ticket en geeft aan dat iemand de verantwoordelijkheid heeft overgenomen.
Waarom dit belangrijk is Deze mijlpaal is belangrijk om de tijd tot de eerste toewijzing te meten. Ook vormt hij de basis voor analyses van overdrachten, herhaald werk en het oplossingspercentage bij het eerste contact. Waar je het vindt Afkomstig uit het auditlog van het ticket wanneer het veld 'assignee_id' wordt ingevuld of gewijzigd. De eerste toewijzing is een belangrijke mijlpaal voor KPI-berekeningen. Vastleggen Herkenbaar aan een 'Change'-gebeurtenis voor het veld 'assignee_id' in het auditlog van het ticket. Eventtype 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 Door interne notities te analyseren, krijg je inzicht in complexe problemen waarvoor samenwerking nodig is. Een groot aantal notities kan echter wijzen op kennishiaten of inefficiënties in het proces. Waar je het vindt Afkomstig uit de commentaardata van het ticket. Een opmerking is een interne notitie wanneer het attribuut 'public' de waarde false heeft. Vastleggen Gebeurtenis die wordt vastgelegd wanneer een nieuwe opmerking met 'public: false' aan het ticket wordt toegevoegd. Eventtype explicit
	Openbaar antwoord verzonden	Dit staat voor communicatie van een supportagent naar de eindgebruiker. Het is een expliciete gebeurtenis in Zendesk, die wordt vastgelegd wanneer een openbare opmerking aan het ticket wordt toegevoegd.
Waarom dit belangrijk is Door openbare antwoorden te volgen, krijg je inzicht in de communicatie frequentie. Ze vormen ook een belangrijk onderdeel van de tijdlijn bij het analyseren van vertragingen in gebruikersbevestigingen. Waar je het vindt Afkomstig uit de commentaardata van het ticket. Een opmerking is openbaar wanneer het attribuut 'public' de waarde true heeft. Vastleggen Gebeurtenis die wordt vastgelegd wanneer een nieuwe opmerking met 'public: true' aan het ticket wordt toegevoegd. Eventtype explicit
	Prioriteit ingesteld	Het prioriteitsniveau van een incident, bijvoorbeeld Low, Normal, High of Urgent, wordt vastgesteld. Dit wordt als expliciete wijzigingsgebeurtenis vastgelegd en bepaalt de urgentie en benodigde responstijd van het ticket.
Waarom dit belangrijk is Door te volgen wanneer en hoe de prioriteit wordt ingesteld, kun je het dashboard 'Prioritization Effectiveness Metrics' voeden en ervoor zorgen dat kritieke problemen snel worden opgepakt. Waar je het vindt Afkomstig uit een 'Change'-gebeurtenis voor het veld 'priority' in het auditlog van het ticket. Latere wijzigingen kunnen ook worden gevolgd om de KPI Priority Change Rate te meten. Vastleggen Herkenbaar aan een 'Change'-gebeurtenis voor het veld 'priority' in het auditlog van het ticket. Eventtype explicit
	SLA-doel overschreden	Dit markeert het moment waarop een ticket niet aan een vastgesteld Service Level Agreement voldoet, bijvoorbeeld voor de eerste reactietijd of de oplostijd. De gebeurtenis wordt berekend op basis van SLA-beleidsregels en timestamps van ticketupdates.
Waarom dit belangrijk is Deze gebeurtenis ondersteunt het monitoren van SLA-compliance rechtstreeks. Door vast te stellen wanneer en waarom overschrijdingen ontstaan, kun je de betrouwbaarheid van de dienstverlening en het vertrouwen van klanten verbeteren. Waar je het vindt Dit is een berekende gebeurtenis. Je kunt deze afleiden door de data in 'sla_policy_metrics' voor een ticket te analyseren en de timestamp 'breached_at' voor elk SLA-doel te gebruiken. Vastleggen Afgeleid uit de timestamp 'breached_at' in de SLA-metriekdata van het ticket. Eventtype calculated
	Status gewijzigd naar Pending	Dit geeft aan dat het proces is gepauzeerd omdat het wacht op een reactie van de aanvrager. De gebeurtenis wordt afgeleid uit een wijziging van het veld 'status' van het ticket naar 'pending'.
Waarom dit belangrijk is Deze activiteit is belangrijk voor het berekenen van de wachttijd op gebruikersbevestiging. Een lange duur in deze status kan de totale doorlooptijd aanzienlijk verhogen en communicatievertragingen zichtbaar maken. Waar je het vindt Afgeleid uit het auditlog van het ticket door een 'Change'-gebeurtenis te herkennen waarbij de nieuwe waarde van het veld 'status' 'pending' is. Vastleggen Afgeleid uit een wijziging van het statusveld naar 'pending'. Eventtype inferred
	Tevredenheid van gebruiker beoordeeld	Dit is het moment waarop de eindgebruiker een tevredenheidsscore geeft voor de ontvangen ondersteuning. Het is een expliciete gebeurtenis die in Zendesk wordt vastgelegd nadat een ticket is opgelost.
Waarom dit belangrijk is Door tevredenheidsscores te analyseren, krijg je belangrijke feedback over de prestaties van agents en de effectiviteit van het proces. Zo verbind je procesmetingen met klantresultaten. Waar je het vindt Afkomstig uit de tevredenheidsdata die aan het ticket is gekoppeld. Deze bevat meestal een score ('good' of 'bad') en eventueel een opmerking. Vastleggen Gebeurtenis die wordt vastgelegd wanneer een tevredenheidsscore voor het ticket wordt ingediend. Eventtype explicit
	Ticket toegewezen aan groep	Dit staat voor de eerste routering of triage van een incident naar een specifieke supportgroep. Meestal is dit de eerste stap bij het toewijzen van verantwoordelijkheid. De stap wordt als expliciete wijzigingsgebeurtenis 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 je het vindt Afkomstig uit het auditlog van het ticket wanneer het veld 'group_id' wordt ingevuld of gewijzigd. De eerste wijziging na het aanmaken geldt als de eerste toewijzing. Vastleggen Herkenbaar aan een 'Change'-gebeurtenis voor het veld 'group_id' in het auditlog van het ticket. Eventtype explicit

Aanbevolen Optioneel

Extractiegidsen

Zo haal je je data uit Zendesk Support

Stappen

Open Zendesk Explore: Log in op je Zendesk Support-instantie met een gebruikersaccount dat rapporten in Zendesk Explore mag maken en beheren.
Maak een nieuw rapport: Ga naar de Explore-module. Klik in de navigatiebalk links op het pictogram 'Reports' en klik daarna op de knop 'New report'.
Selecteer de dataset: Selecteer in het venster 'Choose a dataset' de dataset Support: Ticket updates [default]. Deze dataset bevat de audit trail van elke ticketwijziging en is nodig om een event log te maken.
Voeg de eerste attributen toe (kolommen): 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' en selecteer 'Standard calculated attribute'. Maak de drie attributen uit het gedeelte 'Query': ActivityName, SourceSystem en LastDataUpdate. Kopieer de aangeleverde formules exact.
Verfijn de rapportkolommen: Voeg de nieuwe berekende attributen, ActivityName, SourceSystem en LastDataUpdate, toe aan het gedeelte 'Rows'. Je kunt de ruwe velden die voor ActivityName zijn gebruikt, Changes - Field name, Changes - Previous value, Changes - New value en Comment public, nu verwijderen 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 selecteer een geschikte periode, bijvoorbeeld de afgelopen 3 maanden. Voeg ook een filter toe op 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 de datatabel om te zien of de rijen en kolommen kloppen. Het rapport moet één rij per event tonen.
Exporteer de data naar CSV: Klik rechtsboven op 'Export' zodra het rapport klaar is en selecteer 'CSV'. Zendesk maakt het CSV-bestand en downloadt het.
Bereid de upload voor: Open het geëxporteerde CSV-bestand. Hernoem de kolomkoppen zodat ze overeenkomen met de vereiste attribuutnamen van je process mining-tool, bijvoorbeeld 'Ticket ID' naar TicketId en 'Update - Timestamp' naar EventTimestamp. Controleer of de datumnotatie van timestamps voldoet aan ISO 8601. Het bestand is nu klaar om te uploaden.

Configuratie

Zendesk-dataset: Het rapport moet zijn gebaseerd op de dataset Support: Ticket updates [default]. Dit is de enige standaarddataset met de gedetailleerde audit trail die nodig is om het proces event voor event te reconstrueren.
Filter op datumbereik: Het is belangrijk om een datumfilter toe te passen om de hoeveelheid data te beperken. Gebruik het attribuut Update - Date als primaire filter. Voor een eerste analyse wordt meestal een periode van 3 tot 6 maanden aanbevolen.
Activiteitenfilter: Nadat je het berekende attribuut ActivityName hebt gemaakt, moet je het rapport filteren op niet-lege waarden. Zo verwijder je irrelevante ticketwijzigingen, zoals systeemupdates en tagwijzigingen, uit je event log.
Berekende attributen: Deze extractie steunt sterk op een standaard berekend attribuut dat ruwe ticketveldwijzigingen omzet in begrijpelijke activiteitennamen. 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 de rechten 'Editor' of 'Admin' vereist.

a Voorbeeldquery config

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

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

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

**3. Standard Calculated Attribute Formulas:**

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

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

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

Stappen

Vereisten: Zorg dat Python 3.6 of hoger op je systeem is geïnstalleerd, samen met de libraries requests en pandas. Je kunt deze installeren met pip: pip install requests pandas.
Genereer een Zendesk API-token: Log als beheerder in op je Zendesk Support-instantie. Ga naar Admin Center > Apps and integrations > APIs > Zendesk APIs. Voeg onder "API Tokens" een nieuw actief API-token toe en bewaar de gegenereerde tokenreeks veilig.
Configureer het Python-script: Maak een nieuw Python-bestand, bijvoorbeeld extract_zendesk_logs.py, en kopieer het aangeleverde script daarin. Werk de placeholdervariabelen bovenaan het script bij: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL en ZENDESK_API_TOKEN met je eigen gegevens. Stel START_TIMESTAMP in op het begin van de gewenste extractieperiode, als Unix epoch-timestamp.
Begrijp de API-endpoints: Het script gebruikt vooral twee Zendesk API-endpoints. Het endpoint incremental/tickets/cursor.json haalt efficiënt alle tickets op die sinds START_TIMESTAMP zijn bijgewerkt. Daarna roept het script voor elk ticket het endpoint tickets/{ticket_id}/audits.json aan voor een gedetailleerde geschiedenis van alle wijzigingen en events.
Voer het script uit: Start het script in je terminal met het commando: python extract_zendesk_logs.py. Het script begint data op te halen uit de Zendesk API.
Volg de voortgang: Het script toont in de console hoeveel tickets zijn verwerkt. Afhankelijk van de periode en het aantal tickets kan dit behoorlijk wat tijd kosten.
Data ophalen en paginering: 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 voor de periode zijn opgehaald.
Events omzetten: Voor elk ticket doorloopt het script de auditgeschiedenis. Het leest elk audit-event uit en koppelt interne Zendesk-eventtypen, zoals Create, Change en Comment, aan 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-metingen voor elk opgelost ticket op te halen. Dit is nodig omdat SLA-overschrijdingen geen standaardevents in de auditlog zijn. De functie doet een extra API-aanroep voor de details van de toegepaste SLA-regel.
Maak het event log: Nadat alle tickets zijn verwerkt, zet het script de geëxtraheerde events in een pandas DataFrame en slaat het uiteindelijke event log op als zendesk_incident_event_log.csv in dezelfde map als waarin het script is uitgevoerd.
Bereid de upload voor: Controleer of het gegenereerde CSV-bestand klopt. Het bestand heeft nu het vereiste formaat en kan rechtstreeks in ProcessMind worden geüpload voor analyse.

Configuratie

Zendesk API-inloggegevens: Je moet je Zendesk-subdomein, het e-mailadres van een beheerder- of agentaccount en een geldig API-token opgeven. Bewaar deze gegevens veilig en zet ze voor productiegebruik niet hardcoded in scripts die onder versiebeheer staan.
Starttimestamp (START_TIMESTAMP): Deze gehele waarde bepaalt het beginpunt van de data-extractie. Het moet een Unix epoch-timestamp zijn. Een aanbevolen startpunt is 3 tot 6 maanden geleden, zodat je voldoende data verzamelt zonder het systeem te zwaar te belasten. Gebruik een online converter om de juiste timestamp voor een specifieke datum te bepalen.
API-rate limiting: Het script doet veel API-aanroepen. Zendesk hanteert limieten die per abonnement verschillen. Voor gemiddelde datavolumes werkt het script goed, maar bij zeer grote instanties moet je mogelijk time.sleep()-aanroepen in de lussen toevoegen om de limiet niet te overschrijden en een 429-fout te voorkomen.
Vereiste Python-libraries: Het script gebruikt de library requests voor API-aanroepen en pandas voor dataverwerking en CSV-export. Zorg dat deze in je Python-omgeving zijn geïnstalleerd.
Gebruikersrechten: Het gebruikersaccount dat bij het API-token hoort, moet voldoende rechten hebben om ticketdata te lezen, inclusief audits en ticketmetingen.

a Voorbeeldquery python

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

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

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

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

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

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

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

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

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

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

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

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

    return all_events

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

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

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

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

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

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

Stappen

Maak een Zendesk API-client met rechten om tickets, ticketaudits, gebruikers, groepen, tevredenheidsbeoordelingen en incrementele exports te lezen. Gebruik een API-token of OAuth-inloggegeven dat voor je Zendesk Support-instantie is ingesteld. Bewaar het subdomein, de inloggegevens en de extractiewatermark als beveiligde configuratiewaarden.
Gebruik de Zendesk Incremental Ticket Export API om tickets op te halen die na de vorige succesvolle watermark zijn bijgewerkt. Het onderstaande script gebruikt het gedocumenteerde endpointpatroon, https://[Your Zendesk subdomain].zendesk.com/api/v2/incremental/tickets/cursor.json, en volgt de cursorpaginering totdat de API meldt dat de resultatenset compleet is.
Vraag voor elk opgehaald ticket de auditgeschiedenis op via het ticketaudits-endpoint. Auditrecords zijn nodig omdat ProcessMind het event log ongewijzigd leest en activiteiten niet afleidt uit de uiteindelijke ticketstatus. Bewaar de audittimestamp, actor, ticketidentificatie en audit-events.
Zet audit-events om in expliciete eventrijen. Haal het aanmaken van tickets, groepstoewijzingen, agenttoewijzingen, prioriteitswijzigingen, statuswijzigingen naar open, openbare antwoorden, interne notities, herverdelingen, statuswijzigingen naar pending, opgeloste status en gesloten status op. Haal tevredenheidsbeoordelingen als aparte rijen op wanneer de beoordeling beschikbaar is. Bereken SLA-overschrijdingen alleen wanneer de vereiste SLA-doelwaarde en eventtimestamps beschikbaar zijn en leg de gebruikte berekeningsgegevens vast.
Bewaar de laatst succesvol verwerkte updatetimestamp of cursor. Werk de watermark pas bij nadat alle pagina's, ticketaudits en optionele tevredenheidsrecords succesvol zijn opgeslagen. Gebruik voor de eerste run een afgebakende starttijd, zoals [Start date in ISO 8601 format], meestal voor een periode van drie tot zes maanden.
Vul de vereiste 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. Gebruik alleen lege waarden wanneer Zendesk het attribuut voor het event niet levert.
Verwijder duplicaten op basis van TicketId, ActivityName, EventTimestamp en, wanneer beschikbaar, een stabiele bronidentificatie van het event. Behoud meerdere geldige voorkomens van dezelfde activiteit, zoals verschillende openbare antwoorden, interne notities, toewijzingen of statuswijzigingen.
Schrijf de resulterende rijen naar CSV of een ander door ProcessMind ondersteund event-logformaat. Zorg dat timestamps ISO 8601 zijn en een expliciete UTC-offset bevatten, dat TicketId altijd hetzelfde datatype heeft, dat ActivityName-waarden exact overeenkomen met de gedocumenteerde activiteitennamen en dat LastDataUpdate voor alle rijen in dezelfde extractiebatch gelijk is.
Upload het event log naar ProcessMind en configureer Incident ID als case-identificatie, Activity als activiteitenkolom en Event Timestamp als kolom voor de eventtijd. Controleer of elke vereiste activiteit als expliciete rij aanwezig is en niet tijdens de visualisatie wordt afgeleid.

Configuratie

API-methode: Zendesk Incremental Ticket Export API met cursorpaginering. Gebruik het ticketaudits-endpoint voor extractie op eventniveau en het tevredenheidsendpoint wanneer tevredenheidsbeoordelingen zijn ingeschakeld en toegankelijk zijn.
Vereiste configuratie: Zendesk-subdomein, API-authenticatie, eerste startdatum, extractiewatermark, time-out voor aanvragen, retrybeleid en uitvoerlocatie. Vervang [Your Zendesk subdomain], [Your API email] en [Your API token] door beveiligde waarden voor je implementatie.
Datumbereik: Gebruik voor een eerste import drie tot zes maanden, tenzij een langere geschiedenis nodig is. Vraag voor terugkerende imports records op na de laatste succesvolle watermark en neem een kleine overlapperiode mee om vertraagde updates op te vangen. Verwijder daarna duplicaten.
Filters: Pas filters op bedrijf, merk, groep, organisatie, ticketformulier, kanaal of aangepaste velden alleen toe wanneer ze expliciet binnen de procesafbakening vallen. Zendesk Support gebruikt geen SAP-achtige filters voor Company Code of Document Type, tenzij deze begrippen zijn vastgelegd in geconfigureerde Zendesk-velden.
Eventbetekenis: Beschouw audit-events als de bron voor expliciete wijzigingen. Maak geen statuswijziging aan alleen omdat de huidige ticketstatus een waarde heeft. Een statusevent moet afkomstig zijn uit een audit-event of een andere gedocumenteerde bron.
SLA-configuratie: Voor SLA Target Breached heb je toegang nodig tot het toepasselijke SLA-beleid, de doelduur, de kalender met bedrijfsuren en de timestamps die nodig zijn om het doel te beoordelen. Als Zendesk een breach-event of een meting beschikbaar maakt, gebruik dan die bron. Bereken het event anders alleen met gedocumenteerde beleidsdata en bewaar de basis van de berekening.
Configuratie van tevredenheidsbeoordelingen: User Satisfaction Rated vereist dat tevredenheidsbeoordelingen zijn ingeschakeld en dat het beoordelingsrecord via de API toegankelijk is. Een opgelost ticket zonder beoordeling mag geen kunstmatig beoordelingsevent krijgen.
Prestaties: Gebruik cursorpaginering, beperkte gelijktijdigheid voor ticketaudit-aanvragen, hergebruik van verbindingen, exponentiële backoff bij rate limits en checkpoints na succesvolle batches. Vraag niet bij elke run opnieuw alle ticketaudits op.
Volledigheid: Incrementele exports kunnen tickets bevatten die na het aangevraagde tijdstip zijn bijgewerkt, maar het ophalen van audits en late updates moet apart worden verwerkt. Gebruik een overlapperiode en stabiele sleutels voor het verwijderen van duplicaten.
Vereisten: API-toegang, rechten om tickets en audits te lezen, toegang tot gebruikers en groepen voor naamkoppeling, toegang tot tevredenheidsdata wanneer nodig en toegang tot SLA-data wanneer een berekening van overschrijdingen nodig is. Welke audit-eventtypen beschikbaar zijn, kan verschillen per Zendesk-configuratie en abonnement.

a 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 geverifieerde Zendesk Support-connector. De connector moet ticketauditgeschiedenis en opmerkingen kunnen ophalen en naar je doeldatabase of bestandssysteem kunnen schrijven. Controleer of incrementele extractie, paginering, verwerking van rate limits en behoud van brontimestamps worden ondersteund.
Maak de Zendesk-verbinding in de gekozen tool. Vul het Zendesk-subdomein, de authenticatiemethode, inloggegevens of token en eventuele andere verbindingsinstellingen in via de configuratie-interface van de tool. Geef toegang tot tickets, ticketaudits, opmerkingen, gebruikers, groepen, tevredenheidsbeoordelingen en SLA-data wanneer deze objecten beschikbaar zijn in je Zendesk-abonnement en connector.
Stel het extractievenster in. Gebruik voor de eerste import een doorlopende periode van 3 tot 6 maanden en configureer daarna incrementele imports op basis van de ondersteunde updatetimestamp of audittimestamp van de connector. Bewaar de laatste succesvolle extractiewatermark buiten het event log, zodat latere runs geen events dupliceren of overslaan.
Haal de ticketdata op die nodig is voor de casecontext, waaronder de ticketidentificatie, huidige of eventstatus, toegewezen persoon, groep, prioriteit, rapportagekanaal, SLA-status en relevante updatetimestamps. Haal ook ticketauditrecords op, omdat toewijzingen, prioriteiten, statussen en andere veldwijzigingen als expliciete eventrijen moeten worden vastgelegd.
Haal ticketopmerkingen op en onderscheid openbare opmerkingen van interne notities met de indicator voor zichtbaarheid van de connector. Haal timestamps van opmerkingen, ticketidentificaties, auteursidentificaties en eventuele eind- of voltooiingstimestamps op. Maak rijen Public Reply Sent voor openbare opmerkingen en Internal Note Added voor privéopmerkingen.
Haal tevredenheidsbeoordelingen en SLA-breachrecords op wanneer de connector deze beschikbaar maakt. Als de connector SLA-breach-events niet rechtstreeks levert, configureer je de ETL-tool om overschrijdingen te berekenen op basis van de beschikbare SLA-doelwaarde, het beleid, de bedrijfsuren en ticket-eventtimestamps. Maak geen breach-rij aan tenzij de brondata of een geconfigureerde berekening aantoont dat het doel is overschreden.
Zet de opgehaalde bronrecords om in 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, wijzigingen in prioriteit aan Priority Set, statusovergangen aan de bijbehorende statusactiviteit, opmerkingen aan Public Reply Sent of Internal Note Added, een opgeloste status aan Incident Resolved, tevredenheidsrecords aan User Satisfaction Rated en een gesloten status aan Incident Closed.
Pas de classificatieregels voor events in een vaste volgorde toe. Gebruik de vorige en nieuwe waarden uit de auditgeschiedenis wanneer die beschikbaar zijn. Classificeer de eerste toewijzing aan een groep als Ticket Assigned to Group, de eerste toewijzing aan een agent als Ticket Assigned to Agent en latere wijzigingen in eigenaarschap als Ticket Reassigned. Maak een rij voor elke relevante wijziging, niet alleen voor de laatste ticketstatus.
Vul de vereiste kolommen TicketId, ActivityName, EventTimestamp, SourceSystem en LastDataUpdate. Vul de aanbevolen kolommen TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus en EventEndTime vanuit de eventcontext of het dichtstbijzijnde geldige bronrecord. Bewaar brontimestamps in één consistente tijdzone, bij voorkeur UTC, en behoud de oorspronkelijke precisie die de connector ondersteunt.
Controleer de getransformeerde uitvoer. Controleer of elke TicketId een rij Incident Created heeft, of eventtimestamps waar relevant binnen het extractievenster vallen, of alle 13 vereiste activiteitennamen zijn vertegenwoordigd wanneer brondata beschikbaar is en of dubbele eventkeys worden verwerkt volgens de bronauditidentificatie of een gedocumenteerde samengestelde sleutel.
Schrijf het event log naar de doeldatabasetabel of het bestand in een voor ProcessMind geschikt tabelvormig formaat, zoals CSV of het ondersteunde databaseconnectorformaat. Gebruik één kopregel, stabiele 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 zonder te vertrouwen op afgeleide activiteiten, omdat ProcessMind de geëxtraheerde rijen ongewijzigd leest.

Configuratie

Connector en licentie: Gebruik een commerciële ETL- of dataintegratietool met een Zendesk Support-connector die tickets, ticketaudits, opmerkingen, gebruikers, groepen, tevredenheidsbeoordelingen en SLA-informatie beschikbaar maakt, voor zover het Zendesk-abonnement en de connectorversie dit ondersteunen.
Authenticatie en autorisatie: Configureer het Zendesk-subdomein en een goedgekeurde authenticatiemethode. Geef alleen de rechten die nodig zijn voor het ophalen van tickets, audits, opmerkingen, gebruikers, groepen, tevredenheidsdata en SLA-data. Controleer of het integratieaccount historische records kan lezen.
Datumbereik: Begin voor validatie en de eerste import met 3 tot 6 maanden. Breid de periode pas uit nadat aantallen rijen, paginering en rate-limitgedrag zijn gecontroleerd. Gebruik voor geplande runs een incrementele watermark.
Vereiste filters: Pas alleen filters toe die in de bronconfiguratie zijn bevestigd, zoals een geselecteerd Zendesk-subdomein, merk, organisatie, groep of ticketbereik. Gebruik geen filters voor 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 beschikbaar de bronauditidentificatie om dubbele events bij incrementele imports te voorkomen.
Opmerkingen: Haal zowel openbare als privéopmerkingen 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 opmerking.
Classificatie van toewijzingen: Vergelijk de vorige en nieuwe waarden van groep of toegewezen persoon. Classificeer de eerste relevante toewijzing apart van latere wijzigingen en maak voor volgende wijzigingen in eigenaarschap een event Ticket Reassigned.
Statusclassificatie: Maak alleen rijen voor expliciete statusovergangen. Koppel de waarden new, open, pending, solved en closed volgens het geconfigureerde Zendesk-statusmodel. Leg de koppeling vooraf vast wanneer aangepaste statussen worden gebruikt.
SLA-verwerking: Gebruik bij voorkeur bron-events voor SLA-overschrijdingen. Als die niet beschikbaar zijn, configureer je een gedocumenteerde berekening met de beschikbare SLA-doelwaarde, het beleid, de bedrijfsuren en de eventtimestamps. Leg de basis van de berekening vast in de ETL-metadata en verzin geen bronvelden.
Verwerking van timestamps: Normaliseer EventTimestamp en EventEndTime naar UTC of een andere gedocumenteerde tijdzone. Behoud de brontimestamp en vervang de eventtijd niet door de extractietijd.
LastDataUpdate: Stel LastDataUpdate in op het tijdstip van de succesvolle ETL-verversing en gebruik voor alle rijen in die import dezelfde waarde.
Prestaties: Gebruik paginering, incrementele extractie, partitionering op ticketupdate- of audittimestamp, gecontroleerde paralleliteit, retryverwerking en backoff bij rate limits. Haal niet bij elke geplande run opnieuw de volledige tickethistorie op.
Doelschema: Configureer een platte eventtabel of een plat bestand met de vereiste kolommen TicketId, ActivityName, EventTimestamp, SourceSystem en LastDataUpdate, plus de aanbevolen attributen wanneer die beschikbaar zijn.
Werking van ProcessMind: Vertrouw er niet op dat ProcessMind statuswijzigingen, toewijzingen, antwoorden, notities, SLA-overschrijdingen of mijlpalen in de levenscyclus afleidt. Elke activiteit moet vóór de upload al als eventrij bestaan.

a 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 aan de slag te gaan?

Gebruik deze template om je data sneller voor te bereiden en waardevolle inzichten in je incidentbeheer te krijgen. Begin vandaag met het verbeteren van je proces.

Terug naar de verbetergids Template downloaden

Optimaliseer je incidentbeheer en los incidenten vandaag sneller op

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

Start je gratis proefperiode

Geen creditcard nodig, je kunt binnen enkele minuten aan de slag

Jouw datatemplate voor incidentbeheer

Jouw datatemplate voor incidentbeheer

Attributen voor incidentbeheer

Incidentbeheeractiviteiten

Extractiegidsen

Zendesk Explore-rapport exporteren vanuit de interface naar een CSV-bestand

Stappen

Configuratie

a Voorbeeldquery config

Python-script met de Zendesk Support REST API

Stappen

Configuratie

a Voorbeeldquery python

Zendesk Incremental Export API voor bulksynchronisatie van data

Stappen

Configuratie

a Voorbeeldquery python

ETL-tool van derden met Zendesk API-connector

Stappen

Configuratie

a Voorbeeldquery config

Klaar om aan de slag te gaan?

Optimaliseer je incidentbeheer en los incidenten vandaag sneller op

Jouw datatemplate voor incidentbeheer

Jouw datatemplate voor incidentbeheer

Attributen voor incidentbeheer

Incidentbeheeractiviteiten

Extractiegidsen

Zendesk Explore-rapport exporteren vanuit de interface naar een CSV-bestand

Stappen

Configuratie

a Voorbeeldquery config

Python-script met de Zendesk Support REST API

Stappen

Configuratie

a Voorbeeldquery python

Zendesk Incremental Export API voor bulksynchronisatie van data

Stappen

Configuratie

a Voorbeeldquery python

ETL-tool van derden met Zendesk API-connector

Stappen

Configuratie

a Voorbeeldquery config

Klaar om aan de slag te gaan?

Optimaliseer je incidentbeheer en los incidenten vandaag sneller op

We respecteren je privacy