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

Datatemplate voor klantenservice

Zendesk Support

Attributen voor klantenservice (18) Activiteiten in de klantenservice (14) Extractiegidsen (4)

Datatemplate voor klantenservice

Deze template helpt je de juiste data te verzamelen voor de analyse van het klantenserviceproces. Je vindt erin welke attributen je moet vastleggen, welke activiteiten je moet volgen en hoe je deze informatie kunt ophalen. Met deze gids bouw je een bruikbaar event log om patronen te ontdekken en de dienstverlening te verbeteren.

Aanbevolen attributen om te verzamelen
Belangrijke activiteiten om in het klantenserviceproces te volgen
Data ophalen uit Zendesk Support

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

Template downloaden

Attributen voor klantenservice

Dit zijn de aanbevolen datavelden voor je event log, zodat je de klantenservice volledig kunt analyseren.

5 Verplicht 6 Aanbevolen 7 Optioneel

	Naam	Beschrijving
	Serviceverzoek ServiceRequest	De unieke identificatiecode van elk klantserviceverzoek, ook wel ticket of case genoemd.
Beschrijving Het serviceverzoek is de belangrijkste case-ID die alle activiteiten voor één klantvraag of probleem met elkaar verbindt, van aanmaak tot definitieve oplossing. Elke interactie, wijziging of interne actie is gekoppeld aan deze unieke ID. Bij process mining kun je met gebeurtenissen die per serviceverzoek zijn gegroepeerd het volledige klanttraject analyseren. Dit vormt de basis voor KPI’s zoals de totale oplostijd, het opsporen van procesafwijkingen en inzicht in de levenscyclus van elk klantprobleem. Waarom dit belangrijk is Dit is de essentiële Case-ID die alle processtappen met elkaar verbindt. Zo kun je elk afzonderlijk klantservicetraject reconstrueren en analyseren. Waar vind je dit? Zendesk Tickets API, veld `id`. Voorbeelden 102451287415332
	Starttijd StartTime	De timestamp die aangeeft wanneer een activiteit of gebeurtenis begon.
Beschrijving De starttijd, of event-timestamp, legt de exacte datum en tijd van een activiteit vast. Zo registreert deze wanneer een klant een reactie plaatste, een agent werd toegewezen of de ticketstatus veranderde in 'Opgelost'. Deze timestamp is essentieel voor process mining, omdat je hiermee de chronologische volgorde van gebeurtenissen vaststelt. Je gebruikt de timestamp om de tijd tussen activiteiten te berekenen, doorlooptijden te meten, prestaties ten opzichte van SLA’s te analyseren en het verloop van het serviceproces in de tijd te begrijpen. Waarom dit belangrijk is Deze timestamp is nodig om gebeurtenissen op volgorde te zetten, tijdsduur te berekenen en het verloop van het serviceverzoek te analyseren. Waar vind je dit? Zendesk Ticket Audits API, veld `created_at` voor elke gebeurtenis in het auditspoor. Voorbeelden 2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
	Activiteitsnaam ActivityName	De naam van de specifieke gebeurtenis of taak die tijdens de levenscyclus van het serviceverzoek heeft plaatsgevonden.
Beschrijving De activiteitsnaam beschrijft één stap of mijlpaal in het klantserviceproces, zoals 'Serviceverzoek aangemaakt', 'Verzoek toegewezen aan agent' of 'Serviceverzoek opgelost'. Bij elke gebeurtenis hoort een timestamp. Samen vormen de gebeurtenissen de reeks acties voor elk serviceverzoek. Dit attribuut is belangrijk om het procesverloop zichtbaar te maken, procesvarianten te ontdekken en de frequentie en volgorde van gebeurtenissen te analyseren. Zo zien analisten welke acties worden uitgevoerd en kunnen ze veelvoorkomende routes, bottlenecks en afwijkingen van de standaardprocedure opsporen. Waarom dit belangrijk is Dit attribuut beschrijft de processtappen. Daarmee kun je de proceskaart weergeven en procesverlopen en varianten analyseren. Waar vind je dit? Afgeleid uit Zendesk-ticketauditlogboeken of event streams waarin wijzigingen en acties worden vastgelegd. Voorbeelden Serviceverzoek aangemaaktVerzoek toegewezen aan agentEerste openbare reactie van agent verstuurdServiceverzoek opgelost
	Bronsysteem SourceSystem	Het systeem waaruit de data is gehaald.
Beschrijving Dit attribuut geeft aan uit welk systeem de data over serviceverzoeken afkomstig is, in dit geval Zendesk Support. Het helpt bij datagovernance en het volgen van de herkomst van data, vooral wanneer je data uit meerdere systemen combineert. Bij analyses zorgt dit attribuut ervoor dat data aan de juiste bron wordt gekoppeld. Dat is belangrijk voor de integriteit van de data en om de procescontext te begrijpen, vooral in omgevingen met meerdere systemen. Waarom dit belangrijk is Geeft aan waar de data vandaan komt. Dat is belangrijk voor datagovernance en om procesdata in geïntegreerde omgevingen van elkaar te onderscheiden. Waar vind je dit? Dit is een vaste waarde die tijdens de data-extractie wordt toegevoegd om de herkomst van de data aan te geven. Voorbeelden Zendesk Support
	Laatste data-update LastDataUpdate	De timestamp van de meest recente data-update of extractie uit het bronsysteem.
Beschrijving Dit attribuut geeft aan wanneer de dataset voor het laatst vanuit Zendesk Support is bijgewerkt. Zo weet je hoe actueel de data in de analyse is. Met de datum van de laatste update kunnen analisten en zakelijke gebruikers beoordelen of ze de meest recente procesinformatie bekijken. Dit helpt bij het managen van verwachtingen over de actualiteit van de data en is belangrijk voor rapportages en monitoring. Waarom dit belangrijk is Maakt duidelijk hoe actueel de data is, zodat gebruikers weten hoe recent de procesanalyse is. Waar vind je dit? Dit metadataveld wordt tijdens de data-extractie aangemaakt en opgeslagen. Het bevat de timestamp van de extractietaak. Voorbeelden 2023-10-27T02:00:00Z
	Communicatiekanaal CommunicationChannel	Het kanaal waarlangs het serviceverzoek is ingediend of de communicatie heeft plaatsgevonden.
Beschrijving Dit attribuut geeft aan welk communicatiemiddel is gebruikt, zoals e-mail, een webformulier, chat of telefoon. Zo zie je hoe klanten contact opnemen met de servicedesk. Inzicht in het gebruik van de verschillende kanalen helpt bij de personeelsplanning en het verbeteren van de klantervaring. Het dashboard ‘Overzicht van kanaalgebruik’ analyseert welke kanalen het populairst zijn en of bepaalde kanalen samenhangen met langere oplostijden of andere procesroutes. Zo kun je bepalen waar investeringen in betere dienstverlening of automatisering het meeste opleveren. Waarom dit belangrijk is Laat zien hoe klanten en medewerkers met elkaar communiceren. Zo kun je de efficiëntie van de kanalen analyseren en zien wat het effect is op het proces en de klantervaring. Waar vind je dit? Zendesk Tickets API, veld `via.channel`. Voorbeelden webe-mailapichat
	Prioriteit Priority	De prioriteit van het serviceverzoek, bijvoorbeeld 'Laag', 'Normaal', 'Hoog' of 'Urgent'.
Beschrijving De prioriteit geeft aan hoe dringend een serviceverzoek is. Vaak bepaalt die ook de plek in de wachtrij en de beoogde oplostijd. Zo kunnen agents eerst de meest urgente problemen behandelen. Dit attribuut is belangrijk voor prestatie- en SLA-analyses. Het dashboard 'Analyse van de oplostijd van serviceverzoeken' gebruikt de prioriteit om data uit te splitsen. Zo zie je of verzoeken met hoge prioriteit sneller worden afgehandeld dan verzoeken met een lagere prioriteit en of middelen volgens de behoeften van de organisatie worden ingezet. Waarom dit belangrijk is Geeft aan hoe urgent een verzoek is. Dit is belangrijk om de naleving van SLA’s te analyseren en urgente problemen snel op te lossen. Waar vind je dit? Zendesk Tickets API, veld `priority`. Voorbeelden LaagNormaalHoogUrgent
	SLA overschreden IsSlaBreached	Een booleaanse waarde die aangeeft of de oplostijd van het serviceverzoek langer was dan de SLA-doelstelling.
Beschrijving Dit berekende attribuut geeft met een eenvoudige waar-of-onwaarwaarde aan of een serviceverzoek niet binnen de afgesproken oplostijd is afgehandeld. De waarde wordt bepaald door de werkelijke oplostijd te vergelijken met de SLA-doelstelling. Deze waarde maakt SLA-naleving eenvoudig te analyseren. Het is het belangrijkste datapunt voor het dashboard ‘SLA-naleving’ en de KPI ‘SLA-nalevingspercentage’. Zo kun je snel zien hoeveel verzoeken wel en niet binnen de afgesproken tijd zijn afgehandeld. Waarom dit belangrijk is Geeft per case een helder ja-of-nee-resultaat voor de SLA-prestaties. Zo wordt het eenvoudiger om de naleving te volgen en erover te rapporteren. Waar vind je dit? Berekend tijdens de datatransformatie door de totale oplostijd te vergelijken met SlaTargetResolutionTime. Voorbeelden truefalse
	SLA-doel voor oplostijd SlaTargetResolutionTime	De beoogde tijd waarbinnen een serviceverzoek moet zijn opgelost, volgens het SLA-beleid.
Beschrijving Dit attribuut bepaalt de SLA-doelstelling voor het oplossen van een ticket. De doelstelling is vaak dynamisch en hangt bijvoorbeeld af van de prioriteit of het type verzoek, of van het servicepakket van de klant. Dit attribuut vormt de basis voor het dashboard ‘SLA-naleving’. De doelstelling is de norm waarmee je de werkelijke oplostijd vergelijkt. Door de resultaten met deze norm te vergelijken, kun je de kwaliteit van de dienstverlening meten en controleren of je de afspraken met klanten nakomt. Waarom dit belangrijk is Legt vast welke service je de klant belooft. Deze norm gebruik je om te meten of verzoeken op tijd worden opgelost en of je de SLA naleeft. Waar vind je dit? Afgeleid van het SLA-beleid dat op een ticket van toepassing is. Deze informatie is beschikbaar via de Zendesk Ticket Metrics API. Voorbeelden 144002880086400
	Toegewezen agent AssignedAgent	De naam of ID van de klantenservicemedewerker die het serviceverzoek behandelt.
Beschrijving Dit attribuut geeft aan welke agent op een bepaald moment verantwoordelijk is voor een activiteit of serviceverzoek. De toegewezen agent kan tijdens de levenscyclus veranderen als het verzoek opnieuw wordt toegewezen. Analyse per toegewezen agent geeft inzicht in werkbelasting, prestaties en efficiëntie. Het ondersteunt het dashboard 'Werkbelasting en efficiëntie van agents', waarmee je afhandeltijden en aantallen cases van verschillende agents kunt vergelijken. Zo ontdek je waar coaching nodig is en kun je de werkbelasting beter verdelen. Waarom dit belangrijk is Houdt bij welke agent een actie heeft uitgevoerd. Zo kun je individuele prestaties, de verdeling van de werkbelasting en de inzet van middelen analyseren. Waar vind je dit? Zendesk Tickets API, veld `assignee_id`. Gebruikersgegevens zijn op te halen via de Users API. Voorbeelden Jan JansenJanneke de VriesSupportBot
	Type serviceverzoek ServiceRequestType	De classificatie van het serviceverzoek, bijvoorbeeld 'Vraag', 'Incident', 'Probleem' of 'Taak'.
Beschrijving Dit attribuut deelt serviceverzoeken in op basis van hun aard. De classificatie wordt meestal ingesteld wanneer het verzoek wordt aangemaakt of beoordeeld. Zo kan de juiste workflow en prioriteit worden bepaald. Door analyses op type serviceverzoek uit te splitsen, kun je de oplostijd, escalaties en procesverlopen van verschillende soorten problemen vergelijken. Dit zie je bijvoorbeeld in dashboards zoals 'Analyse van de oplostijd van serviceverzoeken' en 'Percentage en oorzaken van interne escalaties'. Zo ontdek je of bepaalde verzoektypen vaker problemen opleveren of minder efficiënt worden afgehandeld. Waarom dit belangrijk is Deelt verzoeken in categorieën in, zodat je prestaties voor verschillende soorten problemen kunt vergelijken en analyseren. Dat helpt om procesverbeteringen gericht aan te pakken. Waar vind je dit? Zendesk Tickets API, veld `type`. Voorbeelden VraagIncidentProbleemTaak
	Aantal informatieverzoeken InformationRequestCount	Het totale aantal keren dat voor één serviceverzoek informatie bij de klant is opgevraagd.
Beschrijving Deze berekende metriek telt per serviceverzoek hoe vaak de activiteit ‘Informatie opvragen bij klant’ voorkomt. Een hoog aantal kan erop wijzen dat medewerkers niet meteen alle benodigde informatie verzamelen. Deze metriek wordt gebruikt in het dashboard ‘Analyse van herhaalde informatieverzoeken’. Door het aantal bij te houden, kun je inefficiënties in het proces en aandachtspunten voor medewerkerstraining vinden. Minder vaak om informatie vragen kan de oplostijd flink verkorten en de klantervaring verbeteren. Waarom dit belangrijk is Maakt zichtbaar hoe vaak er heen en weer wordt gecommuniceerd met de klant. Zo zie je welke inefficiënties de oplostijd verlengen en de klantervaring verslechteren. Waar vind je dit? Berekend door per serviceverzoek het aantal gebeurtenissen te tellen waarbij ActivityName gelijk is aan ‘Information Requested From Customer’. Voorbeelden 013
	Eindtijd EndTime	De timestamp die aangeeft wanneer een activiteit of gebeurtenis is afgerond.
Beschrijving De eindtijd is het moment waarop een activiteit is afgerond. In veel event logs kan de starttijd van de volgende activiteit dienen als eindtijd van de huidige activiteit. Bij activiteiten die een status beschrijven, zoals 'Agent onderzoekt probleem', geeft de eindtijd aan wanneer die status eindigde. Dit attribuut is nodig om de duur van activiteiten nauwkeurig te berekenen, een belangrijk onderdeel van prestatieanalyse. Je ziet welke stappen de meeste tijd kosten en krijgt de basis voor een gedetailleerde bottleneckanalyse en berekeningen van de efficiëntie van de inzet van middelen. Waarom dit belangrijk is Maakt het mogelijk om de duur van activiteiten te berekenen. Dat is belangrijk om bottlenecks op te sporen en prestaties te meten. Waar vind je dit? Vaak afgeleid van de starttijd van de volgende gebeurtenis in de reeks voor een bepaald serviceverzoek. Voorbeelden 2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z
	Medewerkersgroep AgentGroup	De supportgroep of het team waaraan het serviceverzoek is toegewezen.
Beschrijving Dit attribuut geeft aan welk team verantwoordelijk is voor het serviceverzoek. Verzoeken worden vaak toegewezen aan specifieke groepen op basis van expertise, productgebied of taal. Met een analyse per medewerkersgroep krijg je inzicht in de prestaties en werkverdeling per team en in hoe verzoeken tussen teams worden opgeschaald. Dit geeft een beeld op teamniveau, in plaats van per medewerker. Zo kun je problemen opsporen die binnen een afdeling of functie spelen. Waarom dit belangrijk is Legt vast welk team verantwoordelijk is. Zo kun je de teamprestaties, overdrachten tussen teams en de verdeling van capaciteit over supportniveaus en specialismen analyseren. Waar vind je dit? Zendesk Tickets API, veld `group_id`. Groepsgegevens zijn op te halen via de Groups API. Voorbeelden Supportniveau 1Technische supportFacturering
	Oplossingscode ResolutionCode	Een code of categorie die aangeeft waarom het verzoek uiteindelijk is opgelost of gesloten.
Beschrijving De oplossingscode geeft gestructureerde informatie over de uitkomst van een serviceverzoek. Voorbeelden zijn ‘Opgelost door medewerker’, ‘Dubbel verzoek’, ‘Geen actie nodig’ en ‘Bekend probleem’. Dit geeft meer context dan alleen de status ‘Gesloten’. Dit attribuut is vooral nuttig voor oorzaakanalyse. In het dashboard ‘Trends in heropende serviceverzoeken’ kun je het percentage heropende verzoeken per oplossingscode analyseren. Zo ontdek je of bepaalde oplossingen minder goed werken en klanten daarom opnieuw contact moeten opnemen met de supportafdeling. Waarom dit belangrijk is Geeft inzicht in de uitkomst van een serviceverzoek. Dat is belangrijk voor oorzaakanalyse en om te begrijpen waarom verzoeken opnieuw worden geopend. Waar vind je dit? Dit is meestal een aangepast ticketveld in Zendesk. De exacte veldnaam hangt af van de Zendesk-configuratie. Voorbeelden Opgelost bij eerste contactDoorgestuurd naar niveau 2Wacht op klantProductfout
	Opnieuw geopend IsReopened	Een booleaanse waarde die aangeeft of een serviceverzoek opnieuw is geopend nadat het als opgelost was gemarkeerd.
Beschrijving Dit attribuut krijgt de waarde waar als een serviceverzoek weer open wordt gezet nadat het eerder als opgelost of gesloten was gemarkeerd. Dit geeft aan dat de eerste oplossing niet voldeed. Deze waarde is belangrijk om herstelwerk en problemen met het oplossen bij het eerste contact te volgen. Het dashboard ‘Trends in heropende serviceverzoeken’ en de KPI ‘Percentage heropende serviceverzoeken’ gebruiken deze waarde om eenvoudig te tellen en analyseren welke cases extra aandacht nodig hebben. Dat wijst vaak op onderliggende problemen. Waarom dit belangrijk is Brengt herstelwerk en mislukte oplossingen aan het licht. Zo kun je de kwaliteit en effectiviteit van de geboden oplossingen meten. Waar vind je dit? Berekend tijdens de datatransformatie door te controleren of de ticketstatus verandert van ‘resolved’ of ‘closed’ naar ‘open’. Voorbeelden truefalse
	Product- of servicecategorie ProductServiceCategory	Het specifieke product, de service of functie waar het verzoek van de klant over gaat.
Beschrijving Dit attribuut geeft meer context door het serviceverzoek in te delen naar product- of servicegebied. Een medewerker stelt de categorie vaak handmatig in, maar dit kan ook automatisch op basis van de inhoud van het verzoek. Deze indeling is belangrijk voor de dashboards ‘Nauwkeurigheid van verzoekcategorisering’ en ‘Uitsplitsing van doorlooptijd van onderzoek’. Je kunt ermee analyseren welke producten de meeste supportverzoeken opleveren, welke verzoeken het lastigst op te lossen zijn en of de eerste categorisering overeenkomt met de uiteindelijke oplossing. Die informatie helpt bij het verbeteren van de routering en de training van medewerkers. Waarom dit belangrijk is Koppelt verzoeken aan specifieke bedrijfsonderdelen, producten of services. Zo kun je probleemgebieden en hun effect op het proces gericht analyseren. Waar vind je dit? Dit is meestal een aangepast ticketveld in Zendesk. De exacte veldnaam hangt af van de Zendesk-configuratie. Voorbeelden Mobiele appAbonnementsbeheerAPI-integratieHardware
	Tevredenheidsscore SatisfactionRating	De tevredenheidsscore die de klant geeft nadat het serviceverzoek is opgelost.
Beschrijving Dit attribuut legt vast hoe de klant de service heeft ervaren. De feedback wordt meestal verzameld via een enquête nadat het ticket is opgelost. Veelgebruikte beoordelingen zijn ‘Goed’, ‘Slecht’ of een numerieke score. Dit is een directe meting van de klanttevredenheid en een belangrijke resultaatmetriek. De score wordt gebruikt voor de KPI ‘Klanttevredenheidsscore’. Door de beoordelingen te vergelijken met procesdata, zoals de oplostijd of het aantal contactmomenten met medewerkers, zie je welk procesgedrag tot betere resultaten voor klanten leidt. Waarom dit belangrijk is Meet rechtstreeks hoe klanten de geleverde service beoordelen en koppelt de procesprestaties aan de resultaten voor klanten. Waar vind je dit? Zendesk Tickets API, veld `satisfaction_rating.score`. Voorbeelden goedslechtaangeboden

Verplicht Aanbevolen Optioneel

Activiteiten in de klantenservice

Dit zijn de belangrijkste processtappen en mijlpalen om in je event log vast te leggen, zodat je het klantenserviceproces goed in kaart kunt brengen.

6 Aanbevolen 8 Optioneel

	Activiteit	Beschrijving
	Informatie opgevraagd bij klant	Dit gebeurt wanneer een agent meer informatie van een klant nodig heeft om verder te kunnen en de ticketstatus wijzigt in 'pending'. Deze statuswijziging geeft expliciet aan dat het proces op een externe partij wacht.
Waarom dit belangrijk is Deze activiteit maakt zichtbaar dat het proces afhankelijk is van de klant en pauzeert interne SLA-klokken. Komt dit vaak of herhaaldelijk voor bij één ticket, dan kan dat wijzen op onvolledige informatieverzameling aan het begin en leiden tot een langere oplostijd. Waar vind je dit? Dit is een expliciete statuswijziging in de Zendesk Ticket Audits API. De wijziging wordt vastgelegd wanneer het veld 'status' verandert in 'pending'. Vastleggen Zoek in Ticket Audits naar 'Change'-gebeurtenissen waarbij de ticketstatus op 'pending' wordt gezet. Gebeurtenistype explicit
	Serviceverzoek aangemaakt	Deze activiteit markeert het begin van het klantserviceproces. Er wordt een nieuw ticket aangemaakt in Zendesk, bijvoorbeeld via e-mail, een webformulier of chat. Bij het aanmaken registreert het systeem deze gebeurtenis met een uniek ticket-ID en een timestamp.
Waarom dit belangrijk is Dit is de belangrijkste startgebeurtenis voor het berekenen van de totale doorlooptijd van een case en het analyseren van het aantal binnenkomende verzoeken over tijd. Het is het uitgangspunt voor KPI’s zoals de tijd tot de eerste reactie en de totale oplostijd. Waar vind je dit? Dit is een expliciete gebeurtenis in de Zendesk Ticket Audits API. Het gaat om de gebeurtenis 'Create' voor een ticket, met de timestamp waarop het ticket is aangemaakt. Vastleggen Afkomstig van de gebeurtenis voor het aanmaken van een ticket in het Ticket Audits-logboek. Gebeurtenistype explicit
	Serviceverzoek gesloten	Dit is de laatste activiteit en markeert de definitieve sluiting van het serviceverzoek. Meestal gebeurt dit automatisch nadat een bepaalde tijd is verstreken sinds het ticket op 'solved' is gezet, zonder nieuwe reacties van de klant.
Waarom dit belangrijk is Als definitieve eindgebeurtenis sluit dit de levenscyclus van het ticket af. De tijd tussen 'solved' en 'closed' is de periode waarin het ticket nog kan worden heropend. De gebeurtenis 'closed' bevestigt dat de oplossing is geaccepteerd. Waar vind je dit? Dit is een expliciete statuswijziging in de Zendesk Ticket Audits API, waarbij het veld 'status' op 'closed' wordt gezet. Vastleggen Zoek in Ticket Audits naar 'Change'-gebeurtenissen waarbij de ticketstatus op 'closed' wordt gezet. Gebeurtenistype explicit
	Serviceverzoek heropend	Deze activiteit vindt plaats wanneer een klant reageert op een ticket met de status 'solved'. Zendesk wijzigt de status automatisch terug naar 'open'. Dat betekent dat het probleem niet volledig is opgelost.
Waarom dit belangrijk is Heropeningen wijzen vaak op problemen met de oplossing bij het eerste contact en op een lage oplossingskwaliteit. Door te analyseren hoe vaak tickets opnieuw worden geopend en waarom, ontdek je waar de training van agents en de procedures voor het oplossen van verzoeken beter kunnen. Waar vind je dit? Dit is een expliciete statuswijziging in de Ticket Audits API, die wordt vastgelegd wanneer de status van 'solved' teruggaat naar 'open'. Vastleggen Volg statuswijzigingen van 'solved' naar 'open'. Gebeurtenistype explicit
	Serviceverzoek opgelost	Een agent markeert het serviceverzoek als 'solved' nadat die de klant een oplossing heeft gegeven. Dit is een tijdelijke status: de klant kan het ticket opnieuw openen door te reageren voordat het definitief wordt gesloten.
Waarom dit belangrijk is Dit is het belangrijkste meetpunt voor de oplostijd en de efficiëntie van agents. Het geeft aan wanneer de agent het werk als afgerond beschouwt en vormt de basis om herstelwerk te analyseren als het ticket opnieuw wordt geopend. Waar vind je dit? Dit is een expliciete statuswijziging in de Zendesk Ticket Audits API, waarbij het veld 'status' op 'solved' wordt gezet. Vastleggen Zoek in Ticket Audits naar 'Change'-gebeurtenissen waarbij de ticketstatus op 'solved' wordt gezet. Gebeurtenistype explicit
	Verzoek toegewezen aan agent	Deze gebeurtenis geeft aan dat het serviceverzoek aan een specifieke agent is toegewezen. Dit kan automatisch gebeuren op basis van routeringsregels of handmatig door een teamleider of agent.
Waarom dit belangrijk is De toewijzing is een belangrijk moment voor de verantwoordelijkheid en werkverdeling. Door de tijd tot toewijzing en patronen in herverdeling te analyseren, ontdek je bottlenecks in de eerste beoordeling en verdeling. Waar vind je dit? Dit is een expliciete 'Change'-gebeurtenis in de Zendesk Ticket Audits API. De gebeurtenis wordt vastgelegd wanneer het veld 'assignee_id' wordt ingevuld of gewijzigd. Vastleggen Volg wijzigingen in het veld 'assignee_id' in het Ticket Audits-logboek. Gebeurtenistype explicit
	Eerste ontvangstbevestiging verstuurd	Dit is het automatische eerste antwoord aan de klant, waarin wordt bevestigd dat het verzoek is ontvangen. Meestal verstuurt een Zendesk-trigger direct na het aanmaken van het ticket een e-mail op basis van een template.
Waarom dit belangrijk is Door deze activiteit bij te houden, kun je de eerste reactietijd meten en verwachtingen bij klanten managen. De tijd tussen het aanmaken van een verzoek en deze bevestiging is een belangrijke metriek voor klanttevredenheid. Waar vind je dit? Af te leiden uit de eerste openbare reactie op het ticket, als die is geplaatst door een automatische gebruiker of binnen enkele seconden na het aanmaken van het ticket. Dit is te herkennen door de Ticket Comments-stroom te analyseren. Vastleggen Zoek na het aanmaken van het ticket naar de eerste openbare reactie die direct door een automatisering of trigger is geplaatst. Gebeurtenistype inferred
	Eerste openbare reactie van agent verstuurd	Deze activiteit markeert het eerste openbare bericht dat een agent naar de klant stuurt, los van een automatische ontvangstbevestiging. De gebeurtenis laat zien wanneer de agent voor het eerst inhoudelijk op het probleem van de klant ingaat.
Waarom dit belangrijk is Dit is een belangrijk meetpunt voor de SLA voor de 'First Reply Time', een belangrijke indicator voor de reactiesnelheid van de service. Het maakt onderscheid tussen automatische communicatie en het begin van onderzoek en ondersteuning door een medewerker. Waar vind je dit? Te herkennen aan de eerste openbare reactie in de Ticket Comments-stroom waarvan de auteur een menselijke agent is, en geen automatische systeemgebruiker. Vastleggen Doorzoek de ticketreacties, filter op openbare reacties van agents en selecteer de reactie met de vroegste timestamp. Gebeurtenistype inferred
	Interne escalatie gestart	Dit is de overdracht van een serviceverzoek aan een ander intern team of een hoger supportniveau. Meestal is dit af te leiden uit een wijziging van de toegewezen groep voor het ticket.
Waarom dit belangrijk is Door escalaties bij te houden, spoor je zwakke plekken in het proces, kennishiaten bij eerstelijnssupport en complexe verzoektypen op. Veel escalaties kunnen erop wijzen dat betere training of procesdocumentatie nodig is. Waar vind je dit? Af te leiden uit een 'Change'-gebeurtenis in de Ticket Audits API waarbij het veld 'group_id' is gewijzigd. Een andere groep betekent dat het verzoek aan een ander team is overgedragen. Vastleggen Volg wijzigingen in het veld 'group_id' in het Ticket Audits-logboek. Gebeurtenistype inferred
	Klant heeft gereageerd	Deze gebeurtenis vindt plaats wanneer een klant op een ticket reageert, meestal terwijl de status 'pending' is. Zendesk wijzigt de ticketstatus automatisch van 'pending' naar 'open', zodat de agent het werk kan hervatten.
Waarom dit belangrijk is Deze activiteit markeert het einde van een wachttijd en geeft aan dat het proces verder kan. Door te analyseren hoe lang klanten nodig hebben om te reageren, krijg je zicht op hoe duidelijk de verzoeken van agents zijn. Waar vind je dit? Deze gebeurtenis komt overeen met een nieuwe openbare reactie van de eindgebruiker. Daardoor verandert de status in de Ticket Audits API expliciet van 'pending' naar 'open'. Vastleggen Volg statuswijzigingen van 'pending' naar 'open' of zoek naar nieuwe openbare reacties van een eindgebruiker. Gebeurtenistype explicit
	SLA overschreden	Deze activiteit markeert het moment waarop een serviceverzoek niet voldoet aan een vooraf bepaalde service level agreement, bijvoorbeeld voor de eerste reactietijd of de oplostijd. De gebeurtenis wordt berekend door timestamps van ticketactiviteiten te vergelijken met het SLA-beleid.
Waarom dit belangrijk is SLA-overschrijdingen hebben direct invloed op klanttevredenheid en het nakomen van contractuele afspraken. Door te analyseren wanneer en waarom ze optreden, kun je structurele vertragingen, een tekort aan middelen of onrealistische prestatiedoelen opsporen. Waar vind je dit? Deze informatie is beschikbaar via de Zendesk Ticket Metrics API, waarin timestamps van SLA-overschrijdingen ('breached_at') worden opgeslagen. Je kunt de overschrijding ook berekenen door timestamps van ticketgebeurtenissen te vergelijken met de vastgelegde SLA-regels. Vastleggen Gebruik de timestamp 'breached_at' uit de Ticket Metrics API of bereken de overschrijding door de oplostijd te vergelijken met de tijd in het SLA-beleid. Gebeurtenistype calculated
	Tevredenheidsbeoordeling ontvangen	Deze gebeurtenis vindt plaats wanneer de klant de tevredenheidsenquête invult en een beoordeling geeft, zoals 'Goed' of 'Slecht'. De beoordeling en eventuele toelichting worden bij het ticket opgeslagen.
Waarom dit belangrijk is Rechtstreekse feedback van klanten is waardevol om de servicekwaliteit en klantbeleving te meten. Door beoordelingen in de context van het procesverloop te analyseren, kun je specifieke activiteiten of agents in verband brengen met de resultaten. Waar vind je dit? Vastgelegd als een 'Change'-gebeurtenis in de Ticket Audits API wanneer het veld 'satisfaction_rating' wordt ingevuld met de score en opmerking van de klant. Vastleggen Filter de Ticket Audit-logboeken op wijzigingen in het veld 'satisfaction_rating'. Gebeurtenistype explicit
	Tevredenheidsenquête verstuurd	Dit markeert het moment waarop automatisch een klanttevredenheidsenquête (CSAT) naar de klant wordt verstuurd. Meestal gebeurt dit kort nadat het ticket op 'solved' is gezet.
Waarom dit belangrijk is Met deze activiteit begint de feedbackcyclus met de klant. Het is belangrijk om te weten wanneer en of enquêtes worden verstuurd, zodat je tevredenheidsscores in de juiste context kunt plaatsen en de feedbackaanpak kunt beoordelen. Waar vind je dit? Dit is af te leiden uit een automatiseringslogboek of uit een specifieke tag die aan het ticket is toegevoegd. In de sectie 'satisfaction_rating' van de Ticket Audits API staat ook wanneer de enquête is aangeboden. Vastleggen Zoek naar tags zoals 'csat_sent' of gebruik de timestamp waarop de tevredenheidsbeoordeling is aangeboden. Gebeurtenistype inferred
	Verzoek gecategoriseerd en geprioriteerd	Deze activiteit vindt plaats wanneer een agent of automatisering ticketvelden zoals type, categorie en prioriteit instelt of wijzigt. Deze stap wordt als wijziging in de ticketgeschiedenis vastgelegd.
Waarom dit belangrijk is Een goede categorisering en prioritering zijn belangrijk voor een efficiënte routering en inzet van middelen. Door deze activiteit te analyseren, zie je hoe nauwkeurig de eerste beoordeling is en wat het effect daarvan is op de oplostijd. Waar vind je dit? Vastgelegd als 'Change'-gebeurtenissen in de Zendesk Ticket Audits API. Je herkent ze aan de eerste wijziging van velden zoals 'priority', 'type' of aangepaste velden voor categorisering. Vastleggen Filter de Ticket Audit-logboeken op de eerste 'Change'-gebeurtenis voor belangrijke categoriseringsvelden na het aanmaken van het ticket. Gebeurtenistype explicit

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data op uit Zendesk Support

Stappen

Ga naar Zendesk Explore: Log in op je Zendesk-account en open Explore via het productmenu in de bovenbalk.
Maak een nieuwe query: Klik in Explore op het pictogram Queries in de linkerzijbalk en daarna rechtsboven op de knop "New query".
Selecteer de dataset: Kies in het venster "Choose a dataset" de dataset Support: Tickets. Deze dataset bevat de belangrijkste ticketattributen en event-timestamps.
Voeg metrieken toe: Ga in de query builder naar het paneel "Metrics" en klik op "Add". Selecteer COUNT(Tickets) om het datavolume te controleren.
Voeg attributen toe aan de rijen: Ga naar het paneel "Rows" en klik op "Add". Voeg de volgende attributen toe. Hiermee maak je de basis voor de kolommen in je brede export.
- Ticket ID (dit is je case-ID, ServiceRequest)
- Assignee name (AssignedAgent)
- Ticket type (ServiceRequestType)
- Ticket priority (Priority)
- Ticket channel (CommunicationChannel)
- SLA resolution time (SlaTargetResolutionTime)
- SLA breach status (IsSlaBreached)
- Full resolution time (min) (ServiceRequestResolutionTime)
Voeg activiteitstimestamps toe aan de rijen: Voeg de volgende timestampattributen toe aan het paneel "Rows". Elk attribuut staat voor een mogelijke activiteit. Voor sommige activiteiten moet je een aangepast berekend attribuut maken.
- Ticket created - Timestamp: voor Service Request Created en Initial Acknowledgment Sent.
- Ticket assigned - Timestamp: voor Request Assigned To Agent.
- First reply time - Timestamp: voor First Agent Public Reply Sent.
- Ticket solved - Timestamp: voor Service Request Resolved en Satisfaction Survey Sent.
- Ticket reopened - Timestamp: voor Service Request Reopened.
- Satisfaction rating received - Timestamp: voor Satisfaction Rating Received.
- Ticket closed - Timestamp: voor Service Request Closed.
Maak aangepaste berekende attributen voor andere activiteiten: Sommige activiteiten zijn gebaseerd op specifieke veldwijzigingen. Maak hiervoor aangepaste attributen die de timestamp vastleggen. Ga naar het menu Calculations (rekenmachinepictogram) en selecteer "Standard calculated attribute". Maak voor elk van de volgende activiteiten een attribuut. Zoek in je Zendesk-account de exacte veldnamen en waarden op.
- Naam: Timestamp - Categorized and Prioritized. Formule: IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF. Voeg het attribuut na het aanmaken toe aan het paneel "Rows" en stel de aggregator in op MIN.
- Naam: Timestamp - Info Requested. Formule: IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF. Voeg het toe aan "Rows" en stel de aggregator in op MIN.
- Naam: Timestamp - Customer Responded. Formule: IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF. Voeg het toe aan "Rows" en stel de aggregator in op MIN.
- Naam: Timestamp - Escalated. Formule: IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF. Voeg het toe aan "Rows" en stel de aggregator in op MIN.
- Naam: Timestamp - SLA Breach. Formule: IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF. Voeg het toe aan "Rows" en stel de aggregator in op MIN.
Filter de data: Ga naar het paneel "Filters" en klik op "Add". Voeg een filter toe voor Ticket created - Date en kies een geschikte periode, bijvoorbeeld de afgelopen 3 tot 6 maanden. Zo blijft de dataset beheersbaar.
Voer het rapport uit en exporteer het: Klik op "Save" om de query uit te voeren. Zodra de tabel met data verschijnt, klik je op "Export" en kies je een formaat, zoals CSV of Excel.
Zet de data om naar een event log: Het geëxporteerde bestand heeft een brede indeling: elke rij is een ticket en elke kolom een event-timestamp. Voor process mining moet je dit omzetten naar een lange indeling. Gebruik bijvoorbeeld Microsoft Excel met de functie Unpivot in Power Query, Python of een andere tool voor datavoorbereiding.
- Maak voor elke rij (ticket) meerdere nieuwe rijen, één voor elke timestampkolom die een waarde bevat.
- De uiteindelijke tabel bevat kolommen zoals ServiceRequest, ActivityName, StartTime en de overige attributen. Herhaal die attributen voor elke activiteit van een serviceaanvraag.

Configuratie

Dataset: Gebruik de dataset Support: Tickets. Hiermee heb je in één query toegang tot de meeste ticketeigenschappen en belangrijke timestamps.
Machtigingen: Je hebt in Zendesk Explore minimaal de rol Editor of Admin nodig om queries te maken en op te slaan.
Datumbereik: Stel een filter in voor Ticket created - Date. Een periode van 3 tot 6 maanden biedt een goede balans tussen inzicht en prestaties. Het exporteren van miljoenen tickets kan lang duren of mislukken.
Queryfilters: Je kunt filters toevoegen voor specifieke ticketeigenschappen, zoals Ticket brand, Ticket form of Ticket group, om de analyse op een bepaalde service of een bepaald team te richten.
Berekende attributen: Voor timestamps van events die geen standaardattributen zijn, zoals statuswijzigingen of escalaties, moet je berekende attributen maken. Controleer of je hiervoor de juiste machtigingen hebt.

a Voorbeeldquery config

This extraction is configured through the Zendesk Explore graphical user interface. There is no single script to execute. The configuration below outlines the components to add in the query builder.

**Dataset**: `Support: Tickets`

**Metrics**:
1.  `COUNT(Tickets)`

**Rows (Attributes)**:
1.  `Ticket ID`
2.  `Assignee name`
3.  `Ticket type`
4.  `Ticket priority`
5.  `Ticket channel`
6.  `SLA resolution time`
7.  `SLA breach status`
8.  `Full resolution time (min)`
9.  `MIN(Ticket created - Timestamp)`
10. `MIN(Ticket assigned - Timestamp)`
11. `MIN(First reply time - Timestamp)`
12. `MIN(Ticket solved - Timestamp)`
13. `MIN(Ticket reopened - Timestamp)`
14. `MIN(Satisfaction rating received - Timestamp)`
15. `MIN(Ticket closed - Timestamp)`
16. `MIN(Timestamp - Categorized and Prioritized)` (Custom calculated attribute)
17. `MIN(Timestamp - Info Requested)` (Custom calculated attribute)
18. `MIN(Timestamp - Customer Responded)` (Custom calculated attribute)
19. `MIN(Timestamp - Escalated)` (Custom calculated attribute)
20. `MIN(Timestamp - SLA Breach)` (Custom calculated attribute)

**Filters**:
1.  `Ticket created - Date`: Select a date range (e.g., last 180 days)

**Standard Calculated Attribute Formulas**:
*   `Timestamp - Categorized and Prioritized`: `IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Info Requested`: `IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Customer Responded`: `IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Escalated`: `IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - SLA Breach`: `IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF`

Stappen

Stel toegang tot de Zendesk API in: Log als beheerder in bij Zendesk. Ga naar het Admin Center en vervolgens naar Apps and integrations > APIs > Zendesk API. Controleer op het tabblad Settings of Token Access is ingeschakeld. Klik op 'Add API token' om een token te maken. Bewaar het gegenereerde token veilig, want je kunt het later niet opnieuw bekijken.
Richt de Python-omgeving in: Zorg dat Python 3.6 of hoger is geïnstalleerd. Installeer de bibliotheek requests, die nodig is om HTTP-verzoeken naar de Zendesk API te versturen. Gebruik hiervoor de opdrachtregel: pip install requests.
Configureer het Python-script: Sla het Python-script op in een bestand, bijvoorbeeld extract_zendesk_log.py. Open het bestand in een teksteditor en vul bovenaan de placeholders ZENDESK_SUBDOMAIN, ZENDESK_EMAIL en API_TOKEN in met de gegevens en inloggegevens van je Zendesk-account.
Stel de extractieperiode in: Zoek in het script de variabele START_TIMESTAMP. Deze waarde bepaalt vanaf welke datum historische data wordt opgehaald. De waarde moet een Unix-epochtimestamp zijn. Voor een eerste analyse is een periode van de afgelopen 3 tot 6 maanden aan te raden.
Voer het script uit: Open een terminal of opdrachtprompt, ga naar de map waarin je het script hebt opgeslagen en voer de opdracht uit: python extract_zendesk_log.py.
Volg de voortgang: Het script toont in de console hoeveel tickets zijn verwerkt. De totale uitvoeringstijd hangt af van de hoeveelheid data en eventuele API-limieten van Zendesk. Het script kan API-reacties met een limiet afhandelen.
Haal het event log op: Na een geslaagde uitvoering maakt het script in dezelfde map het bestand zendesk_event_log.csv aan. Dit bestand bevat het gestructureerde event log dat klaar is voor analyse.
Bereid het bestand voor op upload: Open zendesk_event_log.csv en controleer of het goed is aangemaakt. Controleer of de kolommen overeenkomen met de vereiste attributen: ServiceRequest, ActivityName, StartTime, SourceSystem en LastDataUpdate. Het bestand is nu klaar om te uploaden naar de process mining-tool.

Configuratie

API-inloggegevens: Het script heeft een geldig Zendesk-subdomein, het e-mailadres van een medewerker of beheerder en een actief API-token nodig. De gebruiker van deze inloggegevens moet tickets, ticketaudits, gebruikers en ticketmetrieken kunnen lezen.
Datumbereik: De variabele START_TIMESTAMP in het script bepaalt de startdatum van de extractie. Dit moet een Unix-epochtimestamp zijn. Begin bij voorkeur met een kortere periode, bijvoorbeeld 3 maanden, om de uitvoer en prestaties van het script te controleren voordat je meer historische data ophaalt.
Incremental Export API: Deze oplossing gebruikt de Incremental Export API van Zendesk. Dit is de efficiëntste en aanbevolen methode om veel tickets op te halen. De API is bedoeld voor bulksgewijze data-export en voorkomt veelvoorkomende problemen met paginering.
Prestaties en API-limieten: Zendesk hanteert API-limieten die afhangen van het abonnement. Als een limiet wordt bereikt, pauzeert het script op basis van de Retry-After-header van de API. Bij zeer grote Zendesk-omgevingen kan de extractie enkele uren duren.
Vereisten: Voor deze extractiemethode heb je een werkende Python 3.6+-omgeving en de externe bibliotheek requests nodig. Je moet beheerderstoegang hebben tot het Zendesk-account om het benodigde API-token aan te maken.

a Voorbeeldquery python

import requests
import json
import time
import datetime
import csv

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">'[your_zendesk_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_zendesk_login_email]'
API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Set the start time for the export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is Jan 1, 2023 00:00:00 GMT
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', API_TOKEN)
SOURCE_SYSTEM = class="hl-string">'Zendesk Support'
LAST_DATA_UPDATE = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

CSV_FILENAME = class="hl-string">'zendesk_event_log.csv'
CSV_HEADERS = [
    class="hl-string">'ServiceRequest', class="hl-string">'ActivityName', class="hl-string">'StartTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
    class="hl-string">'AssignedAgent', class="hl-string">'ServiceRequestType', class="hl-string">'Priority', class="hl-string">'CommunicationChannel',
    class="hl-string">'SlaTargetResolutionTime', class="hl-string">'IsSlaBreached', class="hl-string">'ServiceRequestResolutionTime'
]

def get_user_name(user_id, users_cache, session):
    if user_id in users_cache:
        return users_cache[user_id]
    if user_id is None:
        return None
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_name = response.json().get(class="hl-string">'user', {}).get(class="hl-string">'name')
        users_cache[user_id] = user_name
        return user_name
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Warning: Could not fetch user {user_id}. Error: {e}')
        users_cache[user_id] = str(user_id)
        return str(user_id)

def format_duration(seconds):
    if seconds is None:
        return None
    return str(datetime.timedelta(seconds=seconds))

def main():
    session = requests.Session()
    session.auth = AUTH
    users_cache = {}
    event_log = []

    class=class="hl-string">"hl-comment"># Fetch tickets using the incremental export API
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}'
    ticket_count = 0

    while url:
        print(fclass="hl-string">'Fetching tickets from: {url}')
        try:
            response = session.get(url)

            if response.status_code == 429:
                retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
                print(fclass="hl-string">'Rate limit hit. Retrying after {retry_after} seconds.')
                time.sleep(retry_after)
                continue

            response.raise_for_status()
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])

            for ticket in tickets:
                ticket_count += 1
                ticket_id = ticket[class="hl-string">'id']
                print(fclass="hl-string">'Processing ticket {ticket_id} ({ticket_count} total)...')

                class=class="hl-string">"hl-comment"># Fetch ticket metrics for SLA and resolution time
                metrics_response = session.get(fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json')
                ticket_metrics = metrics_response.json().get(class="hl-string">'ticket_metric', {}) if metrics_response.ok else {}

                resolution_time_seconds = ticket_metrics.get(class="hl-string">'full_resolution_time_in_minutes', {}).get(class="hl-string">'business')
                if resolution_time_seconds:
                    resolution_time_seconds *= 60

                class=class="hl-string">"hl-comment"># Fetch ticket audits for events
                audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
                audits_response = session.get(audits_url)
                audits = audits_response.json().get(class="hl-string">'audits', []) if audits_response.ok else []

                first_agent_reply_sent = False

                for audit in audits:
                    audit_created_at = audit[class="hl-string">'created_at']
                    base_event = {
                        class="hl-string">'ServiceRequest': ticket_id,
                        class="hl-string">'StartTime': audit_created_at,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'AssignedAgent': get_user_name(ticket.get(class="hl-string">'assignee_id'), users_cache, session),
                        class="hl-string">'ServiceRequestType': ticket.get(class="hl-string">'type'),
                        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'CommunicationChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaTargetResolutionTime': None, class=class="hl-string">"hl-comment"># Requires parsing SLA policies, complex
                        class="hl-string">'IsSlaBreached': ticket_metrics.get(class="hl-string">'sla_breach_at') is not None,
                        class="hl-string">'ServiceRequestResolutionTime': format_duration(resolution_time_seconds)
                    }

                    for event in audit.get(class="hl-string">'events', []):
                        event_type = event.get(class="hl-string">'type')
                        class=class="hl-string">"hl-comment"># Service Request Created
                        if event_type == class="hl-string">'Create' and event.get(class="hl-string">'field_name') == class="hl-string">'id':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Created'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Initial Acknowledgment Sent (Proxy by Notification event)
                        if event_type == class="hl-string">'Notification':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Initial Acknowledgment Sent'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Request Categorized And Prioritized, Assigned, Status Changes
                        if event_type == class="hl-string">'Change':
                            field = event.get(class="hl-string">'field_name')
                            if field in [class="hl-string">'type', class="hl-string">'priority', class="hl-string">'custom_field_[your_category_field_id]']:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Categorized And Prioritized'
                                event_log.append(new_event)
                            
                            if field == class="hl-string">'assignee_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Assigned To Agent'
                                new_event[class="hl-string">'AssignedAgent'] = get_user_name(event.get(class="hl-string">'value'), users_cache, session)
                                event_log.append(new_event)

                            if field == class="hl-string">'group_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Internal Escalation Triggered'
                                event_log.append(new_event)

                            if field == class="hl-string">'status':
                                new_status = event.get(class="hl-string">'value')
                                if new_status == class="hl-string">'pending':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Information Requested From Customer'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'solved':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Resolved'
                                    event_log.append(new_event)
                                    class=class="hl-string">"hl-comment"># Satisfaction Survey Sent (Proxy: occurs after solve)
                                    solve_time = datetime.datetime.fromisoformat(audit_created_at.replace(class="hl-string">'Z', class="hl-string">'+00:00'))
                                    survey_time = solve_time + datetime.timedelta(hours=1)
                                    survey_event = new_event.copy()
                                    survey_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Survey Sent'
                                    survey_event[class="hl-string">'StartTime'] = survey_time.isoformat().replace(class="hl-string">'+00:00', class="hl-string">'Z')
                                    event_log.append(survey_event)
                                elif new_status == class="hl-string">'closed':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Closed'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'open' and event.get(class="hl-string">'previous_value') in [class="hl-string">'solved', class="hl-string">'pending']:
                                    activity = class="hl-string">'Service Request Reopened' if event.get(class="hl-string">'previous_value') == class="hl-string">'solved' else class="hl-string">'Customer Responded'
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = activity
                                    event_log.append(new_event)
                            
                            if field == class="hl-string">'satisfaction_score':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Rating Received'
                                event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># First Agent Public Reply Sent & Customer Responded
                        if event_type == class="hl-string">'Comment':
                            author_id = event.get(class="hl-string">'author_id')
                            author_details_response = session.get(fclass="hl-string">'{BASE_URL}/users/{author_id}.json')
                            author_role = author_details_response.json().get(class="hl-string">'user',{}).get(class="hl-string">'role', class="hl-string">'end-user') if author_details_response.ok else class="hl-string">'end-user'

                            if author_role in [class="hl-string">'agent', class="hl-string">'admin'] and event.get(class="hl-string">'public') and not first_agent_reply_sent:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'First Agent Public Reply Sent'
                                event_log.append(new_event)
                                first_agent_reply_sent = True

                class=class="hl-string">"hl-comment"># SLA Breach Occurred
                if ticket_metrics.get(class="hl-string">'sla_breach_at'):
                    sla_breach_time = ticket_metrics.get(class="hl-string">'sla_breach_at')
                    new_event = base_event.copy()
                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'SLA Breach Occurred'
                    new_event[class="hl-string">'StartTime'] = sla_breach_time
                    event_log.append(new_event)

            url = data.get(class="hl-string">'after_url')
            if not data.get(class="hl-string">'end_of_stream', False):
                time.sleep(1) class=class="hl-string">"hl-comment"># Be a good API citizen
            else:
                url = None

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

    class=class="hl-string">"hl-comment"># Write to CSV
    print(fclass="hl-string">'Writing {len(event_log)} events to {CSV_FILENAME}...')
    with open(CSV_FILENAME, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
        writer = csv.DictWriter(csvfile, fieldnames=CSV_HEADERS)
        writer.writeheader()
        class=class="hl-string">"hl-comment"># Sort events by ticket and then by time for chronological order
        sorted_log = sorted(event_log, key=lambda x: (x[class="hl-string">'ServiceRequest'], x[class="hl-string">'StartTime']))
        for row in sorted_log:
            writer.writerow(row)
    print(class="hl-string">'Extraction complete.')

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

Stappen

Controleer of je Zendesk Support-account toegang biedt tot de Incremental Exports API en of de integratiegebruiker tickets, ticketevents, gebruikers, groepen, opmerkingen, klanttevredenheidsscores en SLA-data mag lezen, voor zover deze functies zijn ingeschakeld. Controleer het subdomein van het account en de authenticatiemethode aan de hand van de goedgekeurde configuratie van je organisatie.
Kies een starttijd voor de extractie die de gewenste analyseperiode dekt. Incremental ticket exports gebruiken een Unix-timestamp en leveren records op die vanaf dat moment zijn aangemaakt of bijgewerkt. Gebruik voor een volledige historische import [Configure based on your system] als eerste starttijd en bewaar daarna de geretourneerde eindtijd voor volgende incrementele runs. Voor reguliere analyses volstaat meestal een periode van 3 tot 6 maanden, als de procesgeschiedenis daarin voldoende is.
Voer het Python-extractiescript uit met het Zendesk-subdomein, de authenticatiegegevens, de starttimestamp en eventuele filters voor je organisatie. Het script vraagt incrementele ticketdata op, doorloopt de pagina’s en slaat de ruwe ticketrecords en beschikbare eventdetails op voordat de data wordt omgezet.
Haal voor elk ticket de audit- of eventgeschiedenis op als de incrementele ticketrespons onvoldoende informatie bevat over veldwijzigingen, toewijzingen, opmerkingen of status. Gebruik alleen Zendesk API-bronnen die in je account zijn ingeschakeld en waarvoor je toestemming hebt. Bewaar waar beschikbaar het bron-ticket-ID, audit-ID, opmerking-ID, eventtimestamp, de actor, veldnaam, vorige waarde en nieuwe waarde.
Zet timestamps om naar UTC en converteer Unix-timestamps of ISO 8601-waarden naar één consistente datum- en tijdnotatie. Sorteer bronrecords op ServiceRequest, eventtimestamp en bron-event-ID. Verwijder dubbele records met het meest specifieke stabiele bron-ID dat beschikbaar is, zoals een audit- of opmerking-ID.
Maak expliciete eventlogregels voor alle 14 vereiste activiteiten. Verwacht niet dat ProcessMind activiteiten afleidt uit statuswijzigingen of veldwaarden. Maak Service Request Created aan op basis van het aanmaken van een ticket, Initial Acknowledgment Sent op basis van een geverifieerd automatisch eerste antwoord, Request Categorized And Prioritized op basis van wijzigingen in categorie, type of prioriteit, Request Assigned To Agent op basis van wijzigingen in de toegewezen medewerker, First Agent Public Reply Sent op basis van de eerste in aanmerking komende openbare opmerking van een medewerker, Information Requested From Customer op basis van een overgang naar pending die hoort bij een informatieverzoek, Customer Responded op basis van een in aanmerking komende reactie van de klant, Internal Escalation Triggered op basis van een wijziging van de toegewezen groep, SLA Breach Occurred op basis van een geverifieerde SLA-overschrijdingstimestamp of een expliciet berekende overschrijding, Service Request Resolved op basis van een overgang naar solved, Service Request Reopened op basis van een overgang van solved naar open na een reactie van de klant, Satisfaction Survey Sent op basis van een geverifieerde verzending van een enquête, Satisfaction Rating Received op basis van een ingediende beoordeling en Service Request Closed op basis van een overgang naar closed of een geverifieerde definitieve sluiting.
Vul de vereiste kolommen ServiceRequest, ActivityName, StartTime, SourceSystem en LastDataUpdate in. Vul de aanbevolen kolommen AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime en IsSlaBreached in als de bron betrouwbare waarden bevat. Gebruik null voor optionele attributen die niet beschikbaar zijn, in plaats van waarden te verzinnen.
Pas goedgekeurde filters voor je organisatie toe na de extractie en vóór de export. Bewaar de ruwe bron-ID’s en brontimestamps in een interne stagingkopie, zodat je de keuzes voor events kunt controleren en de verwerking opnieuw kunt uitvoeren.
Controleer het aantal rijen, de dekking van activiteiten, de volgorde van timestamps, de afhandeling van dubbele records en de ingevulde attributen. Controleer of elke rij een ServiceRequest, ActivityName, StartTime, SourceSystem en LastDataUpdate bevat.
Exporteer het omgezette event log als UTF-8 CSV of een ander tabelbestand dat ProcessMind ondersteunt. Zorg dat de kolomnamen exact overeenkomen met de vereiste attribuutnamen, dat elke activiteit één keer per rij staat en upload het bestand via het ingestelde ProcessMind-importproces.

Configuratie

Extractiemethode: Gebruik de Zendesk Incremental Exports API om grote hoeveelheden tickets op te halen. Het script vraagt data op vanaf een opgeslagen Unix-starttimestamp, doorloopt de pagina’s, houdt rekening met API-limieten en bewaart de geretourneerde eindtimestamp voor de volgende run.
Authenticatie: Stel de door je organisatie goedgekeurde Zendesk-authenticatiemethode, het accountsubdomein, de inloggegevens en API-machtigingen in volgens het beveiligingsbeleid. Zet inloggegevens niet in broncodebeheer.
Datumbereik: Gebruik voor reguliere procesanalyses 3 tot 6 maanden. Kies voor de eerste import een starttijd vóór de vereiste procesperiode, omdat activiteiten van eerder aangemaakte tickets binnen de analyseperiode kunnen vallen. Gebruik voor incrementele imports de watermark van de vorige geslaagde extractie, met een kleine overlap om vertraagde updates op te vangen. Verwijder daarna dubbele records op basis van bron-ID’s.
Filters: Gebruik alleen filters die worden ondersteund door de Zendesk-bronnen in je account, zoals goedgekeurde filters voor organisatie, groep, merk, tickettype, status of aangepaste velden. Stel filters voor je organisatie in op basis van je systeem. Ga er niet van uit dat Zendesk een Company Code of Document Type bevat.
Vereiste uitvoerkolommen: ServiceRequest, ActivityName, StartTime, SourceSystem en LastDataUpdate.
Aanbevolen uitvoerkolommen: AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime en IsSlaBreached.
Eventdetails: Incrementele ticketrecords bevatten mogelijk niet alle historische overgangen. Haal zo nodig toegestane ticketaudits, opmerkingen, klanttevredenheidsgegevens en SLA-events op. Maak voor elke vereiste activiteit expliciet een rij aan.
SLA-configuratie: Gebruik waar mogelijk het daadwerkelijke SLA-beleid en de overschrijdingstimestamps uit het account. Leg bij een berekende overschrijdingsstatus vast welk beleid, welke werktijden, pauzes en tijdzone zijn gebruikt. Bereken een overschrijding niet alleen op basis van verstreken kloktijd als er regels voor werktijden gelden.
Prestaties: Verwerk pagina’s stapsgewijs, gebruik streaming of batches, sla ticketdetails tijdelijk op, beperk gelijktijdige verzoeken, houd rekening met Zendesk-limieten en sla de voortgang na geslaagde pagina’s op. Vraag niet telkens de volledige geschiedenis opnieuw op.
Databehoud: Bewaar ruwe API-responsen, extractiewatermarks, verzoekmetadata en transformatielogs voor controles en nieuwe runs.
Vereisten: Toegang tot de Zendesk API, toestemming om de relevante ticket- en eventbronnen te lezen, ingeschakelde ticketaudits en opmerkingen waar nodig, toegang tot klanttevredenheidsgegevens voor CSAT-activiteiten en toegang tot SLA-data voor SLA-overschrijdingsactiviteiten. Welke functies beschikbaar zijn, hangt af van het Zendesk-abonnement en de accountconfiguratie.

a Voorbeeldquery python

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

import requests

ZENDESK_SUBDOMAIN = os.environ.get(class="hl-string">"ZENDESK_SUBDOMAIN", class="hl-string">"[Configure based on your system]")
ZENDESK_EMAIL = os.environ.get(class="hl-string">"ZENDESK_EMAIL", class="hl-string">"[Configure based on your system]")
ZENDESK_API_TOKEN = os.environ.get(class="hl-string">"ZENDESK_API_TOKEN", class="hl-string">"[Configure based on your system]")
START_TIME = os.environ.get(class="hl-string">"START_TIME", class="hl-string">"[Configure based on your system]")
OUTPUT_FILE = os.environ.get(class="hl-string">"OUTPUT_FILE", class="hl-string">"zendesk_processmind_event_log.csv")
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"

REQUIRED_COLUMNS = [
    class="hl-string">"ServiceRequest",
    class="hl-string">"ActivityName",
    class="hl-string">"StartTime",
    class="hl-string">"SourceSystem",
    class="hl-string">"LastDataUpdate",
]
RECOMMENDED_COLUMNS = [
    class="hl-string">"AssignedAgent",
    class="hl-string">"ServiceRequestType",
    class="hl-string">"Priority",
    class="hl-string">"CommunicationChannel",
    class="hl-string">"SlaTargetResolutionTime",
    class="hl-string">"IsSlaBreached",
]
ALL_COLUMNS = REQUIRED_COLUMNS + RECOMMENDED_COLUMNS


def fail(message: str) -> None:
    raise RuntimeError(message)


def parse_start_time(value: str) -> int:
    if value.isdigit():
        return int(value)
    try:
        return int(datetime.fromisoformat(value.replace(class="hl-string">"Z", class="hl-string">"+00:00")).timestamp())
    except ValueError as exc:
        raise RuntimeError(class="hl-string">"START_TIME must be a Unix timestamp or ISO 8601 timestamp") from exc


def iso_timestamp(value: Any) -> Optional[str]:
    if value is None or value == class="hl-string">"":
        return None
    if isinstance(value, (int, float)):
        return datetime.fromtimestamp(value, tz=timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z")
    text = str(value)
    if text.isdigit():
        return datetime.fromtimestamp(int(text), tz=timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z")
    return text


def now_utc() -> str:
    return datetime.now(timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z")


def api_get(session: requests.Session, path: str, params: Optional[Dict[str, Any]] = None) -> Dict[str, Any]:
    url = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com{path}"
    while True:
        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, 1))
            continue
        response.raise_for_status()
        return response.json()


def paged_get(session: requests.Session, path: str, params: Optional[Dict[str, Any]] = None) -> Iterable[Dict[str, Any]]:
    next_url: Optional[str] = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com{path}"
    next_params = params
    while next_url:
        while True:
            response = session.get(next_url, params=next_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, 1))
                continue
            response.raise_for_status()
            payload = response.json()
            break
        for item in payload.get(class="hl-string">"tickets", payload.get(class="hl-string">"audits", payload.get(class="hl-string">"comments", payload.get(class="hl-string">"results", [])))):
            yield item
        next_url = payload.get(class="hl-string">"next_page")
        next_params = None


def get_user_name(session: requests.Session, user_id: Any, cache: Dict[str, str]) -> Optional[str]:
    if not user_id:
        return None
    key = str(user_id)
    if key in cache:
        return cache[key]
    try:
        user = api_get(session, fclass="hl-string">"/api/v2/users/{key}.json").get(class="hl-string">"user", {})
        name = user.get(class="hl-string">"name") or user.get(class="hl-string">"email") or key
        cache[key] = str(name)
        return cache[key]
    except requests.HTTPError:
        cache[key] = key
        return key


def get_group_name(session: requests.Session, group_id: Any, cache: Dict[str, str]) -> Optional[str]:
    if not group_id:
        return None
    key = str(group_id)
    if key in cache:
        return cache[key]
    try:
        group = api_get(session, fclass="hl-string">"/api/v2/groups/{key}.json").get(class="hl-string">"group", {})
        name = group.get(class="hl-string">"name") or key
        cache[key] = str(name)
        return cache[key]
    except requests.HTTPError:
        cache[key] = key
        return key


def ticket_field(ticket: Dict[str, Any], names: List[str]) -> Any:
    for name in names:
        if ticket.get(name) is not None:
            return ticket.get(name)
    return None


def base_row(ticket: Dict[str, Any], activity: str, event_time: Any, last_update: str, user_cache: Dict[str, str]) -> Dict[str, Any]:
    return {
        class="hl-string">"ServiceRequest": str(ticket.get(class="hl-string">"id")),
        class="hl-string">"ActivityName": activity,
        class="hl-string">"StartTime": iso_timestamp(event_time),
        class="hl-string">"SourceSystem": SOURCE_SYSTEM,
        class="hl-string">"LastDataUpdate": last_update,
        class="hl-string">"AssignedAgent": get_user_name(session, ticket.get(class="hl-string">"assignee_id"), user_cache),
        class="hl-string">"ServiceRequestType": ticket.get(class="hl-string">"type"),
        class="hl-string">"Priority": ticket.get(class="hl-string">"priority"),
        class="hl-string">"CommunicationChannel": ticket.get(class="hl-string">"via", {}).get(class="hl-string">"channel") if isinstance(ticket.get(class="hl-string">"via"), dict) else ticket.get(class="hl-string">"via"),
        class="hl-string">"SlaTargetResolutionTime": ticket.get(class="hl-string">"sla_target_resolution_time"),
        class="hl-string">"IsSlaBreached": ticket.get(class="hl-string">"is_sla_breached"),
    }


def add_event(events: List[Dict[str, Any]], seen: set, ticket: Dict[str, Any], activity: str, event_time: Any, last_update: str, user_cache: Dict[str, str], source_key: str) -> None:
    if event_time is None:
        return
    key = (str(ticket.get(class="hl-string">"id")), activity, source_key, str(event_time))
    if key in seen:
        return
    seen.add(key)
    events.append(base_row(ticket, activity, event_time, last_update, user_cache))


def audit_events(session: requests.Session, ticket_id: Any) -> List[Dict[str, Any]]:
    return list(paged_get(session, fclass="hl-string">"/api/v2/tickets/{ticket_id}/audits.json"))


def audit_events_for_field(audit: Dict[str, Any], field_names: List[str]) -> List[Tuple[str, Any, Any]]:
    output: List[Tuple[str, Any, Any]] = []
    for event in audit.get(class="hl-string">"events", []):
        if event.get(class="hl-string">"type") != class="hl-string">"Change":
            continue
        field = str(event.get(class="hl-string">"field_name") or event.get(class="hl-string">"field") or class="hl-string">"")
        if field in field_names:
            output.append((field, event.get(class="hl-string">"previous_value"), event.get(class="hl-string">"value")))
    return output


def is_customer_actor(audit: Dict[str, Any], ticket: Dict[str, Any]) -> bool:
    author_id = audit.get(class="hl-string">"author_id")
    requester_id = ticket.get(class="hl-string">"requester_id")
    return author_id is not None and requester_id is not None and str(author_id) == str(requester_id)


def is_public_comment(event: Dict[str, Any]) -> bool:
    return event.get(class="hl-string">"type") in {class="hl-string">"Comment", class="hl-string">"VoiceComment"} and event.get(class="hl-string">"public") is not False


def is_automated_acknowledgment(event: Dict[str, Any]) -> bool:
    body = str(event.get(class="hl-string">"body") or event.get(class="hl-string">"html_body") or class="hl-string">"").lower()
    marker = str(event.get(class="hl-string">"via", {}).get(class="hl-string">"channel") if isinstance(event.get(class="hl-string">"via"), dict) else event.get(class="hl-string">"via") or class="hl-string">"").lower()
    return class="hl-string">"acknowledg" in body or class="hl-string">"received your request" in body or marker in {class="hl-string">"trigger", class="hl-string">"automation", class="hl-string">"system"}


def extract_ticket_events(session: requests.Session, ticket: Dict[str, Any], last_update: str, user_cache: Dict[str, str], group_cache: Dict[str, str], seen: set) -> List[Dict[str, Any]]:
    events: List[Dict[str, Any]] = []
    ticket_id = ticket.get(class="hl-string">"id")
    audits = audit_events(session, ticket_id)
    audits.sort(key=lambda item: (str(item.get(class="hl-string">"created_at") or class="hl-string">""), str(item.get(class="hl-string">"id") or class="hl-string">"")))
    add_event(events, seen, ticket, class="hl-string">"Service Request Created", ticket.get(class="hl-string">"created_at"), last_update, user_cache, class="hl-string">"ticket_created")
    first_public_agent_reply = False
    first_ack = False
    for audit in audits:
        audit_time = audit.get(class="hl-string">"created_at")
        audit_id = str(audit.get(class="hl-string">"id") or audit_time)
        for event in audit.get(class="hl-string">"events", []):
            event_type = event.get(class="hl-string">"type")
            if event_type in {class="hl-string">"Comment", class="hl-string">"VoiceComment"} and is_public_comment(event):
                if not first_ack and is_automated_acknowledgment(event):
                    add_event(events, seen, ticket, class="hl-string">"Initial Acknowledgment Sent", audit_time, last_update, user_cache, audit_id + class="hl-string">":ack")
                    first_ack = True
                if not is_customer_actor(audit, ticket) and not first_public_agent_reply and not is_automated_acknowledgment(event):
                    add_event(events, seen, ticket, class="hl-string">"First Agent Public Reply Sent", audit_time, last_update, user_cache, audit_id + class="hl-string">":first_agent_reply")
                    first_public_agent_reply = True
                if is_customer_actor(audit, ticket):
                    add_event(events, seen, ticket, class="hl-string">"Customer Responded", audit_time, last_update, user_cache, audit_id + class="hl-string">":customer_reply")
            if event_type == class="hl-string">"Change":
                field = str(event.get(class="hl-string">"field_name") or event.get(class="hl-string">"field") or class="hl-string">"")
                previous = event.get(class="hl-string">"previous_value")
                value = event.get(class="hl-string">"value")
                if field in {class="hl-string">"type", class="hl-string">"priority", class="hl-string">"custom_fields"}:
                    add_event(events, seen, ticket, class="hl-string">"Request Categorized And Prioritized", audit_time, last_update, user_cache, audit_id + class="hl-string">":category_priority:" + field)
                if field in {class="hl-string">"assignee_id", class="hl-string">"assignee"} and value not in (None, class="hl-string">"", 0, class="hl-string">"0"):
                    add_event(events, seen, ticket, class="hl-string">"Request Assigned To Agent", audit_time, last_update, user_cache, audit_id + class="hl-string">":assignee")
                if field in {class="hl-string">"group_id", class="hl-string">"group"} and previous not in (None, class="hl-string">"", 0, class="hl-string">"0") and value not in (None, class="hl-string">"", 0, class="hl-string">"0") and str(previous) != str(value):
                    get_group_name(session, value, group_cache)
                    add_event(events, seen, ticket, class="hl-string">"Internal Escalation Triggered", audit_time, last_update, user_cache, audit_id + class="hl-string">":group")
                if field == class="hl-string">"status":
                    old_status = str(previous or class="hl-string">"").lower()
                    new_status = str(value or class="hl-string">"").lower()
                    if new_status == class="hl-string">"pending":
                        add_event(events, seen, ticket, class="hl-string">"Information Requested From Customer", audit_time, last_update, user_cache, audit_id + class="hl-string">":pending")
                    if new_status == class="hl-string">"solved":
                        add_event(events, seen, ticket, class="hl-string">"Service Request Resolved", audit_time, last_update, user_cache, audit_id + class="hl-string">":solved")
                    if old_status == class="hl-string">"solved" and new_status == class="hl-string">"open":
                        add_event(events, seen, ticket, class="hl-string">"Service Request Reopened", audit_time, last_update, user_cache, audit_id + class="hl-string">":reopened")
                    if new_status == class="hl-string">"closed":
                        add_event(events, seen, ticket, class="hl-string">"Service Request Closed", audit_time, last_update, user_cache, audit_id + class="hl-string">":closed")
                if field in {class="hl-string">"satisfaction_survey_sent", class="hl-string">"csat_survey_sent"} and str(value).lower() in {class="hl-string">"true", class="hl-string">"1", class="hl-string">"yes", class="hl-string">"sent"}:
                    add_event(events, seen, ticket, class="hl-string">"Satisfaction Survey Sent", audit_time, last_update, user_cache, audit_id + class="hl-string">":survey_sent")
                if field in {class="hl-string">"sla_breached", class="hl-string">"is_sla_breached"} and str(value).lower() in {class="hl-string">"true", class="hl-string">"1", class="hl-string">"yes"}:
                    row = base_row(ticket, class="hl-string">"SLA Breach Occurred", audit_time, last_update, user_cache)
                    row[class="hl-string">"IsSlaBreached"] = True
                    key = (str(ticket_id), class="hl-string">"SLA Breach Occurred", audit_id, str(audit_time))
                    if key not in seen:
                        seen.add(key)
                        events.append(row)
    try:
        satisfaction = api_get(session, fclass="hl-string">"/api/v2/tickets/{ticket_id}/satisfaction_rating.json").get(class="hl-string">"satisfaction_rating")
    except requests.HTTPError:
        satisfaction = None
    if satisfaction:
        add_event(events, seen, ticket, class="hl-string">"Satisfaction Rating Received", satisfaction.get(class="hl-string">"created_at") or satisfaction.get(class="hl-string">"updated_at"), last_update, user_cache, str(satisfaction.get(class="hl-string">"id") or class="hl-string">"rating"))
    return events


def validate_rows(rows: List[Dict[str, Any]]) -> None:
    activities = {
        class="hl-string">"Service Request Created",
        class="hl-string">"Initial Acknowledgment Sent",
        class="hl-string">"Request Categorized And Prioritized",
        class="hl-string">"Request Assigned To Agent",
        class="hl-string">"First Agent Public Reply Sent",
        class="hl-string">"Information Requested From Customer",
        class="hl-string">"Customer Responded",
        class="hl-string">"Internal Escalation Triggered",
        class="hl-string">"SLA Breach Occurred",
        class="hl-string">"Service Request Resolved",
        class="hl-string">"Service Request Reopened",
        class="hl-string">"Satisfaction Survey Sent",
        class="hl-string">"Satisfaction Rating Received",
        class="hl-string">"Service Request Closed",
    }
    missing_columns = [column for column in ALL_COLUMNS if column not in rows[0]] if rows else ALL_COLUMNS
    if missing_columns:
        fail(class="hl-string">"Missing output columns: " + class="hl-string">", ".join(missing_columns))
    invalid = [row for row in rows if not row.get(class="hl-string">"ServiceRequest") or not row.get(class="hl-string">"ActivityName") or not row.get(class="hl-string">"StartTime") or not row.get(class="hl-string">"SourceSystem") or not row.get(class="hl-string">"LastDataUpdate")]
    if invalid:
        fail(fclass="hl-string">"{len(invalid)} rows are missing required values")
    unexpected = sorted({row[class="hl-string">"ActivityName"] for row in rows} - activities)
    if unexpected:
        fail(class="hl-string">"Unexpected activity names: " + class="hl-string">", ".join(unexpected))


def main() -> None:
    global session
    if ZENDESK_SUBDOMAIN.startswith(class="hl-string">"[") or ZENDESK_EMAIL.startswith(class="hl-string">"[") or ZENDESK_API_TOKEN.startswith(class="hl-string">"[") or START_TIME.startswith(class="hl-string">"["):
        fail(class="hl-string">"Configure ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN, and START_TIME")
    start_time = parse_start_time(START_TIME)
    session = requests.Session()
    session.auth = (fclass="hl-string">"{ZENDESK_EMAIL}/token", ZENDESK_API_TOKEN)
    session.headers.update({class="hl-string">"Accept": class="hl-string">"application/json"})
    last_update = now_utc()
    user_cache: Dict[str, str] = {}
    group_cache: Dict[str, str] = {}
    seen = set()
    rows: List[Dict[str, Any]] = []
    tickets = paged_get(session, class="hl-string">"/api/v2/incremental/tickets/cursor.json", {class="hl-string">"start_time": start_time})
    for ticket in tickets:
        rows.extend(extract_ticket_events(session, ticket, last_update, user_cache, group_cache, seen))
    rows.sort(key=lambda row: (row[class="hl-string">"ServiceRequest"], row[class="hl-string">"StartTime"], row[class="hl-string">"ActivityName"]))
    validate_rows(rows)
    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=ALL_COLUMNS, extrasaction=class="hl-string">"ignore")
        writer.writeheader()
        writer.writerows(rows)
    print(json.dumps({class="hl-string">"output_file": OUTPUT_FILE, class="hl-string">"rows": len(rows), class="hl-string">"last_data_update": last_update}))


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

Stappen

Kies een commercieel ETL- of ELT-platform met een ondersteunde connector voor Zendesk Support. Controleer of de connector tickets, ticketevents of audits, opmerkingen, gebruikers, groepen, klanttevredenheidsscores, SLA-data en beschikbare resultaten van triggers of automatiseringen uit je Zendesk-account kan repliceren.
Maak een Zendesk API-integratie aan met de authenticatiemethode die je organisatie en de gekozen connector ondersteunen. Geef alleen leesrechten voor ticket-, audit-, opmerking-, gebruikers-, groeps-, klanttevredenheids- en SLA-data. Bewaar de verbindingsreeks en inloggegevens in de beveiligde opslag van de tool.
Stel de connector in om de vereiste Zendesk-objecten naar het doeldataplatform te repliceren. Gebruik de bronobjecten die de connector aanmaakt en ga niet uit van vaste tabel- of kolomnamen. Noteer de werkelijke object- en veldkoppelingen in de projectdocumentatie als [Your table name] en [Your column name] wanneer de connector accountafhankelijke namen gebruikt.
Stel incrementele extractie in met de ondersteunde updatetimestamp, cursor of methode voor wijzigingsregistratie van het bronsysteem. Neem historische data voor de gekozen analyseperiode mee, meestal drie tot zes maanden, en bewaar het bron-event- of audit-ID om dubbele records na herhaalde updates te kunnen verwijderen.
Maak een genormaliseerd stagingmodel waarin ticketrecords worden gecombineerd met tickethistorie, audit- of eventrecords, opmerkingen, gebruikers, groepen, klanttevredenheidsscores, SLA-records en eventuele connector-specifieke trigger- of automatiseringsrecords. Bewaar waar beschikbaar de oorspronkelijke brontimestamp, het bronrecord-ID, ticket-ID, actor-ID, eventtype, veldnaam, vorige waarde en nieuwe waarde.
Maak een eventtransformatie die één rij oplevert voor elke expliciet waargenomen activiteit. Koppel het aanmaken van een ticket aan Service Request Created, het in aanmerking komende automatische eerste antwoord aan Initial Acknowledgment Sent, wijzigingen in type, categorie of prioriteit aan Request Categorized And Prioritized, wijzigingen van de toegewezen medewerker aan Request Assigned To Agent, de eerste in aanmerking komende openbare reactie van een medewerker aan First Agent Public Reply Sent, een overgang naar pending die hoort bij een informatieverzoek aan Information Requested From Customer, een reactie van de klant aan Customer Responded, groepswijzigingen aan Internal Escalation Triggered, een waargenomen SLA-overschrijdingsrecord of -event aan SLA Breach Occurred, overgangen naar solved aan Service Request Resolved, overgangen van solved naar open na een reactie van de klant aan Service Request Reopened, een waargenomen verzending van een enquête aan Satisfaction Survey Sent, een ingediende beoordeling aan Satisfaction Rating Received en een definitieve overgang naar closed aan Service Request Closed.
Maak geen afgeleide rijen op basis van alleen de huidige ticketstatus of verstreken tijd. Als de bron geen expliciete registratie bevat van een enquêteverzending, SLA-overschrijding, automatische bevestiging of definitieve sluiting, laat die activiteit dan weg of gebruik een afzonderlijk gedocumenteerde bron die deze expliciet registreert. ProcessMind leest het event log zoals het is en leidt ontbrekende events niet af.
Verwijder dubbele events op basis van het bron-event- of audit-ID als dat beschikbaar is. Gebruik bij gebrek aan een stabiel ID een gedocumenteerde samengestelde sleutel met ServiceRequest, ActivityName, StartTime, actor en bronrecord-ID. Behoud meerdere geldige voorkomens van activiteiten zoals Customer Responded, Information Requested From Customer, Internal Escalation Triggered en Service Request Reopened.
Vul de vereiste uitvoerkolommen ServiceRequest, ActivityName, StartTime, SourceSystem en LastDataUpdate in. Voeg AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime en IsSlaBreached toe als de bron deze bevat. Gebruik overal dezelfde UTC-timestampnotatie en bewaar de regel voor het omzetten van de brontijdzone.
Exporteer het uiteindelijke event log als een CSV-bestand dat geschikt is voor ProcessMind, of laad het in de ingestelde ProcessMind-importlocatie. Zorg dat elke activiteit één rij krijgt, ServiceRequest de case-ID is, ActivityName de exacte activiteitsnamen bevat, StartTime een geldige timestamp is en de vereiste attributen in elke uitvoerrij staan als ze technisch beschikbaar zijn.

Configuratie

Connector en bronbereik: Stel de gekozen commerciële ETL- of ELT-tool in voor Zendesk Support en selecteer de bronobjecten met tickets, ticketaudits of events, opmerkingen, gebruikers, groepen, klanttevredenheidsscores, SLA-informatie en resultaten van automatiseringen of triggers. Objectnamen verschillen per connector en account. Gebruik daarom de daadwerkelijke catalogus van de connector en ga niet uit van vaste tabelnamen.
Authenticatie en autorisatie: Gebruik de Zendesk-authenticatiemethode die je organisatie heeft goedgekeurd. Geef leesrechten voor alle geselecteerde bronobjecten, waaronder historische ticketevents en klanttevredenheidsgegevens. Controleer of API-toegang, de vereiste functies van het Zendesk-abonnement en eventuele connectorlicenties zijn ingeschakeld.
Datumbereik: Begin met drie tot zes maanden aan historie. Vergroot de periode pas nadat je de API-quota, capaciteit van het dataplatform, eventvolumes en beschikbaarheid van historische audit-, SLA- en klanttevredenheidsgegevens hebt gecontroleerd.
Incrementeel laden: Gebruik bij voorkeur de ingebouwde cursor, wijzigingsregistratie of updatetimestamp van de connector. Plan eerst een historische import en daarna regelmatige incrementele imports. Neem een terugkijkperiode mee voor opmerkingen, beoordelingen, SLA-resultaten en ticketupdates die later binnenkomen.
Activiteitsfilters: Filter bronrecords op de gekozen analyseperiode en de relevante Zendesk Support-instantie. Filter niet alleen op de huidige ticketstatus, want historische activiteiten kunnen horen bij tickets waarvan de status inmiddels is gewijzigd.
Filters voor organisatie of account: Als de connector meerdere Zendesk-instanties, merken, organisaties of bedrijfseenheden toont, pas dan het goedgekeurde organisatie- of accountfilter toe met het daadwerkelijke veld van de connector. Ga er niet van uit dat er een Company Code-veld bestaat.
Eventkoppeling: Houd een expliciete koppeltabel bij van broneventtype, veldnaam, statusovergang, actortype en automatiseringsindicator naar de 14 vereiste ActivityName-waarden. Maak alleen een rij aan als de bron daar expliciet bewijs voor bevat.
Bevestiging herkennen: Koppel Initial Acknowledgment Sent alleen wanneer de bron een automatisch eerste antwoord of een gelijkwaardige melding uit een trigger registreert. Classificeer een antwoord van een medewerker niet als automatische bevestiging zonder bewijs uit de bron.
SLA-afhandeling: Gebruik expliciete SLA-overschrijdingsrecords of SLA-resultaten die de connector beschikbaar maakt. Sla de doeltijd op in SlaTargetResolutionTime en het overschrijdingsresultaat in IsSlaBreached. Bereken een overschrijding niet op basis van verstreken tijd, tenzij de SLA-kalender, het beleid, de werktijden en de doeltijd bekend zijn en de berekening is gedocumenteerd.
Prestaties: Beperk de eerste import op datum, selecteer alleen de benodigde kolommen, gebruik incrementele replicatie, schakel waar mogelijk partitionering of clustering op ServiceRequest en StartTime in en maak het genormaliseerde eventmodel na de ruwe import. Scan niet steeds opnieuw de volledige tickethistorie.
Datakwaliteit: Bewaar bron-ID’s en timestamps, zet timestamps om naar UTC, gebruik een vaste notatie voor booleans en behoud nullwaarden als de bron een attribuut niet bevat. Vul ontbrekende gegevens over medewerker, categorie, prioriteit, SLA of kanaal niet zelf in.
Verversingstimestamp: Stel LastDataUpdate in op het tijdstip waarop de extractie of transformatie is voltooid. Gebruik voor het hele event log dezelfde tijdzone en notatie.

a Voorbeeldquery config

WITH source_data AS (
    SELECT
        [Your ticket identifier column] AS service_request,
        [Your source event identifier column] AS source_event_id,
        [Your event type column] AS source_event_type,
        [Your field name column] AS source_field_name,
        [Your previous value column] AS previous_value,
        [Your new value column] AS new_value,
        [Your event timestamp column] AS event_time,
        [Your actor type column] AS actor_type,
        [Your actor identifier column] AS actor_id,
        [Your assigned agent column] AS assigned_agent,
        [Your request type column] AS service_request_type,
        [Your priority column] AS priority,
        [Your communication channel column] AS communication_channel,
        [Your SLA target resolution time column] AS sla_target_resolution_time,
        [Your SLA breached flag column] AS is_sla_breached,
        [Your automated response flag column] AS is_automated_response,
        [Your public comment flag column] AS is_public_comment,
        [Your customer reply flag column] AS is_customer_reply,
        [Your survey sent flag column] AS is_survey_sent,
        [Your satisfaction rating column] AS satisfaction_rating,
        [Your source system value] AS source_system,
        [Your extraction timestamp column] AS last_data_update
    FROM [Your normalized Zendesk event source]
    WHERE [Your event timestamp column] >= [Your start date parameter]
      AND [Your event timestamp column] < [Your end date parameter]
),
activity_events AS (
    SELECT service_request, 'Service Request Created' AS activity_name, event_time AS start_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_created'
    UNION ALL
    SELECT service_request, 'Initial Acknowledgment Sent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'comment_added' AND is_automated_response = TRUE AND is_public_comment = TRUE
    UNION ALL
    SELECT service_request, 'Request Categorized And Prioritized', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_field_changed' AND source_field_name IN ('type', 'category', 'priority')
    UNION ALL
    SELECT service_request, 'Request Assigned To Agent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_field_changed' AND source_field_name IN ('assignee', 'assigned_agent')
    UNION ALL
    SELECT service_request, 'First Agent Public Reply Sent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'comment_added' AND is_public_comment = TRUE AND actor_type = 'agent' AND is_automated_response = FALSE
    UNION ALL
    SELECT service_request, 'Information Requested From Customer', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND new_value = 'pending'
    UNION ALL
    SELECT service_request, 'Customer Responded', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'comment_added' AND is_public_comment = TRUE AND is_customer_reply = TRUE
    UNION ALL
    SELECT service_request, 'Internal Escalation Triggered', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_field_changed' AND source_field_name IN ('group', 'assigned_group')
    UNION ALL
    SELECT service_request, 'SLA Breach Occurred', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, TRUE, source_system, last_data_update
    FROM source_data
    WHERE source_event_type IN ('sla_breach', 'sla_breached') OR is_sla_breached = TRUE
    UNION ALL
    SELECT service_request, 'Service Request Resolved', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND new_value = 'solved'
    UNION ALL
    SELECT service_request, 'Service Request Reopened', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND previous_value = 'solved' AND new_value = 'open' AND is_customer_reply = TRUE
    UNION ALL
    SELECT service_request, 'Satisfaction Survey Sent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type IN ('satisfaction_survey_sent', 'csat_survey_sent') OR is_survey_sent = TRUE
    UNION ALL
    SELECT service_request, 'Satisfaction Rating Received', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type IN ('satisfaction_rating_received', 'csat_rating_received') OR satisfaction_rating IS NOT NULL
    UNION ALL
    SELECT service_request, 'Service Request Closed', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND new_value = 'closed'
),
deduplicated_events AS (
    SELECT
        service_request,
        activity_name,
        start_time,
        assigned_agent,
        service_request_type,
        priority,
        communication_channel,
        sla_target_resolution_time,
        is_sla_breached,
        source_system,
        last_data_update,
        ROW_NUMBER() OVER (PARTITION BY service_request, activity_name, source_event_id ORDER BY start_time) AS event_rank
    FROM activity_events
)
SELECT
    service_request AS ServiceRequest,
    activity_name AS ActivityName,
    start_time AS StartTime,
    source_system AS SourceSystem,
    last_data_update AS LastDataUpdate,
    assigned_agent AS AssignedAgent,
    service_request_type AS ServiceRequestType,
    priority AS Priority,
    communication_channel AS CommunicationChannel,
    sla_target_resolution_time AS SlaTargetResolutionTime,
    is_sla_breached AS IsSlaBreached
FROM deduplicated_events
WHERE event_rank = 1
ORDER BY service_request, start_time, activity_name;

Klaar om te beginnen?

Begin vandaag met het verbeteren van je klantenservice. Bereid je data voor met deze template en ontdek waar je Zendesk Support-processen efficiënter kunt maken.

Terug naar de verbetergids Template downloaden

Pak bottlenecks in de klantenservice aan en verhoog nu je CSAT-score

Voorkom herhaalcontact. Behaal 80% FCR en verhoog de klanttevredenheid.

Start je gratis proefperiode

Geen creditcard nodig

Datatemplate voor klantenservice

Datatemplate voor klantenservice

Attributen voor klantenservice

Activiteiten in de klantenservice

Extractiegidsen

Zendesk Explore-interface voor rapportage en data-export

Stappen

Configuratie

a Voorbeeldquery config

Python-script met de Zendesk Support REST API

Stappen

Configuratie

a Voorbeeldquery python

Zendesk Incremental Exports API voor bulksgewijze data-export

Stappen

Configuratie

a Voorbeeldquery python

Connector voor Zendesk van een externe ETL-tool

Stappen

Configuratie

a Voorbeeldquery config

Klaar om te beginnen?

Pak bottlenecks in de klantenservice aan en verhoog nu je CSAT-score

Datatemplate voor klantenservice

Datatemplate voor klantenservice

Attributen voor klantenservice

Activiteiten in de klantenservice

Extractiegidsen

Zendesk Explore-interface voor rapportage en data-export

Stappen

Configuratie

a Voorbeeldquery config

Python-script met de Zendesk Support REST API

Stappen

Configuratie

a Voorbeeldquery python

Zendesk Incremental Exports API voor bulksgewijze data-export

Stappen

Configuratie

a Voorbeeldquery python

Connector voor Zendesk van een externe ETL-tool

Stappen

Configuratie

a Voorbeeldquery config

Klaar om te beginnen?

Pak bottlenecks in de klantenservice aan en verhoog nu je CSAT-score

We gaan zorgvuldig om met je privacy