Een supervisor verandert een kwaliteitsvraag van ‘Is de klant geholpen?’ in ‘Bevat het antwoord iedere actie die de klant moet uitvoeren?’. De volgende run geeft een heel andere score. Dat betekent niet automatisch dat de service slechter werd. De regel veranderde.
De veilige manier om kwaliteitscriteria in Dynamics 365 te testen is eenvoudig. Houd het nieuwe criterium in concept, voer het uit op een bewust gevarieerde selectie van echte cases of gesprekken en vergelijk elke voorspelling met een onafhankelijk menselijk referentieantwoord. Verhelp één onduidelijkheid per keer en test opnieuw met hetzelfde bewijs. Publiceer pas wanneer de regel bij gewone en moeilijke records consequent werkt.
Begin met één beslissing
Begin niet met de gewenste totaalscore. Begin met een beslissing die een beoordelaar uit het record kan verdedigen.
Gaat de vraag over de uitleg van de volgende stap, leg dan vast welk bericht het bewijs bevat, wat een volledige stap nodig heeft, wat genegeerd moet worden en welk antwoord geldt bij een onvolledig record. ‘Is de case goed afgehandeld?’ vraagt de beoordelaar zelf een norm te verzinnen. ‘Noemt het laatste antwoord de actie, eigenaar en verwachte timing?’ is wel toetsbaar.
De actuele criteriahandleiding van Microsoft adviseert specifieke vragen, directe antwoordvoorwaarden, expliciete uitsluitingen en een benoemde gegevensbron. Een vraag kan ook kritisch zijn, zodat een bepaald antwoord de hele evaluatie laat zakken. Gebruik dat voorzichtig. Een vage kritische vraag maakt normale onzekerheid tot een automatische fout.
Dit werk hoort bij de eigenaar van het supportmodel, niet alleen bij een systeembeheerder. De proceseigenaar weet welke informatie een medewerker echt kan zien en beïnvloeden.
Bouw een testset die zwakte toont
Een set vol nette, succesvolle cases bewijst weinig. Neem records op die de grens van de regel zichtbaar maken.
Microsoft laat een simulatie draaien op conceptcriteria of gepubliceerde criteria met echte case of gespreksgegevens. Voorwaarden selecteren de records en standaard gebruikt de run de 25 meest recente overeenkomsten. Dat is een handig startmechanisme, geen bewijs dat de steekproef representatief is. Kies de voorwaarden bewust en noteer waarom ieder voorbeeld is opgenomen. Casebijlagen gaan niet mee in de simulatie. Schrijf dus geen regel die afhankelijk is van bewijs dat de evaluator niet ontvangt.
| Testrecord | Waarom opnemen | Verwacht gedrag | Blokkade voor publicatie |
|---|---|---|---|
| Gewone complete case | Controleert de basisregel | Duidelijk antwoord uit zichtbaar bewijs | Verkeerd antwoord bij duidelijk bewijs |
| Ontbrekend veld of bericht | Test de gegevensgrens | Onbekend of afgesproken terugvalantwoord | Zeker oordeel uit ontbrekende data |
| Overdracht | Test verantwoordelijkheid | Alleen de benoemde bron gebruiken | Verkeerde medewerker krijgt schuld |
| Dubbelzinnige formulering | Vindt gaten in instructies | Dezelfde redelijke uitleg | Deskundigen verschillen terecht |
| Kritieke fout | Test de stopvoorwaarde | Alleen zakken bij voldoende bewijs | Onterechte kritieke fout |
Gebruik bewijs uit dezelfde plek als de live evaluatie. Als gesprekken door een gedeelde inbox lopen, bewaar dan de berichtvolgorde, eigenaarswissel en klantreactie. Bouw achteraf geen netter verhaal.
Vergelijk met een menselijke referentie
Laat vóór de simulatie twee deskundige beoordelaars de records onafhankelijk labelen met de geschreven regel. Ze stemmen niet over welk antwoord ze aardig vonden. Ze maken een referentie en leggen eerlijk verschil van inzicht vast.
Vergelijk daarna het voorspelde antwoord, de uitleg en het kritieke resultaat met die referentie. Houd drie problemen uit elkaar. Het bewijs kan ontbreken, de instructie kan meer dan één redelijke uitleg toelaten, of de voorspelling kan duidelijk bewijs tegenspreken.
Elk probleem vraagt een andere oplossing. Meer instructies halen ontbrekende data niet terug. Een ander gewicht maakt een vage vraag niet helder. Een verschillenlogboek is nuttiger dan één gemiddelde score, omdat het toont waar de regel niet langer verdedigbaar is.
Als een AI proces het resultaat gebruikt voor coaching of escalatie, test die vervolgbeslissing apart. Een juist evaluatieantwoord kan nog steeds een slecht ontworpen actie starten.
Verander één ding en test opnieuw
Los de kleinste duidelijke oorzaak op. Herschrijf één vraag, zet de uitsluiting vóór de bewijsinstructie, splits een dubbele vraag of voeg een antwoord voor ontbrekende informatie toe.
Verander niet tegelijk de regel, steekproef, gewichten en verwachte antwoorden. Dan weet je niet waardoor de uitkomst verbeterde.
Dynamics 365 laat gepubliceerde criteria actief terwijl wijzigingen als concept worden opgeslagen. De versiegeschiedenis registreert bewerkingen en publicaties en een oudere versie kan worden hersteld. Simulatieresultaten veranderen geen klantrecords of organisatiebrede kwaliteitsmetingen, maar iedere run verbruikt Copilot credits. Houd de set klein genoeg om te herhalen en breed genoeg om belangrijke fouten te vinden.
Bepaal de publicatiepoort en terugrol
Er is geen universeel overeenkomstpercentage dat elk criterium veilig maakt. Laat de poort passen bij het risico. Een coachingsadvies verdraagt meer onzekerheid dan een compliancefout of beslissing over toegang.
Eis minstens dat er geen onverklaarde kritieke fouten zijn, geen stellig antwoord zonder vereist bewijs, dat ieder meningsverschil is behandeld en dat iemand de versie kan intrekken. Bewaar bij de publicatie de testset, referentieantwoorden, simulatiedatum en bekende beperkingen.
Nieuwe evaluaties gebruiken de nieuwste gepubliceerde versie. Monitor daarom na publicatie veranderingen in meningsverschillen, onbekende antwoorden en kritieke fouten. Bewaar de vorige versie en leg vast welk signaal terugrollen activeert.
Het beveiligingsmodel moet bepalen wie criteria wijzigt, simulaties start, evaluaties inziet en een versie publiceert. De Microsoft handleiding voor kwaliteitsbeheer noemt aparte rollen voor Quality Administrator, Quality Manager en Quality Evaluator, plus voorwaarden voor verbindingen, credits, AI agents en gegevensverplaatsing. Een geslaagde simulatie vervangt die maatregelen niet.
Houd de klantcase bij de score
Een kwaliteitsscore wordt gevaarlijk wanneer de onderliggende case verdwijnt. Bewaar bij het resultaat het relevante klantrecord, het bekeken bewijs, de criteriumversie en de uitgevoerde actie. Dan kan een coach de score uitleggen en kan een operator hem corrigeren.
Breng bij een proces met berichten, AI en menselijke controle eerst de grenzen in kaart. In een DripTell demo kan een team volgen hoe klantcontext, eigenaarschap en bewijs van overdracht door de bredere workflow bewegen. De evaluatieregel moet ook buiten één platform begrijpelijk blijven.
Veelgestelde vragen
Kan ik conceptcriteria testen zonder live scores te wijzigen?
Ja. Microsoft zegt dat simulaties met conceptcriteria en gepubliceerde criteria kunnen werken en geen klantrecords of organisatiebrede kwaliteitsmetingen veranderen. Controleer eerst de simulatiestroom en beschikbare credits.
Hoeveel cases moet ik testen?
Gebruik genoeg records voor gewone afhandeling, ontbrekend bewijs, overdracht, dubbelzinnigheid en kritieke fouten. Risicodekking is belangrijker dan een universeel aantal.
Test ik een kritieke vraag anders?
Ja. Neem een duidelijke voldoende, duidelijke fout en onvolledig bewijs op. De kritieke regel mag alleen zakken wanneer het benodigde bewijs dat ondersteunt.
Wat moet publicatie stoppen?
Stop wanneer beoordelaars de regel niet consequent toepassen, bewijs ontbreekt, kritieke fouten onterecht zijn of niemand eigenaar is van terugrol en correctie.
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
