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

Datatemplate voor probleembeheer

Zendesk Support

Attributen voor probleembeheer (19) Activiteiten voor probleembeheer (12) Extractiegidsen (3)

Datatemplate voor probleembeheer

Deze template biedt een compleet raamwerk om de levenscyclus van probleembeheer in Zendesk Support in kaart te brengen. Je vindt er de belangrijkste attributen, procesmijlpalen en extractielogica in om bottlenecks in de oorzaakanalyse op te sporen. Met deze structuur bouw je een event log van goede kwaliteit op voor verdere procesanalyse.

Aanbevolen attributen voor gedetailleerde analyse
Belangrijke procesactiviteiten en statusovergangen
Extractiegids voor Zendesk Support-data

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

Template downloaden

Attributen voor probleembeheer

Met deze aanbevolen datavelden heb je de context die nodig is om ticketcategorieën, prioriteiten en eigenaarschap gedurende de hele levenscyclus van probleemoplossing te analyseren.

5 Verplicht 8 Aanbevolen 6 Optioneel

	Naam	Beschrijving
	Activiteit ActivityName	De naam van de gebeurtenis of actie op het probleemrecord.
Beschrijving Dit attribuut legt de specifieke stap of actie vast tijdens de levenscyclus van het probleemrecord. Voorbeelden zijn statuswijzigingen zoals 'Open' naar 'Pending', wijzigingen in de toewijzing of workflowstappen zoals 'Workaround Published'. In de analyse vormen deze activiteiten de knooppunten van de procesmap. Aan de hand van de volgorde kunnen analisten de werkstroom visualiseren, bottlenecks vinden en de tijd tussen processtappen meten. Waarom dit belangrijk is Dit beschrijft wat er in het proces gebeurt en maakt visualisatie van de processtroom en analyse van varianten mogelijk. Waar vind je dit? Afgeleid van Zendesk Ticket Audits of Ticket Metrics Voorbeelden Probleemrecord geregistreerdOnderzoek gestartTijdelijke oplossing gepubliceerd
	Bronsysteem SourceSystem	De naam van het systeem waaruit de data afkomstig is.
Beschrijving Dit attribuut geeft aan uit welk softwareplatform de procesdata is gehaald. In dit geval wordt het steeds gevuld met 'Zendesk Support'. Bij analyses met data uit meerdere systemen, zoals Zendesk en Jira, kunnen analisten hiermee filteren of groeperen op basis van de herkomst. Zo blijven de herkomst en traceerbaarheid van data in procesweergaven met meerdere systemen behouden. Waarom dit belangrijk is Dit houdt de herkomst van data bij en ondersteunt process mining met meerdere systemen. Waar vind je dit? Vast ingesteld tijdens de extractie Voorbeelden Zendesk Support
	Laatste data-update LastDataUpdate	De timestamp waarop het probleemrecord voor het laatst is gewijzigd.
Beschrijving Dit attribuut geeft aan wanneer de data van het probleemrecord voor het laatst in het bronsysteem is bijgewerkt. Het verschilt van de timestamp van een gebeurtenis: het gaat om het record als geheel, niet om een afzonderlijke activiteit. Bij analyses helpt dit om te bepalen hoe actueel de data is. Je kunt ermee zien of de dataset up-to-date is en of er vertraging zit in de synchronisatie tussen het bronsysteem en de process mining-omgeving. Waarom dit belangrijk is Dit houdt bij hoe actueel de data is en helpt bij het stapsgewijs laden van data. Waar vind je dit? Zendesk Ticket-object, veld 'updated_at' Voorbeelden 2023-11-01T14:20:00Z
	Probleemrecord ProblemRecordId	Het unieke numerieke ID dat in Zendesk aan het probleemticket wordt toegewezen.
Beschrijving Dit attribuut is de unieke sleutel van het probleemrecord in Zendesk Support. Het dient als centrale Case-ID voor process mining, zodat alle volgende gebeurtenissen, updates en interacties aan één procescase kunnen worden gekoppeld. Bij analyses wordt dit ID gebruikt om elk probleemonderzoek van aanmaak tot sluiting afzonderlijk te volgen. Zo kun je gerelateerde incidenten met elkaar in verband brengen en de levenscyclus van het probleem door verschillende supportniveaus volgen. Waarom dit belangrijk is Dit is de verplichte sleutel om gebeurtenissen voor elke process mining-analyse aan cases te koppelen. Waar vind je dit? Zendesk Ticket-object, veld 'id' waarbij type 'problem' is Voorbeelden 1045293849921
	Starttijd EventTimestamp	De datum en tijd waarop een activiteit plaatsvond.
Beschrijving Dit attribuut registreert het exacte moment waarop een activiteit in Zendesk plaatsvond. Het geeft de tijdsinformatie die nodig is om gebeurtenissen in de juiste volgorde te zetten en de duur tussen stappen te berekenen. Bij analyses is dit belangrijk om doorlooptijden te berekenen, vertragingen te vinden, SLA-naleving te controleren en het proces in de tijd weer te geven. Zonder nauwkeurige timestamps is het niet mogelijk de snelheid van het oplossingsproces te bepalen. Waarom dit belangrijk is Hiermee kun je activiteiten sorteren en alle tijdgebonden KPI’s berekenen. Waar vind je dit? Zendesk Ticket Audits, veld 'created_at' Voorbeelden 2023-10-12T08:30:00Z2023-10-12T09:15:22Z
	Aantal gerelateerde incidenten RelatedIncidentCount	Het aantal incidenttickets dat aan dit probleemrecord is gekoppeld.
Beschrijving Dit attribuut telt hoeveel afzonderlijke incidenttickets aan dit probleemrecord zijn gekoppeld. In Zendesk gebeurt dit via het veld 'problem_id' op incidenttickets, dat naar dit record verwijst. Bij analyses is dit de belangrijkste metriek voor de correlatie en impact van incidenten. Je kunt er problemen mee prioriteren die de meeste gebruikers raken. Zo kun je bepalen welke fixes de grootste daling in het aantal tickets opleveren. Waarom dit belangrijk is Dit geeft aan hoe groot de impact van het probleem op gebruikers is. Waar vind je dit? Zendesk Tickets API, aantal tickets waarvoor type='incident' en problem_id=ThisID Voorbeelden 015342
	Categorie hoofdoorzaak RootCauseCategory	De vastgestelde onderliggende oorzaak van het probleem (bijvoorbeeld een codefout of configuratiefout).
Beschrijving Dit attribuut legt de uiteindelijke diagnose van de oorzaak van het probleem vast. Meestal wordt het ingevuld tijdens de activiteit ‘Hoofdoorzaak vastgesteld’. In analyses wordt dit gebruikt voor het rapport ‘Nauwkeurigheid van probleemcategorisatie’ en om trends in systeemstoringen te onderzoeken. Zo kan het management bepalen of de aandacht vooral naar codekwaliteit, infrastructuurstabiliteit of leveranciersbeheer moet gaan. Waarom dit belangrijk is Hiermee kun je patronen in storingen analyseren en verbeteringen voor de lange termijn bepalen. Waar vind je dit? Aangepaste velden van Zendesk-tickets Voorbeelden SoftwarefoutConfiguratiefoutGebruikersfout
	Naam van toegewezen agent AssigneeName	De agent die aan het probleem werkt.
Beschrijving Dit attribuut bevat de naam van de gebruiker die momenteel verantwoordelijk is voor het probleemrecord. Zo zie je wie specifieke acties heeft uitgevoerd. Bij analyses helpt dit om de werklast en prestaties per persoon te begrijpen. Analyse per groep is gebruikelijk, maar gegevens per toegewezen agent kunnen laten zien waar training nodig is of wie complexe oorzaken bijzonder goed oplost. Waarom dit belangrijk is Hiermee kun je de inzet van capaciteit per persoon analyseren. Waar vind je dit? Zendesk Ticket-object, veld 'assignee_id' (omgezet naar naam) Voorbeelden Jan JansenJanneke SmitSysteem
	Prioriteit Priority	De urgentie van het probleemrecord.
Beschrijving Dit attribuut geeft het relatieve belang van het probleem aan, meestal als Laag, Normaal, Hoog of Urgent. De prioriteit bepaalt de verwachte serviceniveaus (SLA’s) en de verdeling van capaciteit. Bij analyses kun je processen hiermee opdelen en prestaties per urgentieniveau vergelijken. Zo controleer je bijvoorbeeld of problemen met de prioriteit 'Urgent' inderdaad sneller worden opgelost dan problemen met de prioriteit 'Laag', zoals het dashboard voor de snelheid van oorzaakanalyses vereist. Waarom dit belangrijk is Dit is essentieel om cases op te delen en de SLA-naleving en prioritering van capaciteit te analyseren. Waar vind je dit? Zendesk Ticket-object, veld 'priority' Voorbeelden UrgentHoogNormaalLaag
	Probleemcategorie ProblemCategory	De classificatie van het probleem (bijvoorbeeld software, hardware of netwerk).
Beschrijving Dit attribuut deelt het probleem in op basis van de getroffen dienst of technologiestack. Meestal gaat het om een aangepast keuzemenu in Zendesk-formulieren. In analyses wordt dit gebruikt voor het dashboard ‘Nauwkeurigheid van probleemcategorisatie’. Door de eerste categorie te vergelijken met de uiteindelijke hoofdoorzaak, zie je of problemen bij de eerste beoordeling bij de juiste teams terechtkomen. Waarom dit belangrijk is Hiermee kun je segmenteren op technologie of bedrijfsdienst. Waar vind je dit? Aangepaste velden van Zendesk-tickets Voorbeelden DatabaseUI/UXNetwerkinfrastructuur
	Status van probleem ProblemStatus	De huidige status van het probleemrecord in de levenscyclus.
Beschrijving Dit attribuut toont de huidige status van het probleem, zoals New, Open, Pending, Solved of Closed. Zo zie je hoe ver het onderzoek is. Bij analyses kun je hiermee open en gesloten cases filteren. Het is belangrijk voor het dashboard voor bewaking van verouderde probleemrecords, waarmee je ziet welke actieve cases niet volgens verwachting van status veranderen. Waarom dit belangrijk is Hiermee kun je cases filteren op basis van hun afrondingsstatus. Waar vind je dit? Zendesk Ticket-object, veld 'status' Voorbeelden NieuwOpenIn afwachtingOpgelostGesloten
	Supportgroep SupportGroup	Het team of de afdeling waaraan het probleemrecord momenteel is toegewezen.
Beschrijving Dit attribuut geeft aan welke groep agents op een bepaald moment verantwoordelijk is voor het probleem. De waarde verandert wanneer het ticket van het ene team naar het andere wordt overgedragen. Dit is belangrijk voor het dashboard voor analyse van overdrachten tussen supportgroepen. Je kunt er prestaties per team mee meten, bottlenecks bij overdrachten vinden en de verdeling van de werklast analyseren. Waarom dit belangrijk is Hiermee kun je de organisatie analyseren en bottlenecks tussen afdelingen vinden. Waar vind je dit? Zendesk Ticket-object, veld 'group_id' (omgezet naar naam) Voorbeelden Tweede lijn supportDatabaseteamNetwerkbeheer
	Uiterste SLA-datum SlaDueDate	De datum en tijd waarop het probleem uiterlijk moet zijn opgelost.
Beschrijving Dit attribuut geeft de uiterste oplostijd aan op basis van de configuratie van de service level agreement. De deadline wordt meestal berekend op basis van de prioriteit en het moment waarop het ticket is aangemaakt. Bij analyses wordt deze vergeleken met de werkelijke oplostijd om het percentage nageleefde SLA’s voor problemen te berekenen. Het dashboard voor SLA-prestaties en -risico’s laat zien welke cases de deadline naderen of al hebben overschreden. Waarom dit belangrijk is Dit is essentieel om compliance en contractuele prestaties te meten. Waar vind je dit? Zendesk Ticket Metrics- of SLA Policies-endpoint Voorbeelden 2023-12-01T17:00:00Z
	ID van kennisartikel KnowledgeArticleId	De ID van het kennisbankartikel dat voor het probleem is aangemaakt of eraan is gekoppeld.
Beschrijving Dit attribuut bevat de verwijzing naar een artikel in Zendesk Guide of een extern kennisitem. Het laat zien dat de kennis die uit het probleem is opgedaan, is vastgelegd. In analyses wordt de aanwezigheid van dit veld gebruikt om het ‘Integratiepercentage van de kennisbank’ te berekenen. Zo controleer je of oplossingen zijn gedocumenteerd, zodat ze later opnieuw kunnen worden geraadpleegd. Waarom dit belangrijk is Hiermee meet je hoe effectief kennisbeheerprocessen zijn. Waar vind je dit? Aangepaste Zendesk-ticketvelden of gekoppelde inhoud Voorbeelden 360045889KB-2991
	ID van wijzigingsverzoek ChangeRequestId	De identificatiecode van het wijzigingsverzoek dat aan de oplossing is gekoppeld.
Beschrijving Dit attribuut koppelt de probleemregistratie aan een verandermanagementregistratie, mogelijk in een ander systeem of een ander type ticket. Het geeft aan dat een formeel wijzigingsproces is gestart. In analyses ondersteunt dit het dashboard ‘Percentage gestarte wijzigingsverzoeken’. Je volgt hiermee de overgang van diagnose naar uitvoering en controleert of vastgestelde hoofdoorzaken leiden tot formele wijzigingsacties. Waarom dit belangrijk is Hiermee koppel je het probleemproces aan het verandermanagementproces. Waar vind je dit? Aangepaste Zendesk-ticketvelden of gekoppelde tickets Voorbeelden CR-1002CHG00394
	Onderwerp van probleem ProblemSubject	Een korte samenvatting of titel van het probleemrecord.
Beschrijving Dit attribuut bevat de samenvatting die is ingevoerd toen het probleem werd aangemaakt. Meestal beschrijft die het symptoom of het probleem dat wordt onderzocht. Bij analyses geeft dit de analist context bij het bekijken van afzonderlijke cases. Je kunt ook tekstanalyses toepassen om vergelijkbare problemen te groeperen of terugkerende onderwerpen te vinden die niet in gestructureerde categorievelden staan. Waarom dit belangrijk is Dit geeft afzonderlijke cases context die mensen direct kunnen begrijpen. Waar vind je dit? Zendesk Ticket-object, veld 'subject' Voorbeelden Betalingen verwerken lukt niet in de EU-regioPieken in de latentie van de inlogserverData-export mislukt voor beheerders
	PIR uitgevoerd HasPostImplementationReview	Geeft aan of er een evaluatie na de implementatie is uitgevoerd.
Beschrijving Dit attribuut geeft aan of het oplossingsproces voor het probleem een evaluatiefase bevatte. De waarde wordt afgeleid door te controleren of de activiteit ‘Evaluatie na implementatie uitgevoerd’ in de casegeschiedenis voorkomt. Dit ondersteunt het dashboard ‘Dekking evaluaties na implementatie’. Het is een compliancemetriek die controleert of de organisatie leert van grote problemen. Waarom dit belangrijk is Hiermee controleer je of de processen voor continue verbetering worden nageleefd. Waar vind je dit? Afgeleid van de activiteit ‘Evaluatie na implementatie uitgevoerd’ Voorbeelden truefalse
	Tijdelijke oplossing actief WorkaroundActive	Een aanduiding die aangeeft of er een tijdelijke oplossing is geboden of gepubliceerd.
Beschrijving Dit booleaanse attribuut geeft aan of er een tijdelijke oplossing voor het probleem is vastgelegd. De waarde wordt vaak afgeleid van de activiteit ‘Tijdelijke oplossing gepubliceerd’ of van een specifiek selectievakje in het formulier. In analyses wordt dit gebruikt voor het dashboard ‘Naleving publicatie tijdelijke oplossingen’. Je meet hiermee hoe vaak het supportteam gebruikers direct helpt terwijl het onderzoek naar een oplossing voor de lange termijn doorgaat. Waarom dit belangrijk is Dit is belangrijk om te meten hoe de impact op gebruikers tijdens onderzoeken wordt beperkt. Waar vind je dit? Afgeleid van de activiteit ‘Tijdelijke oplossing gepubliceerd’ of een aangepast veld Voorbeelden truefalse
	Verouderd IsStale	Geeft aan of er langer dan 14 dagen geen activiteit op het probleem is geweest.
Beschrijving Dit berekende attribuut markeert registraties die onlangs niet zijn bijgewerkt. Het vergelijkt de huidige datum (of de analysedatum) met de timestamp van de laatste activiteit. Dit vormt de basis voor het dashboard ‘Bewaking van verouderde probleemregistraties’. Managers kunnen hiermee snel verwaarloosde cases in de achterstand vinden. Die moeten mogelijk administratief worden afgesloten of opnieuw worden toegewezen. Waarom dit belangrijk is Hiermee vind je verspilling in het proces en werkitems die zijn blijven liggen. Waar vind je dit? Berekend in de process mining-tool: (Now - LastDataUpdate) > 14 days Voorbeelden truefalse

Verplicht Aanbevolen Optioneel

Activiteiten voor probleembeheer

Leg deze essentiële processtappen en statuswijzigingen vast om de volledige processtroom in beeld te brengen, van de eerste probleemmelding tot de definitieve oplossing.

8 Aanbevolen 4 Optioneel

	Activiteit	Beschrijving
	Definitieve oplossing toegepast	Dit geeft aan dat de technische oplossing in de omgeving is uitgerold. Meestal wordt dit bijgehouden via een aangepaste statuswijziging of een specifieke tag voordat het ticket volledig is opgelost.
Waarom dit belangrijk is Essentieel voor het dashboard voor de efficiëntie van de implementatie van fixes. Hiermee wordt de tijd tussen diagnose en uitrol gemeten. Waar vind je dit? Afgeleid van een specifieke tag, zoals 'fix_deployed', of van een aangepast statusveld als dat bestaat. Vastleggen Controleer tags of aangepaste statuskeuzelijsten Gebeurtenistype inferred
	Onderzoek gestart	Dit markeert de overgang van de passieve status 'New' naar een actieve werkstatus. Het geeft aan dat een agent het probleem heeft opgepakt en met de diagnose is begonnen.
Waarom dit belangrijk is Wordt gebruikt voor de metriek voor verouderde probleemrecords en is het startpunt voor de KPI voor de gemiddelde duur van de oorzaakanalyse. Waar vind je dit? Afgeleid wanneer de ticketstatus verandert van 'New' naar 'Open' of 'Pending'. Vastleggen Vergelijk de status voor en na de wijziging Gebeurtenistype inferred
	Oorzaak vastgesteld	Het moment waarop de onderliggende oorzaak van het probleem wordt vastgesteld. Dit wordt meestal vastgelegd wanneer een agent een aangepast tekstveld of keuzelijstveld 'Root Cause' invult.
Waarom dit belangrijk is Een belangrijke mijlpaal voor het dashboard voor de snelheid van oorzaakanalyses en voor het meten van de efficiëntie van diagnoses. Waar vind je dit? Controleer of aangepaste velden met de naam 'Root Cause', 'RCA' of 'Problem Source' een waarde krijgen. Vastleggen Controleer of aangepaste velden zijn ingevuld Gebeurtenistype inferred
	Oplossing gecontroleerd	Het probleem wordt formeel als opgelost gemarkeerd. In Zendesk gebeurt dit wanneer de standaardstatus van het systeem op 'Solved' wordt gezet. Dit geeft aan dat de oplossing is gecontroleerd en de case is afgerond.
Waarom dit belangrijk is Het belangrijkste eindpunt voor de berekening van SLA-prestaties en -risico’s en het percentage nageleefde SLA’s voor problemen. Waar vind je dit? Afgeleid wanneer de ticketstatus verandert in 'Solved'. Vastleggen Geregistreerd wanneer de status verandert in Solved Gebeurtenistype explicit
	Probleemrecord geregistreerd	Het probleemticket wordt aangemaakt in Zendesk Support. Deze gebeurtenis legt de timestamp vast waarop het probleem voor het eerst in het systeem is geregistreerd. Meestal begint hiermee het proces.
Waarom dit belangrijk is Dit bepaalt de starttijd van de volledige oplossingscyclus en vormt het uitgangspunt voor alle metingen van de doorlooptijd. Waar vind je dit? Afgeleid van de timestamp 'created_at' in het ticketobject of de eerste vermelding in het auditlog van het ticket. Vastleggen Geregistreerd wanneer de transactie Ticket Created is uitgevoerd Gebeurtenistype explicit
	Probleemrecord gesloten	De laatste gebeurtenis in de levenscyclus: het ticket wordt vergrendeld en kan niet meer worden gewijzigd. In Zendesk gebeurt dit meestal automatisch, vier dagen nadat de status Solved is ingesteld.
Waarom dit belangrijk is Dit markeert het definitieve einde van het record en wordt gebruikt voor gegevensbewaring en historische rapportages. Waar vind je dit? Afgeleid wanneer de ticketstatus verandert in 'Closed'. Vastleggen Geregistreerd wanneer de status verandert in Closed Gebeurtenistype explicit
	Tijdelijke oplossing gepubliceerd	Een tijdelijke oplossing voor het probleem documenteren en delen. In Zendesk wordt dit vaak vastgelegd met een specifieke tag of een aangepast selectievakje dat aangeeft dat er een tijdelijke oplossing beschikbaar is.
Waarom dit belangrijk is Ondersteunt het dashboard voor naleving van de publicatie van tijdelijke oplossingen. Zo krijgen gebruikers tijdens langdurige onderzoeken een tijdelijke oplossing. Waar vind je dit? Controleer of de tag 'workaround_published' is toegevoegd of dat een aangepast booleaans veld met de naam 'Workaround' is gewijzigd. Vastleggen Vergelijk waarden van aangepaste velden of tags Gebeurtenistype inferred
	Toegewezen aan supportgroep	Het probleemrecord wordt toegewezen aan een specifiek technisch team of een specifieke afdeling. Dit wordt bijgehouden wanneer het veld Group ID van het ticket wordt bijgewerkt.
Waarom dit belangrijk is Essentieel voor het dashboard voor analyse van overdrachten tussen supportgroepen, waarmee wachttijden tussen afdelingen worden gemeten. Waar vind je dit? Controleer wijzigingen in het veld 'group_id' in het auditlog van het ticket. Vastleggen Geregistreerd wanneer de transactie Group Assignment Change is uitgevoerd Gebeurtenistype explicit
	Concept van voorgestelde oplossing opgesteld	Er wordt een kennisbankartikel gemaakt op basis van het probleemonderzoek. Dit wordt afgeleid uit het gebruik van de Zendesk Knowledge Capture-app of uit de koppeling van een nieuw artikel.
Waarom dit belangrijk is Ondersteunt de KPI voor het percentage oplossingen dat in de kennisbank wordt opgenomen en helpt kennis binnen de organisatie te delen. Waar vind je dit? Controleer gebeurtenissen rond de integratie 'Knowledge Capture' of tags zoals 'kcs_draft'. Vastleggen Leid dit af uit specifieke systeemtags of koppelingsgebeurtenissen Gebeurtenistype inferred
	Evaluatie na implementatie uitgevoerd	Bevestigt dat de oplossing achteraf is geëvalueerd. Meestal werkt de procescoördinator hiervoor een selectievakje of datumveld bij.
Waarom dit belangrijk is Vereist voor de KPI voor de frequentie van evaluaties na implementatie, zodat aan de kwaliteitsnormen wordt voldaan. Waar vind je dit? Controleer wijzigingen in het aangepaste selectievakje 'PIR Completed' of het datumveld 'PIR Date'. Vastleggen Controleer of het aangepaste veld is bijgewerkt om de afronding vast te leggen Gebeurtenistype inferred
	Probleemonderzoek heropend	Dit gebeurt wanneer een probleemrecord dat eerder als opgelost is gemarkeerd, weer de status Open of een andere actieve status krijgt. Dit kan wijzen op een mislukte fix of een afgewezen oplossing.
Waarom dit belangrijk is Ondersteunt de KPI voor het percentage heropende problemen en helpt kwaliteitsproblemen in het oplossingsproces te vinden. Waar vind je dit? Afgeleid wanneer de status verandert van 'Solved' terug naar 'Open', 'New' of 'Pending'. Vastleggen Vergelijk de status voor en na de wijziging Gebeurtenistype inferred
	Wijzigingsverzoek gestart	Dit geeft aan dat een formeel verandermanagementproces is gestart om het probleem op te lossen. Dit wordt vaak afgeleid wanneer een aangepast veld 'Change Request ID' wordt ingevuld of een ticket van het type 'Change' wordt gekoppeld.
Waarom dit belangrijk is Volgt het percentage gestarte wijzigingsverzoeken en koppelt probleembeheer aan workflows voor verandermanagement. Waar vind je dit? Controleer wijzigingen in een aangepast veld zoals 'change_reference' of het aanmaken van een koppeling van het type 'problem_change'. Vastleggen Controleer of een externe ID is ingevuld in het aangepaste veld Gebeurtenistype inferred

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data op uit Zendesk Support

Stappen

Log in bij je Zendesk-instantie en open via het productmenu de rapportageomgeving van Explore.
Klik op de map Queries (of Reports in nieuwere versies) en kies New query.
Kies bij het selecteren van een dataset achtereenvolgens Support, Updates History en Support: Updates History [default]. Deze dataset bevat de event logs die nodig zijn voor process mining, in tegenstelling tot data over alleen de huidige status.
Voeg in het deelvenster Metrics Count (Tickets) of Count (Updates) toe, zodat er data wordt opgehaald.
Voeg in het deelvenster Filters een filter toe voor Ticket > Ticket type en kies Problem. Zo beperk je de dataset tot het probleembeheerproces.
Voeg in het deelvenster Rows de volgende attributen in deze volgorde toe om de structuur van het event log vast te leggen: Ticket > Ticket ID, Time - Timestamp > Update - Timestamp, Updater > Updater name en Changes > Changes - Field name.
Maak voor de kolom Activity Name een Standard Calculated Attribute aan. Klik op het pictogram Calculation in de rechterzijbalk, kies Standard calculated attribute, geef het attribuut de naam Activity Mapper en plak de code uit het gedeelte Query hieronder.
Voeg het nieuwe attribuut Activity Mapper toe aan het deelvenster Rows. Filter dit attribuut zodat NULL-waarden worden uitgesloten en irrelevante systeemruis wordt verwijderd.
Voeg voor extra context de volgende attributen toe aan Rows: Ticket > Priority, Ticket > Group, Ticket > Status en eventuele aangepaste velden voor oorzaken- of categorieanalyse, zoals Ticket > Ticket tags of specifieke Custom Fields.
Stel de periode in het deelvenster Filters in met Time - Timestamp > Update - Date. Kies de gewenste analyseperiode, bijvoorbeeld Last 6 Months.
Klik op het pictogram Visualization type en kies Table. Zorg dat de tabel niet is gepivot of plat is als die optie beschikbaar is. Controleer anders of alle attributen in de sectie Rows staan.
Exporteer het resultaat via Export > CSV. Vink Keep attribute formatting aan om de timestampnotatie voor ProcessMind te behouden.

Configuratie

Dataset: Support: Updates History (Belangrijk: gebruik niet de standaarddataset Tickets, want die toont alleen de huidige status).
Tijdfilter: Update - Date (Aanbevolen: de afgelopen 90 tot 180 dagen, afhankelijk van het volume).
Tickettype: Filter uitsluitend op Problem om te voorkomen dat incidenten en serviceverzoeken worden meegenomen.
Rijlimiet: Zendesk Explore-exporten zijn vaak beperkt tot 50.000 rijen. Is je dataset groter, gebruik dan het filter Update - Date om de data in maandelijkse delen te exporteren en voeg die buiten Zendesk samen.
Aangepaste velden: Zoek in je Zendesk-instantie de specifieke Field ID’s op voor Root Cause, Change Request en Workaround. Dit zijn geen standaard systeemvelden.
Systeemrechten: Hiervoor is een Explore Viewer- of Explore Professional-licentie nodig.

a Voorbeeldquery config

IF ([Changes - Field name] = "status" AND [Changes - New value] = "New") THEN "Problem Record Logged"
ELIF ([Changes - Field name] = "group_id") THEN "Assigned to Support Group"
ELIF ([Changes - Field name] = "status" AND [Changes - Previous value] = "New" AND [Changes - New value] = "Open") THEN "Investigation Commenced"
ELIF ([Changes - Field name] = "tags" AND CONTAINS([Changes - New value], "workaround_available")) THEN "Workaround Published"
ELIF ([Changes - Field name] = "[Your Root Cause Field Name]") THEN "Root Cause Identified"
ELIF ([Changes - Field name] = "[Your Change Request ID Field Name]") OR ([Changes - Field name] = "type" AND [Changes - New value] = "change") THEN "Change Request Initiated"
ELIF ([Changes - Field name] = "tags" AND CONTAINS([Changes - New value], "fix_deployed")) THEN "Permanent Fix Applied"
ELIF ([Changes - Field name] = "[Your Knowledge Article Linked Field]") THEN "Proposed Solution Drafted"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "Solved") THEN "Resolution Verified"
ELIF ([Changes - Field name] = "status" AND [Changes - Previous value] = "Solved" AND [Changes - New value] = "Open") THEN "Problem Investigation Reopened"
ELIF ([Changes - Field name] = "[Your PIR Completed Checkbox Field]") THEN "Post-Implementation Review Conducted"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "Closed") THEN "Problem Record Closed"
ELSE NULL
ENDIF

Stappen

Controleer de vereisten: Controleer of de Zendesk Data Sharing-add-on voor je organisatie is ingeschakeld. Zorg dat je inloggegevens hebt voor alleen-lezen toegang tot de gerepliceerde Zendesk-database, die meestal op Snowflake of Amazon Redshift staat.
Maak verbinding met de database: Gebruik een SQL-client naar keuze, zoals DBeaver, DataGrip of de webinterface van Snowflake of Redshift, om met de opgegeven inloggegevens verbinding te maken met je Zendesk-datawarehouse.
Zoek de aangepaste velden op: Zoek voordat je de query uitvoert de unieke ID’s op van de aangepaste velden die in je probleembeheerproces worden gebruikt. Ga in Zendesk naar Admin Center > Objects and rules > Tickets > Fields. Zoek de velden ‘Root Cause’, ‘Change Request ID’, ‘Workaround Published’, ‘Permanent Fix Applied’ en ‘Post-Implementation Review’ op en noteer de bijbehorende Field ID’s. Vervang hiermee de placeholders in de query.
Bekijk de SQL-query: De query gebruikt een Common Table Expression (CTE) met de naam ProblemTickets om eerst alle probleemrecords te selecteren en te filteren. Dat maakt de query sneller en beter leesbaar. Daarna combineert UNION ALL de resultaten van 12 afzonderlijke SELECT-statements, één voor elke vereiste activiteit.
Pas de query aan: Open een nieuwe query-editor en plak het volledige SQL-script. Pas de placeholders in het script aan:
- Stel in de CTE ProblemTickets de gewenste periode in door '[YYYY-MM-DD]' te vervangen.
- Vervang voor elke activiteit die afhankelijk is van een aangepast veld de placeholder-ID’s, zoals [Your 'Root Cause Category' field_id] en [Your 'Change Request ID' field_id], door de werkelijke ID’s die je in stap 3 hebt opgezocht.
Voer de query uit: Voer het aangepaste SQL-script uit op de database. De uitvoeringstijd hangt af van de gekozen periode en de hoeveelheid ticketdata.
Controleer de logica voor ‘Proposed Solution Drafted’: De query gaat ervan uit dat een opgestelde oplossing wordt vastgelegd in een aangepast veld met de naam [Your 'KB Article ID' field_id]. Werkt je proces anders, bijvoorbeeld met een specifieke tag of opmerking, pas dit deel van de query dan aan.
Controleer de data: Bekijk de resultaten kort nadat de query is uitgevoerd. Controleer of het aantal rijen aannemelijk is, alle kolommen aanwezig zijn en er geen onverwachte NULL-waarden staan in belangrijke kolommen zoals ProblemRecordId en EventTimestamp.
Exporteer het event log: Exporteer de volledige resultatenset vanuit je SQL-client naar een CSV-bestand. Gebruik UTF-8-codering en controleer of de kolomkoppen overeenkomen met de attribuutnamen die je process mining-tool nodig heeft.
Bereid de upload voor: Controleer het CSV-bestand op opmaakproblemen voordat je het uploadt. Zorg dat datum- en tijdwaarden in de kolom EventTimestamp dezelfde notatie gebruiken, bijvoorbeeld YYYY-MM-DD HH24:MI:SS.

Configuratie

Vereisten: Voor deze extractie heb je de Zendesk Data Sharing-add-on en directe SQL-toegang nodig tot de gerepliceerde data in een Snowflake- of Amazon Redshift-instantie.
Filter op tickettype: De query is zo ingesteld dat alleen tickets met type 'problem' worden geanalyseerd. Zo blijft het probleembeheerproces gescheiden van incidenten en andere tickettypen.
Filter op periode: Filter de data bij voorkeur op een specifieke periode om de prestaties op peil te houden. In de eerste CTE staat de placeholder created_at >= '[YYYY-MM-DD]'. Voor een eerste analyse is een periode van 3 tot 6 maanden gebruikelijk.
Configuratie van aangepaste velden: Deze extractie is sterk afhankelijk van je Zendesk-configuratie. Zoek de juiste field_id op en vul die in voor aangepaste velden die activiteiten vastleggen, zoals ‘Root Cause Identified’, ‘Change Request Initiated’ en ‘Workaround Published’. Als je de placeholder-ID’s niet vervangt, mislukt de query of levert die voor deze activiteiten geen data op.
Vertraging in de data: De data in de gerepliceerde database is niet realtime. Er zit meestal een vertraging van enkele uren tussen een gebeurtenis in Zendesk en het moment waarop die in het datawarehouse verschijnt. Houd hier rekening mee bij analyses van recente activiteiten.

a Voorbeeldquery sql

WITH ProblemTickets AS (
  SELECT
    t.id,
    t.created_at,
    t.updated_at,
    t.priority,
    g.name AS group_name,
    u.name AS assignee_name,
    t.status,
    (SELECT COUNT(*) FROM problem_incident_links pil WHERE pil.problem_id = t.id) AS related_incident_count,
    t.due_at AS sla_due_date,
    cf_cat.value AS problem_category,
    cf_root.value AS root_cause_category
  FROM tickets t
  LEFT JOIN users u ON t.assignee_id = u.id
  LEFT JOIN groups g ON t.group_id = g.id
  LEFT JOIN custom_field_values cf_cat ON t.id = cf_cat.ticket_id AND cf_cat.custom_field_id = [Your 'Problem Category' field_id]
  LEFT JOIN custom_field_values cf_root ON t.id = cf_root.ticket_id AND cf_root.custom_field_id = [Your 'Root Cause Category' field_id]
  WHERE t.type = 'problem'
  AND t.created_at >= '[YYYY-MM-DD]' -- Set start date for the extraction
)
-- 1. Problem Record Logged
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Record Logged' AS "ActivityName",
  pt.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'new' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ProblemTickets pt

UNION ALL

-- 2. Assigned to Support Group
SELECT
  pt.id AS "ProblemRecordId",
  'Assigned to Support Group' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'group'

UNION ALL

-- 3. Investigation Commenced
SELECT
  pt.id AS "ProblemRecordId",
  'Investigation Commenced' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'open' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'open' AND tme.previous_value = 'new'

UNION ALL

-- 4. Workaround Published
SELECT
  pt.id AS "ProblemRecordId",
  'Workaround Published' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Workaround Published'' custom field name]' AND tme.value IS NOT NULL -- Example: checkbox being checked or field being filled

UNION ALL

-- 5. Root Cause Identified
SELECT
  pt.id AS "ProblemRecordId",
  'Root Cause Identified' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Root Cause Category'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 6. Change Request Initiated
SELECT
  pt.id AS "ProblemRecordId",
  'Change Request Initiated' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Change Request ID'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 7. Permanent Fix Applied
SELECT
  pt.id AS "ProblemRecordId",
  'Permanent Fix Applied' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Permanent Fix Applied'' custom field name]' AND tme.value IS NOT NULL -- Assumes a custom field indicates this status

UNION ALL

-- 8. Proposed Solution Drafted
SELECT
  pt.id AS "ProblemRecordId",
  'Proposed Solution Drafted' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''KB Article ID'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 9. Resolution Verified
SELECT
  pt.id AS "ProblemRecordId",
  'Resolution Verified' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'solved' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'solved'

UNION ALL

-- 10. Problem Investigation Reopened
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Investigation Reopened' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'open' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'open' AND tme.previous_value IN ('pending', 'solved')

UNION ALL

-- 11. Post-Implementation Review Conducted
SELECT
  pt.id AS "ProblemRecordId",
  'Post-Implementation Review Conducted' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Post-Implementation Review'' custom field name]' AND tme.value IS NOT NULL -- Assumes a checkbox or date field

UNION ALL

-- 12. Problem Record Closed
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Record Closed' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'closed' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'closed' AND tme.previous_value = 'solved';

Stappen

Vereisten: Zorg dat Python 3.6 of hoger op je systeem is geïnstalleerd. Installeer de benodigde bibliotheken requests en pandas door in je terminal of opdrachtprompt pip install requests pandas uit te voeren.
Maak een Zendesk API-token aan: Log als beheerder in bij Zendesk Support. Ga naar Admin Center > Apps and integrations > APIs > Zendesk API. Klik onder Token Access op ‘Add API token’ om een token aan te maken. Kopieer het token meteen en bewaar het veilig, want je kunt het later niet opnieuw bekijken.
Stel het Python-script in: Maak een Python-bestand aan, bijvoorbeeld extract_zendesk_problems.py, en kopieer het volledige script uit het gedeelte Query naar dit bestand. Werk de placeholdervariabelen bovenaan het script bij: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN en START_TIME. Stel START_TIME voor de eerste uitvoering in op de Unix-timestamp van de gewenste begindatum van de extractie.
Koppel de ID’s van aangepaste velden: Zoek de numerieke ID’s op van de aangepaste velden die in je probleembeheerproces worden gebruikt. Je vindt ze via Admin Center > Objects and rules > Tickets > Fields. Controleer de URL of de eigenschappen van het veld. Werk de dictionary CUSTOM_FIELD_MAPPING in het script bij met de juiste ID’s.
Voer het script uit: Start het script vanuit je terminal met de opdracht python extract_zendesk_problems.py. Het script haalt vervolgens data op via de Zendesk Incremental Export API.
Houd de uitvoering in de gaten: Het script toont de voortgang, waaronder het aantal verwerkte tickets en de timestamp die op dat moment wordt opgehaald. Het houdt automatisch rekening met API-limieten door zo nodig te pauzeren.
Data ophalen en omzetten: Eerst haalt het script alle probleemtickets op die sinds START_TIME zijn aangemaakt of bijgewerkt. Daarna haalt het voor elk probleemticket het volledige auditspoor op, met daarin alle historische wijzigingen.
Het event log samenstellen: Het script verwerkt elke auditgebeurtenis en koppelt veldwijzigingen, zoals status, groep of aangepaste velden, aan de vastgelegde bedrijfsactiviteiten. Ook haalt het script gebruikers- en groepsnamen op en slaat die tijdelijk op om de data aan te vullen.
Incrementele ladingen verwerken: Werk na de eerste volledige lading bij volgende uitvoeringen de variabele START_TIME bij met de end_time die aan het einde van de vorige geslaagde uitvoering is weergegeven. Zo haal je alleen nieuwe en bijgewerkte data op, zonder duplicaten.
Controleer het resultaat: Na afloop maakt het script in dezelfde map het bestand zendesk_problem_event_log.csv aan. Dit CSV-bestand bevat het gestructureerde event log dat klaar is voor analyse.
Bereid de upload voor: Open het CSV-bestand in een spreadsheetprogramma en controleer de inhoud. Controleer vóór het uploaden naar ProcessMind of alle vereiste kolommen (ProblemRecordId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate) aanwezig en correct ingevuld zijn.

Configuratie

Zendesk API-inloggegevens: Voor authenticatie heeft het script je Zendesk-subdomein nodig, het e-mailadres van de gebruiker bij het API-token en het API-token zelf.
Starttijd: De variabele START_TIME is een Unix-epochtimestamp die het beginpunt van de data-extractie bepaalt. Stel deze bij de eerste uitvoering in op een datum in het verleden, bijvoorbeeld zes maanden geleden, om historische data op te halen. Gebruik bij volgende uitvoeringen de eindtijd van de vorige uitvoering om incrementeel data op te halen.
Koppeling van aangepaste velden: De dictionary CUSTOM_FIELD_MAPPING is essentieel. Vervang de placeholder-ID’s door de werkelijke ID’s van de aangepaste velden in je Zendesk-instantie. Zo worden activiteiten als ‘Workaround Published’ en ‘Root Cause Identified’ correct vastgelegd.
Filter op tickettype: Het script verwerkt alleen tickets met type 'problem'. Incidenten, taken en vragen komen daardoor niet in het event log voor probleembeheer terecht.
API-limieten: Het script gebruikt de eenvoudige functie time.sleep(60) om fouten 429 ‘Too Many Requests’ af te handelen. Afhankelijk van je Zendesk-abonnement en de hoeveelheid data moet je deze pauzeduur mogelijk aanpassen.
Vereisten: Voor het script heb je een Python 3-omgeving met de bibliotheken requests en pandas nodig. Het API-token moet gekoppeld zijn aan een account met leesrechten voor ticketdata.

a Voorbeeldquery python

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

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk subdomain, email, and API token
ZENDESK_SUBDOMAIN = class="hl-string">'[your_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_email@example.com]'
ZENDESK_API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1641013200 is for Jan 1, 2022 00:00:00 GMT
START_TIME = 1641013200

class=class="hl-string">"hl-comment"># Map your custom field IDs to the corresponding activity names
class=class="hl-string">"hl-comment"># Find IDs in Admin Center > Objects and rules > Tickets > Fields
CUSTOM_FIELD_MAPPING = {
    class="hl-string">'[Your Workaround Published Field ID]': class="hl-string">'Workaround Published',
    class="hl-string">'[Your Root Cause Identified Field ID]': class="hl-string">'Root Cause Identified',
    class="hl-string">'[Your Change Request Initiated Field ID]': class="hl-string">'Change Request Initiated',
    class="hl-string">'[Your Permanent Fix Applied Field ID]': class="hl-string">'Permanent Fix Applied',
    class="hl-string">'[Your Proposed Solution Drafted Field ID]': class="hl-string">'Proposed Solution Drafted',
    class="hl-string">'[Your Post-Implementation Review Field ID]': class="hl-string">'Post-Implementation Review Conducted'
}

class=class="hl-string">"hl-comment"># --- SCRIPT --- 
BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
API_USER = fclass="hl-string">'{ZENDESK_EMAIL}/token'

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

session = requests.Session()
session.auth = (API_USER, ZENDESK_API_TOKEN)

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 str(user_id) class=class="hl-string">"hl-comment"># Return ID if lookup fails

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 str(group_id) class=class="hl-string">"hl-comment"># Return ID if lookup fails

def fetch_tickets(start_time):
    tickets_url = fclass="hl-string">'{BASE_URL}/incremental/tickets.json'
    params = {class="hl-string">'start_time': start_time, class="hl-string">'include': class="hl-string">'metric_sets'}
    all_tickets = []
    while tickets_url:
        try:
            print(fclass="hl-string">"Fetching from: {tickets_url}")
            response = session.get(tickets_url, params=params)
            class=class="hl-string">"hl-comment"># params are only needed for the first request
            params = {}
            if response.status_code == 429:
                print(class="hl-string">"Rate limit reached. Waiting for 60 seconds.")
                time.sleep(60)
                continue
            response.raise_for_status()
            data = response.json()
            all_tickets.extend(data.get(class="hl-string">'tickets', []))
            tickets_url = data.get(class="hl-string">'next_page')
            if not data.get(class="hl-string">'end_of_stream', True):
                 class=class="hl-string">"hl-comment"># Wait a moment before the next page request to be safe
                 time.sleep(1)
            else:
                print(fclass="hl-string">"End of stream reached. Final timestamp: {data.get('end_time')}")
                tickets_url = None
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching tickets: {e}")
            break
    return all_tickets

def process_ticket_audits(ticket, event_log):
    ticket_id = ticket[class="hl-string">'id']
    audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
    try:
        response = session.get(audits_url)
        response.raise_for_status()
        audits = response.json().get(class="hl-string">'audits', [])
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching audits for ticket {ticket_id}: {e}")
        return

    base_attributes = {
        class="hl-string">'ProblemRecordId': ticket_id,
        class="hl-string">'SourceSystem': class="hl-string">'Zendesk Support',
        class="hl-string">'LastDataUpdate': ticket[class="hl-string">'updated_at'],
        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'RelatedIncidentCount': ticket.get(class="hl-string">'metric_set', {}).get(class="hl-string">'replies', 0), class=class="hl-string">"hl-comment"># Using replies as a proxy if incident_count is not available
        class="hl-string">'SlaDueDate': ticket.get(class="hl-string">'due_at'),
        class="hl-string">'ProblemCategory': next((f[class="hl-string">'value'] for f in ticket.get(class="hl-string">'custom_fields', []) if f.get(class="hl-string">'id') == class="hl-string">'[Your Problem Category Field ID]'), None)
    }

    class=class="hl-string">"hl-comment"># 1. Problem Record Logged
    event_log.append({
        **base_attributes,
        class="hl-string">'ActivityName': class="hl-string">'Problem Record Logged',
        class="hl-string">'EventTimestamp': ticket[class="hl-string">'created_at'],
        class="hl-string">'SupportGroup': get_group_name(ticket.get(class="hl-string">'group_id')),
        class="hl-string">'AssigneeName': get_user_name(ticket.get(class="hl-string">'assignee_id')),
        class="hl-string">'ProblemStatus': class="hl-string">'new',
        class="hl-string">'RootCauseCategory': None
    })

    class=class="hl-string">"hl-comment"># Process audit trail for other activities
    for audit in audits:
        audit_ts = audit[class="hl-string">'created_at']
        for event in audit.get(class="hl-string">'events', []):
            activity_name = None
            field_name = event.get(class="hl-string">'field_name')
            value = event.get(class="hl-string">'value')
            previous_value = event.get(class="hl-string">'previous_value')

            class=class="hl-string">"hl-comment"># 2. Assigned to Support Group
            if field_name == class="hl-string">'group_id' and value is not None:
                activity_name = class="hl-string">'Assigned to Support Group'
            
            class=class="hl-string">"hl-comment"># 3. Investigation Commenced (New -> Open)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'open' and previous_value == class="hl-string">'new':
                activity_name = class="hl-string">'Investigation Commenced'

            class=class="hl-string">"hl-comment"># 4-9. Activities from Custom Fields
            elif str(field_name) in CUSTOM_FIELD_MAPPING and value is not None and value not in [False, class="hl-string">'0', class="hl-string">'']:
                activity_name = CUSTOM_FIELD_MAPPING[str(field_name)]

            class=class="hl-string">"hl-comment"># 10. Resolution Verified (Any -> Solved)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'solved':
                activity_name = class="hl-string">'Resolution Verified'
            
            class=class="hl-string">"hl-comment"># 11. Problem Investigation Reopened (Solved/Closed -> Open)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'open' and previous_value in [class="hl-string">'solved', class="hl-string">'closed']:
                activity_name = class="hl-string">'Problem Investigation Reopened'

            class=class="hl-string">"hl-comment"># 12. Problem Record Closed (Any -> Closed)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'closed':
                activity_name = class="hl-string">'Problem Record Closed'

            if activity_name:
                class=class="hl-string">"hl-comment"># Find the state of attributes at the time of the event
                temp_status = value if field_name == class="hl-string">'status' else None
                temp_group = get_group_name(value) if field_name == class="hl-string">'group_id' else None
                temp_assignee = get_user_name(value) if field_name == class="hl-string">'assignee_id' else None
                temp_root_cause = value if str(field_name) == class="hl-string">'[Your Root Cause Category Field ID]' else None

                event_log.append({
                    **base_attributes,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTimestamp': audit_ts,
                    class="hl-string">'SupportGroup': temp_group,
                    class="hl-string">'AssigneeName': temp_assignee,
                    class="hl-string">'ProblemStatus': temp_status,
                    class="hl-string">'RootCauseCategory': temp_root_cause
                })

def main():
    print(class="hl-string">"Starting Zendesk Problem ticket extraction...")
    tickets = fetch_tickets(START_TIME)
    problem_tickets = [t for t in tickets if t.get(class="hl-string">'type') == class="hl-string">'problem']
    print(fclass="hl-string">"Found {len(problem_tickets)} problem tickets to process.")

    event_log_data = []
    for i, ticket in enumerate(problem_tickets):
        print(fclass="hl-string">"Processing ticket {i+1}/{len(problem_tickets)}: ID {ticket['id']}")
        process_ticket_audits(ticket, event_log_data)

    if not event_log_data:
        print(class="hl-string">"No events were generated. Exiting.")
        return

    df = pd.DataFrame(event_log_data)

    class=class="hl-string">"hl-comment"># Post-processing to fill forward null values for state attributes
    df = df.sort_values(by=[class="hl-string">'ProblemRecordId', class="hl-string">'EventTimestamp']).reset_index(drop=True)
    df[class="hl-string">'SupportGroup'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'SupportGroup'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'AssigneeName'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'AssigneeName'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'ProblemStatus'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'ProblemStatus'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'RootCauseCategory'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'RootCauseCategory'].fillna(method=class="hl-string">'ffill')

    class=class="hl-string">"hl-comment"># Define column order
    column_order = [
        class="hl-string">'ProblemRecordId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'Priority', class="hl-string">'SupportGroup', class="hl-string">'AssigneeName', class="hl-string">'ProblemStatus', class="hl-string">'RelatedIncidentCount',
        class="hl-string">'SlaDueDate', class="hl-string">'ProblemCategory', class="hl-string">'RootCauseCategory'
    ]
    df = df[column_order]

    output_filename = class="hl-string">'zendesk_problem_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">"Extraction complete. Event log saved to {output_filename}")

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

Klaar om aan de slag te gaan?

Verbeter de stabiliteit van je IT door deze template vandaag nog toe te passen op je Zendesk-omgeving. Ons team helpt je graag bij het verfijnen van de data-extractie en het starten met process mining.

Terug naar de verbetergids Template downloaden

Verbeter probleembeheer voor snellere IT-oplossingen

Verkort de doorlooptijd van oplossingen met 30 procent en pak IT-bottlenecks aan.

Start je gratis proefperiode

Geen creditcard nodig. Binnen enkele minuten ingesteld.

Datatemplate voor probleembeheer

Datatemplate voor probleembeheer

Attributen voor probleembeheer

Activiteiten voor probleembeheer

Extractiegidsen

Zendesk Explore: export van de updategeschiedenis

Stappen

Configuratie

a Voorbeeldquery config

SQL-query via Zendesk Data Sharing

Stappen

Configuratie

a Voorbeeldquery sql

Python-extractie met de Incremental Export API

Stappen

Configuratie

a Voorbeeldquery python

Klaar om aan de slag te gaan?

Verbeter probleembeheer voor snellere IT-oplossingen

Datatemplate voor probleembeheer

Datatemplate voor probleembeheer

Attributen voor probleembeheer

Activiteiten voor probleembeheer

Extractiegidsen

Zendesk Explore: export van de updategeschiedenis

Stappen

Configuratie

a Voorbeeldquery config

SQL-query via Zendesk Data Sharing

Stappen

Configuratie

a Voorbeeldquery sql

Python-extractie met de Incremental Export API

Stappen

Configuratie

a Voorbeeldquery python

Klaar om aan de slag te gaan?

Verbeter probleembeheer voor snellere IT-oplossingen

We gaan zorgvuldig om met je privacy