QA-minpunten voor zaken buiten je controle

Hangt een criterium af van een systeem dat faalde, een klant die vertrok of een team dat nooit antwoordde, dan verliezen medewerkers punten die ze niet in de hand hadden. Repareer de scorecard door het criterium uit te sluiten, het als niet van toepassing te markeren of de bevinding naar de eigenaar door te sturen.

In het kort

• Medewerkers herkennen binnen ongeveer een maand een criterium waar ze geen invloed op hebben.
• “Niet van toepassing” moet op elk criterium bestaan en de noemer verkleinen.
• Fouten die zich ophopen in één wachtrij, op één uur of na één release wijzen op een systeemprobleem.
• Een kapot proces moet het proces veranderen, niet de score van de medewerker.

Waarom één oncontroleerbaar criterium de hele score ongeloofwaardig maakt

Als supportmedewerkers een score beschrijven die ze oneerlijk vinden, komen er steeds dezelfde vier situaties terug, en geen ervan is echt een discussie over het oordeel van de reviewer.

• Door een systeemstoring werd een stap die de medewerker had uitgevoerd nooit vastgelegd, dus de reviewer kon hem niet zien en scoorde hem als ontbrekend.
• De klant verbrak de verbinding voor de afsluiting, en elk criterium van de afsluiting gaf een automatische nul.
• Een escalatie ging naar een supervisor die nooit antwoordde, en de medewerker verloor de punten voor oplossing en opvolging.
• Een beller was slecht verstaanbaar, een e-mailadres kwam met een tikfout terug, en een criterium voor de juistheid van gegevens registreerde dat als een privacyfout.

Neem het rekenwerk van de tweede situatie serieus, want die is het duidelijkst. Telt je afsluiting vier criteria en zet een verbroken verbinding er drie op nul, dan bepaalt het gedrag van de klant, niet dat van de medewerker, in welke scoreband die medewerker terechtkomt. De medewerkers die de bozeste bellers krijgen, worden het vaakst opgehangen, dus wie je moeilijkste werk doet, scoort het slechtst.

Daar volgen twee dingen uit, in deze volgorde. Ten eerste draagt de score geen informatie meer. Kan een reviewer je niet vertellen of een 72 slecht werk betekent of een slechte middag met de tools, dan kan niemand verderop het cijfer gebruiken voor een beslissing. Ten tweede, en duurder: de score verliest haar gezag bij de mensen die ze zou moeten helpen. Zodra een medewerker gelooft dat het cijfer deels willekeurig is, komt elke coaching die eraan vastzit al met korting binnen. Je coacht niet meer, je onderhandelt, en je bent de voorwaarden kwijt om een QA-programma te voeren dat medewerkers vertrouwen (in het Engels). Deming zei het algemener en botter dan welke QA-gids ook: a bad system will beat a good person every time, en de persoon harder meten verandert niets aan wie van de twee verliest.

Dit is geen falen van het QA-team. Reviewers werken met hetzelfde formulier als iedereen, en de meeste formulieren geven ze bij een criterium waaraan onmogelijk voldaan kon worden twee opties: afkeuren, of stilletjes goedkeuren en hopen dat niemand het controleert. Allebei fout, en een derde keuze is er niet. Dat is een ontwerpprobleem, en je lost het op in de rubric, niet in de discussie over de rubric.

Zo vind je de criteria op je scorecard die van omstandigheden afhangen

Neem je huidige QA-scorecard en loop die regel voor regel door. Stel bij elk criterium drie vragen, in deze volgorde.

1. Kon de medewerker hieraan voldoen met de tools, rechten en informatie die hij op dat moment had? Niet de tools die hij had moeten hebben. De tools die er echt voor hem lagen.
2. Moet iemand anders eerst iets doen voordat hieraan voldaan kan worden? Een ander team, een klant, een batchjob, een goedkeuring.
3. Kan een sterke medewerker hier elke keer aan voldoen als hij dat wil? Is het eerlijke antwoord nee, dan meet het criterium naast vaardigheid ook omstandigheden.

Deel elk criterium onderweg in een van drie bakken in. Volledig controleerbaar: daar horen de meeste criteria voor soft skills en processen te zitten. Voorwaardelijk controleerbaar: de medewerker heeft het alleen in de hand als aan een voorwaarde voldaan is. Niet controleerbaar: of eraan voldaan wordt, hangt af van iets waar de medewerker helemaal geen invloed op heeft.

In de tweede bak zit het werk. Schrijf voor elk voorwaardelijk controleerbaar criterium de voorwaarde op in één eenvoudige zin: de klant bleef aan de lijn, de tool voor terugbetalingen werkte, het tweedelijnsteam antwoordde binnen zijn servicetermijn, de opname legde het volledige gesprek vast. Die zinnen worden de triggers voor “niet van toepassing” die je later nodig hebt, en door ze uit te schrijven wordt een vaag gevoel van oneerlijkheid een regel die een reviewer twee keer op dezelfde manier kan toepassen.

Doe het met medewerkers erbij

Doe deze ronde met twee reviewers en twee ervaren medewerkers samen, niet als oefening van alleen het QA-team. De medewerkers vinden de criteria die van omstandigheden afhangen in een fractie van de tijd, omdat ze er al maanden punten aan verliezen en het exacte ticket kunnen noemen. Het verandert ook wat de oefening uitstraalt: je vraagt de werkvloer om het formulier te helpen verbeteren in plaats van een correctie aan te kondigen. Reken op twee uur voor een scorecard met vijftien criteria en verwacht twee tot vijf probleemregels te vinden.

De drie soorten fouten die medewerkers niet in de hand hebben

Bijna alles wat je vindt, valt in een van drie soorten, en de soort vertelt je wat je eraan doet. Het onderscheid dat telt is wie de fout had kunnen voorkomen, want dat is ook wie de bevinding moet krijgen.

Uitsluiten, niet van toepassing markeren of doorsturen

Drie oplossingen, en wie de verkeerde kiest, ziet deze correcties mislukken. De toets is niet hoe ernstig de fout was, maar hoe vaak het criterium onmogelijk is en wie eigenaar is van de oorzaak.

Sluit het criterium uit als het de controletoets meestal niet doorstaat. Hangt een criterium af van een onbetrouwbare tool, of van een klant die zich op een bepaalde manier gedraagt, dan is het geen norm maar kop of munt met een puntenwaarde eraan. Een handige vuistregel: als je iemand er nooit op zou coachen, scoor hem er dan ook niet op.

Markeer het als niet van toepassing als het criterium normaal controleerbaar is, maar in dat ene gesprek echt onmogelijk was. Dit is het gewone geval, en het vraagt twee dingen: een benoemde trigger uit de voorwaarden die je eerder opschreef, en bewijs in het dossier dat de trigger afging. Een tijdstip van verbreken van de verbinding vóór de afsluiting is bewijs. De indruk van een reviewer niet.

Stuur de bevinding door als de fout echt is, ertoe doet voor de klant en bij iemand hoort. De klant kreeg zijn terugbetaling niet: een echte kwaliteitsfout die het waard is om te weten, maar de oorzaak was een beleid dat de medewerker niet mag omzeilen. De bevinding verlaat QA als procesdefect met een eigenaar en een datum. De score van de medewerker verandert niet.

Er is een vierde optie waar teams naar grijpen en die je moet weigeren: het criterium afkeuren en een opmerking toevoegen dat het niet de schuld van de medewerker was. De opmerking verandert het cijfer niet, en het cijfer is wat in de maandelijkse review, de ranglijst en het functioneringsgesprek terechtkomt. Medeleven in een vrij tekstveld is geen controle, en het laat de medewerker met niets anders achter dan bezwaar maken tegen de score (in het Engels).

Geef reviewers de bevoegdheid en controleer die daarna

Reviewers moeten “niet van toepassing” kunnen toepassen zonder toestemming te vragen. Teams die er een escalatie van maken, schrappen de optie in feite, want een reviewer met nog veertig reviews te gaan opent geen ticket om één regel over te slaan. Controleer het achteraf: rapporteer het gebruik van “niet van toepassing” per reviewer en per criterium, en zet de uitschieters op de agenda van je volgende kalibratiesessie. Dat is een veel beter gesprek dan het gesprek dat je krijgt door onterechte afkeuringen af te dwingen.

Waarom “niet van toepassing” op elk criterium een volwaardige optie moet zijn

“Niet van toepassing” werkt alleen als het rekenwerk klopt. De score moet bestaan uit behaalde punten gedeeld door de punten die van toepassing zijn, niet gedeeld door het hele formulier. Waren elf van de vijftien criteria van toepassing en voldeed de medewerker aan acht, dan is de score acht op elf. Houdt je formulier alle vijftien in de noemer, dan kost een regel als niet van toepassing markeren precies evenveel als hem afkeuren, merken reviewers dat binnen een week, en wordt de optie niet gebruikt. Veel teams scoren al alleen op de vragen die van toepassing zijn. Andere hebben een vakje “niet van toepassing” dat niets doet, en dat is erger dan er geen hebben, omdat het eruitziet als een oplossing.

Kijk wat er gebeurt op een formulier zonder werkende optie “niet van toepassing”. De strenge reviewers keuren het onmogelijke criterium af, de milde keuren het goed, en allebei gokken ze naar een regel die nooit is opgeschreven. Je hebt een verschil tussen reviewers gefabriceerd dat met geen enkele kalibratiesessie (in het Engels) op te lossen is, omdat het structureel is en niet een kwestie van waarneming: twee reviewers kunnen het volledig eens zijn over wat er gebeurde en toch verschillende scores geven. Medewerkers ervaren hun score dan als een functie van wie hen beoordeelde, en dat is de snelste manier om de geloofwaardigheid van een QA-programma te verliezen.

De schade aan de data duurt langer. Een criterium dat goedgekeurd werd terwijl het nooit getoetst is, blaast je slagingspercentage op. Een criterium dat afgekeurd werd terwijl het onmogelijk was, fabriceert een defect dat nooit gebeurd is. Hoe dan ook worden de statistieken van dat criterium onbruikbaar, en die statistieken zijn precies wat je nodig hebt om de scorecard zinnig te wegen en de systeemproblemen uit de volgende sectie te zien.

Vier vereisten, en ze kosten allemaal weinig:

• Beschikbaar op elk criterium, niet op een paar gekozen. Het criterium waarop je het niet aanzette, is het criterium dat zal breken.
• Een redencode uit een korte lijst, vijf of zes opties, zodat het gebruik telbaar is. Vrije tekst is niet telbaar.
• Zichtbaar voor de medewerker in de review, zodat die ziet dat de reviewer het opmerkte. De helft van de wrevel in dit hele onderwerp komt van medewerkers die aannemen dat niemand het zag.
• Maandelijks gerapporteerd per criterium en per reden.

Eén drempel die het waard is om over te nemen. Komt een criterium in meer dan ongeveer een derde van de gesprekken terug als niet van toepassing, dan hoort het niet op die scorecard. Het hoort op een scorecard per kanaal of per wachtrij, omdat je één formulier vraagt om twee verschillende soorten werk te beoordelen.

Zo zie je het probleem in je data voordat een medewerker het je vertelt

Klachten zijn een achterlopende indicator, en ze komen van je zelfverzekerdste medewerkers in plaats van van de medewerkers die er het meest last van hebben. De data is er eerder, en de methode werkt in een spreadsheet.

Neem per criterium het foutpercentage van het afgelopen kwartaal en splits dat uit naar uur van de dag, wachtrij of skill, kanaal, ancienniteit van de medewerker, en zet het naast de data van releases en beleidswijzigingen. Vaardigheid van medewerkers is redelijk gelijk over die groepen verdeeld. Systeemproblemen niet, en die asymmetrie is de hele diagnose. Een criterium dat in totaal 6% van de tijd faalt, maar 35% van de tijd in één wachtrij tussen twee en vijf uur ‘s middags, vertelt je niets over coaching.

Vier patronen en wat elk meestal betekent:

• Opgehoopt in een tijdvenster. Onderbezetting (in het Engels), druk op de wachtrij, of een batchjob die elke middag een systeem blokkeert. Kijk wat er op dat uur nog meer gebeurt voordat je een coachingnotitie schrijft.
• Opgehoopt in één wachtrij, skill of kanaal. Een tool die alleen die groep gebruikt, een routeringsregel, of een scorecard die niet past bij het werk van die groep.
• Een sprong op een datum. Een release, een beleidswijziging, of een wijziging van de scorecard zelf. Een criterium dat in maart goed ging en vanaf april constant faalt, werd niet moeilijker omdat je medewerkers slechter werden.
• Gelijk verdeeld over iedereen, ook je sterkste medewerkers. Het criterium is dubbelzinnig of onmogelijk. Faalt je beste tiende er ongeveer even vaak op als je zwakste tiende, dan meet het geen vaardigheid.

In deze methode zit een steekproefprobleem verstopt, en het is goed om het te benoemen. Met de steekproef van 3% waarmee de meeste programma’s werken, kun je het helemaal niet doen. Splits één criterium uit naar wachtrij en uur en de meeste cellen zijn leeg, dus het patroon dat de medewerker had kunnen vrijpleiten is onzichtbaar en de anekdote wint de discussie. Dit is het praktische argument om alles te scoren: 100% dekking laat trends zien die een steekproef van 3% nooit kon laten zien. Het punt is niet dat er meer gezien wordt, maar dat de selectiebias verdwijnt, zodat een opgehoopte fout als opgehoopt herkend kan worden.

De Auto QA van Kaizo scoort elk gesprek tegen je eigen scorecard en houdt het bewijs per criterium bij, zodat je de fouten op één criterium kunt filteren op wachtrij en uur en kunt zien of ze zich ophopen voordat iemand erop gecoacht wordt. Die herleidbaarheid doet er meer toe dan de dekking: de nuttige vraag is niet hoeveel gesprekken gescoord werden, maar of je kunt laten zien waarom een specifiek criterium in een specifiek gesprek faalde. Meer over de kant van de dekking in wat 100% QA-dekking echt betekent.

Stuur de bevinding naar de eigenaar, niet naar de score van de medewerker

Alles hierboven wijst naar één principe. Een bevinding die terug te voeren is op een kapot proces moet het proces aanpassen, niet de score van de persoon. QA leest meer van wat klanten echt overkomt dan elke andere functie, en daarmee is het het beste systeem om defecten op te sporen dat de meeste supportorganisaties hebben. Dat signaal opmaken aan individuele puntenaftrek is verspilling.

De werkwijze is gewoon, en dat is precies het punt:

• Tag de eigenaar tijdens de review. Product, workforce management, tweede lijn, kennisbank, beleid. Tijdens de review kost dat seconden. Het reconstrueren in een maandelijkse retro kost een middag en wordt overgeslagen.
• Geef de bevinding de velden die een defect krijgt. Wat faalde, hoe vaak, in welke wachtrijen, wat het kost aan heropeningen of afhandeltijd. Een procesbevinding met een getal eraan wordt opgelost. Een klacht niet. Dit is gewone root cause analyse, toegepast op de scorecard zelf in plaats van op het ticket.
• Zet het criterium op pauze zolang het defect openstaat, en zeg dat hardop op de werkvloer. Deze stap wint de geloofwaardigheid terug, omdat ze bewijst dat de scorecard reageert op bewijs.
• Rapporteer de oplossingen naast de scores. Gepauzeerde criteria, gemelde defecten, gesloten defecten. Het verandert waar QA voor gezien wordt, en het geeft je team een tweede set cijfers die niet de gemiddelde score is.

Wat er na dit werk overblijft, is het deel dat de medewerker echt in de hand heeft, en dat is het enige deel dat een one-on-one waard is. Coaching opent niet meer met een discussie over of de score eerlijk was, en QA-data omzetten in coaching (in het Engels) wordt makkelijker, omdat de bevindingen allemaal dingen zijn die een persoon kan veranderen. De AI-coaching van Kaizo bouwt haar coachingkaarten op gescoorde criteria, dus de criteria die je uitsluit of voorwaardelijk maakt, leveren ook geen coachingruis meer op, naast geen puntenaftrek.

Twee huishoudelijke regels om af te sluiten. Versioneer de scorecard telkens als je een criterium schrapt of voorwaardelijk maakt, en herbereken oude scores nooit met nieuwe regels, want een score uit maart is gemaakt met het formulier van maart. En kondig elke wijziging aan voordat ze ingaat, met de reden. Een scorecard die zichzelf zichtbaar corrigeert, wordt heel anders behandeld dan een scorecard die elk kwartaal stilletjes in een nieuwe versie opduikt.

Veelgestelde vragen

Moeten medewerkers gescoord worden op dingen die ze niet in de hand hebben?

Nee. Een criterium waar een medewerker geen invloed op heeft, meet omstandigheden in plaats van prestaties, en het maakt de totale score onbruikbaar voor coaching of voor een ranglijst. De fout kan nog steeds het vastleggen waard zijn, maar dan tegen het systeem, de situatie van de klant of het team dat haar veroorzaakte. Deel elk criterium in als volledig controleerbaar, voorwaardelijk controleerbaar of niet controleerbaar, en sluit het daarna uit, markeer het als niet van toepassing of stuur het door.

Wat doe je als een medewerker voor QA zakt om een reden die niet zijn schuld was?

Corrigeer het niet met een notitie in de opmerkingen, want de opmerking verandert het cijfer niet dat in zijn review terechtkomt. Was het criterium in dat specifieke gesprek onmogelijk, markeer het dan als niet van toepassing zodat het uit de noemer verdwijnt. Is het criterium regelmatig onmogelijk, haal het dan van de scorecard. Was de fout echt maar veroorzaakt door een ander team, houd de bevinding dan, koppel er een eigenaar aan en laat de score van de medewerker ongemoeid.

Hoe ga je om met een gesprek waarin de klant ophing voor de afsluiting?

Activeer de status “niet van toepassing” op elk criterium van de afsluiting, onderbouwd met het tijdstip waarop de verbinding verbrak, in plaats van ze automatische nullen te laten geven. Scoor de delen van het gesprek die wel plaatsvonden. Een verbroken verbinding die drie of vier criteria van de afsluiting op nul zet, kan een medewerker een hele prestatieband laten zakken op basis van alleen het gedrag van de klant, en het raakt de medewerkers met de moeilijkste bellers het hardst.

Moet een QA-scorecard een optie “niet van toepassing” hebben?

Ja, op elk criterium, en die moet het criterium uit de noemer halen, zodat de score bestaat uit behaalde punten op de punten die van toepassing zijn. Een optie “niet van toepassing” die het totaal intact laat, is rekenkundig hetzelfde als een afkeuring, en reviewers stoppen ermee. Vraag een redencode uit een korte lijst, toon de status aan de medewerker in de review, en rapporteer het gebruik per reviewer en per criterium, zodat kalibratie het kan controleren.

Hoe onderscheid je in QA-data een systeemprobleem van een probleem van de medewerker?

Splits het foutpercentage van elk criterium uit naar uur van de dag, wachtrij, kanaal, ancienniteit en releasedatum. Vaardigheid is redelijk gelijk over die groepen verdeeld, dus een criterium dat veel vaker faalt in één wachtrij, in één tijdvenster of vanaf één releasedatum is bijna altijd een systeem- of procesprobleem. Een criterium waarop je sterkste en zwakste medewerkers ongeveer even vaak falen, is dubbelzinnig of onmogelijk.

Hoe gebruik je root cause analyse in kwaliteitscontrole?

Vraag wat er waar had moeten zijn om de medewerker te laten slagen, en volg die keten tot je iets bereikt waar iemand eigenaar van is. Eindigt de keten bij een tool die een veld niet opsloeg, een kennisbankartikel dat fout was of een escalatie waarop niemand antwoordde, dan hoort de bevinding bij die eigenaar als defect met een frequentie en een kostprijs, en moet het criterium op de scorecard op pauze staan tot het opgelost is. Een bevinding die terug te voeren is op een kapot proces, moet het proces aanpassen, niet de score van de persoon.

Verwante begrippen

• Wat een QA-rubric is en hoe je er een bouwt
• Een QA-programma voeren dat medewerkers vertrouwen (in het Engels)
• Root cause analyse in de klantenservice
• Wat QA-kalibratie is en waarom het telt
• QA-data omzetten in coaching (in het Engels)

Ontdek aan welke criteria je medewerkers eigenlijk niet kunnen voldoen

Neem de scorecard mee die je vandaag gebruikt en een kwartaal aan gescoorde gesprekken. We laten je zien welke criteria falen in patronen die je wachtrijen en je releasedata volgen in plaats van je medewerkers.

Demo boeken Bekijk hoe AI-coaching werkt