De kwaliteit van escalaties in de klantenservice gaat over hoe goed een gesprek wordt afgehandeld nadat het zijn eerste eigenaar heeft verlaten. Beoordeel het met eigen criteria, en wijs elke fout toe aan het punt waar die is ontstaan.
In het kort
- Afhandeltijd, scriptnaleving en de kale CSAT zijn bij een escalatie allemaal misleidend.
- De overdracht is een beoordeelbaar moment met twee eigenaren.
- De echte besparing komt van de vraag of de escalatie er had moeten zijn.
- Escalaties zijn te zeldzaam om het patroon in een kleine steekproef te zien.
Escalaties in de klantenservice: wat telt als escalatie, en waarom je definitie je data bepaalt
Voordat je escalaties kunt scoren, moet je het eens worden over wat een escalatie is, en de meeste supportteams hanteren stilzwijgend drie onverenigbare definities tegelijk. De klant vraagt naar een leidinggevende. Een medewerker zet een ticket door naar een specialistische queue. Een regel gaat af omdat een serviceniveau bijna werd overschreden. Alle drie heten escalatie, operationeel hebben ze niets met elkaar gemeen, en het gemiddelde ervan levert een getal op waar niemand iets mee kan.
Kies een definitie, schrijf die op en zorg dat ze op het ticket wordt vastgelegd, in plaats van achteraf afgeleid uit een tag die iemand uit het geheugen heeft toegevoegd. De bruikbare test is eigenaarschap: een escalatie is elk gesprek waarvan de eigenaar verandert omdat de huidige eigenaar het niet kan oplossen binnen zijn bevoegdheid, informatie of vaardigheden. Dat sluit een routinematige herverdeling vanwege capaciteit uit, en sluit het geval in waarin niemand het ticket verplaatste maar een teamleider de uitkomst moest goedkeuren.
Het type doet ertoe, omdat het bepaalt bij wie de kwaliteitsvraag hoort.
| Type | Wat het veroorzaakt | Bij wie de kwaliteit hoort | Wat een piek je vertelt |
|---|---|---|---|
| Hiërarchisch | De klant of de medewerker haalt een teamleider of manager erbij | Gedeeld: de oorspronkelijke medewerker en de teamleider | Medewerkers missen bevoegdheid, of het vertrouwen in de bevoegdheid die ze hebben |
| Functioneel | Het probleem vraagt om een specialistisch team: facturatie, engineering, trust and safety | Het ontvangende team, plus wie de overdracht schreef | Het takenpakket van de eerste lijn is te smal, of de routeringsregels kloppen niet |
| Prioriteit of serviceniveau | Een regel gaat af op de ouderdom van het ticket, risico op overschrijding of accountniveau | De queue en het personeelsmodel, niet een individu | Een capaciteits- of achterstandsprobleem in een escalatiekostuum |
| Door de klant geëist | De klant vraagt uitdrukkelijk naar iemand anders | Het oorspronkelijke contact, bijna altijd | Het vertrouwen brak in het eerste contact. Beoordeel dat contact, niet de escalatie |
| Extern | Het verlaat het bedrijf: een toezichthouder, een openbare review, een juridische dreiging | Het programma, en het zou een formele review moeten starten | Er is eerst iets door meerdere interne controles geglipt |
Waarom je gewone scorecard niet klopt op een geëscaleerd ticket
De meeste teams scoren escalaties met de scorecard die ze al hebben, juist omdat het de scorecard is die ze al hebben. Die levert cijfers op, dus niemand merkt dat een aantal criteria niets meer meet.
Het probleem is niet dat escalaties moeilijker zijn. Het is dat de standaardcriteria zijn ontworpen rond aannames die een escalatie onderuit haalt: dat de medewerker de klant voor het eerst spreekt, dat de klant neutraal is, dat de snelste oplossing de beste is en dat er binnen het standaardplaybook een goed antwoord bestaat. Bij een geëscaleerd ticket klopt daar niets van. Voordat je iets verandert, is het goed om helder te hebben wat je QA-scorecard eigenlijk beweert te meten.
Criterium voor criterium gaat er dit mis.
| Criterium | Wat het meet op een routineticket | Waarom het misgaat bij een escalatie | Gebruik in plaats daarvan |
|---|---|---|---|
| Afhandeltijd of oplostijd | Efficiëntie | Het werk is bewust trager. De escalatie bestaat omdat de snelle route faalde, en snelheid belonen betekent hier de klant afschepen belonen | Tijd tot de eerste inhoudelijke update, en of beloofde termijnen zijn gehaald |
| Naleving van template, macro of script | Consistentie | Het standaardantwoord is precies wat de klant al heeft afgewezen. Het opnieuw gebruiken voelt als een muur | Of het antwoord inging op het specifieke bezwaar dat de klant maakte |
| Opening en begroeting | Professionaliteit | De klant heeft het verhaal al een keer verteld. Een frisse begroeting die die geschiedenis negeert is de klacht, niet de beleefdheid | Erkenning van de context: bewees het antwoord dat de geschiedenis was gelezen |
| Tevredenheidsscore op het ticket | Uitkomst voor de klant | De klant kwam al ontevreden binnen. De score beoordeelt deels het vorige contact, dus de medewerker erft de beoordeling van iemand anders | Verloop van het sentiment over het geëscaleerde gesprek, plus herhaalcontact binnen 14 dagen |
| Oplossing bij eerste contact | Effectiviteit | Het is per definitie geen eerste contact, dus het criterium faalt altijd of wordt stilletjes weggelaten | Duurzame oplossing: kwam hetzelfde probleem terug |
| Juistheid van kennis of beleid | Correctheid | Dit criterium blijft overeind en is hier belangrijker dan waar ook | Houd het, en geef het meer gewicht dan bij routinewerk |
Wat je in plaats daarvan beoordeelt in een geëscaleerd gesprek
Zes criteria dragen bijna het hele signaal bij een geëscaleerd ticket. Elk criterium heeft bewijs nodig dat een tweede reviewer in het transcript kan aanwijzen, anders heb je bijvoeglijke naamwoorden opgeschreven in plaats van beoordelingscriteria.
- Context opnemen. Las de behandelaar de thread voordat die antwoordde? Het bewijs is concreet: er werd verwezen naar iets wat de klant eerder zei, zonder dat de klant het opnieuw hoefde te vertellen. Het bewijs van falen is nog makkelijker te zien, en dat is het volgende punt.
- De herhaalde vraag. Vroeg de behandelaar om informatie die al in de thread staat? Ordernummer, e-mailadres van het account, wat er misging. Dit is binair, een reviewer heeft er tien seconden voor nodig, en medewerkers betwisten het nooit omdat het transcript het beslist.
- Erkennen zonder de schuld af te schuiven. De klant wil dat de fout benoemd wordt. Wat dit criterium laat falen is geen ontbrekend excuus, maar afschuiven: de vorige medewerker, het systeem, het beleid of de klant de schuld geven. Een collega als oorzaak aanwijzen tegenover een klant zou een knock-out-criterium moeten zijn.
- Juistheid van toezeggingen. Beloofde de behandelaar iets wat het bedrijf echt gaat doen, op een datum waarop het echt gebeurt? Dit is het criterium dat de volgende escalatie veroorzaakt als het faalt, dus het verdient zwaar gewicht.
- Gebruik van de bevoegdheid waarvoor werd geëscaleerd. Een escalatie die eindigt met hetzelfde antwoord, gebracht door iemand die hoger in de organisatie zit, heeft je twee medewerkers gekost en de klant niets opgeleverd. Ofwel gebruikte de behandelaar een beslisruimte die de eerste medewerker niet had, ofwel is de escalatieroute decoratie.
- De cirkel rond maken. Kreeg de klant de uitkomst te horen, en kreeg de oorspronkelijke medewerker te horen wat de oplossing was? De tweede helft wordt bijna overal overgeslagen, en wie die overslaat, garandeert dat dezelfde medewerker volgende week dezelfde escalatie veroorzaakt.
Kalibreer voordat je dit uitrolt
Escalaties zijn precies de gesprekken waarover reviewers het oneens zijn, omdat ze emotioneel geladen zijn en omdat het juiste antwoord vaak afhangt van context die het transcript maar half bevat. Houd een kalibratiesessie over drie geëscaleerde tickets voordat de criteria live gaan. Als je reviewers het niet eens kunnen worden over de vraag of de behandelaar echte beslisruimte gebruikte, zullen medewerkers de score zeker niet accepteren. De opzet is dezelfde als bij elke andere kalibratiesessie die je houdt (in het Engels), met escalaties als enige steekproef.
Scoor de overdracht, niet alleen de oplossing
Vraag een supportteam waar escalaties misgaan en ze beschrijven de oplossing. Lees honderd geëscaleerde threads en je ziet dat de schade meestal werd aangericht in de negentig seconden van de overdracht. Het pleidooi van Harvard Business Review om de moeite voor de klant te verminderen in plaats van te proberen te verrassen geldt hier met extra kracht, omdat een escalatie al een tweede poging is en een slordige overdracht er een derde van maakt.
De overdracht is een beoordeelbaar moment op zich, en heeft twee eigenaren. Scoor de overdracht als een apart blok, waarbij de verzendende kant wordt toegewezen aan de oorspronkelijke medewerker en de ontvangende kant aan de behandelaar. Ze gescheiden houden is precies de bedoeling, want alleen zo komt de score bij de juiste persoon terecht.
Verzendende kant
- De reden voor de escalatie staat in het ticket, in woorden, niet alleen als tag.
- Wat al is geprobeerd, is samengevat, zodat de ontvanger het niet herhaalt.
- De klant kreeg te horen dat de overdracht plaatsvond, waarom, en ongeveer wanneer er een antwoord komt. Een stille overdracht is een fout, ook als de oplossing perfect is.
- Er is niets beloofd namens het ontvangende team waar dat team niet mee heeft ingestemd.
Ontvangende kant
- De thread is gelezen voordat het eerste antwoord de deur uitging. De test van de herhaalde vraag beslist dit.
- Het wachten is erkend. De klant heeft nu al twee keer in een queue gezeten.
- De klant is niet gevraagd het probleem opnieuw te vertellen als manier om het gesprek te openen.
- Als het ticket is teruggestuurd of opnieuw is doorgezet, is de reden vastgelegd met dezelfde discipline als bij de eerste overdracht.
Twee cijfers volgen direct uit het op deze manier scoren van de overdracht, en beide zijn nuttiger dan het escalatiepercentage alleen. Het herhaalvraagpercentage is het aandeel geëscaleerde gesprekken waarin de ontvangende behandelaar vroeg om informatie die al in de thread stond. Het bouncepercentage is het aandeel escalaties dat vóór de oplossing opnieuw wordt teruggestuurd of doorgezet, wat meestal een routeringsfout is en geen persoonlijk falen. Geen van beide vraagt om een enquête, en beide zijn te tellen uit de gespreksgegevens die je al hebt. Als je een bredere set metingen opbouwt, hoort dit naast de andere manieren om gesprekskwaliteit te meten (in het Engels).
Het toewijzingsprobleem: wie veroorzaakte deze escalatie eigenlijk?
Dit is de eerlijkheidsvraag die bepaalt of je een QA-programma kunt runnen waar medewerkers in geloven (in het Engels), en bijna geen enkele gids over escalaties gaat erop in.
De meeste escalaties ontstaan eerder in de keten. Tegen de tijd dat een gesprek bij een specialist of teamleider aankomt, is de beslissing die het veroorzaakte al genomen: door een eerste contact dat iets miste, door beleid dat niemand in de eerste lijn mag oprekken, door een product- of systeemfout, of door een verwachting die iemand anders wekte. De behandelaar scoren op het bestaan van de escalatie is de meest voorkomende oneerlijkheid in support-QA, en medewerkers zien het meteen.
De oplossing is een regel en een gewoonte.
De regel. De behandelaar wordt alleen gescoord op de escalatie zelf. Of de escalatie had moeten gebeuren is een aparte bevinding, toegewezen aan een aparte eigenaar, vastgelegd in een apart record. Laat nooit één score beide oordelen dragen, want zodra dat gebeurt, scoren de mensen die je moeilijkste werk doen het slechtst.
De gewoonte. Elke review van een escalatie is twee reviews. Open het geëscaleerde gesprek, en open het contact dat het veroorzaakte. Tag de oorsprong vervolgens in een van vier categorieën:
- Afhandeling. De eerste medewerker had de informatie en de bevoegdheid en gebruikte ze niet. Dit hoort bij een individu en is te coachen.
- Beleid. De medewerker deed precies wat het beleid voorschreef en het beleid leverde een boze klant op. Dit hoort bij wie het beleid beheert, en de medewerker hierop coachen is erger dan nutteloos.
- Systeem of product. Iets was kapot, traag of fout. Dit hoort op een backlog van engineering of operations, niet in een one-on-one.
- Verwachting. Een belofte die elders werd gedaan, door prijzen, marketing, een eerder ticket of een storingsmelding, overleefde de confrontatie met de werkelijkheid niet.
Twee vangrails houden het taggen eerlijk. De oorsprongstag mag niet worden gezet door de behandelaar, die er een duidelijk belang bij heeft, en ook niet door de oorspronkelijke medewerker. Het is de keuze van een reviewer. En als de oorsprong beleid, systeem of verwachting is, verandert er helemaal geen score op medewerkersniveau, en dat is het deel dat je bij de lancering hardop moet zeggen. Zodra de tags zich opstapelen, vormen ze de input voor een echte oorzaakanalyse in plaats van een maandelijkse gok.
Had deze escalatie überhaupt moeten gebeuren?
De kwaliteit van de afhandeling is het verbeteren waard. Het escalatievolume is meer waard, omdat een escalatie die je voorkomt niets kost om goed af te handelen, en omdat elke vermijdbare escalatie een stukje klantontevredenheid is dat je zelf hebt veroorzaakt.
Koppel daarom aan elke review van een escalatie een oordeel, los van de score. Drie opties, en de formulering doet ertoe, want het hele punt is de middelste categorie zichtbaar te maken.
- Vermijdbaar. De eerste medewerker had de bevoegdheid, de informatie en de tools om het op te lossen. Niets structureels hield hem tegen. Dit is een coachingbevinding, en in een gezond programma zou het een klein deel van het totaal moeten zijn.
- Structureel. Niemand in de eerste lijn had het kunnen oplossen, door een recht dat ze niet hebben, een systeem waar ze niet bij kunnen of beleid dat ze niet mogen oprekken. Dit is de belangrijke categorie. Het is geen probleem van de medewerker, het is een ontwerpprobleem, en elk ticket erin is een kandidaat om bevoegdheid een niveau lager te leggen.
- Terecht. De escalatie is het proces dat werkt. Specialistische kennis was echt nodig. Niets te repareren, en het zou in niemands cijfers als defect moeten tellen.
In de structurele categorie zit het geld, en die is onzichtbaar voor elk escalatieprogramma dat alleen de escalatie zelf scoort. Als veertig escalaties van het afgelopen kwartaal allemaal dezelfde goedkeuring voor een terugbetaling nodig hadden, die een niveau boven de eerste lijn ligt, kijk je niet naar een trainingstekort. Je kijkt naar een goedkeuringsdrempel die op de verkeerde plek ligt, en je kunt een prijs op de oplossing zetten door de tickets te tellen.
Een opmerking over kosten, bewust zonder getal. Het is verleidelijk om escalaties te vermenigvuldigen met gemiddelde afhandelkosten en er een kop van te maken. Doe het niet, tenzij je de invoer kunt verdedigen: een echte escalatie kost minstens de tijd van twee mensen, meestal de aandacht van een teamleider, de wachttijd die de klant ervaart en de grotere kans op klantverloop na een slecht herstel, en niets daarvan is constant tussen soorten vragen. Tel de tickets in de structurele categorie en beschrijf de specifieke oplossing die elk cluster nodig heeft. Dat argument doorstaat kritiek. Verzonnen kosten per escalatie niet.
Wat escalatiepatronen samen vertellen
Eén escalatie is een coachinggesprek. Honderd escalaties samen gelezen zijn een kaart van waar het ontwerp van je service faalt, en ze vertellen dingen die geen enkele losse review kan vertellen.
Vijf analyses die maandelijks de moeite waard zijn
- Concentratie per onderwerp. Groepeer escalaties op wat de klant wilde, niet op de tag die de medewerker gebruikte. Een handvol onderwerpen levert bijna altijd het grootste deel van het volume op, en meestal zijn dat randgevallen van beleid in plaats van complexe problemen.
- Verdeling van de oorsprong door de tijd. Volg de vier toewijzingscategorieën als aandelen. Als het aandeel afhandeling daalt terwijl het structurele aandeel gelijk blijft, werkt je coaching wel, maar je proces niet.
- Herhaalde escalaties. Dezelfde klant, hetzelfde onderliggende probleem, twee keer geëscaleerd. Dit is de sterkste losse aanwijzing dat de eerste oplossing cosmetisch was, en elk geval is het waard om met de hand te bekijken.
- Bounce- en herhaalvraagpercentage per ontvangend team. Die laten de teams zien die werk krijgen waarvoor ze niet zijn ingericht, en dat is een routeringsgesprek, geen kwaliteitsgesprek.
- Tijdstip en bezetting. Escalaties die zich ophopen rond dienstwissels of gaten in de bezetting zijn een roosterbevinding, en geen hoeveelheid coaching zal ze verschuiven.
Het noemerprobleem
Escalatiepercentages tussen medewerkers vergelijken is de snelste manier om het team kwijt te raken, want de medewerker op de moeilijkste queue escaleert het meest. Het escalatiepercentage hoort bij je andere KPI’s voor de klantenservice, en het is alleen vergelijkbaar binnen dezelfde queue, hetzelfde kanaal en ongeveer dezelfde mix van vragen, en ook dan hoort het in een gesprek en niet op een ranglijst. Een hoog escalatiepercentage bij complex werk kan juist gedrag zijn. Een laag percentage kan betekenen dat een medewerker weigert te escaleren wat wel geëscaleerd moet worden, en dat is de duurdere fout, die in plaats daarvan als herhaalcontact zichtbaar wordt.
Waarom steekproeven hier tekortschieten
Escalaties zijn per definitie zeldzaam, en dat is precies wat ze moeilijk goed te beoordelen maakt. Een kleine willekeurige steekproef uit de gesprekken van een maand, getrokken zoals de meeste QA-steekproeven werken, bevat bijna geen escalaties, en de paar die erin zitten zijn niet representatief voor de onderwerpen die ze veroorzaken. De meeste teams reageren door escalaties met de hand uit te kiezen voor review, wat een andere vertekening introduceert: je vindt wat je ging zoeken. Elke escalatie beoordelen in plaats van een steekproef maakt van een anekdote een patroon, en het is hetzelfde argument als achter 100% dekking die trends laat zien die een steekproef van 3% nooit kan tonen (in het Engels).
Daar verdient geautomatiseerd scoren zijn plek, zodra de criteria hierboven bestaan en de reviewers het erover eens zijn. Auto QA van Kaizo past je eigen escalatiecriteria toe op elk geëscaleerd gesprek in plaats van op het handjevol dat in de steekproef belandt, zodat de concentratie per onderwerp en de verdeling van de oorsprong geteld worden in plaats van geschat. Belangrijker dan de dekking is dat elke aftrek gekoppeld blijft aan het moment in het gesprek dat hem veroorzaakte. Als een medewerker een score betwist op een ticket dat hij heeft geërfd, kan de reviewer dus naar het contact kijken in plaats van uit het geheugen te discussiëren. Wat er uit het geheel naar voren komt, voedt vervolgens de coachinggesprekken (in het Engels) die het voeren waard zijn, en laat de gesprekken die dat niet zijn stilletjes verdwijnen.
Veelgestelde vragen
Wat is escalatiebeheer?
Escalatiebeheer is het oplossen van een gesprek nadat het eigenaarschap is overgegaan van de persoon die het als eerste ontving, meestal omdat het probleem meer bevoegdheid, meer specialistische kennis of een beslissing vroeg die de eerste medewerker niet kon nemen. Het omvat de overdracht zelf, het herstel bij een klant die al gefrustreerd is, de juistheid van wat wordt toegezegd, en het rond maken van de cirkel met zowel de klant als de oorspronkelijke medewerker. In kwaliteitscontrole wordt het als een eigen categorie werk behandeld, omdat de criteria voor een routineticket niet zuiver van toepassing zijn op een geërfd ticket.
Hoe handel je een escalatie goed af?
Lees de hele thread voordat je antwoordt, zodat de klant zich nooit hoeft te herhalen. Benoem wat er misging zonder een collega, het beleid of de klant de schuld te geven. Gebruik de beslisruimte waarvoor je werd ingeschakeld, want een escalatie die hetzelfde antwoord oplevert van iemand die hoger in de organisatie zit, heeft niemand geholpen. Zeg alleen toe wat echt gaat gebeuren, op data die echt zijn. Maak daarna de cirkel twee keer rond: vertel de klant de uitkomst, en vertel de medewerker die escaleerde wat de oplossing was, zodat dezelfde escalatie volgende week niet opnieuw gebeurt.
Wat is een voorbeeld van een klantescalatie?
Een medewerker die het beleid volgt, weigert een klant een terugbetaling, de klant antwoordt dat dit onacceptabel is en vraagt naar een leidinggevende. Het ticket gaat naar een teamleider die bevoegd is om een uitzondering te maken. Dat is een hiërarchische, door de klant geëiste escalatie, en het is de meest voorkomende vorm. Een ander voorbeeld: een factuurverschil dat de eerste lijn niet in haar tools kan zien, wordt doorgestuurd naar een specialist van finance. Die escalatie is functioneel, niemand deed iets fout, en ze zou niet tegen de eerste medewerker moeten tellen.
Moet je geëscaleerde tickets met dezelfde QA-scorecard scoren?
Nee. Minstens vier standaardcriteria zijn misleidend bij een escalatie. Afhandeltijd bestraft het tragere werk dat de escalatie juist mogelijk moet maken, naleving van templates beloont het hergebruik van het antwoord dat de klant al afwees, criteria voor begroeting en opening negeren dat het verhaal al een keer is verteld, en tevredenheidsscores beoordelen deels het vorige contact in plaats van het huidige. Houd juistheid en naleving van beleid, schrap of vervang de rest, en voeg criteria toe voor de overdracht, de juistheid van toezeggingen en het gebruik van bevoegdheid.
Hoe meet je de kwaliteit van escalatiebeheer?
Gebruik vier metingen samen en geen ervan los. Een score op basis van criteria voor het geëscaleerde gesprek, die context opnemen, erkenning, juistheid van toezeggingen, gebruik van bevoegdheid en het rond maken van de cirkel dekt. Het herhaalvraagpercentage, het aandeel escalaties waarin de ontvangende behandelaar vroeg om iets wat al in de thread stond. Het bouncepercentage, het aandeel dat vóór de oplossing wordt teruggestuurd of opnieuw doorgezet. En het percentage herhaalde escalaties, het aandeel waarin dezelfde klant hetzelfde probleem twee keer escaleert, het duidelijkste teken dat de eerste oplossing cosmetisch was.
Wat is een goed escalatiepercentage?
Er is geen benchmark die het citeren waard is, omdat het getal volledig afhangt van hoe je een escalatie definieert, wat je product is en hoeveel bevoegdheid in de eerste lijn ligt. Een team dat elke doorverwijzing naar een specialist als escalatie telt, rapporteert een veelvoud van het percentage van een team dat alleen de betrokkenheid van een teamleider telt. Vergelijk je percentage met je eigen trend en met vergelijkbare interne queues, en let meer op de verdeling dan op het niveau. Een stabiel percentage met een dalend aandeel vermijdbare escalaties is een programma dat werkt.
Wie moet je scoren als een ticket wordt geëscaleerd?
Beide mensen, op verschillende dingen. De oorspronkelijke medewerker wordt gescoord op de overdracht die hij verstuurde en op de vraag of zijn afhandeling de escalatie veroorzaakte. De ontvangende behandelaar wordt gescoord op de escalatie zelf en nooit op het feit dat die bestaat. Of de escalatie had moeten gebeuren, wordt vastgelegd als een aparte bevinding met een van vier oorsprongen: afhandeling, beleid, systeem of een verwachting die elders werd gewekt. Als de oorsprong beleid, systeem of verwachting is, zou geen enkele score op medewerkersniveau mogen bewegen.
Gerelateerde onderwerpen
- Wat beoordelingscriteria voor QA zijn en hoe je ze opstelt
- De QA-scorecard: wat erop hoort
- Wat kalibratie in kwaliteitsmonitoring is en waarom het ertoe doet
- Oorzaakanalyse voor supportteams
- Gesprekskwaliteit meten (in het Engels)
- Wat 100% QA-dekking echt betekent (in het Engels)
Ontdek hoeveel van je escalaties vermijdbaar waren
Neem een maand aan geëscaleerde tickets mee en de scorecard waarmee je ze nu beoordeelt. We laten je zien waar die escalaties zijn ontstaan, hoeveel er in de structurele categorie zitten die je weg kunt ontwerpen, en wat er verandert als de criteria op allemaal worden toegepast in plaats van op de paar die in de steekproef belanden.