Een klant zegt dat dezelfde vraag twee keer bij het verkeerde team terechtkwam. De routeringsregel ziet er goed uit, alle medewerkers lijken beschikbaar en toch kan niemand aanwijzen waar het besluit veranderde. Op zo'n moment is een routeringslogboek onmisbaar.
Als uw team eerder vertrouwde op de diagnostiek voor Unified Routing in Dynamics 365, bouw het oude scherm dan niet na met screenshots en handmatige notities. Microsoft zegt dat deze functie op 31 maart 2026 is verwijderd en adviseert gespreksdiagnostiek in Azure Application Insights. De praktische vervanging is een bewijsroute aansluiten, één bekend gesprek uitvoeren, routering en toewijzing apart volgen en één persoon verantwoordelijk maken voor de logs.
Begin met de vraag aan het logboek
Start niet met het exporteren van ieder mogelijk event. Begin met één operationele vraag. Waarom kwam dit gesprek in de verkeerde wachtrij? Waarom kreeg geen enkele medewerker het werk aangeboden? Waarom mislukte een overdracht? Waarom veranderde een capaciteitswijziging de toewijzing?
- 1Bepaal het verwachte padLeg kanaal, wachtrij, vaardigheid, prioriteit, medewerkerstatus en eigenaar vast.
- 2Sluit de bewijsroute aanKoppel beheerde omgeving, Application Insights, toegangseigenaren en bewaartermijn.
- 3Voer een bekende test uitGebruik toegestane ID's en één gecontroleerd gesprek dat het echte probleem toont.
- 4Scheid route en toewijzingBevestig eerst de wachtrij en daarna geschiktheid, capaciteit, aanbod en eigenaarschap.
- 5Wijzig en test opnieuwPas de kleinste relevante instelling aan en vergelijk beide bewijzen.
Leg de vraag vast naast een stabiele testrecord en een tijdvenster. Noteer kanaal, wachtrij, benodigde vaardigheid, prioriteit, verwachte medewerkerstatus en verwacht resultaat. Zo wordt het bewijs leesbaar en sluit het aan op uw bestaande audit van routeringsregels, in plaats van een los monitoringproject te worden.
De officiële melding van Microsoft is duidelijk over de productgrens. Unified Routing diagnostics is niet langer de ondersteunde bestemming. Gespreksdiagnostiek in Application Insights is dat wel. De vervanging moet daarom aantonen dat een echt werkitem het bedoelde pad volgde en dat de informatie om het besluit uit te leggen beschikbaar kwam.
Sluit de bewijsroute aan
Volgens de configuratiehandleiding wordt de Customer Service omgeving via data-export verbonden met een Azure Application Insights instantie. De omgeving moet beheerd zijn. De insteller heeft passende Azure-toegang nodig en iemand die gegevens opvraagt minimaal leestoegang. Per omgeving kan maar één exportconfiguratie van Customer Service naar Application Insights bestaan.
Behandel dit als een verantwoordelijkheidsmodel. Benoem de Dynamics-beheerder, de Azure-eigenaar, de lezer van traces en de operationeel leider die een routeringsresultaat accepteert. Leg vast welke omgeving naar welke Application Insights resource stuurt.
Voor data-inname worden kosten gerekend. Schat daarom volume en bewaartermijn voordat u breed gaat verzamelen. Geef minder mensen toegang dan het volledige serviceteam. Routeringsbewijs kan klant-ID's, handelingen van medewerkers, wachtrijnamen, beschikbaarheidswijzigingen en de operationele structuur tonen. Gebruik dezelfde beveiligingsmaatregelen als voor klantgeschiedenis en medewerkersanalyses.
Voer één bekend gesprek uit
Kies een test die op een echt probleem lijkt zonder gevoelige live-inhoud te gebruiken. Geef de test een bekend kanaal, wachtrij, vaardigheid, prioriteit, medewerkerstatus en verwachte eigenaar. Noteer de starttijd en de identificaties die u volgens het beleid mag bewaren. Stuur het werkitem daarna via de normale route.
Wijzig tijdens de test niet meerdere regels. Eén gecontroleerde case maakt de vergelijking tussen verwachting en bewijs mogelijk. Controleer bij een vermoedelijk beschikbaarheidsprobleem de status met de audit van medewerkerbeschikbaarheid. Vergelijk bij mogelijke capaciteitsproblemen de geaccepteerde instelling met de veilige configuratie van capaciteitsprofielen.
Maak voor iedere test een klein bewijsbewijs.
| Bewijspunt | Eigenaar | Wat u vastlegt | Wanneer u stopt |
|---|---|---|---|
| Testinvoer | Operationeel leider | Kanaal, wachtrij, vaardigheid, prioriteit en verwachte eigenaar | Het verwachte pad is onduidelijk |
| Exportverbinding | Dynamics-beheerder | Omgeving en Application Insights bestemming | De bestemming is niet aantoonbaar |
| Tracezoekopdracht | Azure-lezer | Tijdvenster en toegestane record-ID's | De test is niet te isoleren |
| Routeringsresultaat | Routeringseigenaar | Wachtrijbesluit en regelversie | De wachtrij verschilt zonder uitleg |
| Toewijzingsresultaat | Workloadeigenaar | Beschikbaarheid, capaciteit, aanbod en acceptatie | Eigenaarschap is niet te reconstrueren |
| Acceptatie | Service-eigenaar | Correctie, hertest en monitoringbesluit | Niemand accepteert het resultaat |
Lees routering en toewijzing apart
Een gesprek kan in de juiste wachtrij komen en toch bij de verkeerde persoon belanden. Het kan ook al vóór de toewijzing naar de verkeerde wachtrij gaan. Houd die vragen gescheiden.
Volg eerst intake, classificatie en de route naar een wachtrij. Vergelijk de werkelijke kenmerken met de regelversie die toen actief was. Bekijk daarna de toewijzing. Controleer geschikte medewerkers, vaardigheden, aanwezigheid, capaciteit, aanbiedingen, afwijzing of time-out en het uiteindelijke eigenaarschap. De gids over afwijzingen en time-outs legt uit waarom een aanbod nog geen eigenaarschap is.
Vul ontbrekend bewijs niet zelf in. Een leeg resultaat kan wijzen op een verkeerde export, een onjuist tijdvenster, onvoldoende toegang of een werkitem dat nooit in de verwachte omgeving kwam. Bewijs de route met een tweede bekende test voordat u productieroutering wijzigt.
De gedeelde klantinbox toont het huidige eigenaarschap en de gesprekshistorie aan het operationele team. Dat vervangt platformtelemetrie niet. Gebruik de inbox om de impact voor de klant te begrijpen en diagnostiek om het systeembesluit uit te leggen.
Wijzig één ding en test opnieuw
Wanneer het bewijs naar een regel, vaardigheid, wachtrijlidmaatschap, aanwezigheid of capaciteit wijst, verander dan het kleinste relevante onderdeel. Noteer wie goedkeurde en wat kan worden teruggedraaid. Voer dezelfde test opnieuw uit met dezelfde verwachting.
Vergelijk beide bewijzen. De gecorrigeerde test moet de bedoelde wachtrij en eigenaar bereiken, terwijl het logboek de reden blijft verklaren. Slaagt de test alleen door handmatig ingrijpen van een supervisor, dan is het routeringsprobleem niet opgelost. Handmatig ingrijpen is ook bewijs, maar wel een uitzondering.
Controleer na ingebruikname regelmatig niet-toegewezen werk, herhaalde time-outs, onverwachte wachtrijwissels en onverklaarde handmatige toewijzingen. Een melding moet naar een eigenaar en besluit leiden, niet naar nog een rumoerige inbox.
Bouw het oude bewijs voorzichtig af
De Microsoft-melding verwijst naar een apart proces om oude routeringsgegevens uit Dataverse te verwijderen. Verwijder historische informatie niet alleen omdat de functie weg is. Volg het bewaarbeleid, bewaar materiaal voor lopende onderzoeken, accepteer eerst de Application Insights route en documenteer wat door wie is verwijderd.
Het doel is niet ieder event voor altijd te bewaren. Eén routeringsbesluit moet uit te leggen zijn vanaf de klantvraag tot de uiteindelijke eigenaar. Gebruik die norm wanneer een regel, capaciteitsprofiel of workflow verandert. Verbind het bewijs bij een bredere herinrichting met het operationele supportmodel.
Veelgestelde vragen
Is Dynamics 365 Unified Routing diagnostics nog beschikbaar
Microsoft zegt dat de functie op 31 maart 2026 is verwijderd. Gebruik gespreksdiagnostiek in Azure Application Insights voor de ondersteunde bewijsroute.
Lost gespreksdiagnostiek een routeringsprobleem automatisch op
Nee. De functie registreert lifecycle-events. Een beheerder of operationeel eigenaar moet de trace beoordelen, een gecontroleerde wijziging doen en dezelfde route opnieuw testen.
Welke test moet een team als eerste uitvoeren
Begin met één recent en herhaalbaar probleem waarvan de verwachte wachtrij en eigenaar bekend zijn. Doe geen brede productiewijziging voordat u die test kunt isoleren en de routering en toewijzing kunt uitleggen.
Hulp nodig bij deze handleiding?Vraag het DripTell-team
Van lezen naar doen
Hulp nodig om dit voor jouw bedrijf toe te passen?
Laat je gegevens achter. We nemen dit artikel als context en beginnen met een bruikbaar antwoord voor je team.
DripTell Editorial
Praktische uitleg, gecontroleerd door het product- en klantworkflowteam van DripTell.
Lees hoe DripTell productclaims controleert, primaire bronnen gebruikt en correcties verwerkt.
Redactioneel en bronnenbeleid
