Interne kennisbank maken: de eerlijke vergelijking voor het MKB

Een interne kennisbank maken doe je door te beginnen bij de twintig vragen die je team het vaakst stelt, niet bij een tool. Schrijf per vraag een kort antwoord, wijs er één eigenaar aan en spreek een herzieningsdatum af. Of je dat opslaat in een mappenstructuur, een wiki-tool of een vraag-gestuurd systeem bepaalt vooral hoe lang het vindbaar en actueel blijft.

Wat is een interne kennisbank, en wanneer heb je er echt een nodig?

Een interne kennisbank is een verzameling antwoorden op vragen die binnen je bedrijf steeds terugkomen, toegankelijk zonder dat iemand eerst een collega hoeft te vinden en te storen. Je hebt er een nodig zodra dezelfde vraag voor de derde keer bij dezelfde persoon terechtkomt.

Een kennisbank is geen documentatieproject en geen archief van alles wat je ooit hebt vastgelegd. Het is een naslagwerk voor vragen die je team daadwerkelijk stelt: hoe behandel je een terugkerende klacht, welke leverancier bel je bij welk probleem, wat is de procedure bij een aanvraag buiten de standaard.

De aanleiding is meestal hetzelfde verhaal: één persoon weet het antwoord, de rest vraagt het aan diegene, en dat werkt tot die persoon met vakantie is, ziek wordt of vertrekt. In het tweede kwartaal van 2025 wisselden 305 duizend werknemers van werkgever, 3,8 procent van alle werknemers.³ Dit raakt direct aan kennisborging: een kennisbank is de plek waar geborgde kennis landt, maar borging zelf is een apart proces met eigen regels.

Op welke drie manieren bouwen MKB-bedrijven een interne kennisbank?

De meeste MKB-bedrijven kiezen tussen drie routes: een gedeelde schijf met mappen, een wiki- of Notion-achtige tool, of een vraag-gestuurd systeem dat kennis vastlegt op het moment dat iemand een vraag beantwoordt. Geen van de drie is fout — ze verschillen in wat ze van je team blijven vragen.

Een gedeelde schijf met mappen

De snelste start: een map met submappen in Drive, OneDrive of het bestaande netwerk. Iedereen kan er meteen in en het kost niets extra. De rekening komt later: de mappenstructuur weerspiegelt al snel de indeling van wie hem heeft opgezet, en zodra die vertrekt, kent niemand anders de logica nog.

Een wiki- of Notion-achtige tool

Een speciale tool voor documentatie — Confluence, Notion, een wiki — biedt zoekfunctie, versiegeschiedenis en koppelingen tussen pagina's. Dat lost een deel van het vindbaarheidsprobleem op. Wat het niet oplost: iemand moet nog steeds gaan zitten om te schrijven. De tool is beter, de drempel voor de schrijver niet.

Een vraag-gestuurd systeem

Hierbij ontstaat de kennisbank uit vragen die je toch al beantwoordt, in plaats van uit een schrijfopdracht. Iemand stelt een vraag, het antwoord wordt vastgelegd met eigenaar en datum, en de volgende keer hoeft niemand hem opnieuw te stellen. Schrijven is dan geen losse taak, maar een bijproduct van iets dat toch al gebeurt.

Elke aanpak faalt op hetzelfde punt als je het proces niet borgt: er is geen vaste gewoonte om iets vast te leggen en te herzien. Van de technische organisaties tot 250 medewerkers organiseert 52 procent actief kennisoverdracht, tegen 37 procent van de grotere² — kleine bedrijven doen het dus vaker goed dan je zou verwachten. Dat scheelt, want van de werkgevers die problemen verwachten bij pensionering noemt 90 procent verlies van ervaring als reden,¹ en juist die ervaring wordt in geen van de drie aanpakken vanzelf vastgelegd.

Hoe structureer je een kennisbank: op vraag, niet op organigram?

Organiseer een kennisbank rond de vraag die iemand stelt, niet rond de afdeling die erover gaat. Een medewerker zoekt niet naar 'Klantenservice > Escalaties > Retouren', die zoekt naar 'wat doe ik als een klant een kapot product terugstuurt zonder bon'. Bouw de kaart op die zin, niet op de plek in je organigram.

Dit is de meest gemaakte fout: de structuur van het bedrijf wordt de structuur van de kennisbank. Dat werkt voor wie het bedrijf al kent, en faalt voor iedereen die net moet leren waar iets staat — precies de mensen die de kennisbank het hardst nodig hebben.

Een voorbeeld: bij een installatiebedrijf staat de kennis over een storingsmelding buiten kantooruren vaak verspreid over drie plekken — een procedure bij planning, een contactlijst bij de balie, het hoofd van de monteur die het al twee jaar zo doet. Eén kaart met de titel van de vraag zelf, 'storingsmelding buiten kantooruren: wie bel je en in welke volgorde', vervangt alle drie. Wordt het antwoord langer dan een paar stappen, dan is het eigenlijk geen kaart meer maar een werkinstructie, en dat vraagt om een andere vorm.

Wie is eigenaar van een kaart, en waarom heeft elke entry een datum nodig?

Elke kaart heeft precies één eigenaar — een naam, geen afdeling — en een datum waarop die eigenaar bevestigt dat het antwoord nog klopt. Zonder die twee ontstaat een kennisbank die groeit maar niet meer te vertrouwen is: niemand weet welk antwoord nog actueel is.

Eigenaarschap zonder herzieningsdatum werkt alleen zolang de eigenaar toevallig zelf de wijziging opmerkt. Zodra een leverancier, prijs of procedure verandert, moet iemand actief teruggaan naar de kaart — dat gebeurt bijna nooit vanzelf. Een vaste datum verplicht dat moment: klopt dit nog, ja of nee.

Hoe begin je klein: met de twintig vragen die je team het vaakst stelt?

Begin niet met een volledige taxonomie, maar met de twintig vragen die je team de afgelopen maand het vaakst heeft gesteld. Een lijst van twintig is compleet genoeg om nuttig te zijn en klein genoeg om af te maken.

1. 1

   Verzamel een week lang

   Laat iedereen noteren welke vraag ze aan een collega stelden in plaats van die zelf op te zoeken.

2. 2

   Groepeer per vraag, niet per afdeling

   Voeg dubbele vragen samen en schrap wat al goed staat vastgelegd. Je houdt de vragen over die er echt toe doen.

3. 3

   Ken elke vraag één eigenaar toe

   Vraag niet 'wie weet dit', maar 'wie is verantwoordelijk als dit misgaat'. Dat is vaak een andere persoon.

4. 4

   Schrijf het antwoord in twee tot vier zinnen

   Langer betekent meestal dat de vraag eigenlijk twee vragen is. Splits hem dan.

5. 5

   Herhaal tot je bij twintig zit — en stop dan

   Twintig kaarten die mensen echt gebruiken, verslaan tweehonderd kaarten die niemand controleert.

Hier lopen de meeste kennisbank-projecten al vast: iemand moet gaan zitten om te schrijven, en die tijd is er structureel niet. Buddai draait dit om door twee korte vragen per dag aan een teamlid te stellen en het antwoord meteen om te zetten in een doorzoekbare kaart met eigenaar en datum — schrijven gebeurt zo naast het werk, niet ervoor.

Waarom werkt een mappenstructuur niet meer zodra je kennisbank groeit?

Een mappenstructuur werkt zolang je team de indeling nog uit het hoofd kent. Daarna moet iemand raden in welke map iets staat, en dat raden wordt met elk extra document minder betrouwbaar. Zoeken op bestandsnaam helpt niet als de vraag niet in dezelfde woorden is opgeschreven als de titel.

Dit is geen kritiek op mappen als zodanig — het is een grens die inherent is aan een systeem waarin je vooraf moet bedenken waar iets thuishoort. Een kennisbank die je doorzoekt op de vraag zelf kent die grens niet: het verschil tussen zoeken naar 'ontslag proeftijd brief' en 'wat moet er in een ontslagbrief tijdens de proeftijd'. Sommige bedrijven leggen een AI-laag over de bestaande mappenstructuur; dat werkt alleen als de documenten eronder kloppen, want zoeken in je eigen bedrijfsdocumenten met AI vindt geen antwoord dat nergens is opgeschreven.

Wie mag wat zien: toegang en vertrouwelijkheid in een kennisbank?

Niet elke kaart hoort voor iedereen zichtbaar te zijn. Salarisafspraken, functioneringsgesprekken en klantdossiers met persoonsgegevens vragen om afgeschermde toegang; procedures, contactlijsten en werkinstructies horen juist open te staan. Bepaal dit per categorie, niet per losse kaart — anders wordt toegangsbeheer zelf een onderhoudsklus.

De vuistregel: bevat een kaart persoonsgegevens van een collega of klant, dan geldt de AVG en beperk je de toegang tot wie het nodig heeft. Voor de rest geldt het omgekeerde risico vaker: te veel afscherming zorgt dat mensen het toch weer aan een collega vragen, en dan ben je terug bij af.

Welke onderhoudsloop bepaalt of je kennisbank over een jaar nog leeft?

Een kennisbank blijft alleen bruikbaar als er een vast, terugkerend moment is waarop eigenaren hun kaarten bevestigen of bijwerken. Zonder die loop verzamel je in het eerste half jaar enthousiast kaarten, en vertrouwt niemand ze meer in het tweede jaar.

De loop is simpel om te ontwerpen en moeilijk om vol te houden: elke eigenaar krijgt op de herzieningsdatum van zijn kaart een seintje, en beantwoordt in een paar seconden of het nog klopt. Het lastige zit niet in het ontwerp — het zit in de discipline om dat seintje elke keer op te volgen, maandenlang, zonder dat iemand het project actief bewaakt.

1. Meet welk percentage kaarten binnen de eigen herzieningstermijn is bevestigd — dat is meestal het eerste dat wegzakt.
2. Wijs bij vertrek van een eigenaar meteen een opvolger aan; laat kaarten nooit zonder naam achter.
3. Markeer verouderde kaarten zichtbaar in plaats van ze zonder waarschuwing te laten staan.
4. Voeg nieuwe kaarten alleen toe voor vragen die daadwerkelijk zijn gesteld, niet voor wat je denkt dat ooit nuttig zal zijn.

Hier sneuvelen de meeste kennisbanken: niet omdat de tool tekortschiet, maar omdat niemand structureel tijd krijgt voor het onderhoud. Buddai bouwt die herzieningsloop in het dagelijkse ritme in — de dagelijkse vraag aan een teamlid is tegelijk het moment waarop een bestaande kaart wordt bevestigd of bijgewerkt, in plaats van een aparte taak die verdwijnt. Hoe dat werkt, staat op de pagina over hoe Buddai werkt; de bredere aanpak staat op de pagina over kennisborging-software. De tool is dus nooit het echte probleem: het verschil zit in of iemand op een vast moment gaat zitten om te schrijven en te herzien.