Stap 3: open het tabblad Bestellingen en kies de bestelling.
Stap 4: klik op Opslaan.
Stap 5: de klant krijgt automatisch een bevestiging.
Home
Verouderde documentatie
Verouderde documentatie: waarom ze achterloopt en hoe je het merkt
Je documentatie was juist toen je ze schreef. Je product is sindsdien tien keer veranderd. Deze pagina legt uit hoe documentatie veroudert, waarom dat sneller gaat naarmate je vaker releaset, waarom niemand in je team het ziet, en hoe je het toch op tijd merkt. Het product komt pas op het einde.
Een bestelling bevestigen
Die knop heet nu "Bevestigen" en staat onder een ander tabblad.
Wat verouderde documentatie is
Verouderde documentatie is elk artikel dat iets anders beschrijft dan wat je klant vandaag op zijn scherm ziet. Dat klinkt eenvoudig, maar er zijn drie soorten, en die zien er heel anders uit.
Het artikel dat fout staat
Stap vier zegt "klik op Opslaan", maar die knop heet nu "Bevestigen" en staat onder een ander tabblad. Het artikel leest nog vlot. Het klopt alleen niet meer.
Het artikel dat onvolledig is
Het beschrijft de instellingenpagina zoals ze vorig jaar was. Sindsdien kwamen er drie opties bij. Het artikel is niet fout, het zwijgt gewoon over de helft.
Het artikel dat ontbreekt
Je hebt een functie gebouwd, uitgerold en aangekondigd. Niemand heeft er ooit een artikel over geschreven. Voor je klant is dat hetzelfde als verouderd: hij zoekt, vindt niets, en stuurt een vraag.
Het woord "verouderd" doet vermoeden dat er ooit een goede versie was. Bij de derde soort was die er nooit. Toch hoort ze in dit rijtje, want de oorzaak is dezelfde: je product beweegt en je documentatie beweegt niet mee.
Je documentatie veroudert sowieso
Documentatie veroudert niet omdat je team slordig is. Ze veroudert omdat schrijven en bouwen op twee verschillende momenten gebeuren, door twee verschillende mensen, met twee verschillende prioriteiten.
De ontwikkelaar die een knop verplaatst, ziet dat als een kleine wijziging. Terecht. Het is een kleine wijziging. Te klein om er de kennisbank voor te openen, een artikel te zoeken en een zin aan te passen. Dus doet hij het niet. En de collega van de klantendienst die de kennisbank beheert, weet niet dat de knop verplaatst is. Niemand heeft het haar gezegd, want het was te klein om te melden.
Elk van die wijzigingen is op zichzelf onschuldig. Het probleem zit in de optelsom. Na twintig kleine wijzigingen beschrijft je artikel een product dat niet meer bestaat, en toch kan niemand de release aanwijzen waar het fout liep. Er was geen moment waarop de documentatie brak. Ze is gewoon achtergebleven.
Daar komt bij dat bijna geen enkel softwarebedrijf iemand heeft die alleen maar documentatie schrijft. Het werk ligt bij een ontwikkelaar, een productmanager of een supportmedewerker die het erbij doet. Als het druk is, en het is altijd druk, dan valt "het erbij doen" als eerste weg. Waarom dat zo hardnekkig is, en hoe je er alsnog uitraakt, lees je in Waarom raakt je documentatie altijd verouderd (en hoe je dat oplost).
Hoe sneller je releaset, hoe sneller het gaat
Een softwarebedrijf dat elk kwartaal releaset, heeft vier momenten per jaar waarop documentatie kan achterlopen. Een bedrijf dat elke week releaset, heeft er vijftig. Het probleem is bij beide hetzelfde. Alleen is het tempo anders, en het tempo bepaalt of je het nog kan bijhouden.
4
momenten per jaar waarop documentatie kan achterlopen, bij een release per kwartaal
50
momenten per jaar bij een release per week
+0
extra tijd om na te lezen: die groeit niet mee
Bij vier releases per jaar werkt de klassieke aanpak nog: iemand loopt na elke release de kennisbank door. Bij vijftig releases per jaar werkt die aanpak niet meer. Niemand leest elke week honderd artikels na. Dus schuift het nalezen op naar "na de volgende sprint", en daarna naar "voor het einde van het kwartaal", en daarna naar nooit.
Dat is geen kwestie van discipline. Het is rekenkunde. De hoeveelheid documentatie groeit met je product. Het aantal wijzigingen groeit met je releasetempo. De tijd die je team heeft om ze na te lezen, groeit niet. Op een bepaald moment kruisen die lijnen elkaar, en vanaf dan loopt je documentatie structureel achter.
Wat wel werkt bij een hoog tempo: de controle koppelen aan het moment van de wijziging, elke aanpassing klein houden, en je klantvragen laten bepalen wat eerst moet. Die werkwijze staat uitgeschreven in Hoe je je documentatie in sync houdt met een product dat wekelijks verandert.
Waarom niemand het merkt
Je zou denken dat een fout artikel opvalt. Iemand van je team leest het toch af en toe? Dat klopt, en toch merken ze het niet. De reden is verrassend.
Je collega, die je product kent
Wie je product goed kent, leest niet wat er staat. Die leest wat er zou moeten staan. Staat er in stap vier "klik op Opslaan", dan ziet je collega in gedachten de knop die er nu staat, en leest ze verder. Haar hoofd vult de fout automatisch in. Hoe beter iemand je product kent, hoe minder fouten die ziet in je documentatie.
Je klant, die je product niet kent
Je klant heeft dat probleem niet. Die kent je product niet, dus die volgt stap vier letterlijk. Hij zoekt de knop "Opslaan", vindt ze niet, probeert nog eens, en stuurt dan een vraag naar je klantendienst. Je klant is de enige die je documentatie leest zoals ze bedoeld is: als instructie, niet als geheugensteun.
Dat betekent dat je klant de fout wél ziet. Alleen meldt hij niet "artikel 27 staat fout". Hij stelt een vraag. En omdat je klantendienst die vraag gewoon beantwoordt, wordt het artikel nooit aangepast. De fout blijft staan tot de volgende klant erover struikelt.
Wat het je kost
Verouderde documentatie staat nooit op een factuur. Daarom lijkt ze gratis. Dat is ze niet.
1
Je klantendienst
Begin bij je klantendienst. Elke vraag die een juist artikel had kunnen voorkomen, komt nu bij een mens terecht. Niet één keer, maar elke keer opnieuw, want het artikel blijft fout staan. Je team legt dezelfde stap tien keer uit, in tien verschillende mails, terwijl de klant met het echt moeilijke probleem in de wachtrij zit. Dat is de tijd die je verliest, en je verliest ze elke dag opnieuw.
2
Je klant
Dan je klant zelf. Wie één keer een verkeerde instructie volgt, opent je kennisbank geen tweede keer. Die stuurt voortaan meteen een mail. Je hebt een kennisbank gebouwd om klanten zonder tussenkomst te helpen, en één fout artikel leert hen dat ze ze beter overslaan. Dat vertrouwen win je niet terug met een correctie.
3
Je AI-agent
En dan is er nog iets dat vroeger niet bestond. Steeds meer bedrijven laten een AI-agent klantvragen beantwoorden vanuit hun eigen documentatie. Zolang die documentatie klopt, werkt dat uitstekend. Staat er een fout artikel in, dan geeft de agent dat foute antwoord met volle overtuiging, aan elke klant die het vraagt, en sneller dan een collega het ooit zou kunnen. Verouderde documentatie was vroeger een ergernis. Met een AI-agent erbovenop is ze een risico dat elke week groter wordt.
Waarom je kennisbank altijd weer achterloopt
Wie zich afvraagt waarom zijn kennisbank altijd verouderd is, heeft het meestal al een paar keer geprobeerd op te lossen. Een reviewkalender, een verantwoordelijke, een kwartaalopruiming. En telkens zakte het na een paar maanden weer in.
Dat komt omdat die oplossingen allemaal hetzelfde uitgangspunt hebben: iemand van je team gaat op zoek naar wat fout staat. Dat is precies het werk dat niemand volhoudt, om de redenen hierboven. Het is veel, het is saai, en wie het doet, ziet de fouten toch niet.
Hoe komen de fouten naar mij, in plaats van ik naar de fouten?
De vraag is dus niet "wie moet dit nalezen?". De vraag is "hoe komen de fouten naar mij, in plaats van ik naar de fouten?". Hoe je dat aanpakt, en wat je daarbij echt kan automatiseren en wat niet, staat in Hoe houd ik mijn kennisbank automatisch actueel?.
Hoe je verouderde documentatie opspoort
De signalen zijn er al. Je moet ze alleen leren lezen.
1
Een klantvraag over iets dat al gedocumenteerd is
Het sterkste signaal is een klantvraag over iets dat al gedocumenteerd is. Als het artikel bestaat en de klant stelt de vraag toch, dan is er iets mis. Ofwel vindt hij het artikel niet, ofwel begrijpt hij het niet, ofwel klopt het niet meer. In alle drie de gevallen wijst de vraag je exact aan waar je moet kijken.
2
Een zoekopdracht zonder resultaat
Het tweede signaal is een zoekopdracht zonder resultaat. Als klanten in je kennisbank zoeken op een woord dat nergens voorkomt, dan gebruiken zij een andere naam dan jij, of ontbreekt het onderwerp helemaal.
3
Een collega die het artikel liever niet doorstuurt
Het derde signaal komt van je eigen team. Een collega die een klant liever zelf uitlegt hoe iets werkt, in plaats van een link naar het artikel te sturen, vertrouwt dat artikel niet. Vraag waarom. Het antwoord is bijna altijd "het klopt niet meer helemaal".
4
De nieuwe medewerker
Het vierde signaal is de nieuwe medewerker. Die leest je documentatie zoals een klant: letterlijk, zonder voorkennis. De vragen die hij in zijn eerste twee weken stelt, zijn een lijst van artikels die achterlopen.
Twintig vragen, één uur werk
Je kan die signalen met de hand verzamelen. Neem je laatste twintig klantvragen en zoek bij elke vraag het artikel dat ze had moeten voorkomen.
- Bestaat het en klopt het? Dan is het onvindbaar of onduidelijk.
- Bestaat het en klopt het niet? Dan heb je verouderde documentatie gevonden.
- Bestaat het niet? Dan heb je een gat gevonden.
Twintig vragen, één uur werk, en je weet meer over je documentatie dan na een week nalezen. Waarom dat zo goed werkt, en waarom je documentatie nooit in één keer veroudert, lees je in Waarom je documentatie achterloopt op je product.
Hoe Sarrai het opspoort
Bij een kleine kennisbank werkt het met de hand. Bij een product dat elke week verandert en elke dag vragen binnenkrijgt, wil je dat een systeem de vergelijking voor je maakt.
Sarrai beantwoordt klantvragen vanuit je eigen kennisbank. Bij elk antwoord houdt het bij hoe zeker het was. Is het niet zeker, dan gaat de vraag naar een collega, die antwoordt zoals altijd.
Daarna vergelijkt Sarrai dat antwoord met het artikel dat het zelf gebruikt heeft. Wijken de twee af, dan loopt dat artikel achter op je product, en krijg je een voorstel om het aan te passen. Bestond er geen artikel, dan stelt Sarrai voor om er een te maken, met de vraag van de klant als titel en het antwoord van je collega als inhoud.
Het interessantste geval is het artikel waar Sarrai zeker van was, terwijl je collega toch iets anders antwoordde. Dat is een artikel dat er compleet uitziet en niet meer klopt. Dat vind je nooit door te lezen. Dat vind je alleen door te vergelijken.
Alle voorstellen komen samen in één goedkeuringsinbox. Je ziet welk gesprek het voorstel veroorzaakt heeft en wat er zou veranderen. Je keurt goed, past aan of wijst af. Het zoeken is gedaan. Voor softwarebedrijven die wekelijks releasen, is dat het verschil tussen documentatie die achterloopt en documentatie die meegroeit.
Benieuwd hoe ver je documentatie al achterloopt?
Maak een gratis account of plan een gesprek, dan bekijken we het samen.
