WEBVTT 00:00:00.000 --> 00:00:10.980 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. 00:00:11.240 --> 00:00:14.920 Dat is precies wat Dynamics 365 Case Management oplost. 00:00:15.160 --> 00:00:22.300 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. 00:00:22.300 --> 00:00:31.740 Je bent Mirko Peters van M365FM en in dit kennisfragment zie je hoe cases, routering, reactietermijnen, supportartikelen en afsluiting allemaal samenkomen. 00:00:31.960 --> 00:00:35.840 Wat een case nu eigenlijk is in twintig woorden. Dus, wat is een case nu precies? 00:00:36.040 --> 00:00:45.540 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. 00:00:45.700 --> 00:00:48.480 Dit is het punt één klant kan meerdere cases tegelijk hebben. 00:00:48.480 --> 00:00:54.780 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. 00:00:55.040 --> 00:01:01.660 Dat zijn afzonderlijke problemen, dus Dynamics 365 houdt ze in aparte case dossiers in plaats van elk gesprek op een grote hoop te gooien. 00:01:01.880 --> 00:01:05.220 Wanneer een medewerker een case aanmaakt, koppelt hij deze direct aan de klant. 00:01:05.420 --> 00:01:10.560 Die klant kan een contactpersoon zijn, oftewel een individu, of een account, oftewel het bedrijf waarvoor ze werken. 00:01:10.560 --> 00:01:20.440 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. 00:01:20.680 --> 00:01:30.560 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, 00:01:30.740 --> 00:01:35.000 en die titel helpt mensen een lijst met open cases te scannen zonder elk dossier te openen. 00:01:35.000 --> 00:01:44.700 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? 00:01:44.940 --> 00:01:50.320 Deze details veranderen een vaag bericht in werk dat iemand kan oppakken en oplossen. Laten we dit verder uitsplitsen. 00:01:50.480 --> 00:01:53.900 Een case kan een onderwerp, product, prioriteit en casetype bevatten. 00:01:54.080 --> 00:02:00.020 Het onderwerp groepeert het probleem in een categorie zoals facturering of technische ondersteuning, het product identificeert wat de klant gebruikt, 00:02:00.020 --> 00:02:06.960 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. 00:02:07.200 --> 00:02:13.180 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, 00:02:13.380 --> 00:02:15.920 vooral wanneer honderden cases van verschillende klanten binnenkomen. 00:02:16.100 --> 00:02:21.300 Een team dat te maken heeft met een ernstige service storing zou niet door algemene vragen hoeven te zoeken om deze te vinden. 00:02:21.520 --> 00:02:24.940 Een case is nu niet zomaar een formulier dat iemand invult en vergeet. 00:02:24.940 --> 00:02:29.120 Het wordt het werkdossier voor het hele gesprek. E-mails kunnen aan de case worden gekoppeld, 00:02:29.320 --> 00:02:33.260 telefoongesprekken kunnen erin verschijnen en een medewerker kan na een chatnotices toevoegen, 00:02:33.420 --> 00:02:35.720 een vervolgtaak instellen of een afspraak vastleggen. 00:02:35.880 --> 00:02:42.040 Elke activiteit blijft verbonden aan hetzelfde klantprobleem, zodat de volgende persoon het verhaal niet vanaf nul hoeft op te bouwen. 00:02:42.260 --> 00:02:47.140 Stel je voor dat een medewerker s'ochtends aan het werk gaat en de case naar de lunch overdraagt aan een productspecialist. 00:02:47.360 --> 00:02:50.860 Zonder case dossier krijgt de specialist misschien slechts één kort bericht, zoals 00:02:50.860 --> 00:02:56.040 Oh, kun je hier even naar kijken? Wat niet voldoende is. Met het case dossier kunnen ze het oorspronkelijke probleem zien, 00:02:56.240 --> 00:03:00.320 klantgegevens, wat er tijdens het gesprek is gebeurd en wat de eerste medewerker al heeft gecontroleerd. 00:03:00.520 --> 00:03:02.300 Dat zorgt voor een veel betere overdracht. 00:03:02.560 --> 00:03:07.220 Dynamics 365 houdt de case in een duidelijke status terwijl deze door het ondersteuningsproces gaat. 00:03:07.420 --> 00:03:13.400 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. 00:03:13.400 --> 00:03:19.720 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. 00:03:19.720 --> 00:03:21.800 Actief, opgelost en geannuleerd. 00:03:22.840 --> 00:03:34.700 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. 00:03:35.780 --> 00:03:40.320 Eén dossier geeft je controle en de volledige klantgeschiedenis geeft de medewerker context. 00:03:41.000 --> 00:03:42.740 Het klantverhaal achter de case. 00:03:42.980 --> 00:03:45.000 Een case vertelt je wat er moet worden opgelost. 00:03:45.200 --> 00:03:47.720 Het klantendossier vertelt je wat tot dit moment heeft geleid. 00:03:47.720 --> 00:03:53.380 Wanneer een medewerker een case opent in Dynamics 365 Customer Service, kunnen ze verder kijken dan het laatste bericht. 00:03:53.580 --> 00:03:59.460 Ze zien het grotere geheel, eerdere cases, eerdere e-mails, de producten die aan de klant zijn gekoppeld en een ondersteuningsgeschiedenis. 00:03:59.700 --> 00:04:01.140 Context verandert het gesprek. 00:04:01.340 --> 00:04:02.500 Waarom is context belangrijk? 00:04:02.900 --> 00:04:05.300 Stel je voor dat een klant een defect aan een apparaat meldt. 00:04:05.440 --> 00:04:08.900 Als de medewerker alleen het bericht van vandaag ziet, beginnen ze mogelijk met basisvragen. 00:04:09.100 --> 00:04:10.240 Om welk model gaat het? 00:04:10.400 --> 00:04:11.240 Wanneer is het begonnen? 00:04:11.440 --> 00:04:12.600 Heeft u het opnieuw opgestart? 00:04:12.780 --> 00:04:15.620 Maar de klant heeft deze week al twee keer contact opgenomen met de supportafdeling. 00:04:15.620 --> 00:04:19.320 De eerste medewerker stuurde stappen voor probleemoplossing, de tweede regelde een vervangend onderdeel. 00:04:19.420 --> 00:04:22.680 Een derde medewerker die die historie ziet, zal de klant niet vragen om opnieuw te beginnen. 00:04:22.860 --> 00:04:26.780 In plaats daarvan zeggen ze, ik zie dat u die stappen al heeft geprobeerd en dat het vervangende onderdeel het niet heeft opgelost. 00:04:26.960 --> 00:04:28.220 Laten we de volgende stap proberen. 00:04:28.820 --> 00:04:29.180 Aanhalingsteken. 00:04:29.400 --> 00:04:31.960 Dat voelt heel anders dan, kunt u het probleem nog eens uitleggen? 00:04:32.100 --> 00:04:34.880 Dit wordt vaak een 360 graden klantbeeld genoemd. 00:04:35.020 --> 00:04:36.720 De naam klinkt chic, maar het is simpel. 00:04:36.900 --> 00:04:41.320 Het betekent dat de medewerker de klant vanuit meer dan één invalshoek ziet, niet slechts één losbericht. 00:04:41.320 --> 00:04:47.640 De medewerker ziet de persoon, ze zien het bedrijf, ze zien eerdere supportaanvragen, eerdere gesprekken en de producten die eraan gekoppeld zijn. 00:04:47.840 --> 00:04:50.800 Voor een supportteam vervangt dat gissen door een duidelijk vertrekpunt. 00:04:51.000 --> 00:04:53.580 Nu krijgt niet elke klant hetzelfde soort ondersteuning. 00:04:53.800 --> 00:04:58.460 Een klant kan garantie hebben gekocht, hun bedrijf kan betalen voor een vast aantal supporturen, 00:04:58.780 --> 00:05:03.240 of ze hebben een contract voor een bepaald aantal zaken, of premium support met snellere hulp. 00:05:03.440 --> 00:05:06.800 Dynamics 365 houdt dit allemaal bij via rechten. 00:05:07.140 --> 00:05:10.240 Een recht is de supportovereenkomst van de klant in het systeem. 00:05:10.240 --> 00:05:13.260 Zie het als de servicevoorwaarden die aan een account zijn gekoppeld. 00:05:13.460 --> 00:05:18.740 Voordat de medewerker een engineer toezegt of betaald werk start, controleren ze welke ondersteuning van toepassing is. 00:05:18.980 --> 00:05:20.800 Dat voorkomt ongemakkelijke verrassingen. 00:05:21.000 --> 00:05:23.760 Een klant kan bijvoorbeeld nog garantie hebben op een defect product. 00:05:23.980 --> 00:05:25.500 De zaak kan dat traject volgen. 00:05:25.700 --> 00:05:28.100 Een andere klant heeft misschien al zijn supporturen verbruikt. 00:05:28.320 --> 00:05:31.280 De medewerker ziet dat voordat hij zich vastlegt op werk buiten de overeenkomst. 00:05:31.420 --> 00:05:33.700 Het helpt het supportteam ook om klanten eerlijk te behandelen. 00:05:33.880 --> 00:05:37.120 De medewerker hoeft niet in oude contracten te zoeken of een andere afdeling te vragen. 00:05:37.120 --> 00:05:40.720 De supportvoorwaarden staan bij de klantgegevens, precies waar de medewerker ze kan vinden. 00:05:40.900 --> 00:05:42.080 Dan is er nog de kennisbank. 00:05:42.420 --> 00:05:44.640 Supportteams lossen dezelfde problemen telkens weer op. 00:05:45.140 --> 00:05:49.960 Wachtwoordresets, installatieinstructies, een bekende fout na een update, een factuurvraag met een standaard antwoord. 00:05:50.100 --> 00:05:52.300 Een kennisartikel slaat dat antwoord op één plek op. 00:05:52.520 --> 00:05:56.300 Binnen de servicewerkruimte kan een medewerker naar artikelen zoeken terwijl hij aan een zaak werkt. 00:05:56.460 --> 00:06:01.880 Een artikel kan een eenvoudige uitleg, stappen, een schermafbeelding of de exacte controles bevatten die het team moet uitvoeren. 00:06:01.880 --> 00:06:07.020 In plaats van dat elke medewerker uit het hoofd zijn eigen versie schrijft, gebruiken ze een gedeeld antwoord dat het team heeft beoordeeld. 00:06:07.200 --> 00:06:08.660 Dat houdt de ondersteuning consistent. 00:06:08.980 --> 00:06:10.540 Het helpt ook nieuwere medewerkers. 00:06:10.760 --> 00:06:16.340 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. 00:06:16.480 --> 00:06:20.080 Copilot caseoverzichten helpen bij een ander veelvoorkomend probleem, lange casegeschiedenissen. 00:06:20.220 --> 00:06:23.360 Een case kan in de loop van de tijd veel e-mails, notices en updates verzamelen. 00:06:23.540 --> 00:06:26.040 Het lezen van alles kost tijd, zeker na een overdracht. 00:06:26.040 --> 00:06:33.320 Copilot maakt een kort caseoverzicht waarin de case-titel, klant, onderwerp, product, prioriteit, case-type, beschrijving en recente activiteit worden samengebracht. 00:06:33.500 --> 00:06:35.980 Het is een snelle briefing voordat de medewerker aan het werk gaat. 00:06:36.200 --> 00:06:40.740 De medewerker controleert nog steeds het dossier en gebruikt hun eigen inzicht, maar ze begrijpen de situatie sneller. 00:06:40.980 --> 00:06:44.340 Dat helpt wanneer de klant wacht en de case door verschillende handen is gegaan. 00:06:44.580 --> 00:06:49.200 Zodra de medewerker de klant en het probleem begrijpt, moet de case de juiste persoon bereiken. 00:06:49.200 --> 00:06:52.220 Van intake naar de juiste wachtrij. 00:06:52.420 --> 00:06:57.820 Een klant kan op veel manieren om hulp vragen, e-mail, telefoongesprek, chat, sociale media, een self-service portal. 00:06:58.020 --> 00:07:02.200 Het kanaal verandert, maar het support team heeft nog steeds één duidelijke plek nodig om het verzoek te beheren. 00:07:02.400 --> 00:07:07.940 Dynamics 365 kan cases maken van die gesprekken wanneer de configuratieregels voor het maken van records bevat. 00:07:08.180 --> 00:07:10.880 Denk aan een e-mail die binnenkomt op een gedeeld supportadres. 00:07:10.880 --> 00:07:15.580 In plaats van deze in een mailbox te laten staan tot iemand hem ziet, zet een regel die e-mail om in een case. 00:07:15.760 --> 00:07:18.300 Het bericht wordt het begin van het werk binnen de klantenservice. 00:07:18.300 --> 00:07:20.480 Dat vermindert handmatig kopieerwerk. 00:07:20.680 --> 00:07:23.100 Hetzelfde principe geldt voor andere verbonden kanalen. 00:07:23.300 --> 00:07:27.040 Het team kiest welke berichten een nieuwe case creëren en welke bij een bestaande horen. 00:07:27.220 --> 00:07:29.660 Een antwoord op een openstaand probleem blijft bij dat probleem. 00:07:29.780 --> 00:07:31.300 Een nieuwe vraag krijgt een eigen case. 00:07:31.520 --> 00:07:33.900 Vervolgens heeft de case een thuis nodig terwijl iemand het eigendom neemt. 00:07:34.040 --> 00:07:35.280 Dat thuis is vaak een wachtrij. 00:07:35.460 --> 00:07:37.440 Een wachtrij is een gedeelde werkbak voor een team. 00:07:37.440 --> 00:07:41.360 Het is niet de inbox van één medewerker en het behoort niet toe aan degene die het verzoek zag. 00:07:41.500 --> 00:07:44.680 In plaats daarvan geeft het het hele team een plek om werk te zien dat op aandacht wacht. 00:07:44.680 --> 00:07:48.720 Stel je een bedrijf voor met een facturatie team, een technisch support team en een retour team. 00:07:48.900 --> 00:07:50.400 Elk team heeft zijn eigen wachtrij. 00:07:50.760 --> 00:07:54.220 Facturatie vragen gaan naar facturatie, productfouten naar technische ondersteuning, 00:07:54.420 --> 00:07:56.560 retourverzoeken naar de mensen die het retourproces kennen. 00:07:56.780 --> 00:07:58.360 Dat klinkt eenvoudig omdat het dat is. 00:07:58.620 --> 00:08:01.560 Duidelijke sortering voorkomt dat mensen werk blindelings doorsturen. 00:08:02.160 --> 00:08:03.520 Routeringsregels helpen bij die sortering. 00:08:03.700 --> 00:08:07.720 Een routeringsregel controleert de details van een case en stuurt deze naar de juiste wachtrij of persoon. 00:08:07.880 --> 00:08:10.460 Een case over een specifiek product gaat naar het product team. 00:08:10.620 --> 00:08:13.120 Een case uit een bepaalde regio gaat naar lokale ondersteuning. 00:08:13.120 --> 00:08:15.180 Een ernstig probleem gaat naar een dringende wachtrij. 00:08:15.340 --> 00:08:17.300 Een algemene vraag wacht bij het standaard team. 00:08:17.520 --> 00:08:19.960 Sommige organisaties routeren werk op basis van vaardigheden. 00:08:20.120 --> 00:08:23.120 Een klant die in het Frans schrijft, heeft bijvoorbeeld een Franstalige medewerker nodig. 00:08:23.320 --> 00:08:26.040 Een technisch probleem vereist iemand die is getraind voor een specifiek product. 00:08:26.260 --> 00:08:30.300 Routering brengt de case dichter bij de persoon die het kan oplossen in plaats van elk verzoek hetzelfde te behandelen. 00:08:30.740 --> 00:08:32.960 Automatisering helpt, maar mensen nemen nog steeds de beslissingen. 00:08:33.120 --> 00:08:36.860 Een teamleider kan naar een moeilijke case kijken en deze direct toewijzen aan een seniormedewerker. 00:08:37.020 --> 00:08:38.380 Misschien kent iemand de klant al. 00:08:38.380 --> 00:08:42.340 Misschien overschrijdt het probleem meerdere producten en is er ervaring nodig die een regel niet kan inschatten. 00:08:42.540 --> 00:08:45.300 Want matige toewijzing geeft het team ruimte voor die menselijke keuze. 00:08:45.600 --> 00:08:47.240 Eigenaarschap kan veranderen tijdens een case. 00:08:47.440 --> 00:08:50.680 Een medewerker heeft mogelijk meer informatie nodig en zet de case terug in een wachtrij. 00:08:50.860 --> 00:08:53.620 Een team ontdekt wellicht dat het probleem bij een andere afdeling hoort 00:08:53.620 --> 00:08:57.060 of een urgent verzoek moet worden geëscaleerd als het reguliere team het niet kan oplossen. 00:08:57.300 --> 00:09:01.800 Dynamics 365 houdt het werk in beweging in plaats van het bij iemand te laten stagneren. 00:09:02.000 --> 00:09:03.960 Soms zorgt één probleem voor veel cases. 00:09:04.360 --> 00:09:07.040 Stel je een software storing voor die tientallen klanten treft. 00:09:07.040 --> 00:09:10.980 Elke klant neemt apart contact op met support, dus elke melding heeft een eigen case nodig. 00:09:11.180 --> 00:09:13.700 Maar alle meldingen zijn verbonden aan één groter probleem. 00:09:13.860 --> 00:09:15.980 Een bovenliggende case volgt dat grotere probleem, 00:09:16.020 --> 00:09:18.600 terwijl onderliggende cases individuele klantmeldingen bijhouden. 00:09:18.780 --> 00:09:20.860 Dat geeft het support team twee overzichten tegelijk. 00:09:21.060 --> 00:09:23.480 Ze werken aan de onderliggende storing via de bovenliggende case, 00:09:23.680 --> 00:09:26.200 terwijl elke onderliggende case de juiste klant op de hoogte houdt. 00:09:26.280 --> 00:09:29.860 Wanneer ze de oplossing vinden, hoeven ze niet voor elke beller de storing opnieuw te onderzoeken. 00:09:30.080 --> 00:09:32.860 Dubbele cases zorgen voor een vergelijkbaar probleem op kleinere schaal. 00:09:32.860 --> 00:09:35.400 Een klant kan e-mailen en bellen over hetzelfde probleem, 00:09:35.520 --> 00:09:38.220 of twee medewerkers openen cases voordat ze de andere opmerken. 00:09:38.360 --> 00:09:42.000 In plaats van inspanningen te versnipperen, kan het team soortgelijke cases samenvoegen. 00:09:42.160 --> 00:09:44.740 Eén case wordt het hoofddossier en het werk blijft bij elkaar. 00:09:44.980 --> 00:09:47.240 Niemand hoeft hetzelfde probleem twee keer op te lossen. 00:09:47.400 --> 00:09:50.840 Een case in de juiste wachtrij en bij de juiste persoon krijgen is het begin, 00:09:51.040 --> 00:09:53.500 en de klant verwacht een reactie binnen de toegezegde tijd. 00:09:54.040 --> 00:09:56.400 Afspraken nakomen met slaas en begeleid werk. 00:09:56.740 --> 00:09:59.400 Een case bij de juiste persoon krijgen is pas het halve werk, 00:09:59.400 --> 00:10:01.920 want de klant verwacht ook hulp binnen de beloofde tijd. 00:10:02.060 --> 00:10:05.860 En dat is waar een service level agreement, ik noem het een sla, van pas komt. 00:10:06.060 --> 00:10:07.520 Een sla hangt een klok aan de case, 00:10:07.760 --> 00:10:10.740 zodat het team precies weet hoe lang ze hebben om aan een belofte te voldoen, 00:10:11.000 --> 00:10:14.220 of het nu gaat om een eerste reactie of het volledig oplossen van het probleem. 00:10:14.380 --> 00:10:15.580 Maar hier is het belangrijk. 00:10:15.840 --> 00:10:17.580 Dat zijn niet altijd dezelfde deadlines. 00:10:17.980 --> 00:10:20.320 Neem een klant die een bevestiging verwacht binnen één uur, 00:10:20.540 --> 00:10:24.460 zelfs als het technische team twee werkdagen nodig heeft om de oplossing te vinden en te testen. 00:10:25.060 --> 00:10:29.260 Dynamics 365 houdt het eerste response target en een resolutietarget afzonderlijk bij, 00:10:29.400 --> 00:10:33.080 zodat het team snel kan handelen zonder te doen alsof elk probleem direct is opgelost. 00:10:33.260 --> 00:10:35.580 Stel je nu een klant voor wiens dienst niet meer werkt. 00:10:35.780 --> 00:10:38.340 Ze verwachten geen volledige reparatie binnen tien minuten, 00:10:38.520 --> 00:10:40.660 maar wel dat iemand bevestigt dat het probleem bekend is, 00:10:40.800 --> 00:10:42.860 uitlegt wat er daarna gebeurt en hen op de hoogte houdt. 00:10:42.960 --> 00:10:45.140 Het eerste response target houdt dat eerste contact bij, 00:10:45.320 --> 00:10:48.600 terwijl het resolutietarget het volledige traject naar een antwoord of oplossing volgt. 00:10:48.760 --> 00:10:51.080 En verschillende klanten kunnen verschillende beloftes krijgen. 00:10:51.300 --> 00:10:54.220 Een bedrijf met premium ondersteuning krijgt snellere response targets 00:10:54.220 --> 00:10:55.720 dan een klant met een standaardabonnement. 00:10:55.720 --> 00:11:00.100 Een storing met hoge prioriteit krijgt een kortere deadline dan een routinematige vraag. 00:11:01.020 --> 00:11:04.220 Ondersteuningsovereenkomsten, prioriteit en zaak type bepalen de geldende tijdregels. 00:11:04.440 --> 00:11:06.160 Dat houdt de beloftes eerlijk en duidelijk. 00:11:06.380 --> 00:11:09.200 Zonder slaas kan een medewerker werken vanaf het oudste item in een lijst, 00:11:09.360 --> 00:11:11.880 terwijl een tijdgevoelige zaak stilletjes zijn deadline overschrijdt. 00:11:12.060 --> 00:11:15.380 Met slaas toont het zakenscherm tijdsindicatoren die de medewerker vertellen 00:11:15.380 --> 00:11:17.260 welke belofte als eerste aandacht nodig heeft. 00:11:17.440 --> 00:11:18.780 Je ziet dus de druk opbouwen. 00:11:18.980 --> 00:11:21.060 Een zaak met nog veel tijd over heeft werk nodig, 00:11:21.060 --> 00:11:24.220 maar een zaak die zijn responstermijn nadert, vereist nu aandacht. 00:11:24.400 --> 00:11:26.780 Teams kunnen ook waarschuwingen of escalatiestappen instellen 00:11:26.780 --> 00:11:28.900 wanneer een doel bijna is bereikt of al is verstreken, 00:11:29.120 --> 00:11:32.020 zodat een supervisor kan ingrijpen voordat de klant het team moet achterna zitten. 00:11:32.320 --> 00:11:36.100 Tijdsdoelen sturen de urgentie en bedrijfsprocesstromen sturen het werk zelf aan. 00:11:36.260 --> 00:11:39.580 Een bedrijfsprocesstroom is een reeks fase die in de zaak worden weergegeven. 00:11:39.780 --> 00:11:41.720 Het geeft de medewerker een duidelijk pad om te volgen, 00:11:41.940 --> 00:11:44.520 gebaseerd op hoe de organisatie wil dat zaken worden afgehandeld. 00:11:44.660 --> 00:11:47.380 De fase kunnen lopen van intake naar onderzoek tot resolutie, 00:11:47.540 --> 00:11:49.640 met de juiste vragen en controles op elk punt. 00:11:49.640 --> 00:11:51.980 Zie het als een checklist met een plek in het proces. 00:11:52.180 --> 00:11:54.900 Een nieuwe medewerker hoeft niet te raden welke details belangrijk zijn 00:11:54.900 --> 00:11:56.600 voordat een zaak naar een specialist wordt gestuurd. 00:11:56.760 --> 00:11:59.320 De stroom kan vragen om het product, type probleem, impact 00:11:59.320 --> 00:12:01.340 en andere informatie die het volgende team nodig heeft. 00:12:01.520 --> 00:12:03.260 Een ervaren medewerker kan sneller werken, 00:12:03.400 --> 00:12:06.200 maar het gedeelde pad zorgt ervoor dat het team in dezelfde richting blijft werken. 00:12:06.380 --> 00:12:07.240 Hier is een scenario. 00:12:07.600 --> 00:12:09.860 Een service storing met hoge prioriteit komt binnen. 00:12:10.060 --> 00:12:13.220 De zaak komt in de urgente wachtrij terecht en de sla begint af te tellen. 00:12:13.400 --> 00:12:15.520 De medewerker bevestigt de gegevens van de klant, 00:12:15.840 --> 00:12:19.600 registreert de impact en verstuurt de eerste reactie voordat het response target verloopt. 00:12:19.820 --> 00:12:22.560 Vervolgens verplaatst de processtroom de zaak naar de diagnosefase, 00:12:22.820 --> 00:12:25.900 waar het team vouwdetails verzamelt en controleert op gerelateerde rapporten. 00:12:26.040 --> 00:12:27.880 De zaak gaat dan over naar de resolutiefase 00:12:27.880 --> 00:12:31.140 wanneer het team de oorzaak identificeert en een update voor de klant voorbereidt. 00:12:31.260 --> 00:12:33.560 Die reeks geeft managers ook een duidelijker beeld. 00:12:33.760 --> 00:12:36.160 Ze kunnen zien waar het proces vertraagt tijdens de intake, 00:12:36.440 --> 00:12:38.420 diagnose of de uiteindelijke klantreactie. 00:12:38.580 --> 00:12:40.420 De flow lost het probleem niet op voor het team, 00:12:40.660 --> 00:12:43.240 maar voorkomt dat basisstappen vergeten worden op een drukke dag. 00:12:43.440 --> 00:12:46.640 Dynamics 365 kan ook bepalen welke statuswijzigingen 00:12:46.640 --> 00:12:48.400 een agenten op verschillende momenten kunnen kiezen. 00:12:48.600 --> 00:12:50.240 Dit noemen we statusredentransities. 00:12:50.520 --> 00:12:52.660 Dat klinkt technisch, maar het idee is simpel. 00:12:52.860 --> 00:12:54.920 Een dossier moet logische stappen doorlopen. 00:12:55.120 --> 00:12:57.120 Je wilt niet dat iemand een dossier als opgelost markeert 00:12:57.120 --> 00:12:59.080 terwijl het nog wacht op een vereiste interne controle, 00:12:59.360 --> 00:13:02.340 of van een nieuw dossier direct naar geannuleerd springt zonder opgave van reden. 00:13:02.540 --> 00:13:05.400 De toegestane keuzes kunnen veranderen naarmate het dossier vordert. 00:13:05.580 --> 00:13:07.920 Een dossier in onderzoek kan een agent bijvoorbeeld de optie geven 00:13:07.920 --> 00:13:10.140 om het op pauze te zetten in afwachting van klantgegevens. 00:13:10.360 --> 00:13:11.560 Nadat de klant heeft gereageerd, 00:13:11.720 --> 00:13:13.300 kan de agent het dossier weer in behandeling nemen. 00:13:13.300 --> 00:13:15.980 Wanneer het probleem is verholpen, kan het dossier naar opgelost worden verplaatst. 00:13:16.100 --> 00:13:18.000 Dat zorgt voor een overzichtelijkere dossiergeschiedenis. 00:13:18.160 --> 00:13:20.060 Een antwoord alleen is niet voldoende om het werk af te ronden. 00:13:20.240 --> 00:13:22.220 Het team moet vastleggen hoe het probleem is geëindigd 00:13:22.220 --> 00:13:23.620 en het dossier daarna correct sluiten. 00:13:23.860 --> 00:13:26.140 Oplossing, leerervaring en betere service. 00:13:26.380 --> 00:13:29.020 Het sturen van een antwoord sluit een dossier niet automatisch. 00:13:29.200 --> 00:13:30.640 Het team moet de oplossing vastleggen, 00:13:30.820 --> 00:13:32.700 wat betekent noteren wat het probleem heeft verholpen 00:13:32.700 --> 00:13:34.600 of welk definitief antwoord de klant heeft gekregen. 00:13:34.820 --> 00:13:36.700 Dat kan zijn vervangend apparaat verstuurd, 00:13:36.940 --> 00:13:39.660 dubbele betaling terugbetaald of de klant heeft de instelling aangepast 00:13:39.660 --> 00:13:40.620 die de toegang blokkeerde. 00:13:40.800 --> 00:13:42.780 Die notitie wordt onderdeel van het klantendossier 00:13:42.780 --> 00:13:44.780 en geeft de volgende agent een nuttig startpunt 00:13:44.780 --> 00:13:48.280 als dezelfde klant maanden later opnieuw contact opneemt met een gerelateerd probleem. 00:13:48.480 --> 00:13:50.140 Soms werkt de eerste oplossing niet. 00:13:50.380 --> 00:13:53.020 Misschien volgt de klant de instructies op en keert de fout terug. 00:13:53.220 --> 00:13:54.900 Misschien komt er een vervangend onderdeel aan, 00:13:55.060 --> 00:13:56.180 maar lost dit het effect niet op. 00:13:56.260 --> 00:13:58.200 In die situatie kan het team het dossier heropenen 00:13:58.200 --> 00:14:00.320 of terug in de wachtrij plaatsen voor verder onderzoek, 00:14:00.320 --> 00:14:02.780 in plaats van een volledig nieuw dossier zonder historie te starten. 00:14:02.920 --> 00:14:04.920 Het dossier gaat verder waar het team was gebleven. 00:14:05.160 --> 00:14:07.000 Dat is belangrijk als het eigenaarschap verandert. 00:14:07.000 --> 00:14:09.500 Een nieuwe agent kan zien wat de voorrige agent heeft geprobeerd, 00:14:09.640 --> 00:14:11.880 wat de klant heeft bevestigd en wat er nog moet worden gecontroleerd. 00:14:12.060 --> 00:14:14.480 De klant hoeft niet het hele verhaal vanaf het begin uit te leggen 00:14:14.480 --> 00:14:16.660 alleen omdat iemand anders het werk heeft overgenomen. 00:14:16.880 --> 00:14:19.580 Na verloop van tijd vertellen al die dossiers het ondersteuningsteam 00:14:19.580 --> 00:14:21.680 ook wat er speelt buiten één enkel klantprobleem om. 00:14:21.900 --> 00:14:23.620 Managers kunnen kijken naar de oplostijd 00:14:23.620 --> 00:14:26.260 die bijhoudt hoe lang dossiers duren van opening tot sluiting. 00:14:26.260 --> 00:14:28.220 Ze kunnen kijken naar de doorlooptijd per fase, 00:14:28.400 --> 00:14:30.100 wat laat zien waar dossiers de meeste tijd kosten. 00:14:30.340 --> 00:14:33.020 Ze kunnen ook de first contact resolution in de gaten houden 00:14:33.020 --> 00:14:36.440 hoe vaak de eerste persoon die de klant spreekt het probleem kan oplossen zonder overdracht. 00:14:36.440 --> 00:14:37.960 Werkdruk is ook belangrijk. 00:14:38.200 --> 00:14:41.100 Als een wachtrij elke maandagochtend vol loopt, kan het team dat zien. 00:14:41.340 --> 00:14:44.060 Als technische cases dagenlang wachten op een interne controle, 00:14:44.340 --> 00:14:45.900 verschijnt die vertraging in de case data. 00:14:46.200 --> 00:14:49.040 Als een team cases snel sluit, maar klanten ze steeds heropenen, 00:14:49.240 --> 00:14:52.460 heeft het team reden om de kwaliteit van die eerste oplossingen beter te bekijken. 00:14:52.660 --> 00:14:54.780 De cijfers verklaren niet alles uit zichzelf. 00:14:54.780 --> 00:14:57.460 Ze wijzen het team op de vragen die het waard zijn om te stellen. 00:14:57.700 --> 00:14:59.620 Waarom nemen cases over één product toe? 00:14:59.800 --> 00:15:02.100 Waarom duurt een bepaald type case langer dan verwacht? 00:15:02.100 --> 00:15:06.680 Waarom zoeken medewerkers herhaaldelijk naar hetzelfde antwoord zonder een bruikbaar kennisartikel te vinden? 00:15:06.860 --> 00:15:09.740 Patronen veranderen dagelijks supportwerk in praktisch leervermogen. 00:15:09.920 --> 00:15:12.560 Een stijging in vergelijkbare cases kan wijzen op een productfout. 00:15:12.740 --> 00:15:15.280 Het kan laten zien dat een recente update klanten in verwarring bracht. 00:15:15.440 --> 00:15:18.120 Het kan onthullen dat een handleiding duidelijkere stappen nodig heeft. 00:15:18.120 --> 00:15:22.360 In plaats van elk verzoek als losstaand te behandelen, kan het team de gedeelde oorzaak vinden en aanpakken. 00:15:22.540 --> 00:15:24.500 Dat kan het toekomstige aantal cases verminderen. 00:15:24.860 --> 00:15:26.580 Klantfeedback hoort ook in dat plaatje thuis. 00:15:26.580 --> 00:15:32.980 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. 00:15:33.160 --> 00:15:37.260 Kijken naar zowel de case geschiedenis als de feedback geeft managers een completer beeld van de ervaring. 00:15:37.540 --> 00:15:40.100 Sommige klanten vermijden liever helemaal het aanmaken van een case. 00:15:40.340 --> 00:15:42.100 Daar kan een self-service portal helpen. 00:15:42.340 --> 00:15:49.840 Via een portal kunnen klanten een verzoek aanmaken, de status controleren, nieuwe informatie toevoegen of goedgekeurde supportartikelen lezen zonder het support team te bellen. 00:15:50.020 --> 00:15:52.680 Voor eenvoudige vragen kan dat voor iedereen tijd besparen. 00:15:52.680 --> 00:15:57.460 Een klant kan een leveringstatus controleren of een installatiehandleiding volgen wanneer het hen uitkomt. 00:15:57.520 --> 00:16:02.540 Ondertussen kunnen medewerkers meer tijd besteden aan zaken waarvoor een mens moet onderzoeken, uitleggen of beslissen. 00:16:02.740 --> 00:16:07.900 Dynamics 365 Customer Service kan ook verbinding maken met bekende Microsoft tools rondom het case-proces. 00:16:08.080 --> 00:16:10.340 Een medewerker kan met e-mail werken via Outlook. 00:16:10.480 --> 00:16:12.700 Een team kan een lastig probleem bespreken in Teams. 00:16:13.020 --> 00:16:15.540 Documenten en gedeelde informatie kunnen in SharePoint staan. 00:16:15.540 --> 00:16:23.560 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. 00:16:23.660 --> 00:16:25.180 Elke tool heeft zijn eigen taak. 00:16:25.300 --> 00:16:32.480 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. 00:16:32.600 --> 00:16:35.320 Case Management gaat niet echt over het invullen van een ticketscherm. 00:16:35.520 --> 00:16:40.800 Het gaat er om elk klantprobleem een duidelijk pad, een vastgelegd antwoord en een team dat leert van wat er is gebeurd, te geven. 00:16:40.800 --> 00:16:41.660 Conclusie 00:16:41.660 --> 00:16:43.760 Hou het volledige klantverhaal bij elkaar 00:16:43.760 --> 00:16:45.600 Dus, dit is de belangrijkste lay. 00:16:45.860 --> 00:16:51.760 Dynamics 365 Case Management houdt het probleem, het werk, de beloftes en het resultaat in één dossier. 00:16:52.000 --> 00:16:53.940 Geen verloren context of dubbel werk meer. 00:16:54.120 --> 00:16:56.060 Kijk eens naar je eigen ondersteuningsproces. 00:16:56.280 --> 00:16:58.380 Oh, waar verdwijnt klantinformatie allemaal? 00:16:58.680 --> 00:17:00.880 Dat is waar alles samenbrengen het verschil maakt. 00:17:01.040 --> 00:17:10.660 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. 00:17:10.800 --> 00:17:11.800 Kijk eens naar je vooral. 00:17:11.800 --> 00:17:12.800 Kijk eens naar je vooral. 00:17:12.800 --> 00:17:13.800 Kijk eens naar je vooral. 00:17:13.800 --> 00:17:14.800 Kijk eens naar je vooral. 00:17:14.800 --> 00:17:15.800 Kijk eens naar je vooral. 00:17:15.800 --> 00:17:16.800 Kijk eens naar je vooral. 00:17:16.800 --> 00:17:17.800 Kijk eens naar je vooral. 00:17:17.800 --> 00:17:18.800 Kijk eens naar je vooral. 00:17:18.800 --> 00:17:19.800 Kijk eens naar je vooral. 00:17:19.800 --> 00:17:20.800 Kijk eens naar je vooral. 00:17:20.800 --> 00:17:21.800 Kijk eens naar je vooral. 00:17:21.800 --> 00:17:22.800 Kijk eens naar je vooral. 00:17:22.800 --> 00:17:23.800 Kijk eens naar je vooral. 00:17:23.800 --> 00:17:24.800 Kijk eens naar je vooral. 00:17:24.800 --> 00:17:25.800 Kijk eens naar je vooral. 00:17:25.800 --> 00:17:26.800 Kijk eens naar je vooral. 00:17:26.800 --> 00:17:27.800 Kijk eens naar je vooral. 00:17:27.800 --> 00:17:29.800 Kijk eens naar je vooral. 00:17:29.800 --> 00:17:30.800 Kijk eens naar je vooral. 00:17:30.800 --> 00:17:32.800 Kijk eens naar je vooral. 00:17:32.800 --> 00:17:33.800 Kijk eens naar je vooral.