Jouw datatemplate voor klantenservice

Microsoft Dynamics 365 Customer Service
Jouw datatemplate voor klantenservice

Jouw datatemplate voor klantenservice

Deze template biedt een gestructureerde aanpak voor het verzamelen van de data die je nodig hebt voor een grondige analyse van je klantenserviceproces. Je ziet welke attributen je moet verzamelen, welke activiteiten je moet volgen en hoe je deze informatie effectief extraheert.
  • Aanbevolen attributen om te verzamelen
  • Belangrijkste activiteiten om te volgen
  • Extractiehandleiding voor Microsoft Dynamics 365 Customer Service
Nieuw met event logs? Leer hoe je een process mining-event log maakt.

Attributen voor klantenservice

Dit zijn de aanbevolen datavelden voor je event log voor een volledige analyse van het klantenserviceproces.
5 Verplicht 7 Aanbevolen 8 Optioneel
Naam Beschrijving
Serviceaanvraag
ServiceRequest
De unieke identificatie van een serviceaanvraag van een klant, ook wel een case of ticket genoemd.
Beschrijving

De serviceaanvraag is de primaire identificatie en koppelt alle activiteiten aan één klantvraag of probleem. De aanvraag fungeert als Case ID voor process mining en zorgt voor een volledig en consistent beeld van elke klantinteractie, van aanmaak tot afsluiting. Door op serviceaanvraag te analyseren, kun je de volledige klantreis volgen, oplostijden meten en patronen in vergelijkbare cases herkennen.

Waarom dit belangrijk is

Dit is de essentiële Case ID die alle gerelateerde events aan één procesinstantie koppelt, zodat end-to-end-procesanalyse mogelijk wordt.

Waar je het vindt

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

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

Dit attribuut beschrijft één stap of statuswijziging binnen het klantenserviceproces, zoals 'Case Created', 'Agent Investigated Issue' of 'Case Resolved'. Deze activiteiten vormen de basis van de procesmap en maken visualisatie en analyse van de procesflow mogelijk. Elke activiteit vormt samen met een timestamp een event dat de procesvolgorde bepaalt.

Waarom dit belangrijk is

Activiteiten definiëren de stappen in het proces. Door de volgorde en frequentie van activiteiten te analyseren, krijg je zicht op procesflows, afwijkingen en bottlenecks.

Waar je het vindt

Meestal afgeleid door statuswijzigingen (statuscode) of specifieke events uit gerelateerde entiteiten, zoals Tasks, Emails of Phone Calls, aan een gestandaardiseerde activiteitsnaam te koppelen.

Voorbeelden
Case aangemaaktAgent heeft probleem onderzochtOplossing voorgesteld aan klantCase gesloten
Bronsysteem
SourceSystem
Identificeert het bronsysteem waaruit de data is geëxtraheerd.
Beschrijving

Dit attribuut geeft de herkomst van de eventdata aan. Voor dit proces verwijst het steeds naar Microsoft Dynamics 365 Customer Service als bron. In omgevingen met meerdere systemen is dit veld belangrijk om databronnen van elkaar te onderscheiden en de dataherkomst te bewaken.

Waarom dit belangrijk is

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

Waar je het vindt

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

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

Dit attribuut geeft aan wanneer de data voor het laatst uit Microsoft Dynamics 365 is opgehaald. Je gebruikt het om de actualiteit van de geanalyseerde data te beoordelen. Het is belangrijk voor rapportages en monitoring, zodat gebruikers bij het interpreteren van dashboards en analyses weten hoe actueel de data is.

Waarom dit belangrijk is

Laat zien hoe recent de data is. Dat is belangrijk om op tijd goede bedrijfsbeslissingen te nemen op basis van de procesanalyse.

Waar je het vindt

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

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 specifieke activiteit plaatsvond. Het is essentieel om events in de juiste volgorde te zetten en voor alle tijdgebaseerde analyses, waaronder het berekenen van doorlooptijden, duur en wachttijden tussen activiteiten. Een nauwkeurige en consistente timestamp is belangrijk voor de kwaliteit van de process mining-analyse.

Waarom dit belangrijk is

Deze timestamp zet events chronologisch en maakt alle berekeningen op basis van duur mogelijk. Dat is belangrijk voor prestatieanalyse en het vinden van bottlenecks.

Waar je het vindt

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

Voorbeelden
2023-04-15T10:00:00Z2023-05-20T14:35:10Z2023-06-01T09:12:45Z
Beoogde oplostijd volgens SLA
SlaTargetResolutionTime
De contractueel afgesproken streeftijd voor het oplossen van de serviceaanvraag.
Beschrijving

Dit attribuut specificeert de termijn waarbinnen een serviceaanvraag volgens de actieve Service Level Agreement (SLA) moet zijn opgelost. Het is de norm waarmee je de werkelijke prestaties vergelijkt. Deze waarde is belangrijk voor het dashboard SLA Compliance Monitoring en voor het berekenen van de KPI SLA Compliance Rate. Zo zie je waar het proces niet aan de serviceafspraken voldoet.

Waarom dit belangrijk is

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

Waar je het vindt

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

Voorbeelden
2592008640014400
Kanaal
Channel
Het communicatiekanaal waarlangs de serviceaanvraag is gestart.
Beschrijving

Dit attribuut identificeert de herkomst van de klantinteractie, zoals Telefoon, E-mail, webportaal of chat. Verschillende kanalen hebben vaak een eigen procesflow, klantverwachtingen en complexiteit van de oplossing. Door het proces per kanaal te analyseren, kun je kanaalspecifieke workflows en de inzet van capaciteit verbeteren.

Waarom dit belangrijk is

Geeft inzicht in de invloed van verschillende klantcontactkanalen op procesefficiëntie, oplostijd en klanttevredenheid.

Waar je het vindt

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

Voorbeelden
TelefoonE-mailWebChat
Naam van agent
AgentName
De naam van de klantenserviceagent of gebruiker die verantwoordelijk is voor de activiteit.
Beschrijving

Dit attribuut identificeert de specifieke agent of systeemgebruiker die een activiteit heeft uitgevoerd, zoals het oppakken van een item uit een wachtrij of het oplossen van een case. Het is belangrijk voor het analyseren van agentprestaties, werkverdeling en de inzet van capaciteit. Door activiteiten op agentniveau te volgen, kunnen organisaties goed presterende medewerkers, trainingsbehoeften en onevenwichtige werkverdeling herkennen.

Waarom dit belangrijk is

Maakt analyse van individuele en teamprestaties mogelijk, helpt bij het verdelen van werk en laat zien waar coaching kan bijdragen aan een betere servicekwaliteit.

Waar je het vindt

Komt overeen met het veld 'Owner' (ownerid) op de entiteit Case (incident), dat verwijst naar de entiteit System User (systemuser).

Voorbeelden
Alice SmithBob JohnsonSysteem
Naam van klant
CustomerName
De naam van de klant of account die aan de serviceaanvraag is gekoppeld.
Beschrijving

Dit attribuut identificeert de klant die de serviceaanvraag heeft gestart. Hiermee kun je het proces vanuit klantperspectief analyseren en zien welke klanten de meeste aanvragen indienen, de langste oplostijden hebben of de meest complexe problemen melden. Dat helpt bij klantrelatiebeheer en het verbeteren van de dienstverlening per klant.

Waarom dit belangrijk is

Maakt analyse op klantniveau mogelijk, zodat je patronen herkent, de service voor belangrijke accounts verbetert en de klantreis beter begrijpt.

Waar je het vindt

Dit is het opzoekveld 'Customer' (customerid) op de entiteit Case (incident), dat kan verwijzen naar een Account- of Contactrecord.

Voorbeelden
Global Tech Inc.Jane DoeInnovate Solutions
Prioriteit
Priority
Het prioriteitsniveau van de serviceaanvraag, dat de urgentie aangeeft.
Beschrijving

Dit attribuut bepaalt de urgentie van een serviceaanvraag, meestal ingedeeld als Low, Normal, High of Urgent. De prioriteit bepaalt de volgorde waarin cases worden behandeld en is vaak bepalend voor SLA-doelen. Door te analyseren hoe prioriteit de procesflow, capaciteitsverdeling en oplostijden beïnvloedt, zie je of kritieke problemen snel worden afgehandeld.

Waarom dit belangrijk is

Helpt te bepalen of aanvragen met hoge prioriteit sneller worden verwerkt en hun doelen halen, en hoe prioriteitsniveaus de algehele procesprestaties beïnvloeden.

Waar je het vindt

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

Voorbeelden
LaagNormaalHoog
Statusreden
StatusReason
Geeft een specifiekere reden voor de huidige status van de serviceaanvraag.
Beschrijving

Een case heeft bijvoorbeeld een algemene status als 'Active' of 'Resolved'. De Status Reason geeft extra context, zoals 'Information Provided' of 'Problem Solved'. Dit attribuut helpt om beter te begrijpen hoe en waarom cases door hun levenscyclus gaan. Zo kun je opgeloste cases onderscheiden van cases die door de klant zijn geannuleerd, wat belangrijk is voor een juiste analyse van resultaten.

Waarom dit belangrijk is

Geeft gedetailleerd inzicht in de uitkomst van een case en in de redenen voor statuswijzigingen. Daarmee kun je oplossingspaden en grondoorzaken nauwkeuriger analyseren.

Waar je het vindt

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

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

Dit attribuut categoriseert de serviceaanvraag op basis van de aard ervan, zoals 'Billing Inquiry', 'Technical Support' of 'Product Feedback'. Het is de basis voor segmentatie van de procesanalyse, zodat je ziet hoe verschillende typen aanvragen worden afgehandeld. Analyse per type kan laten zien dat bepaalde categorieën langere oplostijden of hogere escalatiepercentages hebben, of een ander procespad volgen.

Waarom dit belangrijk is

Maakt processegmentatie mogelijk om typegebonden bottlenecks, capaciteitsbehoeften en verbeterkansen te vinden. Dit ondersteunt betere routerings- en afhandelingsstrategieën.

Waar je het vindt

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

Voorbeelden
Vraag over facturatieTechnische ondersteuningProductfeedbackAccountbeheer
Betrokken product
ProductInvolved
Het product dat bij de serviceaanvraag van de klant hoort.
Beschrijving

Dit attribuut identificeert het specifieke product of de specifieke service waarop het probleem van de klant betrekking heeft. Hiermee kun je het serviceproces per product segmenteren. Zo zie je of bepaalde producten meer supportaanvragen of complexere problemen veroorzaken, of specifieke vaardigheden van agents vereisen. Deze analyse helpt bij productverbetering en capaciteitsplanning.

Waarom dit belangrijk is

Maakt productspecifieke procesanalyse mogelijk om terugkerende productproblemen te vinden, supportdocumentatie te verbeteren en experts gericht in te zetten.

Waar je het vindt

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

Voorbeelden
Alpha-100 PrinterZeta CRM SoftwareOmega Data Plan
CSAT-score
CustomerSatisfactionScore
De tevredenheidsscore die de klant na het oplossen van de case geeft.
Beschrijving

Dit attribuut bevat de numerieke of categorische beoordeling uit een klanttevredenheidsonderzoek (CSAT), meestal verzameld nadat een serviceaanvraag is gesloten. Het is een directe maat voor hoe de klant de kwaliteit van de service ervaart. Deze data is belangrijk voor het dashboard Customer Satisfaction Trends en de KPI Average Post-Resolution CSAT Score, omdat je hiermee procesprestaties aan klantresultaten koppelt.

Waarom dit belangrijk is

Geeft een directe maat voor klanttevredenheid. Zo kan de organisatie procesgedrag koppelen aan klanttevredenheid en verbeteringen doorvoeren.

Waar je het vindt

Komt meestal uit een gerelateerde survey-entiteit, zoals Customer Voice, en is gekoppeld aan de entiteit Case (incident).

Voorbeelden
5341
Eigenaarsteam
OwnerTeam
Het team dat momenteel eigenaar is van de serviceaanvraag.
Beschrijving

Dit attribuut identificeert het team dat verantwoordelijk is voor de serviceaanvraag. Een aanvraag kan eigendom zijn van een individuele agent of van een team (wachtrij). Analyse per team helpt bij het beoordelen van teamprestaties, de werkverdeling over supportniveaus of specialismen en verschillen tussen teams.

Waarom dit belangrijk is

Maakt prestatieanalyse op teamniveau mogelijk. Dat is belangrijk voor het effectief beheren van supportniveaus en gespecialiseerde teams.

Waar je het vindt

Afgeleid uit het veld 'Owner' (ownerid) op de entiteit Case (incident) wanneer de eigenaar een Teamrecord is en geen System User.

Voorbeelden
Ondersteuning niveau 1FacturatieafdelingTechnische specialisten
Herstelwerk
IsRework
Een berekende vlag die aangeeft of een case activiteiten voor herstelwerk bevatte.
Beschrijving

Deze booleaanse vlag identificeert cases met herstelwerkloops of herhaalde activiteiten, zoals meerdere events 'Information Requested From Customer' of een event 'Case Reactivated' nadat de case was opgelost. De waarde wordt berekend door de activiteitenvolgorde te analyseren op patronen die wijzen op inefficiëntie of het niet goed oplossen van het probleem bij de eerste poging. Dit attribuut is belangrijk voor het dashboard Rework and Repeat Contact Analysis.

Waarom dit belangrijk is

Helpt procesinefficiënties te kwantificeren en af te zonderen, zodat analisten zich kunnen richten op de grondoorzaken van herhaald werk en verspilde inspanning.

Waar je het vindt

Berekend door specifieke activiteitenreeksen, zoals Resolved -> Reactivated, of herhaalde activiteiten binnen een case te herkennen met process mining-analyses.

Voorbeelden
truefalse
ID van Knowledge Article
KnowledgeArticleId
De identificatie van een Knowledge Article uit de kennisbank die aan de serviceaanvraag is gekoppeld.
Beschrijving

Dit attribuut legt de ID vast van elk Knowledge Article dat tijdens het oplossen van een serviceaanvraag is gebruikt of gekoppeld. Het laat rechtstreeks zien hoe effectief agents de kennisbank gebruiken om klantproblemen op te lossen. Deze data is belangrijk voor het dashboard Knowledge Article Utilization en de bijbehorende KPI, waarmee je de waarde en volledigheid van de kennisbank beoordeelt.

Waarom dit belangrijk is

Volgt het gebruik van de kennisbank en helpt te bepalen of agents beschikbare bronnen gebruiken om problemen sneller en consistenter op te lossen.

Waar je het vindt

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 de serviceaanvraag is geëscaleerd.
Beschrijving

Dit booleaanse attribuut geeft aan of een serviceaanvraag een escalatie heeft doorgemaakt. Escalaties ontstaan wanneer eerstelijnssupport een probleem niet kan oplossen en een senior team of specialist moet ingrijpen. Het volgen van deze vlag is belangrijk voor het dashboard Internal Escalation Pathways en de KPI Internal Escalation Rate. Zo zie je de grondoorzaken van escalaties en zwakke plekken in de eerste supportniveaus.

Waarom dit belangrijk is

Meet rechtstreeks hoe vaak escalaties voorkomen. Zo worden problemen met oplossing bij het eerste contact zichtbaar en zie je waar proces- of vaardigheidsverbetering nodig is.

Waar je het vindt

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 de aanvraag tijdens het eerste contact is opgelost.
Beschrijving

Dit berekende attribuut identificeert serviceaanvragen die zijn opgelost zonder vervolginteracties met de klant of grote vertragingen waarvoor een andere agent nodig was. De exacte logica kan complex zijn, maar omvat meestal een korte doorlooptijd en het ontbreken van heropeningen of nieuwe klantvragen na de eerste interactie. Het vormt de basis voor de KPI First Contact Resolution Rate.

Waarom dit belangrijk is

Dit is een belangrijke maat voor service-efficiëntie en klanttevredenheid, omdat het laat zien of problemen snel en volledig worden opgelost.

Waar je het vindt

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

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

Deze booleaanse vlag wordt bepaald door de werkelijke oplostijd van een serviceaanvraag te vergelijken met de 'SLA Target Resolution Time'. De waarde is true als de werkelijke tijd langer is dan de doeltijd. Dit attribuut is de basis voor het dashboard SLA Compliance Monitoring en de KPI SLA Compliance Rate. Per case zie je zo duidelijk of de SLA is gehaald.

Waarom dit belangrijk is

Geeft voor elke case een duidelijke uitkomst voor het wel of niet naleven van de SLA. Daardoor kun je eenvoudig filteren, totalen berekenen en de grondoorzaken van overschrijdingen analyseren.

Waar je het vindt

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

Voorbeelden
truefalse
Verplicht Aanbevolen Optioneel

Activiteiten voor klantenservice

Dit zijn de belangrijkste processtappen en mijlpalen die je in je event log vastlegt voor een nauwkeurige ontdekking en optimalisatie van de klantenservice.
6 Aanbevolen 7 Optioneel
Activiteit Beschrijving
Case aangemaakt
Deze activiteit markeert het begin van het Customer Service-proces, wanneer in het systeem een nieuwe case wordt aangemaakt. Het aanmaken is een expliciete gebeurtenis met een specifieke timestamp waarop het record van de entiteit 'Incident' voor het eerst wordt opgeslagen.
Waarom dit belangrijk is

Als primair startevent is deze activiteit belangrijk voor het berekenen van de totale doorlooptijd van een case en het begrijpen van trends in het aantal cases. Het vormt het anker voor alle volgende procesanalyses.

Waar je het vindt

Deze gebeurtenis wordt voor elke nieuwe record vastgelegd via de 'createdon'-timestamp van de entiteit 'Incident' (Case).

Vastleggen

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

Eventtype explicit
Case geëscaleerd
Dit staat voor de formele escalatie van een case naar een hoger supportniveau of een ander team. Het kan gaan om een expliciete gebruikersactie waarbij de case opnieuw wordt toegewezen aan een aangewezen escalatiewachtrij of gebruiker.
Waarom dit belangrijk is

Het monitoren van escalaties is essentieel voor de KPI 'Internal Escalation Rate' en voor het vinden van de grondoorzaken van problemen die eerstelijnssupport niet kan oplossen. Het maakt zwakke plekken in het proces en kansen voor training zichtbaar.

Waar je het vindt

Afgeleid uit een wijziging in 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

Identificeer een wijziging met timestamp van 'ownerid' naar een bekende escalatiewachtrij.

Eventtype inferred
Case gesloten
Dit is de definitieve administratieve afsluiting van het caserecord. Die kan tegelijk met de oplossing plaatsvinden, maar ook later. Deze activiteit wordt vastgelegd door een wijziging van de casestatus naar 'Closed'.
Waarom dit belangrijk is

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

Waar je het vindt

Vastgelegd door een wijziging in het veld 'statecode' van de entiteit 'Incident' naar 'Canceled' (2) of een aangepaste gesloten status. De timestamp staat in de auditgeschiedenis.

Vastleggen

Volg de timestamp waarop 'statecode' verandert naar de definitieve eindstatus, bijvoorbeeld Canceled/Closed.

Eventtype explicit
Case opgelost
Dit is een belangrijke mijlpaal: het moment waarop de agent vindt dat het probleem van de klant is opgelost. In Dynamics 365 is dit een expliciete actie die een aan de case gekoppelde activiteit 'Case Resolution' aanmaakt.
Waarom dit belangrijk is

Als belangrijkste eindevent op basis van succes is deze activiteit essentieel voor het berekenen van oplostijden en succespercentages. Bijna elke KPI voor klantenservice gebruikt deze activiteit.

Waar je het vindt

Dit event komt overeen met het aanmaken van een activiteit 'Resolution' (Case Resolution). De timestamp 'actualend' op dit record markeert het moment waarop de case is opgelost.

Vastleggen

Gebruik de timestamp 'actualend' of 'createdon' van het gekoppelde activiteitenrecord 'Resolution'.

Eventtype explicit
Case toegewezen
Deze activiteit staat voor het toewijzen van een case aan een specifieke wachtrij of gebruiker voor afhandeling. Het systeem registreert wijzigingen van de case-eigenaar expliciet. Je kunt die volgen via de auditlogs van het systeem.
Waarom dit belangrijk is

Door toewijzingen te volgen, kun je de werkverdeling analyseren, vertragingen rond toewijzingen vinden en de efficiëntie van de routering begrijpen. Zo zie je hoe snel cases bij het juiste team of de juiste persoon terechtkomen.

Waar je het vindt

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

Vastleggen

Extraheer wijzigingen met timestamp in het veld 'ownerid' uit de auditlogs.

Eventtype explicit
SLA-timer gestart
Dit geeft aan dat een Service Level Agreement (SLA)-timer voor de case is geactiveerd. De timer houdt de tijd bij voor een vastgelegde servicemetric, zoals 'First Response By' of 'Resolve By'. Dit is een expliciete gebeurtenis die wordt beheerd door de SLA-engine van Dynamics 365.
Waarom dit belangrijk is

Deze activiteit is belangrijk om SLA-naleving te monitoren en vast te stellen wanneer de klok voor serviceafspraken begint te lopen. Ze ondersteunt rechtstreeks de analyse van het behalen van servicetargets.

Waar je het vindt

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

Vastleggen

Gebruik de aanmaaktimestamp van het aan de case gekoppelde 'SLA KPI Instance'-record.

Eventtype explicit
Agent heeft probleem onderzocht
Dit staat voor het actieve werk van de agent om het probleem van de klant te begrijpen en te diagnosticeren. Het is een afgeleide activiteit die vaak wordt vastgesteld wanneer de agent een Knowledge Article aan de case koppelt. Dat wijst erop dat er onderzoek is gedaan.
Waarom dit belangrijk is

Door dit te volgen, meet je het gebruik van kennisbronnen en het effect daarvan op de doorlooptijd tot oplossing. Zo zie je of agents beschikbare hulpmiddelen gebruiken om problemen efficiënt op te lossen.

Waar je het vindt

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

Vastleggen

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

Eventtype inferred
Case opnieuw geactiveerd
Dit gebeurt wanneer een eerder opgeloste case automatisch of handmatig opnieuw wordt geopend, meestal omdat de klant heeft gereageerd of meldt dat het probleem niet is opgelost. Dit is standaardgedrag van het systeem waarbij de casestatus van 'Resolved' teruggaat naar 'Active'.
Waarom dit belangrijk is

Deze activiteit is belangrijk om herstelwerk te herkennen en de 'First Contact Resolution Rate' te analyseren. Veel heractiveringen wijzen op onvolledige of ineffectieve eerste oplossingen.

Waar je het vindt

Vastgelegd door een wijziging in het veld 'statecode' van de entiteit 'Incident', van 'Resolved' (1) terug naar 'Active' (0). De timestamp van deze wijziging staat in de auditgeschiedenis.

Vastleggen

Volg de timestamp van de wijziging van 'statecode' van Resolved naar Active in de auditlogs.

Eventtype explicit
Categorisering van case gewijzigd
Deze gebeurtenis vindt plaats wanneer een agent de categorie of het onderwerp van een case na het aanmaken wijzigt. Dit is een expliciete wijziging die via de auditfunctie van het systeem wordt gevolgd.
Waarom dit belangrijk is

Het volgen van hercategorisering is belangrijk voor de KPI 'Service Request Recategorization Rate'. Een hoge frequentie wijst op problemen bij de eerste triage, met verkeerde routering en vertragingen als gevolg.

Waar je het vindt

Dit wordt vastgelegd in de auditgeschiedenis van de entiteit 'Incident', specifiek door wijzigingen in het veld 'subjectid' of andere aangepaste categoriseringsvelden te volgen.

Vastleggen

Extraheer wijzigingen met timestamp in het veld 'subjectid' uit de auditlogs.

Eventtype explicit
Informatie opgevraagd bij klant
Deze activiteit markeert het moment waarop de agent 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 die vanuit de tijdlijn van de case wordt verstuurd.
Waarom dit belangrijk is

Dit is belangrijk om vertragingen aan de kant van de klant te meten en de KPI 'Customer Information Wait Time' te begrijpen. Zo kun je de procestijd isoleren die wordt besteed aan het wachten op input van buitenaf.

Waar je het vindt

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

Vastleggen

Volg de timestamp van een wijziging in statuscode naar een aangewezen status 'waiting for customer'.

Eventtype inferred
Oplossing voorgesteld aan klant
Deze activiteit geeft aan dat de agent een oplossing heeft opgesteld en met de klant heeft gedeeld. Meestal wordt dit afgeleid uit een uitgaande e-mail vanuit de tijdlijn van de case of uit 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, zie je vertragingen in de reactie van de klant of problemen met de voorgestelde oplossing.

Waar je het vindt

Kan worden afgeleid uit de timestamp van een uitgaande 'Email'-activiteit die aan de case is gekoppeld, of uit een wijziging van statuscode naar een status vóór de oplossing.

Vastleggen

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

Eventtype inferred
Queue-item door agent opgepakt
Deze gebeurtenis vindt plaats wanneer een agent actief een case uit een gedeelde wachtrij pakt om eraan te werken. Dit is een bewuste actie van de gebruiker en verschilt van het moment waarop het systeem de case aan de wachtrij toewijst.
Waarom dit belangrijk is

Met deze activiteit meet je hoe lang een case in een wachtrij wacht voordat een agent eraan begint. Dat helpt bij het vinden van bottlenecks in wachtrijen en het begrijpen van de proactiviteit van agents.

Waar je het vindt

Dit wordt gevolgd wanneer een gebruiker het veld 'workedbyid' van de aan de case gekoppelde 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.

Eventtype explicit
Tevredenheidsonderzoek verzonden
Markeert het verzenden van een klanttevredenheidsonderzoek, meestal automatisch nadat een case is opgelost. Dit wordt doorgaans vastgelegd als een uitgaande e-mail of als een Customer Voice survey-activiteit.
Waarom dit belangrijk is

Deze activiteit koppelt het operationele proces aan resultaten op het gebied van klantbeleving. Hiermee kun je tevredenheidsscores analyseren in de context van het procespad dat een case heeft gevolgd.

Waar je het vindt

Afgeleid uit het aanmaken van een uitgaande 'Email'-activiteit met een link naar het onderzoek, of uit een activiteitenrecord 'Customer Voice survey invite' dat aan de case is gekoppeld.

Vastleggen

Gebruik de aanmaaktimestamp van het activiteitenrecord dat bij het onderzoek hoort.

Eventtype inferred
Aanbevolen Optioneel

Extractiegidsen

Zo haal je je data uit Microsoft Dynamics 365 Customer Service

Klaar om aan de slag te gaan?

Gebruik deze datatemplate als startpunt voor je process mining-traject en ontdek nieuwe manieren om je klantenservice efficiënter te maken. Begin vandaag met het optimaliseren van je workflows voor een betere klantervaring.

Optimaliseer je klantenservice: verhoog FCR en verlaag nu je kosten

Vind knelpunten en bereik een oplossing bij 80% van de eerste contacten, voor tevreden klanten.

Start je gratis proefperiode

Je hebt geen creditcard nodig. Je bent in enkele minuten klaar.