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

Datatemplate voor serviceverzoeken

Zendesk Support

Attributen voor serviceverzoeken (21) Activiteiten rond serviceverzoeken (13) Extractiegidsen (3)

Datatemplate voor serviceverzoeken

Deze template laat zien welke data je nodig hebt om het proces voor serviceverzoeken in Zendesk Support te analyseren en hoe je die kunt ophalen. Je vindt er de belangrijkste datavelden om te verzamelen, de activiteiten om bij te houden en praktische aanwijzingen om de informatie rechtstreeks uit het systeem te halen. Gebruik deze bron om een event log op te bouwen voor process mining.

Aanbevolen attributen voor een volledige analyse
Belangrijke activiteiten rond serviceverzoeken om bij te houden
Aanwijzingen voor het ophalen van Zendesk Support-data

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

Template downloaden

Attributen voor serviceverzoeken

Dit zijn de aanbevolen datavelden voor het event log om serviceverzoeken in Zendesk Support goed te kunnen analyseren.

5 Verplicht 7 Aanbevolen 9 Optioneel

	Naam	Beschrijving
	Activiteit ActivityName	De naam van de bedrijfsactiviteit of event die bij een serviceverzoek heeft plaatsgevonden.
Beschrijving De activiteit is een afzonderlijke stap of event in de levenscyclus van een serviceverzoek, zoals 'Serviceverzoek aangemaakt', 'Verzoek toegewezen aan medewerker' of 'Serviceverzoek opgelost'. Deze activiteiten worden afgeleid uit wijzigingen in het auditlog van het Zendesk-ticket. Dat log houdt wijzigingen bij in velden zoals status, toegewezen medewerker en prioriteit, en registreert ook toegevoegde opmerkingen. Activiteiten analyseren is de kern van process mining. Je kunt er de proceskaart mee visualiseren, bottlenecks tussen stappen opsporen en lussen met herstelwerk analyseren. Door de volgorde en frequentie van activiteiten te bekijken, kunnen organisaties inefficiënties en kansen voor procesverbetering vinden. Waarom dit belangrijk is Dit attribuut bepaalt de stappen in het proces. Daarmee kun je proceskaarten visualiseren en de processtroom, variaties en naleving analyseren. Waar vind je dit? Dit wordt conceptueel afgeleid uit events in de Zendesk Ticket Audits API. Een wijziging van het veld 'status' van 'new' naar 'open' kan bijvoorbeeld worden vertaald naar een activiteit als 'Verzoek beoordeeld'. Voorbeelden Serviceaanvraag aangemaaktMedewerker opnieuw toegewezenServiceverzoek opgelost
	ID van serviceverzoek ServiceRequestId	De unieke identificatiecode van elk serviceverzoekticket in Zendesk.
Beschrijving Het ID van het serviceverzoek, in Zendesk vaak Ticket ID genoemd, is de primaire sleutel van elke case. Het koppelt alle bijbehorende activiteiten, opmerkingen en statuswijzigingen aan elkaar, vanaf het aanmaken van een verzoek tot de sluiting ervan. Zo kun je het volledige verloop van één verzoek volgen. Bij process mining is dit attribuut essentieel. Het bepaalt de case en maakt het mogelijk processtromen te reconstrueren, varianten te herkennen en metriek per case te berekenen, zoals de doorlooptijd. Elk event in de dataset moet aan een ID van een serviceverzoek zijn gekoppeld om de context binnen het totale proces te begrijpen. Waarom dit belangrijk is Dit is de unieke identificatiecode die alle events in het verloop van een serviceverzoek met elkaar verbindt. Zo kun je het hele proces analyseren. Waar vind je dit? Zendesk Tickets API, veld 'id'. Voorbeelden 102451024610247
	Starttijd EventTimestamp	De exacte datum en tijd waarop de activiteit plaatsvond.
Beschrijving De timestamp van de event, of starttijd, registreert precies wanneer een activiteit plaatsvond. Zo wordt vastgelegd wanneer een medewerker werd toegewezen, wanneer een openbare reactie werd verzonden of wanneer de ticketstatus veranderde in 'Resolved'. Deze tijdgegevens komen uit het auditlog van elk Zendesk-ticket. Dit attribuut is nodig voor elke tijdsgebonden analyse. Je gebruikt het om events chronologisch te ordenen, de tijd tussen activiteiten te berekenen, wachttijden te meten en de totale doorlooptijd van een case te analyseren. Het helpt bottlenecks op te sporen en prestaties te toetsen aan tijdsgebonden doelen, zoals SLA’s. Waarom dit belangrijk is Deze timestamp ordent events chronologisch en is nodig voor analyses van doorlooptijden, prestaties en bottlenecks. Waar vind je dit? Zendesk Ticket Audits API, veld 'created_at' voor elke audit-event. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
	Bronsysteem SourceSystem	Geeft aan uit welk systeem de data is opgehaald.
Beschrijving Dit attribuut geeft aan waar de data van het serviceverzoek vandaan komt. In deze procesweergave is de waarde altijd 'Zendesk Support', het bronsysteem voor alle activiteiten rond servicebeheer. In omgevingen met meerdere gekoppelde systemen is dit veld belangrijk om de herkomst van data te volgen en problemen op te lossen. Het zorgt ervoor dat analyses op het juiste systeem zijn gericht en helpt data uit verschillende bronnen van elkaar te onderscheiden. Waarom dit belangrijk is Geeft aan uit welk systeem de data afkomstig is. Zo kun je de herkomst volgen en verwarring voorkomen wanneer data uit meerdere systemen wordt samengevoegd. Waar vind je dit? Dit is een vaste waarde ('Zendesk Support') die tijdens het ophalen en transformeren van de data wordt toegevoegd. Voorbeelden Zendesk Support
	Laatste data-update LastDataUpdate	De timestamp van de laatste keer dat de data vanuit het bronsysteem is vernieuwd.
Beschrijving Dit attribuut registreert de datum en tijd waarop de data voor het laatst uit Zendesk Support is opgehaald. Zo zie je hoe actueel de geanalyseerde data is en hoe recent de procesweergave is bijgewerkt. Deze informatie is belangrijk voor doorlopende monitoring en dashboards. Analisten en zakelijke gebruikers kunnen zien of ze naar bijna realtime data kijken of naar een momentopname uit een eerdere periode. Dat is van invloed op de geldigheid van hun conclusies. Waarom dit belangrijk is Geeft aan hoe actueel de data is, zodat je weet hoe recent de analyse is. Waar vind je dit? Dit metadataveld wordt aangemaakt en aan de dataset toegevoegd wanneer de data wordt opgehaald. Voorbeelden 2023-10-27T08:00:00Z
	Kanaal van verzoek RequestChannel	Het kanaal waarlangs het serviceverzoek is ingediend, bijvoorbeeld e-mail, webformulier of telefoon.
Beschrijving Dit attribuut geeft aan via welk kanaal het serviceverzoek is ingediend. Zendesk registreert hoe een ticket is aangemaakt, bijvoorbeeld via e-mail, een webportaal, een API-koppeling, chat of een ander kanaal. Zo zie je hoe de klant contact heeft opgenomen. Het kanaal van het verzoek is een nuttige dimensie voor analyses. Je kunt in het dashboard 'Efficiëntie per verzoekkanaal' oplostijden, tevredenheidsscores en percentages herstelwerk per kanaal vergelijken. Zo kunnen bedrijven hun supportkanalen verbeteren en gebruikers naar de efficiëntste kanalen verwijzen. Waarom dit belangrijk is Helpt de efficiëntie en resultaten van verschillende supportkanalen te analyseren, zodat je gericht verbeteringen kunt aanbrengen. Waar vind je dit? Zendesk Tickets API, object 'via' en de eigenschap 'channel'. Voorbeelden webe-mailapichat
	Naam medewerker AgentName	De naam van de medewerker die op het moment van de event aan het serviceverzoek was toegewezen.
Beschrijving Dit attribuut geeft aan welke supportmedewerker verantwoordelijk is voor de afhandeling van het serviceverzoek. De toegewezen medewerker kan tijdens de levenscyclus van een ticket meerdere keren veranderen. Dit veld legt vast wie bij elke stap verantwoordelijk was. De naam van de medewerker is belangrijk voor prestatieanalyses. Je kunt de data filteren en uitsplitsen om de werkverdeling, oplostijden per medewerker en het aantal nieuwe toewijzingen te bekijken. Dit helpt bij het samenstellen van het dashboard voor prestaties van medewerkers en teams en geeft inzicht in ieders bijdrage aan de efficiëntie van het proces. Waarom dit belangrijk is Dit attribuut helpt bij het analyseren van de prestaties en werkverdeling van medewerkers en van de invloed van nieuwe toewijzingen op oplostijden. Waar vind je dit? Zendesk Users API, door 'assignee_id' uit het antwoord van de Tickets API te koppelen. Voorbeelden Jane DoeJohn SmithEmily Jones
	Prioriteit van verzoek RequestPriority	De prioriteit van het serviceverzoek, bijvoorbeeld laag, normaal, hoog of urgent.
Beschrijving De prioriteit van een verzoek geeft aan hoe dringend het is. Deze bepaalt vaak de beoogde oplostijd en het SLA-beleid dat voor het ticket geldt. Het systeem of de gebruiker kan de prioriteit bij het aanmaken instellen. Een medewerker kan deze later tijdens de levenscyclus van het ticket wijzigen. Dit attribuut is belangrijk om data uit te splitsen en oorzaken te analyseren. Je kunt bijvoorbeeld nagaan of tickets met hoge prioriteit sneller worden opgelost dan tickets met lage prioriteit. Het is ook een belangrijke dimensie voor de dashboards 'Trends in escalaties van serviceverzoeken' en 'SLA-naleving'. Waarom dit belangrijk is Hiermee kun je verzoeken op urgentie uitsplitsen. Dat helpt bij het analyseren van SLA-naleving en het tijdig afhandelen van urgente problemen. Waar vind je dit? Zendesk Tickets API, veld 'priority'. Voorbeelden LaagNormaalHoogUrgent
	Status van verzoek RequestStatus	De status van het serviceverzoek op het moment van de event, bijvoorbeeld nieuw, open of in behandeling.
Beschrijving De status van een verzoek geeft aan wat de toestand van het ticket op een bepaald moment is. Zendesk heeft verschillende standaardstatussen, zoals New, Open, Pending, On-hold, Solved en Closed. Die geven de voortgang van een verzoek aan. Wijzigingen in dit veld vormen een belangrijke aanleiding om activiteiten aan het event log toe te voegen. De tijd in verschillende statussen analyseren is een belangrijk onderdeel van bottleneckanalyse. Zo zie je waar tickets blijven hangen, bijvoorbeeld doordat ze te lang de status 'Pending' of 'On-hold' hebben. Inzicht in statusovergangen helpt ook om lussen met herstelwerk op te sporen. Waarom dit belangrijk is Door de status bij te houden, zie je hoe het verzoek vordert en hoeveel tijd het in een wachtende of actieve status doorbrengt. Waar vind je dit? Zendesk Tickets API, veld 'status'. Voorbeelden NieuwOpenIn behandelingOpgelostGesloten
	Tags van ticket TicketTags	Een lijst met tags die aan het serviceverzoek zijn toegevoegd voor categorisering en routering.
Beschrijving Tags zijn flexibele labels die medewerkers handmatig aan tickets kunnen toevoegen of die automatisch via bedrijfsregels worden toegevoegd. Ze geven een ticket extra context of een categorie die niet in standaardvelden zoals Type of Prioriteit past. Tags zijn een veelzijdig attribuut voor process mining. Je kunt ermee filteren op specifieke situaties, aangepaste workflows volgen of oorzaken opsporen. Met de tag 'VIP' kun je bijvoorbeeld het proces voor belangrijke klanten analyseren. De tag 'product_bug' kan helpen het verloop van defectmeldingen te volgen. Waarom dit belangrijk is Biedt een flexibele manier om de data uit te splitsen. Zo kun je specifieke deelprocessen of ticketattributen analyseren die niet in andere velden staan. Waar vind je dit? Zendesk Tickets API, veld 'tags'. Dit is een array met tekenreeksen. Voorbeelden sales_inquirybilling_issuefeature_requestvip_customer
	Toegewezen team AssignedTeam	Het supportteam of de groep die aan het serviceverzoek is toegewezen.
Beschrijving Dit attribuut geeft aan welk team of welke groep binnen de supportorganisatie verantwoordelijk is voor het serviceverzoek. In Zendesk heten deze groepen 'Groups'. Tickets worden vaak eerst aan een groep toegewezen en daarna door een individuele medewerker opgepakt. Door de data per toegewezen team te analyseren, krijg je inzicht in prestaties en werkdruk per team. Je ziet welke teams welke verzoeken afhandelen, wat hun gemiddelde oplostijd is en hoe vaak ze SLA’s halen. Dit is een belangrijke dimensie voor het dashboard voor prestaties van medewerkers en teams. Waarom dit belangrijk is Maakt het mogelijk te analyseren hoe teams presteren, hoe de werkdruk is verdeeld en hoe efficiënt verzoeken tussen supportgroepen worden gerouteerd. Waar vind je dit? Zendesk Groups API, door 'group_id' uit het antwoord van de Tickets API te koppelen. Voorbeelden Support niveau 1Technische supportFacturering
	Type serviceverzoek ServiceType	De categorie of het type serviceverzoek, bijvoorbeeld incident, vraag, probleem of taak.
Beschrijving Het type serviceverzoek geeft aan wat voor verzoek is ingediend. Zendesk gebruikt het veld 'type' om verschillende soorten supportverzoeken van elkaar te onderscheiden. Deze eerste indeling helpt om het ticket naar het juiste team te routeren en de passende processen toe te passen. Dit attribuut is belangrijk om data te filteren en te vergelijken. Analisten kunnen de processtromen van verschillende soorten verzoeken bekijken. Die volgen vaak heel andere routes en hebben verschillende SLA’s. Het is een belangrijke dimensie voor het dashboard voor prestaties van medewerkers en teams, waarmee je ziet wie bepaalde soorten verzoeken het best afhandelt. Waarom dit belangrijk is De indeling maakt het mogelijk verschillende processen apart te analyseren, zoals incidenten en vragen die elk hun eigen route volgen. Waar vind je dit? Zendesk Tickets API, veld 'type'. Voorbeelden vraagincidentprobleemtaak
	Aantal keer opnieuw toegewezen aan medewerker AgentReassignmentCount	Het totale aantal keren dat een verzoek van de ene medewerker aan een andere is toegewezen.
Beschrijving Dit attribuut telt elke wijziging van het veld 'assignee_id' op een ticket. Veel nieuwe toewijzingen voor één ticket kunnen wijzen op verschillende procesproblemen, zoals een onjuiste eerste routering, onvoldoende kennis bij medewerkers of een verzoek dat te complex is voor één medewerker. Dit is een belangrijke metriek voor de procesefficiëntie en vormt de basis voor de KPI ‘Percentage opnieuw toegewezen tickets’. Door cases met veel nieuwe toewijzingen te analyseren, kun je verbeterkansen vinden in routeringsregels, medewerkerstraining of kennisbankbronnen. Zo komen tickets sneller bij de juiste persoon terecht. Waarom dit belangrijk is Maakt interne overdrachten meetbaar en brengt procesfrictie aan het licht. Veel nieuwe toewijzingen leiden vaak tot vertraging en inefficiëntie. Waar vind je dit? Berekend door per ticket het aantal wijzigingen van 'assignee_id' te tellen in de Zendesk Ticket Audits API. Voorbeelden 013
	Eindtijd EndTime	De exacte datum en tijd waarop de activiteit is afgerond.
Beschrijving De eindtijd markeert het moment waarop een activiteit is afgerond. Bij veel events in Zendesk is de duur nul en is de eindtijd gelijk aan de starttijd. Bij activiteiten die een status beschrijven, zoals 'Verzoek in de wacht gezet', is de eindtijd het moment waarop het ticket niet langer in de wacht staat. Dit attribuut is nodig om de duur van afzonderlijke activiteiten te berekenen, wat helpt bij bottleneckanalyse. Door de starttijd en eindtijd van een activiteit te vergelijken, kun je de verwerkingstijd meten en zien welke stappen de meeste tijd kosten. Waarom dit belangrijk is Maakt het mogelijk de duur van afzonderlijke activiteiten te berekenen. Zo kun je bottlenecks opsporen en de efficiëntie per processtap meten. Waar vind je dit? Bij afzonderlijke events is dit vaak hetzelfde als de starttijd. Voor de duur van een status is dit de timestamp van de volgende event die de status wijzigt. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
	Herstelwerk IsRework	Een indicator die waar is als het serviceverzoek na de oplossing opnieuw is geopend.
Beschrijving Deze booleaanse indicator markeert cases waarin herstelwerk heeft plaatsgevonden. Een serviceverzoek geldt meestal als herstelwerk wanneer de status van ‘Opgelost’ teruggaat naar een open status. Dat betekent dat de eerste oplossing niet volstond en de klant opnieuw contact moest opnemen over hetzelfde probleem. Dit attribuut is nodig om de KPI ‘Percentage serviceverzoeken met herstelwerk’ te berekenen en voor het dashboard ‘Analyse van herstelwerk en heropende verzoeken’. Door cases met herstelwerk te markeren, kunnen analisten deze inefficiënte procesverlopen apart bekijken, oorzaken van heropeningen achterhalen en de oplossing bij het eerste contact verbeteren. Waarom dit belangrijk is Brengt procesfouten aan het licht waarbij een oplossing niet definitief was. Zo worden problemen met kwaliteit en efficiëntie zichtbaar die de klanttevredenheid rechtstreeks beïnvloeden. Waar vind je dit? Berekend door de statusvolgorde van een ticket in de Zendesk Ticket Audits API te analyseren. Een overgang van 'solved' naar 'open' wijst op herstelwerk. Voorbeelden truefalse
	Naam aanvrager RequestorName	De naam van de eindgebruiker of klant die het serviceverzoek heeft ingediend.
Beschrijving Dit attribuut geeft aan wie het serviceverzoek heeft ingediend. Door het verzoek aan een specifieke klant te koppelen, kun je het supportproces vanuit het perspectief van de klant bekijken. Bij procesanalyses kun je de aanvrager gebruiken om patronen bij specifieke klanten of klantgroepen te onderzoeken. Je kunt bijvoorbeeld nagaan of bepaalde klanten langer op een oplossing wachten of vaker met herstelwerk te maken krijgen. Dat kan wijzen op problemen met een product of dienst. Waarom dit belangrijk is Koppelt het proces aan de klant. Zo kun je klantspecifieke problemen, herhaalde verzoeken en tevredenheid analyseren. Waar vind je dit? Zendesk Users API, door 'requester_id' uit het antwoord van de Tickets API te koppelen. Voorbeelden Alice JohnsonBob WilliamsCharlie Brown
	Naam SLA-beleid SlaPolicyName	De naam van het Service Level Agreement (SLA)-beleid dat op het verzoek van toepassing is.
Beschrijving Dit attribuut geeft aan welk specifiek SLA-beleid de streefwaarden voor de reactietijd en oplostijd van het serviceverzoek bepaalt. Het beleid hangt meestal af van factoren zoals de prioriteit en het type verzoek of het abonnementsniveau van de klant. Het toegepaste SLA-beleid is nodig voor het dashboard ‘Analyse van SLA-naleving en overschrijdingen’. Het geeft context om de prestaties te beoordelen, omdat elk beleid eigen streefwaarden heeft. Zo kun je eerlijk en nauwkeurig vaststellen of een ticket aan de bijbehorende serviceniveaudoelen voldeed. Waarom dit belangrijk is Geeft context voor de SLA-analyse door aan te geven aan welke streefwaarden een verzoek is getoetst. Zo kun je de compliance nauwkeurig rapporteren. Waar vind je dit? Zendesk Ticket Metrics API. SLA-data is vaak gekoppeld aan de metrics van het ticket. Voorbeelden Urgent - reactie binnen 1 uurStandaard - oplossing binnen 24 uurSLA voor premiumklanten
	Opgelost bij eerste contact IsFirstContactResolution	Een indicator die aangeeft of de eerste toegewezen medewerker het verzoek heeft opgelost, zonder nieuwe toewijzingen of reacties van de aanvrager.
Beschrijving First Contact Resolution (FCR) geeft aan of het probleem van een klant tijdens één contactmoment is opgelost. Dit berekende attribuut is een booleaanse indicator. De waarde is waar als de eerste toegewezen medewerker het ticket heeft opgelost, zonder nieuwe toewijzingen en met slechts één reactie van een medewerker. Dit attribuut vormt de basis voor de KPI ‘Percentage opgelost bij eerste contact’. De kenmerken van FCR-cases kunnen laten zien wat goed werkt in het proces. Cases die niet aan FCR voldoen, kunnen juist wijzen op kansen voor betere medewerkerstraining, duidelijkere kennisbankartikelen of een effectievere eerste beoordeling. Waarom dit belangrijk is Meet of problemen met één contactmoment efficiënt kunnen worden opgelost. Dit draagt sterk bij aan klanttevredenheid en een efficiënte bedrijfsvoering. Waar vind je dit? Dit is een complex berekend attribuut. Je moet het event log van een ticket analyseren om te controleren of het ticket opnieuw aan een medewerker is toegewezen en hoeveel openbare reacties medewerkers hebben geplaatst. Voorbeelden truefalse
	Organisatie van aanvrager RequestorOrganization	De organisatie of het bedrijf waar de aanvrager bij hoort.
Beschrijving Dit attribuut koppelt het serviceverzoek aan een specifieke klantorganisatie. Dat is vooral relevant bij B2B-support, waar service level agreements en supportcontracten vaak op organisatieniveau zijn afgesproken. Door data per organisatie te analyseren, krijg je inzicht in de supportprestaties per bedrijf. Je kunt zien welke organisaties veel tickets indienen, terugkerende problemen hebben of lage tevredenheidsscores geven. Dat is nuttig voor accountbeheer en om bredere trends in klantrelaties te herkennen. Waarom dit belangrijk is Maakt B2B-serviceanalyses mogelijk door verzoeken per bedrijf te groeperen. Zo kun je klantrelaties en SLA’s op organisatieniveau beheren. Waar vind je dit? Zendesk Organizations API, door 'organization_id' uit het antwoord van de Tickets API te koppelen. Voorbeelden Acme CorporationGlobal Tech Inc.Innovate Solutions
	SLA overschreden IsSlaBreached	Een indicator die aangeeft of het serviceverzoek een of meer SLA-streefwaarden heeft overschreden.
Beschrijving Dit attribuut is een booleaanse of categorische indicator van de SLA-uitkomst voor een ticket. Mogelijke waarden zijn bijvoorbeeld ‘Gehaald’, ‘Overschreden’ of ‘Actief’. De waarde wordt bepaald door de werkelijke reactie- of oplostijd te vergelijken met de streefwaarden van het toegepaste SLA-beleid. Dit attribuut is belangrijk voor het dashboard ‘Analyse van SLA-naleving en overschrijdingen’. Je kunt er eenvoudig mee tellen en visualiseren welke tickets wel en niet aan de afspraken voldeden. Daarna kun je de proceskenmerken van tickets met een overschreden SLA analyseren om oorzaken te vinden, zoals lange wachttijden of veel nieuwe toewijzingen. Waarom dit belangrijk is Meet rechtstreeks hoe de prestaties zich verhouden tot de afgesproken serviceniveaus. Dit is een belangrijke indicator voor servicekwaliteit en klanttevredenheid. Waar vind je dit? Afgeleid uit de Zendesk Ticket Metrics API, die per ticket informatie over de SLA-status bevat. Voorbeelden GehaaldOverschredenActief
	Tevredenheidsscore SatisfactionRating	De tevredenheidsscore die de aanvrager geeft nadat het ticket is opgelost.
Beschrijving Dit attribuut bevat de feedback van de klant over de supportervaring. Die wordt meestal verzameld via een enquête nadat een ticket de status 'solved' heeft gekregen. Veelvoorkomende beoordelingen zijn 'Goed' en 'Slecht', soms met een opmerking. De tevredenheidsscore is een belangrijke uitkomstmaat. Door procespatronen met tevredenheidsscores te vergelijken, zie je welk procesgedrag tot tevreden of ontevreden klanten leidt. Zo kan blijken dat veel nieuwe toewijzingen of lange oplostijden sterk samenhangen met lage tevredenheidsscores. Waarom dit belangrijk is Verbindt de uitvoering van het proces rechtstreeks met de resultaten voor klanten. Zo kun je zien welk procesgedrag de klanttevredenheid beïnvloedt. Waar vind je dit? Zendesk Tickets API, veld 'satisfaction_rating.score' of 'satisfaction_rating.reason'. Voorbeelden GoedSlechtAangeboden

Verplicht Aanbevolen Optioneel

Activiteiten rond serviceverzoeken

Dit zijn de belangrijkste processtappen en mijlpalen om in het event log vast te leggen. Zo kun je serviceverzoeken nauwkeurig ontdekken en analyseren.

7 Aanbevolen 6 Optioneel

	Activiteit	Beschrijving
	Aanvraag toegewezen aan medewerker	Deze activiteit vindt plaats wanneer een serviceaanvraag voor het eerst aan een specifieke medewerker wordt toegewezen. Dit wordt afgeleid uit een gebeurtenis ‘Change’ in het auditlog van het ticket, waarbij het veld ‘assignee_id’ wordt ingevuld terwijl het eerst leeg was of een groeps-ID bevatte.
Waarom dit belangrijk is Dit markeert het begin van het actieve werk van een medewerker. Je hebt dit nodig om de eerste reactietijd, de vertraging tot de eerste toewijzing en de werkverdeling te meten. Waar vind je dit? Afgeleid uit de eerste gebeurtenis ‘Change’ voor het veld ‘assignee_id’ in het auditlog van het ticket, waarbij een specifieke gebruikers-ID wordt ingesteld. Vastleggen Afgeleid uit de eerste wijzigingsgebeurtenis waarbij het veld ‘assignee_id’ aan een medewerker wordt toegewezen. Gebeurtenistype inferred
	Openbaar antwoord verzonden	Deze activiteit staat voor alle communicatie die een medewerker naar de aanvrager verstuurt. Dit wordt vastgelegd als een expliciete event 'Comment' in de Zendesk-ticketdata, waarbij het attribuut 'public' de waarde true heeft.
Waarom dit belangrijk is Deze events zijn belangrijk om de communicatie frequentie te analyseren, reactietijden van medewerkers te meten en vast te stellen hoeveel contactmomenten nodig zijn om een verzoek op te lossen. Waar vind je dit? Dit is een expliciete event 'Comment' in de ticketdata. De eventdetails bevatten het attribuut 'public: true', waarmee deze reactie zich onderscheidt van interne notities. Vastleggen Vastgelegd uit events 'Comment' van tickets waarbij de vlag 'public' op true staat. Gebeurtenistype explicit
	Serviceaanvraag aangemaakt	Dit markeert het begin van de levenscyclus van een serviceaanvraag, wanneer een aanvrager via een kanaal een nieuw ticket indient. In het auditlog van Zendesk wordt dit vastgelegd als een ‘Create’-gebeurtenis. De timestamp daarvan geeft het exacte begin van het proces aan.
Waarom dit belangrijk is Deze activiteit is de belangrijkste startgebeurtenis voor elke serviceaanvraag. Je hebt die nodig om de totale doorlooptijd te berekenen en het aantal binnenkomende aanvragen te analyseren. Waar vind je dit? Dit wordt in het auditlog van Zendesk vastgelegd als een gebeurtenistype ‘Create’. De timestamp van deze gebeurtenis is het tijdstip waarop het ticket voor de serviceaanvraag is aangemaakt. Vastleggen Rechtstreeks vastgelegd in de gebeurtenis ‘Create’ in het auditlog van het ticket. Gebeurtenistype explicit
	Serviceverzoek gesloten	Dit staat voor de definitieve sluiting van het serviceverzoek. Na een bepaalde periode met de status 'solved' verandert een ticket automatisch in de status 'closed'. Daarna kan het niet meer worden heropend.
Waarom dit belangrijk is Deze activiteit markeert het definitieve einde van het serviceverzoek. Dit is het eindpunt voor de berekening van de volledige doorlooptijd van de case. Waar vind je dit? Afgeleid uit een event 'Change' voor het veld 'status' in het auditlog van het ticket, waarbij de nieuwe waarde 'closed' is. Vastleggen Afgeleid uit een event 'Change' in het auditlog waarbij de status verandert in 'closed'. Gebeurtenistype inferred
	Serviceverzoek heropend	Dit gebeurt wanneer een aanvrager reageert op een verzoek met de status 'solved'. De status verandert dan automatisch terug in 'open'. Dit betekent dat de voorgestelde oplossing niet voldeed.
Waarom dit belangrijk is Deze activiteit is de belangrijkste aanwijzing voor herstelwerk. Door te analyseren hoe vaak dit gebeurt, kun je de kwaliteit van oplossingen meten en oorzaken van ontevreden klanten opsporen. Waar vind je dit? Afgeleid uit een event 'Change' voor het veld 'status' in het auditlog van het ticket, waarbij de oude waarde 'solved' was en de nieuwe waarde 'open' is. Vastleggen Afgeleid uit een statuswijziging van 'solved' naar 'open'. Gebeurtenistype inferred
	Serviceverzoek opgelost	Deze activiteit markeert het moment waarop een medewerker een oplossing heeft geboden en de ticketstatus heeft gewijzigd in 'solved'. Vanuit het perspectief van de medewerker is het verzoek afgehandeld, maar de aanvrager kan het nog heropenen.
Waarom dit belangrijk is Dit is een belangrijke mijlpaal: het actieve werk van de medewerker is afgerond. De tijd tot dit moment is een belangrijke maatstaf voor de efficiëntie van de afhandeling. Waar vind je dit? Afgeleid uit een event 'Change' voor het veld 'status' in het auditlog van het ticket, waarbij de nieuwe waarde 'solved' is. Vastleggen Afgeleid uit een event 'Change' in het auditlog waarbij de status verandert in 'solved'. Gebeurtenistype inferred
	SLA-doel niet gehaald	Deze activiteit markeert het moment waarop een serviceverzoek niet aan een afgesproken SLA-doel voldoet, zoals de tijd tot de eerste reactie of de oplostijd. Zendesk registreert dit als een expliciete event wanneer een doel niet wordt gehaald.
Waarom dit belangrijk is Deze event is belangrijk voor compliancebewaking en vormt een belangrijke invoer voor de KPI voor het percentage nagekomen SLA’s. De event laat zien wanneer serviceafspraken niet zijn gehaald. Waar vind je dit? Vastgelegd uit de event 'SLABreach' in de ticketevents of het auditlog van Zendesk. De event vermeldt welke SLA-metriek niet is gehaald. Vastleggen Herkenbaar aan de expliciete event 'SLABreach' in de ticketdata. Gebeurtenistype explicit
	Interne notitie toegevoegd	Een medewerker heeft een interne notitie of opmerking aan het serviceverzoek toegevoegd. Alleen andere medewerkers kunnen deze zien. Dit wordt vastgelegd als een event 'Comment' waarbij het attribuut 'public' de waarde false heeft.
Waarom dit belangrijk is Interne notities bijhouden geeft inzicht in de samenwerking tussen medewerkers of teams. Die samenwerking kan vertraging veroorzaken, maar ook helpen om problemen efficiënt op te lossen. Waar vind je dit? Dit is een expliciete event 'Comment' in de ticketdata. De eventdetails bevatten het attribuut 'public: false', wat aangeeft dat het om een interne notitie gaat. Vastleggen Vastgelegd uit events 'Comment' van tickets waarbij de vlag 'public' op false staat. Gebeurtenistype explicit
	Medewerker opnieuw toegewezen	Dit geeft aan dat een serviceverzoek van de ene medewerker naar de andere is overgedragen. Dit wordt afgeleid uit een volgende event 'Change' voor het veld 'assignee_id', na de eerste toewijzing.
Waarom dit belangrijk is Het bijhouden van nieuwe toewijzingen is nodig om de KPI voor het percentage opnieuw toegewezen verzoeken te berekenen. Zo kun je inefficiënte processen, onjuiste routering of kennishiaten opsporen. Waar vind je dit? Afgeleid uit events 'Change' voor het veld 'assignee_id' in het auditlog van het ticket. De eerste toewijzing van het ticket telt niet mee. Vastleggen Afgeleid uit de tweede en daaropvolgende events 'Change' voor het veld 'assignee_id'. Gebeurtenistype inferred
	Prioriteit gewijzigd	Geeft aan dat de prioriteit van de serviceaanvraag is gewijzigd, bijvoorbeeld van ‘Low’, ‘Normal’, ‘High’ of ‘Urgent’. Dit wordt in het auditlog van het ticket vastgelegd als een gebeurtenis ‘Change’ voor het veld ‘priority’.
Waarom dit belangrijk is Door wijzigingen in prioriteit te analyseren, zie je welke verzoeken steeds urgenter worden en of de prioriteiten goed worden beheerd. Waar vind je dit? Vastgelegd als een event 'Change' voor het veld 'priority' in het auditlog van het Zendesk-ticket. Daarbij worden de oude en nieuwe waarde getoond. Vastleggen Afgeleid uit events 'Change' voor het veld 'priority' in het auditlog. Gebeurtenistype inferred
	SLA-doel toegepast	Dit is het moment waarop een SLA-beleid (Service Level Agreement) wordt toegepast op het ticket voor de serviceaanvraag. De gebeurtenis wordt expliciet vastgelegd wanneer de eigenschappen van het ticket voldoen aan de voorwaarden van een actief SLA-beleid.
Waarom dit belangrijk is Door bij te houden wanneer een SLA wordt toegepast, kun je de naleving volgen, mogelijke overschrijdingen analyseren en zien welke afhandelingstermijn voor verschillende typen aanvragen geldt. Waar vind je dit? Vastgelegd in de gebeurtenis ‘SLAPolicyApplied’ in de ticketgebeurtenissen of het auditlog van Zendesk. Deze gebeurtenis vermeldt welk beleid van toepassing was. Vastleggen Herkenbaar aan de expliciete gebeurtenis ‘SLAPolicyApplied’ in de ticketgegevens. Gebeurtenistype explicit
	Verzoek geëscaleerd	Dit staat voor de formele escalatie van een serviceverzoek naar een hoger supportniveau, een ander team of het management. Dit wordt meestal afgeleid uit een wijziging van de toegewezen groep van het ticket of van een aangepast veld dat escalaties bijhoudt.
Waarom dit belangrijk is Door escalaties te volgen, kun je complexe verzoeken, opleidingsbehoeften van eerstelijnsmedewerkers en structurele problemen opsporen waarvoor ingrijpen op een hoger niveau nodig is. Waar vind je dit? Dit is geen standaardevent. Je moet deze afleiden uit een event 'Change' voor het veld 'group_id' naar een escalatiegroep, of uit een wijziging van een aangepast ticketveld waarmee escalaties worden bijgehouden. Vastleggen Afgeleid uit een wijziging van 'group_id' of een aangepast veld 'escalation'. Gebeurtenistype inferred
	Verzoek in de wacht gezet	Deze activiteit vindt plaats wanneer de status van het serviceverzoek verandert in 'on-hold'. Meestal wacht de medewerker dan op informatie van de aanvrager of een derde partij. Dit wordt afgeleid uit een statuswijziging.
Waarom dit belangrijk is Zo kun je wachttijden buiten de directe invloed van het supportteam apart bekijken en meten. Dat geeft een nauwkeuriger beeld van de behandeltijd van medewerkers. Waar vind je dit? Afgeleid uit een event 'Change' voor het veld 'status' in het auditlog van het ticket, waarbij de nieuwe waarde 'on-hold' is. Vastleggen Afgeleid uit een event 'Change' in het auditlog waarbij de status verandert in 'on-hold'. Gebeurtenistype inferred

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data op uit Zendesk Support

Stappen

Open Zendesk Explore en maak het eerste rapport: Klik rechtsboven op het Zendesk-productpictogram en kies Explore. Klik in Explore links op het pictogram Queries en daarna op New query. Selecteer de dataset Support: Ticket updates als bron.
Stel metrics en attributen voor ticketevents in: Voeg in de query builder een metriek toe, zoals COUNT(Tickets), om data te visualiseren. Ga daarna naar de sectie Rows en voeg de volgende attributen toe: Ticket ID, Update - Timestamp, Updater name, Update - Field name, Update - Previous value, Update - New value, Assignee name, Group name, Ticket priority, Ticket status, Submission channel, Ticket type en Ticket tags.
Maak een berekend attribuut voor ActivityName: Maak een standaard berekend attribuut om ruwe updates om te zetten in betekenisvolle activiteiten. Ga naar het menu Calculations (rekenmachinepictogram), selecteer Standard calculated attribute en noem het attribuut ActivityName. Plak de logica uit de sectie Query in het formuleveld. De formule koppelt verschillende ticketupdates aan de vereiste activiteitnamen.
Pas het eerste rapport aan en filter het: Voeg het nieuwe attribuut ActivityName toe aan de sectie Rows. Maak een filter op dit attribuut en sluit (null) en ongewenste, door het systeem gegenereerde waarden uit. Voeg ook een filter toe voor Ticket created - Date om de query te beperken tot een werkbare periode, bijvoorbeeld de afgelopen 6 maanden.
Maak het tweede rapport voor SLA-events: Maak een nieuwe query en selecteer deze keer de dataset Support: SLAs. Dit is nodig omdat SLA-events niet beschikbaar zijn in de dataset Ticket updates.
Stel het SLA-rapport in: Voeg in de SLA-query COUNT(SLA tickets) toe aan Metrics. Voeg in de sectie Rows de attributen Ticket ID, SLA policy, SLA target, SLA updated - Timestamp, SLA status en Updater name toe. In de transformatiefase leiden we de activiteit af uit SLA status.
Exporteer beide datasets: Voer beide queries uit in de Explore-interface. Klik zodra de tabellen klaar zijn op Export en kies CSV als bestandsindeling. Je hebt nu twee aparte CSV-bestanden.
Voeg de data samen en transformeer die: Combineer de twee CSV-bestanden met een spreadsheetprogramma zoals Microsoft Excel of een scripttaal zoals Python. Het doel is één event log te maken. Voeg voor het SLA-bestand de kolom ActivityName toe. Als SLA status de waarde Actief heeft, is de activiteit SLA Target Applied. Als SLA status de waarde Breached heeft, is de activiteit SLA Target Breached. Gebruik SLA updated - Timestamp als EventTimestamp.
Maak de kolomkoppen gelijk: Hernoem in het samengevoegde bestand de kolommen zodat ze voldoen aan de vereiste indeling voor process mining. Hernoem bijvoorbeeld Ticket ID naar ServiceRequestId, Update - Timestamp naar EventTimestamp en Updater name naar AgentName.
Voeg vaste kolommen toe en rond het bestand af: Voeg twee kolommen toe aan het definitieve CSV-bestand. Vul SourceSystem met de waarde 'Zendesk' en LastDataUpdate met de timestamp waarop je de export hebt uitgevoerd. Het bestand is nu klaar om te uploaden.

Configuratie

Zendesk-abonnement: Voor het maken van aangepaste queries en attributen heb je een Zendesk Support-abonnement nodig met Zendesk Explore Professional of Enterprise.
Machtigingen: Je moet Agent zijn en toestemming hebben om queries in Explore te maken en te bewerken. Dit is meestal een beheerder of een medewerker met een aangepaste rol.
Dataset selecteren: Voor deze methode maak je twee aparte rapporten op basis van verschillende datasets: Support: Ticket updates voor algemene events en Support: SLAs voor specifieke SLA-events.
Filter voor datumbereik: Stel een filter voor het datumbereik in, bijvoorbeeld op Ticket created - Date, zodat de hoeveelheid data werkbaar blijft. Voor de eerste analyse raden we een periode van 3 tot 6 maanden aan.
Berekende attributen: De activiteitnamen worden afgeleid met een complex, aangepast berekend attribuut in Explore. Controleer of de formule goed is ingesteld om fouten in de uitvoer te voorkomen.
Hoeveelheid data: De Zendesk Explore-interface en de exportfunctie kunnen traag zijn of een time-out geven bij zeer grote datasets. Splits de export op in kleinere perioden als je meer dan een jaar aan data of miljoenen tickets wilt ophalen.

a Voorbeeldquery config

This method uses the Zendesk Explore UI, where queries are built visually. The following describes the configuration for the two required reports.

**Report 1: Ticket Events Configuration**
* **Dataset**: `Support: Ticket updates`
* **Metrics**: `COUNT(Tickets)`
* **Rows**:
  * `Ticket ID`
  * `ActivityName` (This is the custom calculated attribute defined below)
  * `Update - Timestamp`
  * `Updater name`
  * `Assignee name`
  * `Group name`
  * `Ticket priority`
  * `Ticket status`
  * `Submission channel`
  * `Ticket type`
  * `Ticket tags`
* **Standard Calculated Attribute (`ActivityName`) Formula**:
```
IF [Update - Field name] = "assignee_id" AND ([Update - Previous value] = "" OR [Update - Previous value] = NULL) THEN
    "Request Assigned to Agent"
ELIF [Update - Field name] = "assignee_id" AND [Update - Previous value] != "" AND [Update - Previous value] != NULL THEN
    "Agent Reassigned"
ELIF [Update - Field name] = "group_id" THEN
    "Request Escalated"
ELIF [Update - Field name] = "priority" AND [Update - New value] != [Update - Previous value] THEN
    "Priority Changed"
ELIF [Update - Field name] = "status" AND [Update - New value] = "hold" THEN
    "Request Placed On-Hold"
ELIF [Update - Field name] = "status" AND [Update - New value] = "solved" THEN
    "Service Request Resolved"
ELIF [Update - Field name] = "status" AND [Update - New value] = "closed" THEN
    "Service Request Closed"
ELIF [Update - Field name] = "status" AND [Update - New value] = "open" AND [Update - Previous value] = "solved" THEN
    "Service Request Reopened"
ELIF [Update - Field name] = "requester_id" AND [Update - Previous value] = NULL THEN
    "Service Request Created"
ELSE
    NULL
ENDIF
```
* **Note on Comment Activities**: Capturing `Public Reply Sent` and `Internal Note Added` from the `Ticket updates` dataset is not reliably possible as the public vs. internal distinction is often missing. For these events, creating a third report on the `Support: Comments` dataset and merging it is the recommended, though more complex, approach.

**Report 2: SLA Events Configuration**
* **Dataset**: `Support: SLAs`
* **Metrics**: `COUNT(SLA tickets)`
* **Rows**:
  * `Ticket ID`
  * `SLA updated - Timestamp`
  * `SLA status`
  * `Updater name`
  * `Assignee name`
  * `Group name`
  * `Ticket priority`
* **Note**: The `ActivityName` for this report (`SLA Target Applied`, `SLA Target Breached`) must be generated after export based on the value in the `SLA status` column.

Stappen

Vereisten: Zorg dat Python 3.6 of hoger op je systeem is geïnstalleerd. Je hebt ook beheerderstoegang tot je Zendesk Support-account nodig om een API-token aan te maken.
Installeer Python-bibliotheken: Open een terminal of opdrachtprompt en installeer de benodigde Python-bibliotheken met pip. De bibliotheek requests wordt gebruikt voor API-aanroepen en pandas voor het bewerken van data en het exporteren naar een CSV-bestand.
```
pip install requests pandas
```
Maak een Zendesk API-token aan: Meld je als beheerder aan bij Zendesk. Ga naar Admin Center > Apps and integrations > APIs > Zendesk API. Schakel onder Token Access de toegang in als dat nog niet is gebeurd en klik op "Add API token". Geef het token een beschrijving, bijvoorbeeld "ProcessMind Extraction", en kopieer het gegenereerde token. Je kunt dit token later niet opnieuw bekijken.
Stel het Python-script in: Open het meegeleverde Python-script in een teksteditor. Vul bovenaan het bestand de configuratievariabelen in: ZENDESK_SUBDOMAIN (de Zendesk-domeinnaam van je bedrijf), ZENDESK_EMAIL (het e-mailadres van de beheerder aan wie het token is gekoppeld) en ZENDESK_API_TOKEN. Stel ook START_TIME_STR in op de begindatum van de periode waaruit je data ophaalt, meestal 3 tot 6 maanden geleden.
Bekijk hoe het script werkt: Het script haalt eerst met de efficiënte Incremental Tickets API een lijst op van tickets die binnen de opgegeven periode zijn bijgewerkt. Daarna haalt het voor elk ticket het volledige auditspoor, de reacties en de SLA-metrics op. Vervolgens verwerkt het deze events op tijdsvolgorde om een gedetailleerde geschiedenis op te bouwen.
Koppel Zendesk-events aan activiteiten: Het script bevat logica om ruwe Zendesk-events om te zetten in de vereiste bedrijfsactiviteiten. Een event 'Change' voor het veld 'status' wordt bijvoorbeeld gekoppeld aan activiteiten zoals 'Service Request Resolved' of 'Request Placed On-Hold'. Bij reactie-events wordt gecontroleerd of het gaat om 'Public Reply Sent' of 'Internal Note Added'.
Voer het extractiescript uit: Voer in de terminal python your_script_name.py uit. Het script toont de voortgang terwijl het data ophaalt uit de Zendesk API. Afhankelijk van de hoeveelheid data en de API-limieten kan dit even duren.
Controleer het uitvoerbestand: Na afloop maakt het script in dezelfde map een CSV-bestand met de naam zendesk_event_log.csv. Dit bestand bevat het opgehaalde event log met alle opgegeven activiteiten en attributen.
Bereid het bestand voor op upload: Controleer of het CSV-bestand de juiste indeling heeft. De kolomkoppen moeten overeenkomen met de vereiste attributen, zoals ServiceRequestId, ActivityName, EventTimestamp, SourceSystem en LastDataUpdate. Het bestand is nu klaar om te uploaden naar ProcessMind.

Configuratie

Toegang tot de Zendesk API: Het script vereist een actief API-token dat is gekoppeld aan een beheerder of een medewerker met voldoende machtigingen. Het e-mailadres dat je in de scriptconfiguratie opgeeft, moet overeenkomen met het e-mailadres waarmee het API-token is aangemaakt.
Scriptparameters: Stel vóór het uitvoeren deze variabelen in het script in: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN en START_TIME_STR. Gebruik voor START_TIME_STR de indeling 'YYYY-MM-DD'.
Datumbereik: Begin bij voorkeur met data uit de afgelopen 3 tot 6 maanden (START_TIME_STR). Zo krijg je een representatieve dataset voor analyse zonder dat het script onnodig lang draait of vaak de API-limieten bereikt. Bij een langere periode duurt het ophalen van de data aanzienlijk langer.
Incremental Exports API: Het script gebruikt het Incremental Exports-eindpunt (/api/v2/incremental/tickets/cursor.json) om alleen tickets op te halen die sinds de vorige uitvoering of een opgegeven starttijd zijn bijgewerkt. Dat is veel efficiënter dan alle tickets doorzoeken.
API-limieten: Zendesk hanteert limieten voor API-aanroepen. Het script kan tijdelijk pauzeren wanneer een limiet is bereikt, maar bij zeer grote accounts kan het ophalen van de data veel tijd kosten. Voer het script bij voorkeur buiten piekuren uit.
Escalatieregels: De activiteit 'Request Escalated' wordt afgeleid uit een wijziging van het veld group_id. Gebruikt je organisatie een andere methode, zoals een aangepast ticketveld, dan moet je de logica van het script aanpassen om escalaties goed te herkennen.

a Voorbeeldquery python

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

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk subdomain, admin email, and API token
ZENDESK_SUBDOMAIN = class="hl-string">'[Your Subdomain]'
ZENDESK_EMAIL = class="hl-string">'[Your Zendesk Admin Email]'
ZENDESK_API_TOKEN = class="hl-string">'[Your Zendesk API Token]'

class=class="hl-string">"hl-comment"># Set the start date for the data extraction (YYYY-MM-DD)
START_TIME_STR = class="hl-string">'2023-01-01'

class=class="hl-string">"hl-comment"># --- End of Configuration ---

class=class="hl-string">"hl-comment"># Set up constants and session
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.now(timezone.utc).isoformat()

session = requests.Session()
session.auth = AUTH

class=class="hl-string">"hl-comment"># Caches for user and group names to reduce API calls
user_cache = {}
group_cache = {}

def get_user_name(user_id):
    if not user_id:
        return None
    if user_id in user_cache:
        return user_cache[user_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_cache[user_id] = response.json()[class="hl-string">'user'][class="hl-string">'name']
        return user_cache[user_id]
    except requests.exceptions.RequestException:
        return fclass="hl-string">'User ID {user_id}'

def get_group_name(group_id):
    if not group_id:
        return None
    if group_id in group_cache:
        return group_cache[group_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/groups/{group_id}.json')
        response.raise_for_status()
        group_cache[group_id] = response.json()[class="hl-string">'group'][class="hl-string">'name']
        return group_cache[group_id]
    except requests.exceptions.RequestException:
        return fclass="hl-string">'Group ID {group_id}'

def handle_rate_limit(response):
    if response.status_code == 429:
        retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
        print(fclass="hl-string">'Rate limit reached. Waiting for {retry_after} seconds...')
        time.sleep(retry_after)
        return True
    response.raise_for_status()
    return False

def fetch_paginated_data(url):
    while url:
        try:
            response = session.get(url)
            if handle_rate_limit(response):
                continue
            data = response.json()
            yield data
            url = data.get(class="hl-string">'next_page')
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'Error fetching data from {url}: {e}')
            break

def process_ticket(ticket, event_log):
    ticket_id = ticket[class="hl-string">'id']
    print(fclass="hl-string">'Processing Ticket ID: {ticket_id}')

    class=class="hl-string">"hl-comment"># --- 1. Fetch Ticket Audits ---
    audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
    all_events = [] class=class="hl-string">"hl-comment"># A temporary list to hold all events for sorting

    for audit_page in fetch_paginated_data(audits_url):
        for audit in audit_page.get(class="hl-string">'audits', []):
            author_id = audit.get(class="hl-string">'author_id')
            timestamp = audit[class="hl-string">'created_at']

            class=class="hl-string">"hl-comment"># Store ticket state at the time of the audit
            ticket_state = {}
            for event in audit.get(class="hl-string">'events', []):
                if event.get(class="hl-string">'field_name') in [class="hl-string">'assignee_id', class="hl-string">'group_id', class="hl-string">'priority', class="hl-string">'status', class="hl-string">'channel', class="hl-string">'type', class="hl-string">'tags']:
                    ticket_state[event[class="hl-string">'field_name']] = event.get(class="hl-string">'value')

            for event in audit.get(class="hl-string">'events', []):
                event[class="hl-string">'timestamp'] = timestamp
                event[class="hl-string">'author_id'] = author_id
                event[class="hl-string">'ticket_state'] = ticket_state
                all_events.append(event)

    class=class="hl-string">"hl-comment"># --- 2. Fetch Comments (which are not fully detailed in audits) ---
    comments_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/comments.json'
    for comment_page in fetch_paginated_data(comments_url):
        for comment in comment_page.get(class="hl-string">'comments', []):
            comment[class="hl-string">'type'] = class="hl-string">'Comment'
            comment[class="hl-string">'timestamp'] = comment[class="hl-string">'created_at']
            class=class="hl-string">"hl-comment"># Add ticket_state placeholder, though it's less relevant for comments
            comment[class="hl-string">'ticket_state'] = {}
            all_events.append(comment)

    class=class="hl-string">"hl-comment"># --- 3. Fetch SLA Metrics ---
    metrics_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json'
    try:
        response = session.get(metrics_url)
        if not handle_rate_limit(response):
            metrics_data = response.json().get(class="hl-string">'ticket_metric', {})
            if metrics_data.get(class="hl-string">'sla_policy'):
                for sla in metrics_data[class="hl-string">'sla_policy'][class="hl-string">'policy_metrics']:
                    all_events.append({
                        class="hl-string">'type': class="hl-string">'SlaApply',
                        class="hl-string">'timestamp': metrics_data[class="hl-string">'created_at'],
                        class="hl-string">'policy_name': sla[class="hl-string">'policy'][class="hl-string">'title'],
                        class="hl-string">'ticket_state': {}
                    })
                    if sla.get(class="hl-string">'breach_at') and datetime.fromisoformat(sla[class="hl-string">'breach_at'].replace(class="hl-string">'Z', class="hl-string">'+00:00')) < datetime.now(timezone.utc):
                        all_events.append({
                            class="hl-string">'type': class="hl-string">'SlaBreach',
                            class="hl-string">'timestamp': sla[class="hl-string">'breach_at'],
                            class="hl-string">'policy_name': sla[class="hl-string">'policy'][class="hl-string">'title'],
                            class="hl-string">'metric': sla[class="hl-string">'metric'],
                            class="hl-string">'ticket_state': {}
                        })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Could not fetch SLA metrics for ticket {ticket_id}: {e}')


    class=class="hl-string">"hl-comment"># --- 4. Sort all collected events by timestamp ---
    all_events.sort(key=lambda x: x[class="hl-string">'timestamp'])

    class=class="hl-string">"hl-comment"># --- 5. Process sorted events to create event log rows ---
    last_assignee = None

    for event in all_events:
        activity_name = None
        timestamp = event[class="hl-string">'timestamp']

        event_type = event.get(class="hl-string">'type')
        field_name = event.get(class="hl-string">'field_name')

        if event_type == class="hl-string">'Create':
            activity_name = class="hl-string">'Service Request Created'
            last_assignee = event.get(class="hl-string">'value') if field_name == class="hl-string">'assignee_id' else None

        elif event_type == class="hl-string">'Change':
            prev_value = event.get(class="hl-string">'previous_value')
            new_value = event.get(class="hl-string">'value')

            if field_name == class="hl-string">'status':
                if new_value == class="hl-string">'solved': activity_name = class="hl-string">'Service Request Resolved'
                elif new_value == class="hl-string">'closed': activity_name = class="hl-string">'Service Request Closed'
                elif new_value == class="hl-string">'hold': activity_name = class="hl-string">'Request Placed On-Hold'
                elif new_value == class="hl-string">'open' and prev_value == class="hl-string">'solved': activity_name = class="hl-string">'Service Request Reopened'
            elif field_name == class="hl-string">'priority': activity_name = class="hl-string">'Priority Changed'
            elif field_name == class="hl-string">'assignee_id':
                if prev_value is None and new_value is not None:
                    activity_name = class="hl-string">'Request Assigned to Agent'
                elif prev_value is not None and new_value is not None:
                    activity_name = class="hl-string">'Agent Reassigned'
                last_assignee = new_value
            elif field_name == class="hl-string">'group_id':
                if prev_value is not None and new_value is not None:
                    activity_name = class="hl-string">'Request Escalated'

        elif event_type == class="hl-string">'Comment':
            if event.get(class="hl-string">'public', False):
                activity_name = class="hl-string">'Public Reply Sent'
            else:
                activity_name = class="hl-string">'Internal Note Added'

        elif event_type == class="hl-string">'SlaApply':
            activity_name = class="hl-string">'SLA Target Applied'
        elif event_type == class="hl-string">'SlaBreach':
            activity_name = class="hl-string">'SLA Target Breached'

        if activity_name:
            class=class="hl-string">"hl-comment"># Get attribute values from the ticket object itself as a baseline
            agent_id = ticket.get(class="hl-string">'assignee_id')
            group_id = ticket.get(class="hl-string">'group_id')
            priority = ticket.get(class="hl-string">'priority')
            status = ticket.get(class="hl-string">'status')
            
            class=class="hl-string">"hl-comment"># Override with values at the time of the event if available
            state = event.get(class="hl-string">'ticket_state', {})
            agent_id = state.get(class="hl-string">'assignee_id', agent_id)
            group_id = state.get(class="hl-string">'group_id', group_id)
            priority = state.get(class="hl-string">'priority', priority)
            status = state.get(class="hl-string">'status', status)
            
            event_log.append({
                class="hl-string">'ServiceRequestId': ticket_id,
                class="hl-string">'ActivityName': activity_name,
                class="hl-string">'EventTimestamp': timestamp,
                class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                class="hl-string">'AgentName': get_user_name(agent_id),
                class="hl-string">'AssignedTeam': get_group_name(group_id),
                class="hl-string">'RequestPriority': priority,
                class="hl-string">'RequestStatus': status,
                class="hl-string">'RequestChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                class="hl-string">'ServiceType': ticket.get(class="hl-string">'type'),
                class="hl-string">'TicketTags': class="hl-string">', '.join(ticket.get(class="hl-string">'tags', [])),
            })


def main():
    print(class="hl-string">'Starting Zendesk data extraction...')
    event_log = []
    start_unix_time = int(datetime.strptime(START_TIME_STR, class="hl-string">'%Y-%m-%d').timestamp())
    
    class=class="hl-string">"hl-comment"># Use the incremental export endpoint for efficiency
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={start_unix_time}'

    while url:
        try:
            response = session.get(url)
            if handle_rate_limit(response):
                continue
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])
            print(fclass="hl-string">'Fetched {len(tickets)} tickets...')
            for ticket in tickets:
                process_ticket(ticket, event_log)
            
            if not data.get(class="hl-string">'after_cursor'):
                break
            url = data[class="hl-string">'next_page']

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

    print(fclass="hl-string">'Extraction complete. Total events found: {len(event_log)}')
    
    if not event_log:
        print(class="hl-string">'No events were extracted. Please check your configuration and date range.')
        return

    df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Reorder columns to match requirements
    columns = [
        class="hl-string">'ServiceRequestId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'AgentName', class="hl-string">'AssignedTeam', class="hl-string">'RequestPriority', class="hl-string">'RequestStatus',
        class="hl-string">'RequestChannel', class="hl-string">'ServiceType', class="hl-string">'TicketTags'
    ]
    df = df[columns]
    df = df.sort_values(by=[class="hl-string">'ServiceRequestId', class="hl-string">'EventTimestamp']).reset_index(drop=True)

    class=class="hl-string">"hl-comment"># Save to CSV
    output_filename = class="hl-string">'zendesk_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">'Event log saved to {output_filename}')

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

Stappen

Vraag in Zendesk Admin Center de volledige JSON-export van het account aan of start deze. Gebruik hiervoor de exportfunctie die bij je Zendesk-abonnement en account hoort. De exacte menupaden en machtigingen verschillen per account. Gebruik de exportoptie in Admin Center en volg de goedkeuringsprocedure van je organisatie.
Selecteer een datumbereik voor de analyse, bij voorkeur drie tot zes maanden. Biedt de exportfunctie geen datumfilter, download dan de volledige export en pas het filter tijdens de transformatie toe.
Download en bewaar alle JSON-bestanden die de export oplevert. Bewaar ook de oorspronkelijke bestanden, de exporttimestamp, de account-ID en eventuele manifest- of metadatabestanden. Overschrijf de bronbestanden niet tijdens de verwerking.
Verwerk de ticketrecords, ticketauditrecords, auditevents, reacties, gebruikers, organisaties, groepen, SLA-gerelateerde records en aangepaste velden uit de export. Omdat bestandsnamen en JSON-structuren per Zendesk-exportversie kunnen verschillen, moet je vóór uitvoering de bronpaden en JSON-eigenschapskoppelingen in de scriptplaceholders instellen.
Zet elk ticketauditevent om naar een vaste structuur met ServiceRequestId, audit-timestamp, eventtype, veldnaam, vorige waarde, nieuwe waarde, actor-ID, indicator voor openbare reactie, ticketstatus, toegewezen medewerker, groep, prioriteit, kanaal, servicetype, tags, bronsysteem en LastDataUpdate.
Maak voor elke relevante activiteit een rij in het event log. De extractie moet expliciet rijen aanmaken voor Service Request Created, SLA Target Applied, Request Assigned to Agent, Priority Changed, Agent Reassigned, Public Reply Sent, Internal Note Added, Request Placed On-Hold, Request Escalated, SLA Target Breached, Service Request Reopened, Service Request Resolved en Service Request Closed. ProcessMind leest deze rijen zoals ze zijn en leidt geen extra events af.
Koppel waar mogelijk de ID's van medewerkers, groepen, organisaties en aanvragers aan de bijbehorende geëxporteerde gebruikers-, groeps- en organisatierecords. Vul AgentName en AssignedTeam in op basis van de toewijzing op het moment van het event. Behoud de ID of laat de waarde leeg als er geen weergavenaam kan worden gevonden.
Pas vaste eventregels toe. Gebruik het Create-event van de ticketaudit voor Service Request Created en expliciete SLA-auditevents voor SLA Target Applied en SLA Target Breached. Gebruik de eerste relevante wijziging van de toegewezen medewerker voor Request Assigned to Agent en latere wijzigingen voor Agent Reassigned. Gebruik de indicator voor openbare of privéreacties voor reactie- en notitie-events. Leid events voor on-hold, heropend, opgelost en gesloten af uit statusovergangen. Gebruik wijzigingen van de groep of het ingestelde escalatieveld voor Request Escalated.
Sorteer de rijen op ServiceRequestId en EventTimestamp. Gebruik de volgorde van de bron-events als vaste volgorde wanneer timestamps gelijk zijn. Verwijder events niet alleen omdat hun timestamps gelijk zijn: er kunnen meerdere reacties of auditevents op hetzelfde moment plaatsvinden.
Controleer of alle vereiste kolommen aanwezig zijn en of elke activiteit minstens één relevante rij heeft wanneer de brondata het bijbehorende event bevat. Exporteer het eindresultaat als UTF-8-CSV of een andere indeling voor event logs die ProcessMind ondersteunt. Gebruik één rij per event en de vereiste kolomnamen ServiceRequestId, ActivityName, EventTimestamp, SourceSystem en LastDataUpdate.

Configuratie

Omvang van de export: Gebruik de volledige JSON-export van het Zendesk Support-account en bewaar alle JSON-bestanden die de export oplevert. De export moet ticketdata en ticketaudit- of eventdata bevatten. Worden SLA-, reactie-, gebruikers-, organisatie-, groeps- of aangepaste-velddata apart geleverd, voeg die bestanden dan toe aan de invoer voor de transformatie.
Datumbereik: Gebruik voor de eerste extractie en controle bij voorkeur drie tot zes maanden. Is de export accountbreed en kun je die niet op datum beperken, filter dan na het verwerken op EventTimestamp en bewaar het volledige bronarchief.
Activiteitsregels: Stel expliciete koppelingen in voor alle 13 activiteiten. Vertrouw er niet op dat ProcessMind toewijzingen, escalaties, SLA-, status- of reactie-events uit andere rijen afleidt.
SLA-instellingen: Koppel de werkelijke eventnamen of eigenschappen uit de export aan het toepassen en overschrijden van SLA-streefwaarden. Bevat de export geen expliciete SLA-events, verzin die dan niet. Stel de bijbehorende bronpaden in de placeholders in en documenteer welke activiteiten niet beschikbaar zijn.
Escalatie-instellingen: Bepaal welk groepsveld of aangepast veld in het account voor escalatie wordt gebruikt. Stel vóór uitvoering ESCALATION_FIELD_ID of de vergelijkbare configuratie in op de ID van het geëxporteerde veld.
Bronpaden: Stel de JSON-bestandspaden en JSON-eigenschapskoppelingen in het script in. Bestandsnamen en nesting in Zendesk-exports kunnen verschillen per exportversie en accountconfiguratie.
Vereiste uitvoer: Vul voor elke eventrij ServiceRequestId, ActivityName, EventTimestamp, SourceSystem en LastDataUpdate in. Aanbevolen kolommen zijn AgentName, AssignedTeam, RequestPriority, RequestStatus, RequestChannel, ServiceType en TicketTags.
Filters: Pas het vereiste datumbereik voor de analyse, de account- of merkselectie en eventuele bedrijfsfilters pas toe nadat je hebt gecontroleerd of de bijbehorende eigenschap in de export aanwezig is. Gebruik geen filters op basis van niet-ondersteunde of niet-gecontroleerde veldnamen.
Prestaties: Verwerk JSON waar mogelijk stapsgewijs en laad niet de volledige accountexport in het geheugen. Indexeer ticket-ID's en audit-ID's en schrijf genormaliseerde tussenbestanden voordat je het definitieve event log maakt. Grote exports moeten mogelijk worden opgesplitst op datum of ticket-ID.
Vereisten: Beheerderstoegang om de volledige accountexport aan te vragen of te downloaden, toestemming voor ticketaudits en referentiedata van gebruikers of groepen, een Zendesk-abonnement met de exportfunctie, voldoende lokale opslag voor de volledige export en een omgeving die JSON kan verwerken en UTF-8-CSV kan schrijven.
Gegevensbescherming: Behandel gegevens over aanvragers, medewerkers, organisaties, reacties en tickets als mogelijk gevoelig. Bewaar bronbestanden en getransformeerde bestanden volgens de bewaartermijnen, toegangsregels en privacyvereisten van je organisatie.

a Voorbeeldquery config

import csv
import json
import os
from datetime import datetime, timezone
from pathlib import Path

SOURCE_DIRECTORY = "[Path to extracted Zendesk JSON directory]"
OUTPUT_FILE = "[Path to ProcessMind event log CSV]"
START_DATE = "[YYYY-MM-DD or blank]"
END_DATE = "[YYYY-MM-DD or blank]"
SOURCE_SYSTEM = "Zendesk Support"
LAST_DATA_UPDATE = "[ISO-8601 timestamp of source refresh]"
ESCALATION_FIELD_ID = "[Zendesk custom field identifier used for escalation, or blank]"


def load_json_files(directory):
    documents = []
    for path in Path(directory).rglob("*.json"):
        with path.open("r", encoding="utf-8") as handle:
            documents.append((path.name, json.load(handle)))
    return documents


def as_list(value):
    if isinstance(value, list):
        return value
    if isinstance(value, dict):
        for key in ("tickets", "ticket", "audits", "events", "comments", "users", "groups", "organizations", "data", "results"):
            if isinstance(value.get(key), list):
                return value[key]
    return []


def parse_timestamp(value):
    if not value:
        return None
    text = str(value).replace("Z", "+00:00")
    try:
        parsed = datetime.fromisoformat(text)
        if parsed.tzinfo is None:
            parsed = parsed.replace(tzinfo=timezone.utc)
        return parsed.astimezone(timezone.utc)
    except ValueError:
        return None


def in_range(timestamp):
    if timestamp is None:
        return False
    if START_DATE and timestamp.date().isoformat() < START_DATE:
        return False
    if END_DATE and timestamp.date().isoformat() > END_DATE:
        return False
    return True


def value(record, *keys):
    for key in keys:
        if isinstance(record, dict) and record.get(key) is not None:
            return record.get(key)
    return None


def identifier(record):
    return value(record, "id", "user_id", "group_id", "organization_id", "ticket_id")


def normalize_id(value_to_normalize):
    if value_to_normalize is None or value_to_normalize == "":
        return None
    return str(value_to_normalize)


def audit_events(audit):
    events = value(audit, "events", "audit_events")
    return events if isinstance(events, list) else []


def event_type(event):
    return str(value(event, "type", "event_type", "action") or "").lower()


def event_field(event):
    return str(value(event, "field_name", "field", "property") or "").lower()


def event_value(event, key):
    return value(event, key, key.replace("_", ""))


def status_value(ticket, event, new=True):
    if new:
        return value(event, "value", "new_value", "to") or value(ticket, "status")
    return value(event, "previous_value", "old_value", "from")


def comment_public(event):
    public_value = value(event, "public", "is_public")
    return public_value is True or str(public_value).lower() == "true"


def add_row(rows, ticket, activity, timestamp, agent_name=None, assigned_team=None, priority=None, status=None, channel=None, service_type=None, tags=None, sequence=0):
    parsed = parse_timestamp(timestamp)
    if not in_range(parsed):
        return
    rows.append({
        "ServiceRequestId": str(value(ticket, "id", "ticket_id")),
        "ActivityName": activity,
        "EventTimestamp": parsed.isoformat(),
        "SourceSystem": SOURCE_SYSTEM,
        "LastDataUpdate": LAST_DATA_UPDATE,
        "AgentName": agent_name or "",
        "AssignedTeam": assigned_team or "",
        "RequestPriority": priority or "",
        "RequestStatus": status or "",
        "RequestChannel": channel or "",
        "ServiceType": service_type or "",
        "TicketTags": ",".join(tags) if isinstance(tags, list) else (tags or ""),
        "SourceSequence": sequence
    })


def main():
    documents = load_json_files(SOURCE_DIRECTORY)
    tickets = {}
    audits_by_ticket = {}
    users = {}
    groups = {}
    organizations = {}
    standalone_comments = []
    standalone_sla_events = []

    for filename, document in documents:
        records = as_list(document)
        lower_name = filename.lower()
        for record in records:
            if not isinstance(record, dict):
                continue
            record_id = normalize_id(identifier(record))
            if any(token in lower_name for token in ("user", "agent")) and record_id:
                users[record_id] = record
            elif "group" in lower_name and record_id:
                groups[record_id] = record
            elif "organization" in lower_name and record_id:
                organizations[record_id] = record
            elif "audit" in lower_name and value(record, "ticket_id") is not None:
                audits_by_ticket.setdefault(normalize_id(value(record, "ticket_id")), []).append(record)
            elif "comment" in lower_name:
                standalone_comments.append(record)
            elif "sla" in lower_name:
                standalone_sla_events.append(record)
            elif value(record, "ticket_id") is not None and value(record, "type", "event_type") is not None:
                standalone_sla_events.append(record)
            elif value(record, "id") is not None and any(key in record for key in ("status", "priority", "assignee_id", "group_id", "tags")):
                tickets[record_id] = record

    rows = []
    for ticket_id, ticket in tickets.items():
        if not ticket_id:
            continue
        ticket_audits = audits_by_ticket.get(ticket_id, [])
        ticket_audits.sort(key=lambda item: (parse_timestamp(value(item, "created_at", "timestamp", "time")) or datetime.min.replace(tzinfo=timezone.utc), str(value(item, "id") or "")))
        current_assignee = normalize_id(value(ticket, "assignee_id"))
        current_group = normalize_id(value(ticket, "group_id"))
        assignment_seen = False
        sequence = 0
        base_priority = value(ticket, "priority")
        base_status = value(ticket, "status")
        base_channel = value(ticket, "via", "channel")
        base_service_type = value(ticket, "type", "service_type")
        base_tags = value(ticket, "tags") or []

        for audit in ticket_audits:
            audit_time = value(audit, "created_at", "timestamp", "time")
            actor_id = normalize_id(value(audit, "author_id", "actor_id", "user_id"))
            actor = users.get(actor_id, {})
            agent_name = value(actor, "name", "display_name", "email") or ""
            audit_group = groups.get(current_group, {})
            assigned_team = value(audit_group, "name", "display_name") or ""
            for event in audit_events(audit):
                sequence += 1
                kind = event_type(event)
                field = event_field(event)
                timestamp = value(event, "created_at", "timestamp", "time") or audit_time
                new_value = event_value(event, "value") or event_value(event, "new_value") or event_value(event, "to")
                old_value = event_value(event, "previous_value") or event_value(event, "old_value") or event_value(event, "from")
                event_agent = agent_name
                event_team = assigned_team
                if field in ("assignee_id", "assignee"):
                    new_assignee = normalize_id(new_value)
                    old_assignee = normalize_id(old_value)
                    if new_assignee and not assignment_seen and new_assignee != current_group:
                        assigned_agent = users.get(new_assignee, {})
                        add_row(rows, ticket, "Request Assigned to Agent", timestamp, value(assigned_agent, "name", "display_name", "email") or event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                        assignment_seen = True
                    elif new_assignee and assignment_seen and new_assignee != old_assignee:
                        assigned_agent = users.get(new_assignee, {})
                        add_row(rows, ticket, "Agent Reassigned", timestamp, value(assigned_agent, "name", "display_name", "email") or event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    current_assignee = new_assignee or current_assignee
                elif field in ("priority",):
                    add_row(rows, ticket, "Priority Changed", timestamp, event_agent, event_team, new_value, base_status, base_channel, base_service_type, base_tags, sequence)
                    base_priority = new_value or base_priority
                elif field in ("group_id", "group"):
                    new_group = normalize_id(new_value)
                    new_group_record = groups.get(new_group, {})
                    new_team = value(new_group_record, "name", "display_name") or event_team
                    if new_group and new_group != current_group:
                        add_row(rows, ticket, "Request Escalated", timestamp, event_agent, new_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    current_group = new_group or current_group
                elif field in ("status", "status_category"):
                    status_text = str(new_value or "").lower()
                    old_status_text = str(old_value or "").lower()
                    if status_text == "on-hold":
                        add_row(rows, ticket, "Request Placed On-Hold", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    if status_text == "solved":
                        add_row(rows, ticket, "Service Request Resolved", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    if status_text == "closed":
                        add_row(rows, ticket, "Service Request Closed", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    if old_status_text == "solved" and status_text in ("open", "pending", "on-hold"):
                        add_row(rows, ticket, "Service Request Reopened", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    base_status = new_value or base_status
                elif kind in ("comment", "comment_created", "comment_added") or field in ("comment", "comment_body"):
                    if comment_public(event):
                        add_row(rows, ticket, "Public Reply Sent", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    else:
                        add_row(rows, ticket, "Internal Note Added", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                elif "sla" in kind or "sla" in field:
                    sla_text = str(value(event, "target_status", "status", "action", "event_type", "type") or "").lower()
                    if any(token in sla_text for token in ("breach", "breached", "missed", "failed")):
                        add_row(rows, ticket, "SLA Target Breached", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    elif any(token in sla_text for token in ("applied", "active", "started", "target")):
                        add_row(rows, ticket, "SLA Target Applied", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                elif ESCALATION_FIELD_ID and field == ESCALATION_FIELD_ID.lower():
                    add_row(rows, ticket, "Request Escalated", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)

            if str(value(audit, "action", "type", "event_type") or "").lower() == "create":
                add_row(rows, ticket, "Service Request Created", audit_time, agent_name, assigned_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)

        for record in standalone_sla_events:
            if normalize_id(value(record, "ticket_id")) != ticket_id:
                continue
            timestamp = value(record, "created_at", "timestamp", "time")
            text = str(value(record, "event_type", "type", "status", "action") or "").lower()
            if "breach" in text or "missed" in text or "failed" in text:
                add_row(rows, ticket, "SLA Target Breached", timestamp, "", "", base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
            elif "sla" in text or "applied" in text or "active" in text:
                add_row(rows, ticket, "SLA Target Applied", timestamp, "", "", base_priority, base_status, base_channel, base_service_type, base_tags, sequence)

    rows.sort(key=lambda row: (row["ServiceRequestId"], row["EventTimestamp"], int(row["SourceSequence"])))
    output_columns = ["ServiceRequestId", "ActivityName", "EventTimestamp", "SourceSystem", "LastDataUpdate", "AgentName", "AssignedTeam", "RequestPriority", "RequestStatus", "RequestChannel", "ServiceType", "TicketTags"]
    with open(OUTPUT_FILE, "w", encoding="utf-8", newline="") as handle:
        writer = csv.DictWriter(handle, fieldnames=output_columns)
        writer.writeheader()
        for row in rows:
            writer.writerow({column: row.get(column, "") for column in output_columns})


if __name__ == "__main__":
    main()

Klaar om te beginnen?

Begin vandaag met het verbeteren van je proces voor serviceverzoeken. Gebruik deze datatemplate om bottlenecks te vinden en Zendesk Support efficiënter te maken.

Terug naar de verbetergids Template downloaden

Verbeter het beheer van serviceverzoeken. Verminder vertragingen.

Maak een einde aan trage afhandeling en frustratie bij gebruikers. Bereik 70% automatisering.

Start je gratis proefperiode

Geen creditcard nodig. Snel ingesteld.

Datatemplate voor serviceverzoeken

Datatemplate voor serviceverzoeken

Attributen voor serviceverzoeken

Activiteiten rond serviceverzoeken

Extractiegidsen

Zendesk Explore: rapportage en data-export

Stappen

Configuratie

a Voorbeeldquery config

Zendesk REST API-data ophalen met een Python-script

Stappen

Configuratie

a Voorbeeldquery python

Zendesk Support: volledige JSON-export van een account

Stappen

Configuratie

a Voorbeeldquery config

Klaar om te beginnen?

Verbeter het beheer van serviceverzoeken. Verminder vertragingen.

Datatemplate voor serviceverzoeken

Datatemplate voor serviceverzoeken

Attributen voor serviceverzoeken

Activiteiten rond serviceverzoeken

Extractiegidsen

Zendesk Explore: rapportage en data-export

Stappen

Configuratie

a Voorbeeldquery config

Zendesk REST API-data ophalen met een Python-script

Stappen

Configuratie

a Voorbeeldquery python

Zendesk Support: volledige JSON-export van een account

Stappen

Configuratie

a Voorbeeldquery config

Klaar om te beginnen?

Verbeter het beheer van serviceverzoeken. Verminder vertragingen.

We gaan zorgvuldig om met je privacy