De correctiegraad: hoe je meet of je antwoorden kloppen

Kijk naar het dashboard van een willekeurig serviceteam. Er staat een gemiddelde reactietijd, een aantal afgehandelde tickets, een CSAT-score en misschien een resolutiegraad in eerste contact. Alle vier zeggen iets over hoe het gesprek verliep. Geen van de vier zegt of het antwoord juist was.

Dat is een vreemd gat, want inhoudelijke juistheid is precies waar een klant op afrekent. Een antwoord binnen vier minuten dat de verkeerde retourtermijn noemt, is duurder dan een antwoord na een uur dat klopt. De eerste levert een tweede ticket op, een correctie en een klant die niet meer weet welke van de twee versies waar is.

Er is één cijfer dat hier wel iets over zegt en dat veel teams al onbewust produceren: hoe vaak een voorgesteld antwoord wordt gewijzigd voordat het de deur uit gaat. Noem het de correctiegraad. Het is de goedkoopste kwaliteitsmeting die er is, want de meting gebeurt al terwijl iemand gewoon zijn werk doet.

De correctiegraad is het aandeel voorgestelde antwoorden dat inhoudelijk wordt aangepast voor verzending. Werkt je team met AI-concepten, dan is dat het aandeel concepten dat een medewerker wijzigt. Werk je met antwoordsjablonen, dan is het het aandeel sjablonen dat niet ongewijzigd de deur uit kan.

De rekenregel is bewust simpel:

Correctiegraad = gewijzigde concepten / (verzonden concepten + gewijzigde concepten)

Belangrijk is wat je niet meetelt. Een concept dat iemand weggooit en volledig zelf opnieuw schrijft, is geen correctie maar een afwijzing. Die hoort in een eigen cijfer, want de oorzaak is anders: bij een correctie was de richting goed en een detail fout, bij een afwijzing begreep het systeem de vraag niet.

Tel ook alleen inhoudelijke wijzigingen. Iemand die een aanhef aanpast of een zin korter maakt, corrigeert niets. Dat onderscheid is de reden dat je dit cijfer niet volledig automatisch kunt vaststellen: een tekstvergelijking ziet wel dat er iets veranderde, niet of het om de retourtermijn of om een komma ging. In de praktijk werkt een steekproef beter dan een algoritme. Twintig gewijzigde concepten per week met de hand nakijken geeft een scherper beeld dan een percentage dat elke spelfout meerekent.

Hier gaat het bij het invoeren van deze meting het vaakst mis. Een team ziet de correctiegraad zakken van dertig naar acht procent en concludeert dat de kwaliteit is gestegen. Dat kan. Maar er zijn twee andere verklaringen die net zo goed passen, en die zijn beide slechter.

De eerste is gewenning. Medewerkers die vijftig keer een concept hebben goedgekeurd dat klopte, gaan het eenenvijftigste minder aandachtig lezen. Dat is geen slordigheid maar een voorspelbare reactie op een betrouwbaar systeem. Een correctiegraad die daalt terwijl het aantal heropende tickets stijgt, meet dus niet je kwaliteit maar je oplettendheid.

De tweede is verschuiving van de mix. Zet je AI aan op de simpelste categorieën en breid je daarna niet uit, dan daalt je correctiegraad omdat de vragen makkelijker werden. Meet je correctiegraad daarom altijd per categorie en nooit alleen als totaal. Een gemiddelde over bezorgvragen en garantiegeschillen is een cijfer waar geen enkele beslissing op te baseren valt.

De tegencheck die dit afdekt is eenvoudig: leg de correctiegraad naast het aantal heropende tickets over dezelfde periode. Dalen ze samen, dan gaat het echt beter. Daalt de eerste terwijl de tweede stijgt, dan keurt je team fouten goed die de klant vervolgens terugstuurt.

Het cijfer zelf is het minst interessante deel. De waarde zit in de wijzigingen: elke correctie wijst naar een plek waar de informatie in je organisatie niet klopt, niet vindbaar is of zichzelf tegenspreekt.

Ga bij twintig gewijzigde concepten na wat er precies veranderde en je vindt bijna altijd vier soorten oorzaken. Een verouderd feit, bijvoorbeeld een retourtermijn die vorig jaar is aangepast maar nog in één document staat. Een ontbrekend feit, waar niemand ooit heeft vastgelegd wat er gebeurt bij een beschadigd artikel na de retourtermijn. Een tegenstrijdigheid, waar twee pagina's iets anders zeggen en het systeem de verkeerde koos. En toonwijzigingen, die geen kennisgat zijn maar een instelling.

Alleen die eerste drie hoef je te repareren, en ze zijn allemaal te repareren op de bron. Dat is het verschil met een CSAT-score, die je vertelt dat een klant ontevreden was zonder te zeggen welk feit fout stond.

Een geanonimiseerd voorbeeld uit onze eigen praktijk: bij een webshop stond op de retourpagina een termijn van 100 dagen en elders op dezelfde site een herroepingstermijn van 30 dagen. Beide kunnen juridisch naast elkaar bestaan. Wie een concept moest corrigeren, koos elke keer opnieuw welke van de twee hij noemde. De correctie was daar dus geen fout van het systeem, maar het signaal dat de bron zelf niet eenduidig was.

Je hebt hier geen nieuwe software voor nodig en geen kwartaal aan voorbereiding. Vier stappen zijn genoeg.

1. Kies één categorie. Neem de grootste, want daar is een steekproef het snelst representatief. Bezorgvragen of retouren zijn bij webshops de logische eerste.
2. Leg vast wat er gebeurde. Verzonden, gewijzigd of weggegooid. Als je systeem dat niet bijhoudt, doe het twee weken met de hand in een spreadsheet. Twee weken is genoeg voor een beginwaarde.
3. Lees twintig wijzigingen na. Niet om het percentage te verfijnen, maar om de oorzaak per correctie te benoemen. Verouderd, ontbrekend, tegenstrijdig of toon.
4. Repareer de bron, niet het antwoord. Werk de kennisbron bij en meet de week erna opnieuw. Zakt de correctiegraad in die categorie, dan werkte de reparatie.

Meet daarna maandelijks, niet dagelijks. Een correctiegraad reageert op wijzigingen in je kennisbronnen, en die veranderen niet per dag. Wie dit wekelijks in een dashboard zet, kijkt vooral naar ruis.

Er zijn situaties waarin de correctiegraad geen bruikbaar signaal geeft, en het is eerlijker die te benoemen dan de meting overal aan te bevelen.

Werk je zonder voorgestelde antwoorden, dan is er niets te corrigeren en meet je niets. Een team dat elk antwoord vanaf nul typt, heeft dit cijfer niet en moet kwaliteit anders vaststellen, bijvoorbeeld met steekproefsgewijs meelezen.

Bij lage volumes is de uitkomst instabiel. Onder ongeveer vijftig voorstellen per maand per categorie schommelt het percentage zo sterk dat een verandering van tien procentpunt niets betekent. Kijk dan naar de wijzigingen zelf en negeer het getal.

En bij vragen zonder feitelijk juist antwoord werkt de meting niet. Een klacht over de toon van een eerdere mail heeft geen correct antwoord dat in een kennisbron staat. Daar meet een correctie het oordeel van de medewerker, niet de juistheid van de informatie.

Productneutraal gezien heb je hiervoor drie dingen nodig. Een systeem dat een voorgesteld antwoord als apart object bewaart, dus niet direct in het tekstveld schrijft. Een status per voorstel die onderscheid maakt tussen verzonden, gewijzigd en weggegooid. En een plek waar vragen zonder bruikbare bron zichtbaar worden, zodat een kennisgat niet in het hoofd van één medewerker blijft.

In Cuego staat een AI-concept als eigen record bij het gesprek, met een status die tussen die drie uitkomsten onderscheidt. Vragen waarbij de agent geen onderbouwing in de kennisbank vond, komen apart terecht in de kennisgaten-lijst, met de oorspronkelijke vraag en het kanaal erbij. Die twee samen maken de correctiegraad afleesbaar per categorie in plaats van als één gemiddelde over alles.

Begin deze week met één categorie en twee weken handmatig turven. Je hebt dan iets wat op weinig servicedashboards staat: een cijfer over de juistheid van je antwoorden dat niet afhangt van de vraag of de klant de moeite nam om een enquête in te vullen.