Datatemplate voor klantenservice

Microsoft Dynamics 365 Customer Service
Datatemplate voor klantenservice

Datatemplate voor klantenservice

Deze template biedt een vaste aanpak voor het verzamelen van de data die nodig is om het klantenserviceproces grondig te analyseren. Je vindt erin welke attributen je verzamelt, welke activiteiten je bijhoudt en hoe je deze informatie kunt ophalen.
  • Aanbevolen attributen om te verzamelen
  • Belangrijke activiteiten om bij te houden
  • Instructies voor data-extractie uit Microsoft Dynamics 365 Customer Service

Attributen voor klantenservice

Dit zijn de aanbevolen datavelden voor het event log, zodat je het klantenserviceproces volledig kunt analyseren.
5 Verplicht 7 Aanbevolen 8 Optioneel
Naam Beschrijving
Serviceverzoek
ServiceRequest
De unieke identificatiecode van een serviceverzoek, ook wel case of ticket genoemd.
Beschrijving

Het serviceverzoek is de belangrijkste identificatiecode die alle activiteiten rond één klantvraag of probleem met elkaar verbindt. Bij process mining fungeert het als Case-ID, zodat je elke klantinteractie van aanmaak tot afsluiting volledig en consistent kunt volgen. Door serviceverzoeken te analyseren, kun je het volledige procesverloop volgen, afhandeltijden meten en patronen in vergelijkbare cases herkennen.

Waarom dit belangrijk is

Dit is de belangrijkste Case-ID die alle bijbehorende events aan één procesinstantie koppelt. Zo wordt end-to-end procesanalyse mogelijk.

Waar vind je dit?

Dit is de primaire sleutel van de Case-entiteit (incident) in Microsoft Dynamics 365 Customer Service.

Voorbeelden
CAS-01024-F3B4V6SR-2023-00589TKT-4815162342
Activiteit
ActivityName
De naam van een specifieke bedrijfsgebeurtenis die op een bepaald moment plaatsvond voor een serviceverzoek.
Beschrijving

Dit attribuut beschrijft één stap of statuswijziging in het klantenserviceproces, zoals 'Case aangemaakt', 'Medewerker onderzoekt probleem' of 'Case opgelost'. Deze activiteiten vormen de basis van de proceskaart en maken het mogelijk het procesverloop zichtbaar te maken en te analyseren. Elke activiteit vormt samen met een timestamp een event dat de procesvolgorde bepaalt.

Waarom dit belangrijk is

Activiteiten beschrijven de stappen in het proces. Door de volgorde en frequentie ervan te analyseren, krijg je inzicht in het procesverloop, afwijkingen en bottlenecks.

Waar vind je dit?

Meestal afgeleid door statuswijzigingen (statuscode) of specifieke events uit gekoppelde entiteiten, zoals Tasks, Emails of Phone Calls, om te zetten naar een gestandaardiseerde activiteitsnaam.

Voorbeelden
Case aangemaaktMedewerker onderzoekt probleemOplossing voorgesteld aan klantCase gesloten
Bronsysteem
SourceSystem
Geeft aan uit welk systeem de data is gehaald.
Beschrijving

Dit attribuut geeft aan waar de eventdata vandaan komt. Voor dit proces is dat steeds Microsoft Dynamics 365 Customer Service. In omgevingen met meerdere systemen is dit veld belangrijk om databronnen van elkaar te onderscheiden en de herkomst van data te kunnen volgen.

Waarom dit belangrijk is

Maakt de herkomst van data duidelijk. Dat is belangrijk voor datagovernance en het oplossen van inconsistenties, vooral bij analyses waarin data uit meerdere systemen wordt gecombineerd.

Waar vind je dit?

Dit is meestal een vaste waarde die tijdens de data-extractie en -transformatie wordt toegevoegd om de herkomst van de dataset aan te geven.

Voorbeelden
Microsoft Dynamics 365 Customer Service
Laatste data-update
LastDataUpdate
De timestamp van de laatste data-update of -extractie uit het bronsysteem.
Beschrijving

Dit attribuut geeft aan wanneer de data voor het laatst uit Microsoft Dynamics 365 is opgehaald. Zo zie je hoe actueel de geanalyseerde data is. Dit is belangrijk voor rapportages en monitoring, zodat gebruikers bij dashboards en analyses weten hoe recent de data is.

Waarom dit belangrijk is

Laat zien hoe recent de data is. Zo kunnen gebruikers op tijd en op basis van actuele informatie beslissingen nemen over de bedrijfsvoering.

Waar vind je dit?

Deze waarde wordt gegenereerd en aan de dataset toegevoegd tijdens de data-extractie.

Voorbeelden
2023-10-27T08:00:00Z
Starttijd
EventTime
De timestamp die aangeeft wanneer de activiteit plaatsvond.
Beschrijving

Dit attribuut registreert de exacte datum en tijd waarop een activiteit plaatsvond. Het is nodig om events in de juiste volgorde te zetten en voor alle tijdsanalyses, zoals het berekenen van doorlooptijden, tijdsduur en wachttijden tussen activiteiten. Een nauwkeurige en consistente timestamp is belangrijk voor betrouwbare process mining-analyses.

Waarom dit belangrijk is

Deze timestamp zet events in chronologische volgorde en maakt berekeningen van tijdsduur mogelijk. Die zijn nodig om prestaties te analyseren en bottlenecks op te sporen.

Waar vind je dit?

Dit komt overeen met velden zoals 'createdon' of 'modifiedon' van de Case-entiteit (incident) of gekoppelde activiteitsentiteiten, zoals Email, Task of Phone Call.

Voorbeelden
2023-04-15T10:00:00Z2023-05-20T14:35:10Z2023-06-01T09:12:45Z
Kanaal
Channel
Het communicatiekanaal waarlangs het serviceverzoek is ingediend.
Beschrijving

Dit attribuut geeft aan waar het klantcontact begon, bijvoorbeeld via Telefoon, E-mail, een webportaal of chat. Elk kanaal heeft vaak een eigen procesverloop, klantverwachtingen en complexiteit bij de afhandeling. Door het proces per kanaal te analyseren, kun je de workflows en inzet van medewerkers per kanaal verbeteren.

Waarom dit belangrijk is

Laat zien welk effect verschillende klantcontactkanalen hebben op de procesefficiëntie, afhandeltijd en klanttevredenheid.

Waar vind je dit?

Komt overeen met het veld 'Case Origin' (caseorigincode) van de Case-entiteit (incident).

Voorbeelden
TelefoonE-mailWebChat
Klantnaam
CustomerName
De naam van de klant of account die bij het serviceverzoek hoort.
Beschrijving

Dit attribuut geeft aan welke klant het serviceverzoek heeft ingediend. Zo kun je het proces vanuit het perspectief van de klant analyseren en zien welke klanten de meeste verzoeken indienen, het langst op een oplossing wachten of de meest complexe problemen hebben. Dit helpt bij het beheren van klantrelaties en het verbeteren van de dienstverlening per klant.

Waarom dit belangrijk is

Maakt analyse per klant mogelijk, zodat je patronen kunt herkennen, belangrijke accounts beter kunt helpen en de klantreis kunt begrijpen.

Waar vind je dit?

Dit is het opzoekveld 'Customer' (customerid) van de Case-entiteit (incident). Het kan verwijzen naar een Account- of Contact-record.

Voorbeelden
Global Tech Inc.Jane DoeInnovate Solutions
Naam medewerker
AgentName
De naam van de klantenservicemedewerker of gebruiker die verantwoordelijk is voor de activiteit.
Beschrijving

Dit attribuut geeft aan welke medewerker of systeemgebruiker een activiteit heeft uitgevoerd, bijvoorbeeld een item uit een wachtrij pakken of een case oplossen. Het is belangrijk om prestaties, werkverdeling en de inzet van medewerkers te analyseren. Door activiteiten per medewerker te volgen, kunnen organisaties zien wie goed presteert, waar training nodig is en waar de werkdruk ongelijk verdeeld is.

Waarom dit belangrijk is

Maakt het mogelijk om individuele en teamprestaties te analyseren, de werkdruk beter te verdelen en mogelijkheden voor coaching te vinden om de servicekwaliteit te verbeteren.

Waar vind je dit?

Komt overeen met het veld 'Owner' (ownerid) van de Case-entiteit (incident), dat is gekoppeld aan de entiteit System User (systemuser).

Voorbeelden
Alice SmithBob JohnsonSysteem
Prioriteit
Priority
De prioriteit van het serviceverzoek, die aangeeft hoe dringend het is.
Beschrijving

Dit attribuut geeft aan hoe dringend een serviceverzoek is. De gebruikelijke categorieën zijn Laag, Normaal, Hoog en Urgent. De prioriteit bepaalt in welke volgorde cases worden behandeld en is vaak bepalend voor de SLA-targets. Door te analyseren hoe prioriteit het procesverloop, de inzet van medewerkers en de afhandeltijden beïnvloedt, zie je of urgente problemen op tijd worden opgepakt.

Waarom dit belangrijk is

Helpt te bepalen of verzoeken met hoge prioriteit sneller worden afgehandeld en hun targets halen, en welk effect prioriteitsniveaus hebben op de prestaties van het proces.

Waar vind je dit?

Komt overeen met het veld 'Priority' (prioritycode) van de Case-entiteit (incident).

Voorbeelden
LaagNormaalHoog
SLA-target voor afhandeltijd
SlaTargetResolutionTime
De contractueel afgesproken tijd waarbinnen het serviceverzoek moet zijn afgehandeld.
Beschrijving

Dit attribuut geeft aan binnen welke tijd een serviceverzoek volgens de actieve Service Level Agreement (SLA) moet zijn afgehandeld. Het is de norm waarmee je de werkelijke prestaties vergelijkt. Deze waarde is belangrijk voor het dashboard voor SLA-naleving en voor het berekenen van de KPI voor het SLA-nalevingspercentage. Zo zie je waar het proces de serviceafspraken niet haalt.

Waarom dit belangrijk is

Dit is de belangrijkste norm om de serviceprestaties met de afspraken te vergelijken. Hiermee kun je de SLA-naleving en overschrijdingen analyseren.

Waar vind je dit?

Deze waarde wordt bepaald door de SLA-configuratie in Dynamics 365 en via SLA KPI Instances aan een case gekoppeld.

Voorbeelden
2592008640014400
Statusreden
StatusReason
Geeft een specifiekere reden voor de huidige status van het serviceverzoek.
Beschrijving

Een case heeft een algemene status, zoals 'Active' of 'Resolved'. De statusreden geeft meer context, bijvoorbeeld 'Information Provided' of 'Problem Solved'. Dit attribuut helpt te begrijpen hoe en waarom cases tijdens hun levenscyclus veranderen. Zo kun je onderscheid maken tussen cases die succesvol zijn opgelost en cases die door de klant zijn geannuleerd. Dat is belangrijk voor een nauwkeurige uitkomstanalyse.

Waarom dit belangrijk is

Geeft meer inzicht in de uitkomst van een case en de redenen voor statuswijzigingen. Zo kun je oplossingsroutes en oorzaken nauwkeuriger analyseren.

Waar vind je dit?

Komt overeen met het veld 'Status Reason' (statuscode) van de Case-entiteit (incident).

Voorbeelden
In behandelingIn de wachtProbleem opgelostInformatie verstrekt
Type serviceverzoek
ServiceRequestType
De belangrijkste categorie of classificatie van het serviceverzoek.
Beschrijving

Dit attribuut deelt serviceverzoeken in op basis van hun aard, bijvoorbeeld 'Factuurvraag', 'Technische ondersteuning' of 'Productfeedback'. Zo kun je de procesanalyse opdelen en zien hoe verschillende soorten verzoeken worden afgehandeld. Uit de analyse per type kan bijvoorbeeld blijken dat bepaalde categorieën langer duren, vaker worden geëscaleerd of een ander procesverloop volgen.

Waarom dit belangrijk is

Maakt het mogelijk het proces per type te analyseren en specifieke bottlenecks, benodigde bronnen en verbeterkansen te vinden. Dit helpt bij het bepalen van een betere routering en afhandeling.

Waar vind je dit?

Deze informatie staat vaak in het veld 'Subject' (subjectid) of in een aangepast categorisatieveld van de Case-entiteit (incident).

Voorbeelden
FactuurvraagTechnische ondersteuningProductfeedbackAccountbeheer
Betrokken product
ProductInvolved
Het product dat bij het serviceverzoek van de klant hoort.
Beschrijving

Dit attribuut geeft aan op welk product of welke dienst het probleem van de klant betrekking heeft. Zo kun je het serviceproces per product analyseren. Dat maakt zichtbaar of bepaalde producten meer supportverzoeken opleveren, complexere problemen hebben of specifieke vaardigheden van medewerkers vereisen. Deze analyse helpt bij productverbetering en het plannen van capaciteit.

Waarom dit belangrijk is

Maakt procesanalyse per product mogelijk. Zo kun je terugkerende productproblemen opsporen, supportdocumentatie verbeteren en experts gericht inzetten.

Waar vind je dit?

Dit komt overeen met het opzoekveld 'Product' (productid) op de entiteit Case (incident).

Voorbeelden
Alpha-100-printerZeta CRM-softwareOmega-databundel
CSAT-score
CustomerSatisfactionScore
De tevredenheidsscore die de klant geeft nadat de case is opgelost.
Beschrijving

Dit attribuut bevat de numerieke of categorische beoordeling uit een klanttevredenheidsonderzoek (CSAT), meestal afgenomen nadat een serviceverzoek is gesloten. Het meet rechtstreeks hoe de klant de servicekwaliteit ervaart. Deze data is belangrijk voor het dashboard Trends in klanttevredenheid en de KPI Gemiddelde CSAT-score na oplossing. Zo kun je procesprestaties koppelen aan klantresultaten.

Waarom dit belangrijk is

Meet de klanttevredenheid rechtstreeks. Zo kan de organisatie procesgedrag vergelijken met de ervaringen van klanten en verbeteringen doorvoeren.

Waar vind je dit?

Deze data komt meestal uit een gekoppelde enquête-entiteit, zoals Customer Voice, en is gekoppeld aan de entiteit Case (incident).

Voorbeelden
5341
Herstelwerk
IsRework
Een berekende vlag die aangeeft of er herstelwerk aan een case is uitgevoerd.
Beschrijving

Deze booleaanse vlag geeft aan welke cases herstelrondes of herhaalde activiteiten bevatten, zoals meerdere gebeurtenissen 'Informatie opgevraagd bij klant' of een gebeurtenis 'Case opnieuw geactiveerd' nadat de case was opgelost. De vlag wordt berekend door de activiteitenvolgorde te analyseren op patronen die wijzen op inefficiëntie of een probleem dat niet meteen goed is opgelost. Dit attribuut is belangrijk voor het dashboard Analyse van herstelwerk en herhaald contact.

Waarom dit belangrijk is

Helpt inefficiënties in processen te meten en af te bakenen. Zo kunnen analisten zich richten op de oorzaken van herhaald werk en verspilde inspanning.

Waar vind je dit?

Berekend door specifieke activiteitenreeksen (bijvoorbeeld Opgelost -> Opnieuw geactiveerd) of herhaalde activiteiten binnen een case te herkennen met process mining-analyses.

Voorbeelden
truefalse
ID van kennisartikel
KnowledgeArticleId
De identificatiecode van een kennisbankartikel dat aan het serviceverzoek is gekoppeld.
Beschrijving

Dit attribuut bevat de ID van een kennisartikel dat is gebruikt of gekoppeld bij het oplossen van een serviceverzoek. Het laat zien hoe goed medewerkers de kennisbank gebruiken om klantproblemen op te lossen. Deze data is belangrijk voor het dashboard Gebruik van kennisartikelen en de bijbehorende KPI. Zo kun je de waarde en volledigheid van de kennisbank beoordelen.

Waarom dit belangrijk is

Houdt het gebruik van de kennisbank bij. Zo zie je of medewerkers beschikbare bronnen gebruiken om problemen sneller en consistenter op te lossen.

Waar vind je dit?

Deze informatie staat in de relatie tussen de entiteiten Case (incident) en Knowledge Article (knowledgearticle).

Voorbeelden
KA-01337KA-02048
Is geëscaleerd
IsEscalated
Een vlag die aangeeft of het serviceverzoek is geëscaleerd.
Beschrijving

Dit booleaanse attribuut geeft aan of een serviceverzoek is geëscaleerd. Een escalatie vindt plaats wanneer de eerstelijnssupport een probleem niet kan oplossen en hulp nodig is van een senior team of specialist. Deze vlag is nodig voor het dashboard Interne escalatieroutes en de KPI Interne escalatiegraad. Zo zie je wat escalaties veroorzaakt en waar de eerste supportlagen tekortschieten.

Waarom dit belangrijk is

Meet hoe vaak escalaties voorkomen. Zo worden problemen met het oplossen bij het eerste contact zichtbaar en zie je waar processen of vaardigheden van medewerkers verbetering nodig hebben.

Waar vind je dit?

Dit komt overeen met het veld 'Is Escalated' (isescalated) op de entiteit Case (incident).

Voorbeelden
truefalse
Opgelost bij eerste contact
IsFirstContactResolution
Een vlag die aangeeft of het verzoek tijdens het eerste contact is opgelost.
Beschrijving

Dit berekende attribuut geeft aan welke serviceverzoeken zijn opgelost zonder vervolgcontact met de klant of grote vertragingen waarvoor een andere medewerker nodig was. De precieze logica kan ingewikkeld zijn, maar kijkt meestal naar een korte doorlooptijd en de afwezigheid van heropeningen of klantvragen na het eerste contact. Dit attribuut vormt de basis voor de KPI Oplossingspercentage bij eerste contact.

Waarom dit belangrijk is

Dit is een belangrijke maatstaf voor service-efficiëntie en klanttevredenheid. De score laat zien of problemen snel en volledig worden opgelost.

Waar vind je dit?

Berekend op basis van de volgorde en tijdstippen van activiteiten in het event log van elke case.

Voorbeelden
truefalse
SLA overschreden
IsSlaBreached
Een berekende vlag die aangeeft of het serviceverzoek de SLA-doelstelling heeft overschreden.
Beschrijving

Deze booleaanse vlag wordt bepaald door de werkelijke oplostijd van een serviceverzoek te vergelijken met de 'SLA Target Resolution Time'. De vlag krijgt de waarde true als de werkelijke tijd langer is dan de doeltijd. Dit attribuut is nodig voor het dashboard SLA-naleving en voor de berekening van de KPI SLA-nalevingspercentage. Per case geeft het een duidelijke uitkomst voor de SLA-prestaties.

Waarom dit belangrijk is

Geeft per case duidelijk aan of de SLA is gehaald. Zo kun je overschrijdingen eenvoudig filteren, optellen en analyseren om de oorzaken te vinden.

Waar vind je dit?

Berekend door 'ServiceRequestCycleTime' te vergelijken met 'SlaTargetResolutionTime'.

Voorbeelden
truefalse
Verantwoordelijk team
OwnerTeam
Het team dat op dit moment verantwoordelijk is voor het serviceverzoek.
Beschrijving

Dit attribuut geeft aan welk team verantwoordelijk is voor het serviceverzoek. Een verzoek kan eigendom zijn van een individuele medewerker of een team (wachtrij). Analyse per team is belangrijk om te zien hoe teams presteren, hoe het werk is verdeeld over supportlagen en specialisaties, en waar processen tussen teams verschillen.

Waarom dit belangrijk is

Maakt prestatieanalyse per team mogelijk. Dat is belangrijk om supportlagen en gespecialiseerde teams goed aan te sturen.

Waar vind je dit?

Afgeleid van het veld 'Owner' (ownerid) op de entiteit Case (incident), wanneer de eigenaar een Team-record is en geen System User.

Voorbeelden
EerstelijnssupportFacturatieafdelingTechnische specialisten
Verplicht Aanbevolen Optioneel

Klantenserviceactiviteiten

Dit zijn de belangrijkste processtappen en mijlpalen voor het event log. Ze helpen je de klantenservice nauwkeurig in kaart te brengen en te verbeteren.
6 Aanbevolen 7 Optioneel
Activiteit Beschrijving
Case aangemaakt
Deze activiteit markeert het begin van het klantenserviceproces: er wordt een nieuwe caserecord aangemaakt in het systeem. Dit expliciete event wordt vastgelegd met een specifieke timestamp wanneer de record van de entiteit 'Incident' voor het eerst wordt opgeslagen.
Waarom dit belangrijk is

Als belangrijkste startevent is deze activiteit nodig om de totale levenscyclus van een case te berekenen en trends in het aantal cases te begrijpen. De activiteit vormt het uitgangspunt voor alle volgende procesanalyses.

Waar vind je dit?

Dit event wordt voor elke nieuwe record vastgelegd aan de hand van de timestamp 'createdon' van de entiteit 'Incident' (Case).

Vastleggen

Gebruik de timestamp 'createdon' van de Incident-record.

Gebeurtenistype explicit
Case geëscaleerd
Geeft aan dat een case formeel is geëscaleerd naar een hoger supportniveau of een ander team. Dit kan een expliciete gebruikersactie zijn waarbij de case wordt toegewezen aan een aangewezen escalatiewachtrij of gebruiker.
Waarom dit belangrijk is

Door escalaties te volgen, kun je de KPI 'Internal Escalation Rate' meten en de oorzaken opsporen van problemen die de eerstelijnssupport niet kan oplossen. Dit maakt zwakke plekken in het proces en mogelijkheden voor training zichtbaar.

Waar vind je dit?

Af te leiden uit een wijziging van het veld 'ownerid' naar een aangewezen escalatiewachtrij of team. Het kan ook gaan om een expliciete aangepaste actie die de case als geëscaleerd markeert.

Vastleggen

Zoek een wijziging met timestamp waarbij 'ownerid' wordt gewijzigd naar een bekende escalatiewachtrij.

Gebeurtenistype inferred
Case gesloten
Dit is de definitieve administratieve afsluiting van de caserecord. Die kan tegelijk met de oplossing plaatsvinden of later. De activiteit wordt vastgelegd wanneer de status van de case verandert naar 'Closed'.
Waarom dit belangrijk is

Dit markeert het absolute einde van de levenscyclus van het proces in het systeem. De tijd tussen 'Resolved' en 'Closed' kan wijzen op administratieve handelingen of vertraging bij het afronden van records.

Waar vind je dit?

Dit wordt vastgelegd wanneer het veld 'statecode' van de entiteit 'Incident' verandert naar 'Canceled' (2) of naar een aangepaste gesloten status. De timestamp staat in de auditgeschiedenis.

Vastleggen

Houd de timestamp bij waarop 'statecode' verandert naar de definitieve eindstatus, bijvoorbeeld Canceled of Closed.

Gebeurtenistype explicit
Case opgelost
Deze belangrijke mijlpaal geeft aan dat de medewerker het probleem van de klant als opgelost beschouwt. Dit is een expliciete actie in Dynamics 365, waarbij een activiteit 'Case Resolution' wordt aangemaakt en aan de case gekoppeld.
Waarom dit belangrijk is

Als belangrijkste eindevent voor succesvolle afhandeling is deze activiteit nodig om afhandeltijden en succespercentages te berekenen. De activiteit speelt een belangrijke rol in vrijwel elke klantenservice-KPI.

Waar vind je dit?

Dit event komt overeen met het aanmaken van een activiteit 'Resolution' (Case Resolution). De timestamp 'actualend' van deze record geeft het moment van oplossing aan.

Vastleggen

Gebruik de timestamp 'actualend' of 'createdon' van de gekoppelde activiteit 'Resolution'.

Gebeurtenistype explicit
Case toegewezen
Deze activiteit geeft aan dat een case is toegewezen aan een specifieke wachtrij of gebruiker. Het systeem registreert wijzigingen van de case-eigenaar expliciet. Je kunt deze terugvinden in de auditlogs van het systeem.
Waarom dit belangrijk is

Door toewijzingen bij te houden, kun je de werkverdeling analyseren, vertragingen door toewijzingen opsporen en zien hoe efficiënt de routering verloopt. Zo wordt duidelijk hoe snel cases bij het juiste team of de juiste persoon terechtkomen.

Waar vind je dit?

Dit wordt vastgelegd door wijzigingen in het veld 'ownerid' van de entiteit 'Incident' bij te houden. De timestamp van de wijziging staat in de auditgeschiedenis.

Vastleggen

Haal wijzigingen met timestamps van het veld 'ownerid' uit de auditlogs.

Gebeurtenistype explicit
SLA-timer gestart
Geeft aan dat de Service Level Agreement (SLA)-timer voor de case is gestart. De timer houdt de tijd bij voor een vastgestelde servicemetriek, zoals 'First Response By' of 'Resolve By'. Dit expliciete event wordt beheerd door de SLA-engine van Dynamics 365.
Waarom dit belangrijk is

Deze activiteit is nodig om de SLA-naleving te volgen en te zien wanneer de tijd voor serviceafspraken begint te lopen. Hiermee kun je analyseren of de servicetargets worden gehaald.

Waar vind je dit?

Dit wordt vastgelegd in de entiteit 'SLA KPI Instance', die is gekoppeld aan de entiteit 'Incident'. De timestamp 'createdon' van de betreffende SLA KPI Instance-record geeft het startmoment aan.

Vastleggen

Gebruik de aanmaaktimestamp van de 'SLA KPI Instance'-record die aan de case is gekoppeld.

Gebeurtenistype explicit
Case opnieuw geactiveerd
Dit gebeurt wanneer een eerder opgeloste case automatisch of handmatig wordt heropend, meestal omdat de klant reageert of meldt dat het probleem niet is opgelost. Het is standaardgedrag van het systeem: de casestatus verandert van 'Resolved' terug naar 'Active'.
Waarom dit belangrijk is

Deze activiteit is belangrijk om herstelwerk op te sporen en de 'First Contact Resolution Rate' te analyseren. Veel heractiveringen wijzen erop dat de eerste oplossing onvolledig of niet effectief was.

Waar vind je dit?

Dit wordt vastgelegd wanneer het veld 'statecode' van de entiteit 'Incident' verandert van 'Resolved' (1) terug naar 'Active' (0). De timestamp van deze wijziging wordt opgeslagen in de auditgeschiedenis.

Vastleggen

Houd in de auditlogs de timestamp bij van een wijziging van 'statecode' van Resolved naar Active.

Gebeurtenistype explicit
Casecategorie gewijzigd
Dit event vindt plaats wanneer een medewerker de categorie of het onderwerp van een case wijzigt nadat deze is aangemaakt. Het systeem houdt deze expliciete wijziging bij in de auditgegevens.
Waarom dit belangrijk is

Het bijhouden van hercategoriseringen is nodig voor de KPI 'Service Request Recategorization Rate'. Een hoog aantal wijst op problemen bij de eerste beoordeling, waardoor cases verkeerd worden gerouteerd en vertraging oplopen.

Waar vind je dit?

Dit wordt vastgelegd in de auditgeschiedenis van de entiteit 'Incident', met name door wijzigingen in het veld 'subjectid' of andere aangepaste categorisatievelden bij te houden.

Vastleggen

Haal wijzigingen met timestamps van het veld 'subjectid' uit de auditlogs.

Gebeurtenistype explicit
Informatie opgevraagd bij klant
Deze activiteit markeert het moment waarop de medewerker meer informatie van de klant nodig heeft om verder te kunnen. Dit wordt vaak afgeleid uit een statuswijziging van de case naar 'waiting' of uit een uitgaande e-mail in de tijdlijn van de case.
Waarom dit belangrijk is

Dit is belangrijk om vertragingen door de klant te meten en de KPI 'Customer Information Wait Time' te begrijpen. Zo kun je de tijd isoleren waarin het proces wacht op informatie van buitenaf.

Waar vind je dit?

Dit kan worden afgeleid uit een wijziging van het veld 'statuscode' van de entiteit 'Incident' naar bijvoorbeeld 'On Hold' met als reden 'Waiting for Customer'. De timestamp van deze statuswijziging wordt gebruikt.

Vastleggen

Houd de timestamp bij van een wijziging van statuscode naar een aangewezen status 'waiting for customer'.

Gebeurtenistype inferred
Medewerker onderzoekt probleem
Geeft aan dat de medewerker actief probeert het probleem van de klant te begrijpen en vast te stellen. Deze activiteit wordt afgeleid uit bijvoorbeeld het koppelen van een Knowledge Article aan de case, wat erop wijst dat er onderzoek is gedaan.
Waarom dit belangrijk is

Door dit bij te houden, kun je zien hoe kennisbronnen worden gebruikt en welk effect dat heeft op de afhandeltijden. Zo wordt duidelijk of medewerkers beschikbare hulpmiddelen gebruiken om problemen efficiënt op te lossen.

Waar vind je dit?

Afgeleid uit het aanmaken van een record in de entiteit 'IncidentKnowledgeBaseRecord', die een Knowledge Article aan een Case koppelt. De timestamp waarop deze record is aangemaakt, wordt gebruikt.

Vastleggen

Gebruik de timestamp waarop een Knowledge Article aan de Incident wordt gekoppeld.

Gebeurtenistype inferred
Medewerker pakt wachtrij-item op
Dit event vindt plaats wanneer een medewerker een case uit een gedeelde wachtrij pakt om eraan te werken. Het gaat om een bewuste actie van de gebruiker, niet om de toewijzing van de case aan de wachtrij door het systeem.
Waarom dit belangrijk is

Met deze activiteit meet je hoelang een case in de wachtrij staat voordat een medewerker eraan begint. Dat helpt bottlenecks in wachtrijen op te sporen en te zien hoe proactief medewerkers cases oppakken.

Waar vind je dit?

Dit wordt bijgehouden wanneer een gebruiker het veld 'workedbyid' van de entiteit 'QueueItem' bijwerkt, of wanneer de case-eigenaar verandert van een wachtrij naar een gebruiker.

Vastleggen

Bepaal de timestamp waarop het veld 'workedbyid' van de QueueItem wordt ingevuld.

Gebeurtenistype explicit
Oplossing voorgesteld aan klant
Deze activiteit geeft aan dat de medewerker een oplossing heeft bedacht en met de klant heeft gedeeld. Dit wordt meestal afgeleid uit een uitgaande e-mail in de tijdlijn van de case of een statuswijziging naar 'Pending Customer Confirmation'.
Waarom dit belangrijk is

Deze mijlpaal markeert de overgang van onderzoek naar oplossing. Door de tijd tussen het voorstellen en bevestigen van een oplossing te analyseren, kun je vertragingen in de reactie van de klant of problemen met de voorgestelde oplossing opsporen.

Waar vind je dit?

Dit kan worden afgeleid uit de timestamp van een uitgaande activiteit 'Email' die aan de case is gekoppeld, of uit een statuswijziging naar een status vóór de oplossing.

Vastleggen

Gebruik de timestamp van een uitgaande e-mailactiviteit of een statuswijziging naar 'Solution Proposed'.

Gebeurtenistype inferred
Tevredenheidsonderzoek verstuurd
Geeft aan dat een klanttevredenheidsonderzoek is verstuurd, meestal automatisch nadat een case is opgelost. Dit wordt doorgaans vastgelegd als een uitgaande e-mail of een Customer Voice-surveyactiviteit.
Waarom dit belangrijk is

Deze activiteit koppelt het operationele proces aan de resultaten van de klantervaring. Zo kun je tevredenheidsscores analyseren in de context van het procesverloop van een case.

Waar vind je dit?

Af te leiden uit het aanmaken van een uitgaande activiteit 'Email' met een link naar een enquête, of uit een activiteit 'Customer Voice survey invite' die aan de case is gekoppeld.

Vastleggen

Gebruik de aanmaaktimestamp van de activiteit die bij het onderzoek hoort.

Gebeurtenistype inferred
Aanbevolen Optioneel

Extractiegidsen

Zo haal je data op uit Microsoft Dynamics 365 Customer Service

Klaar om te beginnen?

Gebruik deze datatemplate om snel met process mining aan de slag te gaan en je klantenservice efficiënter te maken. Optimaliseer vandaag nog je workflows voor een betere klantervaring.

Verbeter je klantenservice: verhoog FCR en verlaag nu de kosten

Spoor bottlenecks op en bereik 80% oplossing bij het eerste contact, voor tevredener klanten.

Start je gratis proefperiode

Geen creditcard nodig. Binnen enkele minuten ingesteld.