Casestudy versus bewijs: wat één succesverhaal je vertelt

Eén gedocumenteerde casestudy kan laten zien dat een uitkomst in één situatie is opgetreden, maar kan op zichzelf niet schatten hoe vaak vergelijkbare bedrijven dat resultaat halen, of dat jij het ook gaat zien. Het resultaat bij één klant is een aanknopingspunt voor een beslissing, geen voorspelling.

Neem een hypothetisch voorbeeld. Een oprichter overweegt software te kopen die de onboarding van nieuwe klanten automatiseert. Op de site van de leverancier staat een casestudy: bij een klant daalde het aantal supporttickets na de invoering. De naam van het bedrijf staat erbij, de uitrol wordt beschreven en een tevreden manager komt aan het woord. Rechtvaardigt dat verhaal een aankoop voor het hele bedrijf?

Het verschil zit tussen wat in één omgeving mogelijk bleek en hoe vaak dat in vergelijkbare omgevingen gebeurt. Een derde vraag is wat het resultaat veroorzaakte. Een vierde is of de omstandigheden bij die klant lijken op die van jouw bedrijf. Elke vraag vraagt om een eigen onderbouwing.

Is een casestudy bewijs?

Ja. Een casestudy is bewijs over één specifiek geval. Hoe zwaar dat bewijs weegt, hangt af van wat je kunt inzien. Een losse getuigenis zonder onderliggende stukken is mager bewijs. Een verslag met gedateerde metingen, een duidelijke volgorde van gebeurtenissen en openheid over andere veranderingen in dezelfde periode onderbouwt veel preciezere uitspraken over die ene omgeving. Het etiket op de voorkant zegt weinig over de kwaliteit van wat erin zit.

In Het bewijsbewuste leven staat een gerapporteerde ervaring op de tweede sport van de Bewijsladder. De zeven sporten zijn bewering, anekdote, autoriteit, mechanisme, studie, convergentie en je eigen test. Het zijn geen automatische rapportcijfers, maar vragen om te onderzoeken wat voor onderbouwing er onder een claim ligt. Hoofdstuk 2 vraagt je om op elke sport de striktheid, de onafhankelijkheid en de relevantie te toetsen. Een zorgvuldig uitgewerkte casus kan heel bruikbaar zijn, maar al dat detail levert nog geen slagingskans op over bedrijven heen. Een casestudy is één sport op de ladder, geen eindoordeel.

Houd vier conclusies uit elkaar:

Vraag	Wat één gedocumenteerde casus je kan geven	Wat die casus alleen niet kan beslechten
Is het gebeurd?	Een verslag van de uitkomst op één plek en in één periode, dat je kunt controleren.	Of de vastlegging klopt en of de uitkomst steeds op dezelfde manier is gemeten.
Hoe verliep het werk?	De stappen, de randvoorwaarden en een mogelijk mechanisme.	Welke stap de uitkomst veroorzaakte, of wat er zonder de ingreep was gebeurd.
Hoe vaak gebeurt dit bij vergelijkbare bedrijven?	Het resultaat bij één bedrijf, en soms verhoudingscijfers binnen dat bedrijf.	Hoe vaak vergelijkbare implementaties elders hetzelfde opleveren.
Werkt het ook hier?	Omstandigheden die je naast je eigen praktijk kunt leggen.	Welke voorwaarden noodzakelijk waren, en wat er gebeurt in een ander team, klantsegment of markt.

Een casus kan meer bevatten dan een anekdote. Zitten er een vergelijking of operationele cijfers in, beoordeel die onderdelen dan op hun eigen merites. Vraag je ook dan af welke conclusie elk onderdeel draagt. Hoofdstuk 8 van het boek maakt die scheiding met een verzonnen supportcasus: de gebeurtenissen liggen voor de oefening vast, terwijl de concurrerende verklaringen en het advies voor een ander team open blijven.

Wat laat één casus wél nuttig zien?

Ten eerste kan een casus aantonen dat iets in één omgeving mogelijk is en het mechanisme van het werk zichtbaar maken. In het onboardingvoorbeeld zitten de waardevolle details in de uitvoering: welke vragen klanten stelden, waar de automatisering ze opving, wanneer een medewerker het overnam en welke verzoeken bleven liggen. Zulke details laten stap voor stap zien hoe de uitrol verliep en waar je in je eigen proces op moet letten. Ze vertellen je niet wat er zonder de wijziging was gebeurd, of welke voorwaarden doorslaggevend waren.

Ten tweede kan een geverifieerde casus dienen als tegenvoorbeeld voor een letterlijke ‘dit werkt nooit’-bewering. Zegt iemand dat een aanpak nooit werkt, dan haalt één goed gedocumenteerd geval dat aan dezelfde definitie van succes voldoet die stelling onderuit. Of de aanpak meestal werkt, weet je daarmee nog steeds niet. Wees net zo kritisch op de definitie: minder tickets betekent niet automatisch dat klanten beter zijn geholpen.

Ten derde kan een geloofwaardig verslag van schade een snelle veiligheidscheck rechtvaardigen voordat je weet hoe vaak die schade voorkomt. Konden gebruikers in één casus geen menselijke hulp meer bereiken, dan kun je die route bij jezelf controleren voordat je een uitrol uitbreidt. Wat er op het spel staat, rechtvaardigt een voorzorgsmaatregel terwijl de frequentie onbekend is. Bekend wordt die frequentie er niet door.

De nuttige gewoonte: schrijf eerst de smalle zin op die de casus echt ondersteunt, en pas daarna de bredere bewering waarop je wilt handelen. De ruimte tussen die twee zinnen is je volgende onderzoek. Hoe grondig je toetst, hangt af van wat je met de casus van plan bent. Hoofdstuk 8 zegt het zonder omwegen: “Het gebruik dat je van het verhaal wilt maken, bepaalt hoeveel toetsing de moeite waard is.”

Waar verandert één succes in een slechte voorspelling?

De voorbeeldklant van een leverancier wordt de gemiddelde klant. Het verhaal kan kloppen en de klant kan oprecht tevreden zijn. Maar een casus die voor publicatie is uitgekozen, is geen afgebakende steekproef van iedereen die het product heeft geprobeerd. Vraag hoeveel vergelijkbare implementaties er waren, welke klanten in aanmerking kwamen voor een casestudy en wat er gebeurde bij de pogingen waarover niets is geschreven. Gepubliceerde successen tellen zonder die pogingen levert geen slagingskans op.

De geschiedenis van een bekend bedrijf wordt jouw draaiboek. Je kunt de zichtbare tactiek kopiëren zonder de uitgangspositie, de distributie, de mensen of de timing van dat bedrijf. De introductie van het boek laat dit zien met Daniel, een gefictionaliseerde, samengestelde oprichter die het kanaalsucces van een andere oprichter uit een podcast behandelt als voorspelling voor zijn eigen bedrijf. Het boek benoemt de valkuil: wie hetzelfde probeerde en faalde, kwam nooit in een podcast. Dat is overlevingsbias. Daniels verhaal leert je de vraag te stellen; het is geen bewijs over een bestaand bedrijf. De redenering geldt breder: hoor je vooral van bedrijven waarvan de uitkomst een goed verhaal opleverde, dan kun je niet afleiden hoe gangbaar hun tactiek was.

Eén verslag klinkt als een koor. Hoofdstuk 2 waarschuwt ervoor om “één bron in twintig jassen” aan te zien voor onafhankelijke convergentie. Hoofdstuk 10 vraagt je je voor te stellen dat iedereen in Daniels overleg dezelfde casestudy van de leverancier heeft gelezen. Hun overeenstemming kan die lezing goed weergeven, maar voegt geen onafhankelijke casus toe. Twee mensen die ook mislukte implementaties hadden onderzocht, zouden meer bewijs op tafel leggen, ook als ze het oneens waren over wat er moet gebeuren. Hetzelfde geldt als een handvol blogs of verkooppresentaties het resultaat van één klant navertelt.

Niets hiervan vraagt je om de leverancier, de oprichter of het team van oneerlijkheid te betichten. Het vraagt alleen dat je de onzichtbare pogingen in beeld houdt wanneer je bepaalt wat één zichtbaar succes kan dragen.

Uitgewerkt voorbeeld: het aantal tickets daalde

Stel dat de casestudy de oprichter twee onboardingcohorten laat zien. Elk getal hieronder is hypothetisch. Beide cohorten zijn 30 dagen gevolgd, en de tickets zijn geteld over de eerste 30 dagen van elke nieuwe klant.

Cohort	Nieuwe klanten	Onboardingtickets	Tickets per nieuwe klant
Voor de tool	400	120	0,30
Na de tool	200	90	0,45

Het totale aantal tickets daalde van 120 naar 90. Rekenkundig klopt die kop. Alleen stroomden er half zoveel nieuwe klanten in, en het aantal tickets per nieuwe klant steeg van 0,30 naar 0,45. Geen van beide cijfers vertelt je of de ondersteuning beter werd. Meer tickets kan wijzen op meer problemen, maar ook op een laagdrempeliger route naar hulp. Onopgeloste verzoeken en de weg naar een medewerker tellen net zo goed mee.

Een voor-en-navergelijking kan bovendien geen van beide verschuivingen aan de tool toeschrijven. De klantmix, de hulppagina’s, de bezetting of het product zelf kunnen in dezelfde periode zijn veranderd. Een sterkere casus zou die veranderingen benoemen en een vergelijking laten zien waarmee je de aannemelijke verklaringen uit elkaar kunt houden. En ook dan blijft de vraag of de situatie bij die klant op die van jou lijkt.

Wie iets over de frequentie wil weten, stelt de leverancier een andere vraag: welk deel van alle vergelijkbare klanten die de tool invoerden, verbeterde in dezelfde periode op een vooraf vastgelegde onboardingmaat? Voor dat antwoord heb je ook de mislukte en onafgemaakte pogingen nodig, niet alleen de uitgelichte. En je hebt een vaste maat en meetperiode nodig. De check voor virale startupcijfers werkt met dezelfde discipline: vul in wie meetelt, welke gebeurtenis en over welke periode.

Kan de leverancier die noemer niet geven, noteer dan: slagingskans onbekend op basis van dit materiaal. Een map met uitgekozen klantverhalen vult dat gat niet. De oprichter kan nog steeds besluiten dat een kleine proef de moeite waard is, maar zet geen verzonnen slagingspercentage in het investeringsvoorstel.

Welk bewijs rechtvaardigt je volgende stap?

In het besluitvormingsoverleg van vijfentwintig minuten uit hoofdstuk 10 houdt het team twee dingen uit elkaar: de casestudy van de leverancier maakt het plausibel dat een aanpassing in de onboarding helpt, terwijl Daniels eigen supportdossiers het probleem aanwijzen dat ze willen oplossen. Geen van beide toont aan dat deze specifieke wijziging ook echt werkt. Begin op dezelfde manier, bij je eigen dossiers. Levert de onboarding echt vermijdbare tickets op, of lost de tool een probleem op dat je nooit hebt gemeten? Leg vóór een pilot vast welke klanten meedoen en welke uitkomst telt. In dit voorbeeld kan de oprichter kijken naar tickets per nieuwe klant, onopgeloste verzoeken en of klanten nog een medewerker kunnen bereiken.

Beperk de proef daarna tot één geschikte onboardingroute en houd de bestaande route naar een medewerker open. Is een vergelijkingsgroep haalbaar, gebruik die dan; zo niet, noteer wat er tijdens de proef nog meer veranderde. Laat een korte teambeslissingsnotitie achter met de actie, de eigenaar, het hiaat in het bewijs, de stopvoorwaarde als verzoeken niet veilig kunnen worden afgehandeld en de evaluatiedatum. Doe dat voordat het eerste resultaat binnenkomt, nu je nog makkelijk een eerlijke maatstaf kiest.

Zo’n proef kan laten zien of de aanpak in jouw bedrijf past, of waar het schuurt. Een marktbrede slagingskans levert hij niet op, en een kleine voor-en-navergelijking isoleert op zichzelf ook geen oorzaak. Die grenzen maken de proef niet zinloos. Ze laten zien hoeveel gewicht de uitkomst kan dragen.

Het LEVEL-framework uit het boek geeft de beslissing een kort verslag:

1. Locate: “Deze tool verlaagt bij ons het aantal onboardingtickets per nieuwe klant zonder dat er meer verzoeken onopgelost blijven.”
2. Estimate: Wat kost een volledige uitrol als die bewering niet klopt? En wat kosten wachten of een beperkte proef?
3. Value: Benoem de sport, het verslag van één klant, en toets dan de onderliggende cijfers, de selectie, de onafhankelijkheid en de relevantie, naast je eigen supportdata.
4. Expose: De noemer van de leverancier, andere verklaringen en de aansluiting op jouw klanten blijven open.
5. Lean: Vraag de ontbrekende gegevens op en doe, als dat veilig en haalbaar is, eerst een afgebakende proef voordat je uitbreidt.

Het boek presenteert LEVEL als praktische synthese, niet als gevalideerde garantie voor betere uitkomsten. De uitleg van de vijf stappen laat de volledige check zien. Reizen er meerdere claims mee tussen de leverancierspagina, het budgetvoorstel en het uitrolplan, houd ze dan bij in een bewijsregister op claimniveau, zodat de casus niet bij elke doorvertelling een grotere conclusie krijgt.

Probeer dit vandaag (15 minuten)

Kies één casestudy die nu meeweegt in een beslissing. Houd de bron open en schrijf vier regels op:

Wat de casus laat zien:   [Waargenomen uitkomst, omgeving, periode en controleerbaar verslag]
Wat de casus niet toont:  [Frequentie bij vergelijkbare pogingen, oorzaak en aansluiting op onze praktijk]
De vraag naar de noemer:  [Bij welke vergelijkbare pogingen trad deze uitkomst op, en in welke periode?]
Goedkoopste veilige test: [Afgebakende lokale proef, eigenaar, maat, stopregel en evaluatiedatum]

Staat er bij de eerste regel geen controleerbaar verslag, vraag daar dan om. Ontbreekt bij de derde regel de noemer, laat de slagingskans dan op onbekend staan. Is er geen veilige test mogelijk, zoek dan beter bewijs voordat je je aan iets groters bindt. De casus verdient je aandacht. Je volgende stap hangt af van wat je echt kunt natrekken.

Citeer deze pagina:Casestudy versus bewijs: wat één succesverhaal je vertelt.Len P. van der Hof. https://lenvanderhof.com/nl/blog/casestudy-versus-bewijs/ · Gepubliceerd 22 oktober 2026.