> Continue verbetering > Beheer van Serviceaanvragen > Zendesk Support > datatemplate

Uw Beheer van serviceaanvragen datatemplate

Zendesk Support

Beheer van serviceaanvragen `Attributen` (21) Beheer van serviceaanvragen Activiteiten (13) Extractiegidsen (3)

Uw Beheer van serviceaanvragen datatemplate

Deze template is een volledige gids voor het extraheren van de benodigde data om uw Serviceaanvraagbeheer proces in Zendesk Support te analyseren. Het schetst de benodigde data attributen om te verzamelen, belangrijke activiteiten om te volgen, en praktische begeleiding over hoe u deze Informatie direct uit je systeem kunt extraheren. Gebruik dit hulpmiddel om een betrouwbare event log te bouwen voor uw process mining-initiatieven.

Aanbevolen attributen voor grondige analyse
Belangrijke `service request activiteiten` om te volgen
Extractiehandleiding voor Zendesk Support `data`

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

Template downloaden

Beheer van serviceaanvragen `Attributen`

Dit zijn de aanbevolen velden om op te nemen in uw event log voor een volledige analyse van serviceaanvraagbeheer binnen Zendesk Support.

5 Verplicht 7 Aanbevolen 9 Optioneel

	Naam	Omschrijving
	Activiteit ActivityName	De naam van de bedrijfsactiviteit of gebeurtenis die plaatsvond voor een serviceaanvraag.
Omschrijving De Activiteit vertegenwoordigt een afzonderlijke stap of gebeurtenis in de service request levenscyclus, zoals 'Service Request Created', 'Request Assigned to Agent' of 'Service Request Opgelost'. Deze activiteiten zijn afgeleid van wijzigingen die zijn vastgelegd in de auditlog van het Zendesk ticket, die wijzigingen in velden zoals status, assignee, priority en het toevoegen van opmerkingen bijhoudt. Het analyseren van activiteiten vormt de kern van process mining. Het maakt de visualisatie van de proceskaart, identificatie van knelpunten tussen stappen en analyse van herstelwerk-loops mogelijk. Door de volgorde en frequentie van activiteiten te begrijpen, kunnen organisaties inefficiënties en kansen voor procesverbetering vinden. Het belang Dit attribuut definieert de stappen in het proces, wat de visualisatie van proceskaarten en de analyse van processtroom, variaties en naleving mogelijk maakt. Vindplaats Dit is conceptueel afgeleid van gebeurtenissen die zijn vastgelegd in de Zendesk Ticket Audits API. Bijvoorbeeld, een wijziging in het 'status' veld van 'new' naar 'open' kan worden toegewezen aan een activity zoals 'Request Triaged'. Voorbeelden Serviceverzoek AangemaaktAgent opnieuw toegewezenServiceaanvraag Opgelost
	Serviceaanvraag-ID ServiceRequestId	De unieke ID voor elk serviceaanvraag ticket binnen Zendesk.
Omschrijving De Service Request ID, vaak Ticket ID genoemd in Zendesk, dient als de primaire key voor elke case. Het verbindt alle gerelateerde activiteiten, opmerkingen en statuswijzigingen met elkaar, vanaf het moment dat een aanvraag wordt aangemaakt totdat deze wordt afgesloten. Dit maakt een complete, end-to-end trace van de levenscyclus van een enkele aanvraag mogelijk. In process mining analysis is dit attribuut belangrijk. Het definieert de case, waardoor de reconstructie van processtromen, de identificatie van varianten en de berekening van case-level meetwaarden zoals doorlooptijd mogelijk is. Elke gebeurtenis in de dataset moet worden geassocieerd met een Service Request ID om de context binnen het algehele proces te begrijpen. Het belang Dit is de essentiële case kenmerk die alle gebeurtenissen in het traject van een serviceaanvraag verbindt, waardoor het mogelijk is om het end-to-end process te analyseren. Vindplaats Zendesk Tickets API, veld 'id'. Voorbeelden 102451024610247
	Starttijd EventTimestamp	De exacte datum en tijd waarop de activiteit plaatsvond.
Omschrijving `Event Timestamp`, of Starttijd, registreert het exacte moment waarop een activiteit plaatsvond. Zo legt het vast wanneer een `agent` werd toegewezen, wanneer een publieke reactie werd verzonden, of wanneer de `ticket`status werd gewijzigd naar 'Opgelost'. Deze tijdelijke `data` is afkomstig uit het `auditlog` van elk Zendesk `ticket`. Dit `attribuut` is belangrijk voor elke tijdsgebaseerde analyse. Het wordt gebruikt om `gebeurtenissen` chronologisch te ordenen, de duur tussen activiteiten te berekenen, wachttijden te meten en de algehele `case doorlooptijd` te analyseren. Het is onmisbaar voor het vinden van `knelpunten` en het ewaarderen van prestaties ten opzichte van tijdsgebonden doelen zoals SLA's. Het belang Deze timestamp ordent gebeurtenissen chronologisch en is belangrijk voor alle duur-, prestaties- en bottleneck analysis. Vindplaats Zendesk Ticket Audits API, veld 'created_at' voor elke audit gebeurtenis. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
	Bronsysteem SourceSystem	Geeft het systeem aan waaruit de data is opgehaald.
Omschrijving Dit attribuut specificeert de oorsprong van de service request data. Voor deze procesweergave zal de waarde consistent 'Zendesk Support' zijn, wat het identificeert als het bronsysteem voor alle service management activiteiten. In omgevingen met meerdere geïntegreerde systemen is dit veld belangrijk voor data lineage en probleemoplossing. Het zorgt ervoor dat analyses correct zijn afgestemd op het beoogde systeem en helpt data te differentiëren wanneer deze vanuit verschillende bronnen wordt samengevoegd. Het belang Identificeert het bronsysteem van de `data`, wat `data lineage` waarborgt en verwarring voorkomt wanneer `data` uit meerdere systemen wordt gecombineerd. Vindplaats Dit is een statische waarde ('Zendesk Support') toegevoegd tijdens data-extractie en transformation. Voorbeelden Zendesk Support
	Tijdstip van extractie LastDataUpdate	De `timestamp` die de laatste keer aangeeft dat de `data` is ververst vanuit het bronsysteem.
Omschrijving Dit attribuut registreert de datum en tijd van de meest recente data-extractie uit Zendesk Support. Het biedt context over de recentheid van de geanalyseerde data, zodat gebruikers zich bewust zijn van hoe actueel de procesweergave is. Voor voortdurende monitoring en dashboarding is deze Informatie belangrijk. Het stelt analysesten en zakelijke gebruikers in staat te begrijpen of zij kijken naar bijna realtime-data of een snapshot van een vorige periode, wat de validiteit van hun conclusies beïnvloedt. Het belang Biedt belangrijke context over `de relevantie van de data`, zodat gebruikers weten hoe `up-to-date` de analyse is. Vindplaats Dit is een metadataveld gegenereerd en gestempeld op de dataset op het moment van data-extractie. Voorbeelden 2023-10-27T08:00:00Z
	Aanvraagkanaal RequestChannel	Het kanaal via welke de serviceaanvraag is ingediend (bijv. E-mail, Web Form, Telefoon).
Omschrijving Dit attribuut identificeert de indieningsbron van de serviceaanvraag. Zendesk legt vast hoe een ticket is aangemaakt, of dit nu via email, een web portal, een API-integratie, chat of andere kanalen was. Dit biedt context over de interactiemethode van de klant. Het Request Channel is een waardevolle factor voor analyse. Het ondersteunt het 'Request Channel Efficiency' dashboard door vergelijkingen mogelijk te maken van oplostijden, satisfaction ratings en herstelwerk rates over verschillende kanalen. Dit kan bedrijven helpen hun support channels te optimaliseren en gebruikers naar de meest efficiënte te leiden. Het belang Helpt bij het analyseren van de efficiëntie en resultaten van verschillende `klantenservice channels`, waardoor gerichte verbeteringen mogelijk worden. Vindplaats Zendesk Tickets API, object 'via' en de 'channel' property. Voorbeelden webemailapichat
	Aanvraagprioriteit RequestPriority	Het prioriteitsniveau toegewezen aan de serviceaanvraag, zoals Low, Normaal, High, of Urgent.
Omschrijving `Request Priority` is een classificatie die de urgentie van een serviceaanvraag aangeeft. Dit niveau bepaalt vaak de `target oplostijden` en SLA-beleid dat op het `ticket` wordt toegepast. De prioriteit kan initiëel door het systeem of de gebruiker worden ingesteld en kan door een `agent` worden gewijzigd tijdens de `ticket's levenscyclus`. Dit `attribuut` is belangrijk voor segmentatie en `oorzaakanalyse`. Het helpt bij het analyseren of `hoge prioriteit tickets` sneller worden opgelost dan `lage prioriteit tickets` en is een belangrijke factor in de 'Service Request Escalation Trends' en 'SLA Adherence' `dashboards`. Het belang Maakt segmentatie van aanvragen op urgentie mogelijk, wat belangrijk is voor het analyseren van SLA-`compliance` en ervoor te zorgen dat kritieke problemen snel worden afgehandeld. Vindplaats Zendesk Tickets API, veld 'priority'. Voorbeelden LaagNormaalHoog`Urgent`
	Agentnaam AgentName	De naam van de agent die op het moment van de gebeurtenis aan de serviceaanvraag was toegewezen.
Omschrijving Dit attribuut identificeert de support agent die verantwoordelijk is voor de afhandeling van de serviceaanvraag. De toegewezen medewerker kan meerdere keren wijzigen gedurende de levenscyclus van het ticket, en dit veld legt vast wie in elke stap verantwoordelijk was. Agent Naam is belangrijk voor prestaties analysis. Het maakt filtering en segmentering van data mogelijk om werkbelastingverdeling, oplostijden per agent en de frequentie van reassignments te beoordelen. Dit helpt bij het bouwen van het Agent & Team Performance dashboard en het begrijpen van individuele bijdragen aan de algehele procesefficiëntie. Het belang Dit attribuut is belangrijk voor het analyseren van agent prestaties, werkbelastingverdeling en de impact van reassignments op oplostijden. Vindplaats Zendesk Gebruikers API, door de 'assignee_id' uit de Tickets API response te joinen. Voorbeelden Jane DoeJohn SmithEmily Jones
	Servicetype ServiceType	De categorie of het type van de serviceaanvraag (bijv. Incident, Question, Problem, Task).
Omschrijving Service Type categoriseert de aard van de serviceaanvraag. Zendesk gebruikt een 'type'-veld om onderscheid te maken tussen verschillende soorten supportinteracties. Deze initiële classificatie helpt bij het routeren van het ticket naar het juiste team en het toepassen van de juiste processen. Dit attribuut is belangrijk voor filtering en vergelijking. Het stelt analysesten in staat om de processtromen voor verschillende typen aanvragen te onderzoeken, die vaak zeer verschillende afhandelingspaden en SLA's hebben. Het is een belangrijke dimensie voor het Agent & Team Performance dashboard om te zien wie het beste is in het afhandelen van specifieke aanvraagtypen. Het belang Categoriseert aanvragen voor afzonderlijke analyse van verschillende processen, zoals incidenten versus vragen, die unieke paden volgen. Vindplaats Zendesk Tickets API, veld 'type'. Voorbeelden questionincidentproblemtaak
	Ticket Tags TicketTags	Een lijst met `tags` die zijn toegepast op de serviceaanvraag voor categorisatie en routering.
Omschrijving Tags zijn flexibele labels die handmatig door medewerkers of automatisch via business rules aan tickets kunnen worden toegevoegd. Ze worden gebruikt om specifieke context of categorieën toe te voegen aan een ticket die mogelijk niet worden gedekt door standaardvelden zoals Type of Priority. Tags zijn een uiterst veelzijdig attribuut voor process mining-analyse. Ze kunnen worden gebruikt om te filteren op zeer specifieke scenario's, custom workflows te volgen of grondoorzaken te vinden. Bijvoorbeeld, een 'VIP' tag kan worden gebruikt om het proces voor belangrijke klanten te analyseren, of een 'product_bug' tag kan worden gebruikt om de levenscyclus van defectrapporten te traceren. Het belang Biedt een flexibele manier om de `data` te `slicen` en `dicen`, wat een `deep-dive` analyse in specifieke subprocessen of `ticket attributen` mogelijk maakt die niet in andere velden zijn vastgelegd. Vindplaats Zendesk Tickets API, veld 'tags'. Dit is een array van strings. Voorbeelden sales_inquiryfacturatieprobleemfeature_requestvip_customer
	Toegewezen Team AssignedTeam	Het supportteam of de groep die is toegewezen aan de serviceaanvraag.
Omschrijving Dit attribuut geeft aan welk team of welke groep binnen de support organization verantwoordelijk is voor de serviceaanvraag. In Zendesk staan deze bekend als 'Groups'. Tickets worden vaak eerst aan een groep toegewezen voordat ze door een individuele agent worden opgepakt. Analyseren per Assigned Team is belangrijk voor het begrijpen van team-level prestaties en workload. Het helpt bij het beantwoorden van vragen over welke teams welke soorten aanvragen afhandelen, hun gemiddelde oplostijden en hun SLA-naleving rates. Dit is een primaire dimensie voor het Agent & Team Performance dashboard. Het belang Maakt analyse mogelijk van teamprestaties, `werkdrukverdeling` en routeringsefficiëntie tussen verschillende supportgroepen. Vindplaats Zendesk Groups API, door de 'group_id' uit de Tickets API response te joinen. Voorbeelden Tier 1 SupportTechnische supportFacturatie
	Verzoekstatus RequestStatus	De status van de serviceaanvraag op het moment van de gebeurtenis (bijv. New, Open, Pending).
Omschrijving `Request Status` vertegenwoordigt de status van het `ticket` op een specifiek tijdsTip. Zendesk heeft verschillende standaardstatussen zoals New, Open, Pending, On-hold, Solved en Closed, die de voortgang van een aanvraag gedurende de `levenscyclus` markeren. Wijzigingen in dit veld zijn primaire `triggers` voor het creëren van activiteiten in het `event log`. Het analyseren van de tijd die wordt besteed in verschillende statussen is een kernonderdeel van `bottleneck` analyse. Het helpt bij het vinden waar `tickets` vastlopen, bijvoorbeeld te veel tijd doorbrengen in een 'Pending' of 'On-hold' status. Het begrijpen van statusovergangen is ook belangrijk voor het bekijken van `herstelwerk-loops`. Het belang Het bijhouden van de status is onmisbaar voor het begrijpen van de voortgang van de aanvraag en het vinden hoeveel tijd wordt besteed in wacht- of actieve states. Vindplaats Zendesk Tickets API, veld 'status'. Voorbeelden NieuwOpenPendingOpgelostGesloten
	Aantal toewijzingen agent AgentReassignmentCount	Het totale aantal keren dat een aanvraag opnieuw is toegewezen van de ene agent naar de andere.
Omschrijving Dit attribuut is een teller die elke keer ophoogt wanneer het 'assignee_id'-veld op een ticket verandert. Een hoog aantal reassignments voor een enkel ticket kan wijzen op verschillende procesproblemen, zoals onjuiste initiële routing, gebrek aan agent knowledge of aanvragen die te complex zijn voor één agent om af te handelen. Dit is een belangrijke metriek voor het meten van procesefficiëntie en ondersteunt direct de 'Agent Reassignment Rate' KPI. Het analyseren van cases met hoge reassignment counts kan kansen zichtbaar maken om routing rules, agent training of knowledge base bronnen te verbeteren om ervoor te zorgen dat tickets sneller bij de juiste persoon terechtkomen. Het belang Helpt bij het kwantificeren van interne `overdrachten` en identificeert procesknelpunten, aangezien hoge herovertoewijzingspercentages vaak leiden tot vertragingen en inefficiëntie. Vindplaats Berekend door het aantal 'assignee_id' wijzigingen te tellen in de Zendesk Ticket Audits API voor elk `ticket`. Voorbeelden 013
	Eindtijd EndTime	De precieze datum en tijd waarop de activity is voltooid.
Omschrijving De End Time markeert de voltooiing van een activity. Voor veel gebeurtenissen in Zendesk is de duur ogenblikkelijk, dus de End Time is hetzelfde als de Starttijd. Echter, voor statusgerelateerde activiteiten zoals 'Request Placed On-Hold', zou de End Time zijn wanneer het ticket uit de wacht wordt gehaald. Dit attribuut is belangrijk voor het berekenen van de duur van specifieke activiteiten, wat belangrijk is voor bottleneck analysis. Door de Starttijd en End Time van een activity te vergelijken, kan men de verwerkingstijd direct meten, wat helpt bij het vinden welke stappen de meeste tijd in beslag nemen. Het belang Maakt de berekening mogelijk van individuele activiteitsduren, wat belangrijk is voor het vinden van `process knelpunten` en het meten van `step-level efficiency`. Vindplaats Dit is vaak hetzelfde als de StartTime voor discrete gebeurtenissen. Voor statusduren is het de timestamp van de volgende gebeurtenis die de status wijzigt. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
	Is `First Contact Resolution` IsFirstContactResolution	Een `flag` die aangeeft of de aanvraag is opgelost door de eerst toegewezen `agent` zonder heroverwegingen of antwoorden van de aanvrager.
Omschrijving `First Contact Resolution` (FCR) is een belangrijke `metriek` die aangeeft dat het probleem van een klant in één interactie is opgelost. Dit berekende `attribuut` is een boolean `flag` die `true` is als een `ticket` is opgelost door de eerste `agent` aan wie het was toegewezen, zonder heroverwegingen en met slechts één `agent reply`. Dit `attribuut` ondersteunt direct de KPI 'First Contact Resolution Rate'. Het analyseren van de kenmerken van FCR `cases` kan een `blueprint` bieden voor `optimale processen`. Omgekeerd kan het analyseren van `cases` die FCR missen, mogelijkheden belichten voor betere `agent training`, verbeterde `knowledge base articles`, of effectievere initiële `triage`. Het belang Meet het vermogen om problemen efficiënt op te lossen in één contact, wat een sterke drijfveer is voor zowel klanttevredenheid als operationele efficiëntie. Vindplaats Dit is een complex berekend attribuut. Het vereist het analyseren van de event log voor een ticket om te controleren op agent reassignments en het aantal openbare reacties van medewerkers. Voorbeelden truefalse
	Is `SLA` Geschonden IsSlaBreached	Een `flag` die aangeeft of de serviceaanvraag een van zijn SLA-doelen heeft geschonden.
Omschrijving Dit attribuut is een booleaanse of categorische flag die de SLA outcome voor een ticket toont. Het kan statussen aangeven zoals 'Met', 'Breached' of 'Active'. Dit wordt bepaald door de werkelijke response of oplostijden te vergelijken met de targets gedefinieerd in de toegepaste SLA policy. Dit is een onmisbaar attribuut voor het 'SLA Adherence and Breach Analysis' dashboard. Het maakt eenvoudig tellen en visualiseren van compliant versus non-compliant tickets mogelijk. Verdere analyse kan zich dan richten op de proceskenmerken van geschonden tickets om grondoorzaken te vinden, zoals lange wachttijden of excessieve reassignments. Het belang Meet direct de prestaties ten opzichte van `service level commitments`, een belangrijke indicator van servicekwaliteit en klanttevredenheid. Vindplaats Afgeleid van de Zendesk `Ticket Kengetallen` API, die Informatie verschaft over de SLA-status voor elk `ticket`. Voorbeelden BehaaldOverschredenActief
	Is herstelwerk IsRework	Een `flag` die `true` is als de serviceaanvraag opnieuw is geopend nadat deze was opgelost (`solved`).
Omschrijving Deze booleaanse flag identificeert cases die herstelwerk hebben ondergaan. Een serviceaanvraag wordt doorgaans beschouwd als herstelwerk als de status verandert van 'Solved' terug naar een open status, wat aangeeft dat de initiële oplossing niet voldoende was en de klant moest opvolgen voor hetzelfde probleem. Dit attribuut is belangrijk voor het berekenen van de 'Service Request Rework Rate' KPI en voor het 'Rework and Reopening Activiteit Analysis' dashboard. Door flagging herstelwerk cases, kunnen analysesten deze inefficiënte processtromen isoleren, de grondoorzaken van heropeningen bekijken en werken aan het verbeteren van first contact resolution. Het belang Identificeert procesfouten waarbij de oplossing niet definitief was, en belicht problemen met kwaliteit en efficiëntie die direct van invloed zijn op de klanttevredenheid. Vindplaats Berekend door de reeks statussen voor een `ticket` in de Zendesk Ticket Audits API te analyseren. Een overgang van 'solved' naar 'open' duidt op herstelwerk (`herstelwerk`). Voorbeelden truefalse
	Naam aanvrager RequestorName	De naam van de eindgebruiker of klant die de serviceaanvraag heeft ingediend.
Omschrijving Dit attribuut identificeert de persoon die de serviceaanvraag heeft geïnitieerd. Het koppelen van de aanvraag aan een specifieke klant biedt een user-centric view van het support proces. In procesanalyse kan de aanvrager worden gebruikt om patronen voor specifieke klanten of klantsegmenten te analyseren. Men zou bijvoorbeeld kunnen onderzoeken of bepaalde klanten langere oplostijden ervaren of hogere herstelwerk rates hebben, wat kan duiden op problemen met een product of dienst die zij gebruiken. Het belang Verbindt het proces met de klant, waardoor analyse van klantspecifieke problemen, herhaalde aanvragen en tevredenheidsniveaus mogelijk worden. Vindplaats Zendesk Gebruikers API, door de 'requester_id' uit de Tickets API response te joinen. Voorbeelden Alice JohnsonBob WilliamsCharlie Brown
	Organisatie aanvrager RequestorOrganization	De organisatie of het bedrijf waartoe de aanvrager behoort.
Omschrijving Dit attribuut koppelt de serviceaanvraag aan een specifieke klantorganisatie. Dit is met name relevant in B2B support-scenario's, waar service level agreements en support contracts vaak op organisatieniveau worden gedefinieerd. Het analyseren van data per organisatie maakt een bedrijfsbreed beeld van support prestaties mogelijk. Het kan helpen organisaties te vinden die een hoog volume aan tickets genereren, terugkerende problemen ervaren of lage tevredenheidsscores hebben. Dit is waardevol voor account management en het vinden van bredere customer health trends. Het belang Maakt B2B-serviceanalyse mogelijk door aanvragen te groeperen per bedrijf, wat belangrijk is voor het beheren van klantrelaties en SLA's op organisatieniveau. Vindplaats Zendesk Organizations API, door de 'organization_id' uit de Tickets API response te joinen. Voorbeelden Acme CorporationWereldwijd Tech Inc.Innoveer oplossingen
	SLA Beleidsnaam SlaPolicyName	De naam van het Service Level Agreement (SLA) beleid dat op de aanvraag van toepassing is.
Omschrijving Dit attribuut identificeert de specifieke SLA policy die de target response en oplostijden voor de serviceaanvraag regelt. Een policy wordt doorgaans bepaald door factoren zoals de priority, het type van de aanvraag of het subscription level van de klant. Het kennen van de toegepaste SLA policy is belangrijk voor het 'SLA Adherence and Breach Analysis' dashboard. Het biedt de nodige context om de prestaties te ewaarderen, aangezien verschillende policies verschillende targets zullen hebben. Dit maakt een eerlijke en nauwkeurige beoordeling mogelijk of een ticket voldeed aan zijn specifieke service level objectives. Het belang Biedt de context voor SLA-analyse door te vinden tegen welke reeks doelen een aanvraag werd gemeten, waardoor nauwkeurige `compliance reporting` mogelijk worden. Vindplaats Zendesk Ticket Kengetallen API. SLA data is vaak geassocieerd met de meetwaarden van het ticket. Voorbeelden Urgent - Reactie binnen 1 uurStandaard - Oplossing binnen 24 uurPremium Klant SLA
	Tevredenheidsscore SatisfactionRating	De tevredenheidsscore die de aanvrager heeft gegeven nadat het ticket was opgelost.
Omschrijving Dit attribuut legt de feedback van de klant vast over hun support experience, doorgaans verzameld via een enquête nadat een ticket als opgelost is gemarkeerd. Veelvoorkomende ratings zijn onder andere 'Good' of 'Bad', soms met een opmerking. Satisfaction Rating is een kritieke uitkomst metriek. Het correleren van procespatronen met tevredenheidsscores kan zichtbaar maken welk procesgedrag leidt tot tevreden of ontevreden klanten. Analyse kan bijvoorbeeld aantonen dat hoge reassignment rates of lange oplostijden sterk correleren met negatieve tevredenheidsbeoordelingen. Het belang Biedt een directe link tussen procesuitvoering en klantresultaten, en helpt te vinden welke procesgedragingen de klanttevredenheid sturen. Vindplaats Zendesk Tickets API, veld 'satisfaction_rating.score' of 'satisfaction_rating.reason'. Voorbeelden GoedSlechtAangeboden

Verplicht Aanbevolen Optioneel

Beheer van serviceaanvragen Activiteiten

Dit zijn de belangrijkste processtappen en mijlpalen om vast te leggen in uw event log voor nauwkeurige process discovery van uw serviceaanvragen.

7 Aanbevolen 6 Optioneel

	Activiteit	Omschrijving
	Aanvraag Toegewezen aan `Agent`	Deze activity treedt op wanneer een serviceaanvraag voor het eerst wordt toegewezen aan een specifieke agent. Het wordt afgeleid van een 'Change' gebeurtenis in de ticket auditlog waarbij het 'assignee_id'-veld wordt gevuld vanuit null of een group ID.
Het belang Dit markeert de start van actief werk door een agent en is belangrijk voor het meten van initiële response times, first assignment lag en agent werkbelastingverdeling. Vindplaats Afgeleid van de eerste 'Change' `gebeurtenis` op het 'assignee_id' veld in het `ticket auditlog` waarbij een specifieke `user ID` is ingesteld. Vastleggen Afgeleid van de eerste `change gebeurtenis` die het 'assignee_id' veld instelt op een `agent`. Gebeurtenistype inferred
	Openbaar Antwoord Verzonden	Deze activity markeert elke communicatie die van een agent naar de aanvrager is verzonden. Dit wordt vastgelegd als een expliciete 'Comment' gebeurtenis in de Zendesk ticket data waarbij de 'public' attribuut true is.
Het belang Deze gebeurtenissen zijn belangrijk voor het analyseren van communicatiefrequentie, het meten van agent response times en het vinden van het aantal interacties dat nodig is voor oplossing. Vindplaats Dit is een expliciete 'Comment' gebeurtenis in de ticket data. De gebeurtenis details omvatten een 'public: true' attribuut, wat het onderscheidt van interne notities. Vastleggen Vastgelegd vanuit `ticket` 'Comment' `gebeurtenissen` waarbij de `flag` 'public' is ingesteld op `true`. Gebeurtenistype explicit
	Serviceaanvraag Gesloten	Vertegenwoordigt de uiteindelijke, permanente sluiting van de serviceaanvraag. Een `ticket` gaat automatisch naar de 'closed' status na een ingestelde periode van 'solved' zijn en kan niet langer worden heropend.
Het belang Deze activity markeert het definitieve einde van het serviceaanvraagproces. Het biedt het eindpunt voor het berekenen van de volledige case duur. Vindplaats Afgeleid van een 'Change' `gebeurtenis` op het 'status' veld in het `ticket auditlog`, waarbij de nieuwe waarde 'closed' is. Vastleggen Afgeleid van een 'Change' `gebeurtenis` in het `auditlog` waarbij de status 'closed' wordt. Gebeurtenistype inferred
	Serviceaanvraag Heropend	Treedt op wanneer een aanvrager reageert op een aanvraag die in een 'solved' status verkeert, waardoor de status automatisch terug verandert naar 'open'. Dit betekent dat de voorgestelde oplossing niet toereikend was.
Het belang Deze activity is de primaire indicator van herstelwerk. Het analyseren van de frequentie helpt bij het meten van de oplossingskwaliteit en het vinden van oorzaken van klantontevredenheid. Vindplaats Afgeleid van een 'Change' `gebeurtenis` op het 'status' veld in het `ticket auditlog`, waarbij de vorige waarde 'solved' was en de nieuwe waarde 'open' is. Vastleggen Afgeleid van een statuswijziging van 'solved' naar 'open'. Gebeurtenistype inferred
	Serviceaanvraag Opgelost	Deze activity markeert het punt waarop een agent een oplossing heeft geboden en de ticket status heeft gewijzigd naar 'solved'. De aanvraag wordt als voltooid beschouwd vanuit het perspectief van de agent, maar kan nog steeds worden heropend door de aanvrager.
Het belang Dit is een belangrijke mijlpaal die het einde van actief agent work aangeeft. De tijd om deze state te bereiken is een primaire maatstaf voor resolution efficiency. Vindplaats Afgeleid van een 'Change' `gebeurtenis` op het 'status' veld in het `ticket auditlog`, waarbij de nieuwe waarde 'solved' is. Vastleggen Afgeleid van een 'Change' `gebeurtenis` in het `auditlog` waarbij de status 'solved' wordt. Gebeurtenistype inferred
	Serviceverzoek Aangemaakt	Markeert het begin van de `service request levenscyclus` wanneer een nieuw `ticket` wordt ingediend door een aanvrager via elk kanaal. Dit wordt vastgelegd als een 'Create' `gebeurtenis` in het Zendesk `ticket auditlog`, wat een definitieve starttijd voor het proces biedt.
Het belang Deze activity dient als de primaire start gebeurtenis voor elke serviceaanvraag, wat het belangrijk maakt voor het berekenen van end-to-end doorlooptijden en het analyseren van request intake volumes. Vindplaats Dit wordt vastgelegd als een 'Create' gebeurtenis type in de Zendesk ticket auditlog. De timestamp van deze gebeurtenis is de aanmaaktijd van het service request ticket. Vastleggen Rechtstreeks vastgelegd vanuit de 'Create' `gebeurtenis` in het `ticket auditlog`. Gebeurtenistype explicit
	SLA-doelstelling overschreden	Deze activity markeert het moment waarop een serviceaanvraag niet voldoet aan een gedefinieerde SLA target, zoals first reply time of resolution time. Zendesk registreert dit als een expliciete gebeurtenis wanneer een target wordt gemist.
Het belang Dit is een kritieke gebeurtenis voor compliance monitoring en is een belangrijke input voor de SLA-nalevingspercentage (KPI). Het wijst op het niet nakomen van serviceverplichtingen. Vindplaats Vastgelegd vanuit de 'SLABreach' `gebeurtenis` binnen de Zendesk `ticket gebeurtenissen` of `auditlog`. De `gebeurtenis` specificeert welke SLA `metriek` werd geschonden. Vastleggen Geïdentificeerd via de expliciete 'SLABreach' `gebeurtenis` in `ticket data`. Gebeurtenistype explicit
	Aanvraag Geëscaleerd	Vertegenwoordigt de formele escalatie van een serviceaanvraag naar een hogere support `pakket`, een ander team of het management. Dit wordt doorgaans afgeleid van een wijziging in de toegewezen groep van het `ticket` of een wijziging in een `aangepast veld` dat is aangewezen voor het bijhouden van escalaties.
Het belang Het `monitoren` van escalaties helpt bij het vinden van complexe aanvragen, `trainingsbehoeften` voor `front-line medewerkers`, en systemische problemen die interventie op hoger niveau vereisen. Vindplaats Dit is geen standaard gebeurtenis. Het moet worden afgeleid van een 'Change' gebeurtenis op het 'group_id'-veld naar een escalation group of van een wijziging naar een custom ticket veld gebruikt voor escalation tracking. Vastleggen Afgeleid van een wijziging van 'group_id' of een `custom 'escalation' veld`. Gebeurtenistype inferred
	Aanvraag in de wacht gezet	Deze activity treedt op wanneer de status van de serviceaanvraag wordt gewijzigd naar 'on-hold', wat doorgaans aangeeft dat de agent wacht op Informatie van de aanvrager of een derde partij. Dit wordt afgeleid van een status change gebeurtenis.
Het belang Dit helpt bij het isoleren en meten van wachttijden die buiten de directe controle van het support team vallen, wat een nauwkeuriger beeld geeft van de agent handling time. Vindplaats Afgeleid van een 'Change' `gebeurtenis` op het 'status' veld in het `ticket auditlog`, waarbij de nieuwe waarde 'on-hold' is. Vastleggen Afgeleid van een 'Change' `gebeurtenis` in het `auditlog` waarbij de status 'on-hold' wordt. Gebeurtenistype inferred
	Agent opnieuw toegewezen	Vertegenwoordigt de overdracht van eigenaarschap van een serviceaanvraag van de ene `agent` naar de andere. Dit wordt afgeleid van elke volgende 'Change' `gebeurtenis` op het 'assignee_id' veld na de initiële toewijzing.
Het belang Het volgen van reassignments is belangrijk voor het berekenen van de Agent Reassignment Rate KPI, wat helpt bij het vinden van procesinefficiënties, onjuiste routing of knowledge gaps. Vindplaats Afgeleid van 'Change' `gebeurtenissen` op het 'assignee_id' veld in het `ticket auditlog`, met uitzondering van de allereerste `assignment gebeurtenis` voor het `ticket`. Vastleggen Afgeleid van de tweede en volgende 'Change' `gebeurtenissen` op het 'assignee_id' veld. Gebeurtenistype inferred
	Interne Notitie Toegevoegd	Een interne notitie of `comment` is toegevoegd aan de serviceaanvraag door een `agent`, alleen zichtbaar voor andere `medewerkers`. Dit wordt geregistreerd als een 'Comment' `gebeurtenis` waarbij het `attribuut` 'public' `false` is.
Het belang Het bijhouden van interne notities geeft inzicht in de samenwerking tussen medewerkers of teams, wat een bron van vertraging kan zijn of een sleutel tot efficiënte probleemoplossing. Vindplaats Dit is een expliciete 'Comment' gebeurtenis in de ticket data. De gebeurtenis details omvatten een 'public: false' attribuut, wat aangeeft dat het een interne notitie is. Vastleggen Vastgelegd vanuit `ticket` 'Comment' `gebeurtenissen` waarbij de `flag` 'public' is ingesteld op `false`. Gebeurtenistype explicit
	Prioriteit Gewijzigd	Geeft aan dat het prioriteitsniveau van de serviceaanvraag, zoals 'Laag', 'Normaal', 'Hoog' of 'Urgent', is bijgewerkt. Dit wordt vastgelegd als een 'Change' `gebeurtenis` op het 'priority' veld in het `ticket auditlog`.
Het belang Het analyseren van prioriteitswijzigingen helpt bij het vinden van aanvragen die in de loop van de tijd urgenter worden en beoordeelt of de prioritering effectief wordt beheerd. Vindplaats Geregistreerd als een 'Change' `gebeurtenis` op het 'priority' veld binnen het Zendesk `ticket auditlog`, met weergave van de vorige en nieuwe waarden. Vastleggen Afgeleid van 'Change' `gebeurtenissen` op het 'priority' veld in het `auditlog`. Gebeurtenistype inferred
	SLA Target toegepast	Vertegenwoordigt het moment waarop een `Service Level Agreement` (SLA) beleid wordt toegepast op het `service request ticket`. Deze `gebeurtenis` wordt expliciet gelogd wanneer de eigenschappen van het `ticket` overeenkomen met de voorwaarden van een actief SLA-beleid.
Het belang Het bijhouden wanneer een SLA wordt toegepast, is belangrijk voor het monitoren van compliance, het analyseren van potentiële schendingen en het begrijpen van de verwachte servicetermijn voor verschillende aanvraagtypen. Vindplaats Vastgelegd vanuit de 'SLAPolicyApplied' `gebeurtenis` binnen de Zendesk `ticket gebeurtenissen` of `auditlog`. Deze `gebeurtenis` specificeert welk beleid overeenkwam. Vastleggen Geïdentificeerd via de expliciete 'SLAPolicyApplied' `gebeurtenis` in `ticket data`. Gebeurtenistype explicit

Aanbevolen Optioneel

Extractiegidsen

Hoe u je data uit Zendesk Support haalt

Stappen

Toegang tot Zendesk Explore en Creëer het Primaire Rapport: Navigeer naar het Zendesk productenicoon in de rechterbovenbalk en selecteer Explore. Eenmaal in Explore, klik op het Queries icoon aan de linkerzijde en klik vervolgens op Nieuwe query. Selecteer de Support: Ticket updates dataset als bron.
Configureer Kengetallen en Attributen voor Ticket Events: Voeg in de query builder een metriek zoals COUNT(Tickets) toe om data te visualiseren. Ga vervolgens naar de sectie Rows en voeg de volgende attributen toe: Ticket ID, Update - Timestamp, Updater name, Update - Field name, Update - Previous waarde, Update - New waarde, Assignee name, Group name, Ticket priority, Ticket status, Submission channel, Ticket type, en Ticket tags.
Creëer een Berekend Attribute voor ActiviteitNaam: Om ruwe updates te vertalen naar betekenisvolle activiteiten, creëer een standaard berekend attribuut. Ga naar het Calculations menu (rekenmachine-icoon), selecteer Standard calculated attribuut en noem het ActiviteitNaam. Plak de logica uit de Query sectie in het formulevak. Deze formule koppelt verschillende ticket update gebeurtenissen aan de vereiste activiteitsnamen.
Verfijn en Filter het Primaire Rapport: Voeg het nieuwe ActiviteitNaam attribuut toe aan de sectie Rows. Creëer een filter op dit attribuut om (null) of ongewenste systeem-gegenereerde waarden uit te sluiten en de dataset op te schonen. Voeg ook een filter toe voor Ticket created - Date om de query te beperken tot een beheersbaar tijdsbestek, zoals de laatste 6 maanden.
Creëer het Tweede Rapport voor SLA Events: Creëer nog een nieuwe query, selecteer dit keer de Support: SLAs dataset. Dit is nodig omdat SLA gebeurtenissen niet beschikbaar zijn in de Ticket updates dataset.
Configureer het SLA Rapport: Voeg in de SLA query COUNT(SLA tickets) toe aan Kengetallen. Voeg in de sectie Rows de volgende attributen toe: Ticket ID, SLA policy, SLA target, SLA updated - Timestamp, SLA status, en Updater name. We zullen de activiteit afleiden uit de SLA status in de transformatiestap.
Exporteer Beide Datasets: Voer beide queries uit in de Explore UI. Zodra de tabellen zijn gegenereerd, klikt u op de Export knop en kiest u CSV als formaat. U heeft nu twee afzonderlijke CSV-bestanden.
Voeg de Data Samen en Transformeer deze: Combineer de twee CSV-bestanden met behulp van een spreadsheettool zoals Microsoft Excel of een scripting language zoals Python. Het doel is om een enkel event log te creëren. Voor het SLA-bestand moet u de ActiviteitNaam kolom aanmaken. Als SLA status Active is, is de activiteit SLA Target Applied. Als SLA status Breached is, is de activiteit SLA Target Breached. Gebruik de SLA updated - Timestamp als de EventTimestamp.
Standaardiseer Kolomkoppen: Hernoem in het uiteindelijke samengevoegde bestand de kolommen zodat ze overeenkomen met het vereiste formaat voor process mining. Hernoem bijvoorbeeld Ticket ID naar ServiceRequestId, Update - Timestamp naar EventTimestamp, en Updater name naar AgentNaam.
Voeg Statische Kolommen Toe en Finaliseer: Voeg twee nieuwe kolommen toe aan uw uiteindelijke CSV-bestand. Vul Bronsysteem met de waarde 'Zendesk'. Vul LastDataUpdate met de timestamp van wanneer u de export heeft uitgevoerd. Het bestand is nu klaar voor upload.

Configuratie

Zendesk Plan: Een Zendesk Support plan inclusief Zendesk Explore Professional of Enterprise is vereist om aangepaste queries en attributen te maken.
Rechten: U moet een agent zijn met rechten om queries te maken en te bewerken in Explore. Doorgaans is dit een beheerder of een agent met een aangepaste rol.
Datasetselectie: Deze methode vereist het maken van twee afzonderlijke rapporten gebaseerd op twee verschillende datasets: Support: Ticket updates voor algemene gebeurtenissen en Support: SLAs voor SLA-specifieke gebeurtenissen.
Datumbereikfilter: Het is belangrijk om een datumbereikfilter toe te passen, bijvoorbeeld op Ticket created - Date, om het datavolume beheersbaar te houden. Een bereik van 3 tot 6 maanden wordt aanbevolen voor initiële analyse.
Berekende Attributen: De logica voor het afleiden van activiteitsnamen wordt afgehandeld door een complex, aangepast berekend attribuut binnen Explore. Zorg ervoor dat de formule correct is aangemaakt om fouten in de output te voorkomen.
Datavolume: De Zendesk Explore UI en exportfunctionaliteit kunnen traag zijn of time-outen bij zeer grote datasets. Voor extracties van meer dan een jaar aan data of miljoenen tickets, overweeg om de export op te splitsen in kleinere, gebundelde tijdsperioden.

a Voorbeeldquery config

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

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

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

Stappen

Voorwaarden: Zorg ervoor dat Python 3.6 of nieuwer op je systeem is geïnstalleerd. U heeft ook beheerdersrechten nodig voor uw Zendesk Support-omgeving om een API-token te genereren.
Python-bibliotheken installeren: Open uw terminal of opdrachtprompt en installeer de benodigde Python-bibliotheken via pip. De requests-bibliotheek wordt gebruikt voor API-aanroepen en pandas voor databewerking en het exporteren naar een CSV-bestand.
```
pip install requests pandas
```
Zendesk API-token genereren: Log in bij Zendesk als beheerder. Ga naar Beheercentrum > Apps en integraties > API's > Zendesk-API. Schakel bij de sectie Token-toegang de optie in als dit nog niet is gebeurd en klik op "API-token toevoegen". Geef een beschrijving op, bijvoorbeeld "ProcessMind Extractie", en kopieer het gegenereerde token. Dit token wordt hierna niet meer getoond.
Het Python-script configureren: Open het meegeleverde Python-script in een teksteditor. Vul de configuratievariabelen bovenaan het bestand in: ZENDESK_SUBDOMAIN (de subdomeinnaam van uw bedrijf in Zendesk), ZENDESK_EMAIL (het e-mailadres van de beheerder die aan het token is gekoppeld) en ZENDESK_API_TOKEN. Stel ook de START_TIME_STR in om het begin van de extractieperiode te bepalen, meestal 3 tot 6 maanden geleden.
De logica van het script begrijpen: Het script haalt eerst een lijst met tickets op die binnen het opgegeven datumbereik zijn bijgewerkt via de efficiënte Incremental Tickets API. Voor elk ticket worden vervolgens de volledige audittrail, opmerkingen en SLA-statistieken opgehaald. Deze gebeurtenissen worden chronologisch verwerkt om een gedetailleerde historie op te bouwen.
Zendesk-gebeurtenissen koppelen aan activiteiten: Het script bevat de logica om ruwe Zendesk-gebeurtenissen te vertalen naar de benodigde bedrijfsactiviteiten. Een 'Change' gebeurtenis in het veld 'status' wordt bijvoorbeeld gekoppeld aan activiteiten als 'Service Request Opgelost' of 'Request Placed On-Hold'. Bij comment-gebeurtenissen wordt gecontroleerd of het een 'Public Reply Sent' of een 'Internal Note Added' betreft.
Het extractiescript uitvoeren: Start het script vanuit uw terminal door python uw_script_naam.py uit te voeren. Het script toont voortgangsupdates terwijl het data ophaalt uit de Zendesk API. Afhankelijk van het datavolume en de API-limieten kan dit proces enige tijd duren.
Het uitvoerbestand controleren: Zodra het script klaar is, wordt er een CSV-bestand met de naam zendesk_gebeurtenis_log.csv aangemaakt in dezelfde map. Dit bestand bevat het opgehaalde event log met alle opgegeven activiteiten en attributen.
Voorbereiden voor upload: Open het CSV-bestand om te controleren of de opmaak correct is. De kolomkoppen moeten overeenkomen met de vereiste attributen: ServiceRequestId, ActiviteitNaam, EventTimestamp, Bronsysteem, LastDataUpdate, enzovoort. Dit bestand is nu klaar voor upload naar ProcessMind.

Configuratie

Zendesk API Toegang: Het script vereist een actieve API token die is gekoppeld aan een beheerder of een agent met voldoende rechten. Het e-mailadres van de gebruiker voor de scriptconfiguratie moet hetzelfde zijn als het e-mailadres dat de API token heeft aangemaakt.
Scriptparameters: Voordat u het script uitvoert, moet u deze belangrijke variabelen configureren: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN en START_TIME_STR. De START_TIME_STR moet de indeling 'JJJJ-MM-DD' hebben.
Datumbereik: We raden aan te beginnen met een extractieperiode van de afgelopen 3 tot 6 maanden aan data (START_TIME_STR). Dit levert een representatieve dataset op voor analyse zonder buitensporige looptijd of te frequente API-limieten te veroorzaken. Een groter datumbereik zal de extractietijd aanzienlijk verlengen.
Incrementele Exports API: Het script maakt gebruik van het Incrementele Exports endpoint (/api/v2/incremental/tickets/cursor.json) om efficiënt alleen tickets op te halen die zijn bijgewerkt sinds de laatste keer of een gespecificeerde starttijd. Dit is veel efficiënter dan het scannen van alle tickets.
Rate Limiting: Zendesk hanteert API-rate limits. Het script bevat basisfunctionaliteit om te pauzeren als een rate limit wordt bereikt, maar voor extreem grote instanties kan de extractie aanzienlijk veel tijd in beslag nemen. Het is het beste om het script buiten piekuren uit te voeren.
Escalatielogica: De activiteit 'Verzoek geëscaleerd' wordt afgeleid van een wijziging in het veld group_id. Als uw organisatie een ander mechanisme gebruikt, zoals een aangepast ticketveld, moet u de logica van het script aanpassen om escalaties correct te vinden.

a Voorbeeldquery python

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

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

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

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

class=class="hl-string">"hl-comment"># Set up constants and session
BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
AUTH = (fclass="hl-string">'{ZENDESK_EMAIL}/token', ZENDESK_API_TOKEN)
SOURCE_SYSTEM = class="hl-string">'Zendesk Support'
LAST_DATA_UPDATE = datetime.now(timezone.utc).isoformat()

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

    df = pd.DataFrame(event_log)

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

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

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

Stappen

Toegang tot Zendesk Explore en Creëer het Primaire Rapport: Navigeer naar het Zendesk productenicoon in de rechterbovenbalk en selecteer Explore. Eenmaal in Explore, klik op het Queries icoon aan de linkerzijde en klik vervolgens op Nieuwe query. Selecteer de Support: Ticket updates dataset als bron.
Configureer Kengetallen en Attributen voor Ticket Events: Voeg in de query builder een metriek zoals COUNT(Tickets) toe om data te visualiseren. Ga vervolgens naar de sectie Rows en voeg de volgende attributen toe: Ticket ID, Update - Timestamp, Updater name, Update - Field name, Update - Previous waarde, Update - New waarde, Assignee name, Group name, Ticket priority, Ticket status, Submission channel, Ticket type, en Ticket tags.
Creëer een Berekend Attribute voor ActiviteitNaam: Om ruwe updates te vertalen naar betekenisvolle activiteiten, creëer een standaard berekend attribuut. Ga naar het Calculations menu (rekenmachine-icoon), selecteer Standard calculated attribuut en noem het ActiviteitNaam. Plak de logica uit de Query sectie in het formulevak. Deze formule koppelt verschillende ticket update gebeurtenissen aan de vereiste activiteitsnamen.
Verfijn en Filter het Primaire Rapport: Voeg het nieuwe ActiviteitNaam attribuut toe aan de sectie Rows. Creëer een filter op dit attribuut om (null) of ongewenste systeem-gegenereerde waarden uit te sluiten en de dataset op te schonen. Voeg ook een filter toe voor Ticket created - Date om de query te beperken tot een beheersbaar tijdsbestek, zoals de laatste 6 maanden.
Creëer het Tweede Rapport voor SLA Events: Creëer nog een nieuwe query, selecteer dit keer de Support: SLAs dataset. Dit is nodig omdat SLA gebeurtenissen niet beschikbaar zijn in de Ticket updates dataset.
Configureer het SLA Rapport: Voeg in de SLA query COUNT(SLA tickets) toe aan Kengetallen. Voeg in de sectie Rows de volgende attributen toe: Ticket ID, SLA policy, SLA target, SLA updated - Timestamp, SLA status, en Updater name. We zullen de activiteit afleiden uit de SLA status in de transformatiestap.
Exporteer Beide Datasets: Voer beide queries uit in de Explore UI. Zodra de tabellen zijn gegenereerd, klikt u op de Export knop en kiest u CSV als formaat. U heeft nu twee afzonderlijke CSV-bestanden.
Voeg de Data Samen en Transformeer deze: Combineer de twee CSV-bestanden met behulp van een spreadsheettool zoals Microsoft Excel of een scripting language zoals Python. Het doel is om een enkel event log te creëren. Voor het SLA-bestand moet u de ActiviteitNaam kolom aanmaken. Als SLA status Active is, is de activiteit SLA Target Applied. Als SLA status Breached is, is de activiteit SLA Target Breached. Gebruik de SLA updated - Timestamp als de EventTimestamp.
Standaardiseer Kolomkoppen: Hernoem in het uiteindelijke samengevoegde bestand de kolommen zodat ze overeenkomen met het vereiste formaat voor process mining. Hernoem bijvoorbeeld Ticket ID naar ServiceRequestId, Update - Timestamp naar EventTimestamp, en Updater name naar AgentNaam.
Voeg Statische Kolommen Toe en Finaliseer: Voeg twee nieuwe kolommen toe aan uw uiteindelijke CSV-bestand. Vul Bronsysteem met de waarde 'Zendesk'. Vul LastDataUpdate met de timestamp van wanneer u de export heeft uitgevoerd. Het bestand is nu klaar voor upload.

Configuratie

Zendesk Plan: Een Zendesk Support plan inclusief Zendesk Explore Professional of Enterprise is vereist om aangepaste queries en attributen te maken.
Rechten: U moet een agent zijn met rechten om queries te maken en te bewerken in Explore. Doorgaans is dit een beheerder of een agent met een aangepaste rol.
Datasetselectie: Deze methode vereist het maken van twee afzonderlijke rapporten gebaseerd op twee verschillende datasets: Support: Ticket updates voor algemene gebeurtenissen en Support: SLAs voor SLA-specifieke gebeurtenissen.
Datumbereikfilter: Het is belangrijk om een datumbereikfilter toe te passen, bijvoorbeeld op Ticket created - Date, om het datavolume beheersbaar te houden. Een bereik van 3 tot 6 maanden wordt aanbevolen voor initiële analyse.
Berekende Attributen: De logica voor het afleiden van activiteitsnamen wordt afgehandeld door een complex, aangepast berekend attribuut binnen Explore. Zorg ervoor dat de formule correct is aangemaakt om fouten in de output te voorkomen.
Datavolume: De Zendesk Explore UI en exportfunctionaliteit kunnen traag zijn of time-outen bij zeer grote datasets. Voor extracties van meer dan een jaar aan data of miljoenen tickets, overweeg om de export op te splitsen in kleinere, gebundelde tijdsperioden.

a Voorbeeldquery config

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

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

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

Uw Beheer van serviceaanvragen datatemplate

Uw Beheer van serviceaanvragen datatemplate

Beheer van serviceaanvragen `Attributen`

Beheer van serviceaanvragen Activiteiten

Extractiegidsen

Zendesk Explore UI voor Rapport en Data Export

Stappen

Configuratie

a Voorbeeldquery config

Zendesk REST API Extraction via Python Script

Stappen

Configuratie

a Voorbeeldquery python

Zendesk Support Native Full Account JSON Export

Stappen

Configuratie

a Voorbeeldquery config

Klaar om te starten?

Optimaliseer Beheer van serviceaanvragen. Verkort Vertragingen Nu.

Uw Beheer van serviceaanvragen datatemplate

Uw Beheer van serviceaanvragen datatemplate

Beheer van serviceaanvragen Attributen

Beheer van serviceaanvragen Activiteiten

Extractiegidsen

Zendesk Explore UI voor Rapport en Data Export

Stappen

Configuratie

a Voorbeeldquery config

Zendesk REST API Extraction via Python Script

Stappen

Configuratie

a Voorbeeldquery python

Zendesk Support Native Full Account JSON Export

Stappen

Configuratie

a Voorbeeldquery config

Wij hechten veel waarde aan je privacy

Klaar om te starten?

Optimaliseer Beheer van serviceaanvragen. Verkort Vertragingen Nu.

Beheer van serviceaanvragen `Attributen`