Een klant mailt over een kapotte bestelling, belt de volgende dag en opent daarna een chat omdat niemand lijkt te weten wat er is gebeurd en ze herhalen elke keer hetzelfde verhaal terwijl je supportteam zoekt in inboxen, notities en losse tools. Dat is precies wat Dynamics 365 Case Management oplost. Zie een case als een gelabelde map in een druk kantoorpand waar elk onderdeel van een klantprobleem in die map terechtkomt, van de eerste vraag tot het uiteindelijke antwoord. Je bent Mirko Peters van M365FM en in dit kennisfragment zie je hoe cases, routering, reactietermijnen, supportartikelen en afsluiting allemaal samenkomen. Wat een case nu eigenlijk is in twintig woorden. Dus, wat is een case nu precies? Een case is één dossier voor één klantprobleem dat een antwoord of oplossing vereist en het probleem kan een beschadigd product zijn, een factuurvraag, een inlogprobleem of een hulpvraag bij het gebruik van een dienst.

Dit is het punt één klant kan meerdere cases tegelijk hebben. Een klant kan op maandag vragen over een factuur, op dinsdag een defectapparaat melden en op vrijdag hulp nodig hebben bij het wijzigen van een adres. Dat zijn afzonderlijke problemen, dus Dynamics 365 houdt ze in aparte case dossiers in plaats van elk gesprek op een grote hoop te gooien. Wanneer een medewerker een case aanmaakt, koppelt hij deze direct aan de klant. Die klant kan een contactpersoon zijn, oftewel een individu, of een account, oftewel het bedrijf waarvoor ze werken. Dus, als Jamie van Nordwind traders een probleem meldt, kan de case naar zowel Jamie als het bedrijf verwijzen, en iedereen die het dossier opent, ziet wie hulp nodig heeft en bij welke organisatie het probleem hoort. De case heeft ook een duidelijke beschrijving van het probleem nodig, meestal beginnend met een titel als Onze printer stopt na software update, of Klant twee keer gefactureerd voor jaarplan, en die titel helpt mensen een lijst met open cases te scannen zonder elk dossier te openen.

Onder die titel voegt de medewerker de details toe. Wat is er gebeurd? Wanneer begon het? Wat heeft de klant al geprobeerd? Om welk product gaat het? En of het een vraag, een verzoek of een fout is? Deze details veranderen een vaag bericht in werk dat iemand kan oppakken en oplossen. Laten we dit verder uitsplitsen. Een case kan een onderwerp, product, prioriteit en casetype bevatten. Het onderwerp groepeert het probleem in een categorie zoals facturering of technische ondersteuning, het product identificeert wat de klant gebruikt, de prioriteit geeft aan het team aan hoe snel ze ernaar moeten kijken, en het casetype biedt het team een andere manier om werk te sorteren op basis van hun ondersteuningsproces. Geen van deze velden lost de klant of zijn probleem op zichzelf op, maar ze helpen het ondersteuningsteam om het werk duidelijk in kaart te brengen, vooral wanneer honderden cases van verschillende klanten binnenkomen.

Een team dat te maken heeft met een ernstige service storing zou niet door algemene vragen hoeven te zoeken om deze te vinden. Een case is nu niet zomaar een formulier dat iemand invult en vergeet. Het wordt het werkdossier voor het hele gesprek. E-mails kunnen aan de case worden gekoppeld, telefoongesprekken kunnen erin verschijnen en een medewerker kan na een chatnotices toevoegen, een vervolgtaak instellen of een afspraak vastleggen. Elke activiteit blijft verbonden aan hetzelfde klantprobleem, zodat de volgende persoon het verhaal niet vanaf nul hoeft op te bouwen. Stel je voor dat een medewerker s'ochtends aan het werk gaat en de case naar de lunch overdraagt aan een productspecialist. Zonder case dossier krijgt de specialist misschien slechts één kort bericht, zoals Oh, kun je hier even naar kijken? Wat niet voldoende is. Met het case dossier kunnen ze het oorspronkelijke probleem zien, klantgegevens, wat er tijdens het gesprek is gebeurd en wat de eerste medewerker al heeft gecontroleerd.

Dat zorgt voor een veel betere overdracht. Dynamics 365 houdt de case in een duidelijke status terwijl deze door het ondersteuningsproces gaat. Het kan actief blijven terwijl het team onderzoek doet en zodra het team het probleem heeft opgelost of het definitieve antwoord heeft gegeven, sluiten ze het af. Als het verzoek niet langer werk vereist, misschien omdat het per ongeluk is binnengekomen of de klant het heeft ingetrokken, kan het team het annuleren. Actief, opgelost en geannuleerd. Die drie statussen geven het team een gedeeld beeld van de status van elk probleem, zodat niemand hoeft te raden of een case nog aandacht nodig heeft en managers hoeven oud, afgerond werk niet als een nieuw klantprobleem te behandelen. Eén dossier geeft je controle en de volledige klantgeschiedenis geeft de medewerker context. Het klantverhaal achter de case. Een case vertelt je wat er moet worden opgelost.

Het klantendossier vertelt je wat tot dit moment heeft geleid. Wanneer een medewerker een case opent in Dynamics 365 Customer Service, kunnen ze verder kijken dan het laatste bericht. Ze zien het grotere geheel, eerdere cases, eerdere e-mails, de producten die aan de klant zijn gekoppeld en een ondersteuningsgeschiedenis. Context verandert het gesprek. Waarom is context belangrijk? Stel je voor dat een klant een defect aan een apparaat meldt. Als de medewerker alleen het bericht van vandaag ziet, beginnen ze mogelijk met basisvragen. Om welk model gaat het? Wanneer is het begonnen? Heeft u het opnieuw opgestart? Maar de klant heeft deze week al twee keer contact opgenomen met de supportafdeling. De eerste medewerker stuurde stappen voor probleemoplossing, de tweede regelde een vervangend onderdeel. Een derde medewerker die die historie ziet, zal de klant niet vragen om opnieuw te beginnen.

In plaats daarvan zeggen ze, ik zie dat u die stappen al heeft geprobeerd en dat het vervangende onderdeel het niet heeft opgelost. Laten we de volgende stap proberen. Aanhalingsteken. Dat voelt heel anders dan, kunt u het probleem nog eens uitleggen? Dit wordt vaak een 360 graden klantbeeld genoemd. De naam klinkt chic, maar het is simpel. Het betekent dat de medewerker de klant vanuit meer dan één invalshoek ziet, niet slechts één losbericht. De medewerker ziet de persoon, ze zien het bedrijf, ze zien eerdere supportaanvragen, eerdere gesprekken en de producten die eraan gekoppeld zijn. Voor een supportteam vervangt dat gissen door een duidelijk vertrekpunt. Nu krijgt niet elke klant hetzelfde soort ondersteuning. Een klant kan garantie hebben gekocht, hun bedrijf kan betalen voor een vast aantal supporturen, of ze hebben een contract voor een bepaald aantal zaken, of premium support met snellere hulp.

Dynamics 365 houdt dit allemaal bij via rechten. Een recht is de supportovereenkomst van de klant in het systeem. Zie het als de servicevoorwaarden die aan een account zijn gekoppeld. Voordat de medewerker een engineer toezegt of betaald werk start, controleren ze welke ondersteuning van toepassing is. Dat voorkomt ongemakkelijke verrassingen. Een klant kan bijvoorbeeld nog garantie hebben op een defect product. De zaak kan dat traject volgen. Een andere klant heeft misschien al zijn supporturen verbruikt. De medewerker ziet dat voordat hij zich vastlegt op werk buiten de overeenkomst. Het helpt het supportteam ook om klanten eerlijk te behandelen. De medewerker hoeft niet in oude contracten te zoeken of een andere afdeling te vragen. De supportvoorwaarden staan bij de klantgegevens, precies waar de medewerker ze kan vinden. Dan is er nog de kennisbank. Supportteams lossen dezelfde problemen telkens weer op.

Wachtwoordresets, installatieinstructies, een bekende fout na een update, een factuurvraag met een standaard antwoord. Een kennisartikel slaat dat antwoord op één plek op. Binnen de servicewerkruimte kan een medewerker naar artikelen zoeken terwijl hij aan een zaak werkt. Een artikel kan een eenvoudige uitleg, stappen, een schermafbeelding of de exacte controles bevatten die het team moet uitvoeren. In plaats van dat elke medewerker uit het hoofd zijn eigen versie schrijft, gebruiken ze een gedeeld antwoord dat het team heeft beoordeeld. Dat houdt de ondersteuning consistent. Het helpt ook nieuwere medewerkers. Ze hebben geen jarenlange ervaring nodig om veelvoorkomende problemen goed aan te pakken, omdat de bekende oplossingen van het team beschikbaar zijn wanneer ze die nodig hebben. Copilot caseoverzichten helpen bij een ander veelvoorkomend probleem, lange casegeschiedenissen. Een case kan in de loop van de tijd veel e-mails, notices en updates verzamelen.

Het lezen van alles kost tijd, zeker na een overdracht. Copilot maakt een kort caseoverzicht waarin de case-titel, klant, onderwerp, product, prioriteit, case-type, beschrijving en recente activiteit worden samengebracht. Het is een snelle briefing voordat de medewerker aan het werk gaat. De medewerker controleert nog steeds het dossier en gebruikt hun eigen inzicht, maar ze begrijpen de situatie sneller. Dat helpt wanneer de klant wacht en de case door verschillende handen is gegaan. Zodra de medewerker de klant en het probleem begrijpt, moet de case de juiste persoon bereiken. Van intake naar de juiste wachtrij. Een klant kan op veel manieren om hulp vragen, e-mail, telefoongesprek, chat, sociale media, een self-service portal. Het kanaal verandert, maar het support team heeft nog steeds één duidelijke plek nodig om het verzoek te beheren. Dynamics 365 kan cases maken van die gesprekken wanneer de configuratieregels voor het maken van records bevat.

Denk aan een e-mail die binnenkomt op een gedeeld supportadres. In plaats van deze in een mailbox te laten staan tot iemand hem ziet, zet een regel die e-mail om in een case. Het bericht wordt het begin van het werk binnen de klantenservice. Dat vermindert handmatig kopieerwerk. Hetzelfde principe geldt voor andere verbonden kanalen. Het team kiest welke berichten een nieuwe case creëren en welke bij een bestaande horen. Een antwoord op een openstaand probleem blijft bij dat probleem. Een nieuwe vraag krijgt een eigen case. Vervolgens heeft de case een thuis nodig terwijl iemand het eigendom neemt. Dat thuis is vaak een wachtrij. Een wachtrij is een gedeelde werkbak voor een team. Het is niet de inbox van één medewerker en het behoort niet toe aan degene die het verzoek zag. In plaats daarvan geeft het het hele team een plek om werk te zien dat op aandacht wacht. Stel je een bedrijf voor met een facturatie team, een technisch support team en een retour team.

Elk team heeft zijn eigen wachtrij. Facturatie vragen gaan naar facturatie, productfouten naar technische ondersteuning, retourverzoeken naar de mensen die het retourproces kennen. Dat klinkt eenvoudig omdat het dat is. Duidelijke sortering voorkomt dat mensen werk blindelings doorsturen. Routeringsregels helpen bij die sortering. Een routeringsregel controleert de details van een case en stuurt deze naar de juiste wachtrij of persoon. Een case over een specifiek product gaat naar het product team. Een case uit een bepaalde regio gaat naar lokale ondersteuning. Een ernstig probleem gaat naar een dringende wachtrij. Een algemene vraag wacht bij het standaard team. Sommige organisaties routeren werk op basis van vaardigheden. Een klant die in het Frans schrijft, heeft bijvoorbeeld een Franstalige medewerker nodig. Een technisch probleem vereist iemand die is getraind voor een specifiek product.

Routering brengt de case dichter bij de persoon die het kan oplossen in plaats van elk verzoek hetzelfde te behandelen. Automatisering helpt, maar mensen nemen nog steeds de beslissingen. Een teamleider kan naar een moeilijke case kijken en deze direct toewijzen aan een seniormedewerker. Misschien kent iemand de klant al. Misschien overschrijdt het probleem meerdere producten en is er ervaring nodig die een regel niet kan inschatten. Want matige toewijzing geeft het team ruimte voor die menselijke keuze. Eigenaarschap kan veranderen tijdens een case. Een medewerker heeft mogelijk meer informatie nodig en zet de case terug in een wachtrij. Een team ontdekt wellicht dat het probleem bij een andere afdeling hoort of een urgent verzoek moet worden geëscaleerd als het reguliere team het niet kan oplossen. Dynamics 365 houdt het werk in beweging in plaats van het bij iemand te laten stagneren.

Soms zorgt één probleem voor veel cases. Stel je een software storing voor die tientallen klanten treft. Elke klant neemt apart contact op met support, dus elke melding heeft een eigen case nodig. Maar alle meldingen zijn verbonden aan één groter probleem. Een bovenliggende case volgt dat grotere probleem, terwijl onderliggende cases individuele klantmeldingen bijhouden. Dat geeft het support team twee overzichten tegelijk. Ze werken aan de onderliggende storing via de bovenliggende case, terwijl elke onderliggende case de juiste klant op de hoogte houdt. Wanneer ze de oplossing vinden, hoeven ze niet voor elke beller de storing opnieuw te onderzoeken. Dubbele cases zorgen voor een vergelijkbaar probleem op kleinere schaal. Een klant kan e-mailen en bellen over hetzelfde probleem, of twee medewerkers openen cases voordat ze de andere opmerken. In plaats van inspanningen te versnipperen, kan het team soortgelijke cases samenvoegen.

Eén case wordt het hoofddossier en het werk blijft bij elkaar. Niemand hoeft hetzelfde probleem twee keer op te lossen. Een case in de juiste wachtrij en bij de juiste persoon krijgen is het begin, en de klant verwacht een reactie binnen de toegezegde tijd. Afspraken nakomen met slaas en begeleid werk. Een case bij de juiste persoon krijgen is pas het halve werk, want de klant verwacht ook hulp binnen de beloofde tijd. En dat is waar een service level agreement, ik noem het een sla, van pas komt. Een sla hangt een klok aan de case, zodat het team precies weet hoe lang ze hebben om aan een belofte te voldoen, of het nu gaat om een eerste reactie of het volledig oplossen van het probleem. Maar hier is het belangrijk. Dat zijn niet altijd dezelfde deadlines. Neem een klant die een bevestiging verwacht binnen één uur, zelfs als het technische team twee werkdagen nodig heeft om de oplossing te vinden en te testen.

Dynamics 365 houdt het eerste response target en een resolutietarget afzonderlijk bij, zodat het team snel kan handelen zonder te doen alsof elk probleem direct is opgelost. Stel je nu een klant voor wiens dienst niet meer werkt. Ze verwachten geen volledige reparatie binnen tien minuten, maar wel dat iemand bevestigt dat het probleem bekend is, uitlegt wat er daarna gebeurt en hen op de hoogte houdt. Het eerste response target houdt dat eerste contact bij, terwijl het resolutietarget het volledige traject naar een antwoord of oplossing volgt. En verschillende klanten kunnen verschillende beloftes krijgen. Een bedrijf met premium ondersteuning krijgt snellere response targets dan een klant met een standaardabonnement. Een storing met hoge prioriteit krijgt een kortere deadline dan een routinematige vraag. Ondersteuningsovereenkomsten, prioriteit en zaak type bepalen de geldende tijdregels.

Dat houdt de beloftes eerlijk en duidelijk. Zonder slaas kan een medewerker werken vanaf het oudste item in een lijst, terwijl een tijdgevoelige zaak stilletjes zijn deadline overschrijdt. Met slaas toont het zakenscherm tijdsindicatoren die de medewerker vertellen welke belofte als eerste aandacht nodig heeft. Je ziet dus de druk opbouwen. Een zaak met nog veel tijd over heeft werk nodig, maar een zaak die zijn responstermijn nadert, vereist nu aandacht. Teams kunnen ook waarschuwingen of escalatiestappen instellen wanneer een doel bijna is bereikt of al is verstreken, zodat een supervisor kan ingrijpen voordat de klant het team moet achterna zitten. Tijdsdoelen sturen de urgentie en bedrijfsprocesstromen sturen het werk zelf aan. Een bedrijfsprocesstroom is een reeks fase die in de zaak worden weergegeven. Het geeft de medewerker een duidelijk pad om te volgen, gebaseerd op hoe de organisatie wil dat zaken worden afgehandeld.

De fase kunnen lopen van intake naar onderzoek tot resolutie, met de juiste vragen en controles op elk punt. Zie het als een checklist met een plek in het proces. Een nieuwe medewerker hoeft niet te raden welke details belangrijk zijn voordat een zaak naar een specialist wordt gestuurd. De stroom kan vragen om het product, type probleem, impact en andere informatie die het volgende team nodig heeft. Een ervaren medewerker kan sneller werken, maar het gedeelde pad zorgt ervoor dat het team in dezelfde richting blijft werken. Hier is een scenario. Een service storing met hoge prioriteit komt binnen. De zaak komt in de urgente wachtrij terecht en de sla begint af te tellen. De medewerker bevestigt de gegevens van de klant, registreert de impact en verstuurt de eerste reactie voordat het response target verloopt. Vervolgens verplaatst de processtroom de zaak naar de diagnosefase, waar het team vouwdetails verzamelt en controleert op gerelateerde rapporten.

De zaak gaat dan over naar de resolutiefase wanneer het team de oorzaak identificeert en een update voor de klant voorbereidt. Die reeks geeft managers ook een duidelijker beeld. Ze kunnen zien waar het proces vertraagt tijdens de intake, diagnose of de uiteindelijke klantreactie. De flow lost het probleem niet op voor het team, maar voorkomt dat basisstappen vergeten worden op een drukke dag. Dynamics 365 kan ook bepalen welke statuswijzigingen een agenten op verschillende momenten kunnen kiezen. Dit noemen we statusredentransities. Dat klinkt technisch, maar het idee is simpel. Een dossier moet logische stappen doorlopen. Je wilt niet dat iemand een dossier als opgelost markeert terwijl het nog wacht op een vereiste interne controle, of van een nieuw dossier direct naar geannuleerd springt zonder opgave van reden. De toegestane keuzes kunnen veranderen naarmate het dossier vordert. Een dossier in onderzoek kan een agent bijvoorbeeld de optie geven om het op pauze te zetten in afwachting van klantgegevens.

Nadat de klant heeft gereageerd, kan de agent het dossier weer in behandeling nemen. Wanneer het probleem is verholpen, kan het dossier naar opgelost worden verplaatst. Dat zorgt voor een overzichtelijkere dossiergeschiedenis. Een antwoord alleen is niet voldoende om het werk af te ronden. Het team moet vastleggen hoe het probleem is geëindigd en het dossier daarna correct sluiten. Oplossing, leerervaring en betere service. Het sturen van een antwoord sluit een dossier niet automatisch. Het team moet de oplossing vastleggen, wat betekent noteren wat het probleem heeft verholpen of welk definitief antwoord de klant heeft gekregen. Dat kan zijn vervangend apparaat verstuurd, dubbele betaling terugbetaald of de klant heeft de instelling aangepast die de toegang blokkeerde. Die notitie wordt onderdeel van het klantendossier en geeft de volgende agent een nuttig startpunt als dezelfde klant maanden later opnieuw contact opneemt met een gerelateerd probleem.

Soms werkt de eerste oplossing niet. Misschien volgt de klant de instructies op en keert de fout terug. Misschien komt er een vervangend onderdeel aan, maar lost dit het effect niet op. In die situatie kan het team het dossier heropenen of terug in de wachtrij plaatsen voor verder onderzoek, in plaats van een volledig nieuw dossier zonder historie te starten. Het dossier gaat verder waar het team was gebleven. Dat is belangrijk als het eigenaarschap verandert. Een nieuwe agent kan zien wat de voorrige agent heeft geprobeerd, wat de klant heeft bevestigd en wat er nog moet worden gecontroleerd. De klant hoeft niet het hele verhaal vanaf het begin uit te leggen alleen omdat iemand anders het werk heeft overgenomen. Na verloop van tijd vertellen al die dossiers het ondersteuningsteam ook wat er speelt buiten één enkel klantprobleem om. Managers kunnen kijken naar de oplostijd die bijhoudt hoe lang dossiers duren van opening tot sluiting.

Ze kunnen kijken naar de doorlooptijd per fase, wat laat zien waar dossiers de meeste tijd kosten. Ze kunnen ook de first contact resolution in de gaten houden hoe vaak de eerste persoon die de klant spreekt het probleem kan oplossen zonder overdracht. Werkdruk is ook belangrijk. Als een wachtrij elke maandagochtend vol loopt, kan het team dat zien. Als technische cases dagenlang wachten op een interne controle, verschijnt die vertraging in de case data. Als een team cases snel sluit, maar klanten ze steeds heropenen, heeft het team reden om de kwaliteit van die eerste oplossingen beter te bekijken. De cijfers verklaren niet alles uit zichzelf. Ze wijzen het team op de vragen die het waard zijn om te stellen. Waarom nemen cases over één product toe? Waarom duurt een bepaald type case langer dan verwacht? Waarom zoeken medewerkers herhaaldelijk naar hetzelfde antwoord zonder een bruikbaar kennisartikel te vinden?

Patronen veranderen dagelijks supportwerk in praktisch leervermogen. Een stijging in vergelijkbare cases kan wijzen op een productfout. Het kan laten zien dat een recente update klanten in verwarring bracht. Het kan onthullen dat een handleiding duidelijkere stappen nodig heeft. In plaats van elk verzoek als losstaand te behandelen, kan het team de gedeelde oorzaak vinden en aanpakken. Dat kan het toekomstige aantal cases verminderen. Klantfeedback hoort ook in dat plaatje thuis. Een gesloten case laat misschien zien dat het team de respons tijd haalde, maar de klant kan toch gefrustreerd zijn als ze drie keer contact moesten opnemen. Kijken naar zowel de case geschiedenis als de feedback geeft managers een completer beeld van de ervaring. Sommige klanten vermijden liever helemaal het aanmaken van een case. Daar kan een self-service portal helpen. Via een portal kunnen klanten een verzoek aanmaken, de status controleren, nieuwe informatie toevoegen of goedgekeurde supportartikelen lezen zonder het support team te bellen.

Voor eenvoudige vragen kan dat voor iedereen tijd besparen. Een klant kan een leveringstatus controleren of een installatiehandleiding volgen wanneer het hen uitkomt. Ondertussen kunnen medewerkers meer tijd besteden aan zaken waarvoor een mens moet onderzoeken, uitleggen of beslissen. Dynamics 365 Customer Service kan ook verbinding maken met bekende Microsoft tools rondom het case-proces. Een medewerker kan met e-mail werken via Outlook. Een team kan een lastig probleem bespreken in Teams. Documenten en gedeelde informatie kunnen in SharePoint staan. Power BI kan case-data omzetten in rapporten en dashboards, terwijl Power Platform tools extra formulieren, meldingen of geautomatiseerde stappen voor het teamproces kunnen ondersteunen. Elke tool heeft zijn eigen taak. De case blijft de plek waar het supportprobleem en de geschiedenis verbonden blijven, zelfs wanneer mensen andere tools gebruiken om te communiceren, bestanden te delen of het werk te beoordelen.

Case Management gaat niet echt over het invullen van een ticketscherm. Het gaat er om elk klantprobleem een duidelijk pad, een vastgelegd antwoord en een team dat leert van wat er is gebeurd, te geven. Conclusie Hou het volledige klantverhaal bij elkaar Dus, dit is de belangrijkste lay. Dynamics 365 Case Management houdt het probleem, het werk, de beloftes en het resultaat in één dossier. Geen verloren context of dubbel werk meer. Kijk eens naar je eigen ondersteuningsproces. Oh, waar verdwijnt klantinformatie allemaal? Dat is waar alles samenbrengen het verschil maakt. Abonneer je op je favoriete podcastplatform voor meer Microsoft-kennis van mij, Mirko Peters op m365.fm, waar we de Microsoft tools voor dagelijks werk in begrijpelijke taal uitleggen. Kijk eens naar je vooral.