Stap 3: open het tabblad Bestellingen en kies de bestelling.
Stap 4: klik op Opslaan.
Stap 5: de klant krijgt automatisch een bevestiging.
Je documentatie was juist toen je ze schreef. Je product is sindsdien tien keer veranderd. Deze pagina gaat over de artikels in je helpcenter, de artikels die je klanten lezen. Interne documentatie veroudert op dezelfde manier. Je leest waarom het gebeurt, waarom niemand in je team het ziet, hoe je verouderde artikels opspoort en hoe je ze weer bijwerkt. Het product komt pas op het einde.
Stap 3: open het tabblad Bestellingen en kies de bestelling.
Stap 4: klik op Opslaan.
Stap 5: de klant krijgt automatisch een bevestiging.
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.
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 beschrijft de instellingenpagina zoals ze vorig jaar was. Sindsdien kwamen er drie opties bij. Wat er staat, klopt nog. Over de helft van de pagina zegt het gewoon niets.
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.
Documentatie veroudert omdat schrijven en bouwen op verschillende momenten gebeuren, door verschillende mensen, met elk hun eigen prioriteiten. Ook een zorgvuldig team loopt daartegen aan.
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. Hoe je daar toch uitraakt, lees je verderop bij verouderde artikels bijwerken.
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.
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.
Dit is gewoon rekenwerk. 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, blijft gelijk. 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. Hoe je dat opzet, staat verderop bij voorkomen dat je documentatie opnieuw veroudert.
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.
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 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, stap voor stap.
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.
Verouderde documentatie staat nooit op een factuur, en daarom lijkt ze gratis. Toch betaal je ervoor, op drie plekken.
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.
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.
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.
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 betere vraag is dus: "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?.
De signalen zijn er al. Je moet ze alleen leren lezen.
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.
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.
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".
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.
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.
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.
Na het opsporen heb je een lijst met artikels die achterlopen. Die lijst werk je het best af als een reeks kleine correcties, tussen ander werk door. Zo raakt ze ook echt leeg.
Werk eerst de artikels bij die veel bezoekers krijgen, en de artikels achter vragen die steeds terugkomen. Een fout in een artikel dat niemand opent, kan wachten.
Soms zie je dat een artikel niet meer klopt, maar weet je nog niet wat er moet staan. Noteer het dan meteen, met de reden erbij. Wie later de juiste informatie heeft, weet zo waar ze naartoe moet.
Schrap wat niet meer geldt en verbeter de stap die niet meer klopt. Een kort artikel dat klopt, helpt je klant meer dan een lang artikel dat achterloopt. Controleer daarna elke aanpassing in het live product, en volg de stappen zoals een klant dat zou doen. Je geheugen loopt vaak een release of twee achter.
Beschrijft een artikel een functie die niet meer bestaat, haal het dan uit de bronnen van je AI-agent. Zolang de agent het artikel kan vinden, gebruikt hij het, ook als het in een archiefmap staat.
Bijwerken ruimt op wat al fout staat. Om te voorkomen dat er nieuwe fouten bijkomen, breng je schrijven en bouwen dichter bij elkaar. Hoe kleiner de afstand tussen een wijziging en het artikel erover, hoe minder er kan wegglijden.
Begin bij je releaseproces. Zet één regel in elke pull request of releasechecklist: "documentatie bijgewerkt, of niet nodig". Wie de wijziging maakt, weet op dat moment nog precies wat er veranderde. Een week later is dat al vervaagd.
Geef elk belangrijk artikel één eigenaar en een datum waarop het laatst nagekeken werd. Dat werkt het best als de signalen uit je klantvragen bij die eigenaar terechtkomen, zodat die de fouten krijgt aangereikt.
Schrijf je artikels in kleine stukken: één taak per artikel, een korte sectie per stap. Verandert er iets, dan pas je één alinea aan en blijft de rest staan. Laat daarbij je klantvragen bepalen welk artikel eerst aan de beurt is.
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. Veel tools geven je een rapport met slecht scorende artikels en onbeantwoorde vragen. Uitzoeken wat er moet veranderen, en het dan ook schrijven, blijft dan bij jou liggen.
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 artikel ziet er compleet uit en klopt niet meer. Zo'n artikel vind je alleen door te vergelijken.
Kan je een artikel nog niet bijwerken, zet dan in Sarrai de schakelaar "Beschikbaar voor AI Agent" uit. Het artikel blijft staan en de AI gebruikt het niet meer, terwijl jij de juiste informatie verzamelt.
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.
Verouderde documentatie is een artikel dat iets anders beschrijft dan wat je klant vandaag in je product ziet. Het kan een artikel zijn dat fout staat, een artikel dat onvolledig is, of een artikel dat er nooit gekomen is.
Koppel het nalezen aan elke wijziging in je product. Een vaste kalender, bijvoorbeeld elk kwartaal, loopt achter op je releases zodra je vaker dan een paar keer per jaar iets uitrolt.
Het sterkste signaal is een klantvraag over iets dat al gedocumenteerd is. Ook een zoekopdracht zonder resultaat in je kennisbank wijst op een probleem, net als een collega die liever zelf uitlegt dan een link stuurt.
Een AI-agent beantwoordt klantvragen vanuit je documentatie. Staat er een fout artikel in, dan geeft hij dat foute antwoord met volle overtuiging, aan elke klant die het vraagt. Een collega die twijfelt, vraagt het even na. Een AI-agent merkt niet dat het artikel achterloopt.
Je spreekt dan van een levend document. De tekst groeit mee met het product, met een kleine aanpassing telkens als er iets verandert.
Maak een gratis account of plan een gesprek, dan bekijken we het samen.