Open antwoorden uit je enquête analyseren, en waar AI past

De meeste enquêteteams steken al hun ontwerptijd in de schaalvragen en behandelen het opmerkingenveld als bijzaak. Dat is de omgekeerde wereld. De gesloten vragen vertellen je wat er gebeurde. De ene open vraag aan het eind vertelt je waarom. Open tekst is ook waar de analyse stilletjes vastloopt, want een paar duizend vrije antwoorden lezen is traag werk dat geen enkel dashboard voor je doet. Dus worden ze vluchtig doorgekeken, of in een chatmodel geplakt dat een samenvatting teruggeeft die niemand controleert. Dit is een gids om het wél goed te doen, en om de grens te kennen waar een AI-model ophoudt met helpen.

Waarom open antwoorden de moeite waard zijn

Een cijfer vertelt je de omvang van een gevoel, niet de oorzaak. Een klant die je een 3 op 5 geeft, geeft je een getal dat je kunt middelen, maar het zwijgt over de vraag of het aan de prijs lag, de onboarding, één supportticket, of een advertentie van een concurrent die ochtend. Het open antwoord naast dat cijfer is de enige plek waar de reden in hun eigen woorden opduikt, voordat jij hem filtert door je aanname over het probleem.

Open tekst is ook het deel van een enquête dat je niet vooraf hebt vastgelegd. Elke gesloten vraag is een hypothese: je gokte de antwoorden en drukte ze af als opties. Was je gok onvolledig, dan kan de vraag je dat niet vertellen, want de ontbrekende optie staat er niet. In het open veld verschijnt het antwoord waar je nooit aan dacht. Gooi je het weg, dan hou je alleen over wat je al verwachtte.

Coderen is de vaardigheid waar de rest op steunt

Het punt is dat open tekst niet als data binnenkomt. Het komt als proza, in wisselende lengtes, spelling, talen en moeite, en niets past in een grafiek tot iemand er structuur op legt. Die stap heet coderen, en dat is waar alles om draait.

Coderen betekent dat je elk antwoord leest en het labelt met een of meer categorieën, zodat "de checkout bleef time-outen" en "de betaalpagina bevroor twee keer" allebei onder een code als betrouwbaarheid checkout vallen. Zodra elk antwoord codes draagt, kun je ze tellen, kruisen met het cijfer, en rapporteren dat 31% van de criticasters de checkout-betrouwbaarheid noemde, in plaats van drie citaten aan te halen en te hopen dat ze typisch zijn. Coderen maakt van een anekdote bewijs.

De verzameling codes en hun definities is je codeboek. Een goed codeboek heeft categorieën die duidelijk genoeg gescheiden zijn om niet te overlappen, specifiek genoeg om iets mee te doen, en elk in één zin gedefinieerd zodat twee verschillende mensen die hetzelfde antwoord labelen bij dezelfde code uitkomen. Vage codes als "gebruikservaring" zijn waardeloos, want alles past eronder. Open tekst analyseren is eigenlijk het werk van een solide codeboek bouwen en toepassen. En dat is precies het werk waarvan mensen hopen dat AI het overneemt.

Deductief en inductief coderen zijn niet hetzelfde

Deze splitsing bepaalt waar AI veilig is, dus is het de moeite waard om precies te zijn. Deductief coderen betekent dat je het codeboek naar de data brengt: je hebt je categorieën al, en de taak is ze consistent toepassen op duizenden antwoorden. Inductief coderen betekent dat je het codeboek uit de data bouwt: je leest de antwoorden zonder vaste categorieën en laat de thema's opkomen uit wat mensen echt schreven. De meeste echte projecten doen allebei: eerst inductief een codeboek opstellen uit een eerste steekproef, dan deductief toepassen op de volledige set.

De twee taken vragen om verschillende dingen. Een bekende code toepassen is een matchtaak met een duidelijk goed antwoord. Een thema ontdekken is interpretatie. Het hangt af van toon, van context, en van het oordeel om te zien dat drie verschillend geformuleerde klachten hetzelfde onderliggende probleem zijn. Hou deze splitsing vast: ze valt bijna samen met wat een taalmodel wel en niet aankan.

Waar AI echt betrouwbaar is: een codeboek toepassen dat jij schreef

Geef een model een duidelijk codeboek en vraag het antwoorden ertegen te labelen, en het presteert ongeveer zo goed als een mens. Een blinde vergelijking in PLOS Digital Health van april 2026 toetste meerdere modellen tegen menselijke analisten op interviewdata uit de zorg. Bij deductief coderen, het toepassen van vooraf bepaalde codes, kwamen de modellen non-inferieur uit tegenover mensen: een gemiddelde overeenstemming van 93,5% voor de modellen tegen 92,7% voor de mensen. De strikte hallucinatiegraad, waarbij een model bewijs verzon dat niet in de tekst stond, was 1,2%. Voor de saaie helft van het coderen is dat echte winst. Een model labelt tienduizend antwoorden tegen je codeboek in één nacht, zonder in te zakken bij antwoord vierduizend. Jij houdt de interpretatie in handen en delegeert het opschalen. De gids over enquêtes analyseren met AI via MCP legt uit hoe je een model read-only op je responsdata aansluit, zodat het dit labelen doet op data die het niet kan wijzigen.

Waar AI thema's misvat: ze zelf voor je ontdekken

Draai de taak nu om. Vraag een model om ruwe antwoorden te lezen en je te vertellen wat de thema's zijn, zonder codeboek, en het wordt veel minder betrouwbaar. In hetzelfde onderzoek haalde slechts één van de geteste modellen de non-inferioriteitsgrens bij inductieve analyse. De modellen waren juist het zwakst waar het telt: gevoeligheid voor nuance en latente betekenis, het soort lezen dat een impliciete klacht of een onuitgesproken thema opvangt. De brede foutmarge, die ook gedeeltelijke mismatches en verkeerde toewijzingen meetelt, was 12,4%.

De fout is zelden een wilde verzinning. Ze is stiller, en dat maakt het erger. Een model produceert een plausibele, netjes geordende reeks thema's die gezaghebbend leest, en strijkt onderweg de uitschieters glad, voegt twee losse problemen onder één kop samen, of promoveert een formulering die het één keer zag tot "belangrijk thema". Je vangt dit niet uit de samenvatting, die oogt altijd zelfverzekerd. Je vangt het door de ruwe antwoorden eerst zelf te lezen. Een model met een dunne stapel antwoorden geeft nog steeds vijf keurige thema's terug, zonder je te waarschuwen dat de steekproef te klein was om ze te dragen.

Een werkwijze die AI inzet voor wat het goed kan

Leg de twee bevindingen naast elkaar en de taakverdeling schrijft zichzelf. Lees eerst een steekproef met de hand, een paar honderd antwoorden, genoeg om de vormen te zien die terugkomen. Dit is de inductieve stap, en die blijft menselijk, want het is de stap waar AI het slechtst in is. Stel je codeboek op uit dat lezen, één zin per categorie. Geef dan het codeboek en de volledige dataset aan het model voor de deductieve stap, en laat het elk antwoord op schaal labelen. Controleer het werk steekproefsgewijs door zelf een willekeurige selectie opnieuw te coderen en te vergelijken. Verschil je op meer dan een klein deel, dan is je codeboek dubbelzinnig, niet het model. Wat de mens nooit uit handen geeft, is beslissen wat de categorieën zijn en of de resultaten standhouden. De rest, het repetitieve matchen, gaat naar het model.

Open tekst kwantificeren zonder met cijfers te liegen

Zodra antwoorden gecodeerd zijn, wil je percentages, en percentages zijn waar open-tekstanalyse zichzelf het meest overschat. Een code die in 8% van de opmerkingen opduikt is niet hetzelfde als een probleem dat 8% van de klanten raakt, want maar een deel schreef überhaupt iets, en wie dat deed zit aan de meer gemotiveerde of geïrriteerde kant van je steekproef. Rapporteer gecodeerde open tekst als een aandeel van de mensen die iets schreven, nooit als een aandeel van iedereen.

Let ook op kleine aantallen. Een thema dat door negen opmerkingen op vierduizend wordt gedragen is een signaal om uit te zoeken, geen trend om beslissingen op te baseren. De gids over schaalvragen ontwerpen legt uit waarom een getal genoeg antwoorden onder zich nodig heeft voordat het iets betekent, en gecodeerde open tekst is geen uitzondering.

Faalvormen om op te letten

Een paar valkuilen komen steeds terug. Toewijzing van antwoorden: voer je een model veel antwoorden tegelijk, dan kan het vertroebelen welk antwoord wat zei, deels waarom de brede foutmarge hierboven hoger lag dan het verzinselcijfer. Gehoorzame thema's: modellen neigen naar de nette samenvatting, dus een echt tegenstrijdige of ongemakkelijke bevinding kan worden weggepoetst. Het verdwijnende zeldzame geval: de ene opmerking over een ernstig toegankelijkheidsprobleem of een juridisch risico telt veel zwaarder dan de frequentie van één op drieduizend suggereert, en een samenvatting die op frequentie stuurt laat hem vallen. En antwoorden van lage kwaliteit of door een machine geschreven die de invoer vervuilen nog voor het coderen begint. De gids over responskwaliteit bewaken legt uit hoe je die er eerst uit filtert.

Niets hiervan betekent dat je AI moet mijden. Het betekent: lees zelf een echte steekproef van de ruwe tekst, hou de zeldzame-maar-ernstige opmerkingen in beeld, en behandel elk thema dat het model zelf naar boven haalt als een hypothese om te verifiëren, niet als iets om te publiceren.

De analyse begint bij het schrijven van de vraag

De schoonste open-tekstanalyse is degene die je maanden eerder opzette door een goede vraag te stellen. "Nog opmerkingen?" levert een kerkhof op van "nee", "n.v.t." en gemopper dat lastig te coderen is, want het gaat nergens specifiek over. Een gerichte prompt als "Welk ene ding had dit makkelijker gemaakt?" levert antwoorden op die al clusteren, want je hebt afgebakend waarover mensen zouden praten voordat ze begonnen te typen. De gids over betere enquêtevragen schrijven is hier direct van toepassing. Een gerichte open vraag is vriendelijker voor de respondent, en het is het verschil tussen een codeboek dat zichzelf bijna bouwt en een dat je op verspreide antwoorden moet forceren. Stel er dus liever één goede dan drie vage, en beslis vóór je verzendt welk besluit de antwoorden moeten voeden.