Template voor procesdocumentatie: zo documenteer je een proces zodat het wordt gevolgd (2026)

Procesdocumentatie is de schriftelijke beschrijving van hoe een stuk werk door je organisatie stroomt, van de gebeurtenis die het start tot het resultaat dat het afsluit: de fasen op volgorde, de rol die elke fase beheert, wat van de ene rol naar de volgende gaat, wat elke fase achterlaat en wat er gebeurt als het normale pad geblokkeerd is. Een template voor procesdocumentatie is het vaste skelet waarin die woorden komen te staan, zodat het tiende proces leest als het eerste en iemand die er één heeft gelezen zijn weg vindt in alle andere.

De meeste processen zijn al ergens gedocumenteerd: in een diagram van een workshop van twee jaar geleden, op een wikipagina die niemand opent, in het hoofd van die ene persoon die het van het begin af aan doet. Het probleem is zelden dat het document niet bestaat. Het probleem is dat het niet wordt gevolgd, en de drie redenen daarvoor zijn in elke organisatie dezelfde. Deze gids behandelt eerst het vak: wat een procesdocument wel en niet is, het standaardformaat, een template die je kunt kopiëren en een uitgewerkt voorbeeld. Daarna komen de drie redenen en wat elk ervan oplost, waar het document en de walkthrough ervan leven in de tools die je team al gebruikt, en wat de collega krijgt die het in een andere taal leest. Een procesdocument wordt immers beoordeeld op de ochtend waarop een nieuwe accountmanager, een nieuwe verpleegkundige of een nieuwe medewerker van een distributeur iets moet overdragen aan de volgende persoon en niet weet wie dat is.

Wat een procesdocument is — en wat niet

Drie documenten beschrijven op procesniveau hoe werk wordt gedaan. Ze worden vaak door elkaar gehaald, en ook met de procedures eronder:

Het schema is het plaatje, het procesdocument is de tekst die het plaatje bruikbaar maakt, en de SOP's zijn het detail onder elk vak. Dat onderscheid bepaalt de lengte: een procesdocument dat uitlegt hoe elke stap wordt aangeklikt is een handleiding die niemand leest, en een processchema zonder tekst is een plaatje dat iedereen anders interpreteert. De SOP, de template ervoor en de reviewcyclus staan in SOP template en how to write an SOP. Deze gids gaat over het niveau erboven, het niveau dat zegt waar de SOP's nodig zijn en wie wat aan wie overdraagt.

Een procesdocument is ook niet een beschrijving van hoe het werk meestal gebeurt. Het is de afgesproken manier, met een eigenaar, een versie en een reviewdatum. Een fase die niemand volgt is daarom een fase om te wijzigen of een gesprek om te voeren, geen zin om te laten staan.

Wat erin hoort: het standaardformaat

Een bruikbaar procesdocument heeft een kop en acht onderdelen. De meeste templates online hebben doel, stappen en een diagram en houden daar op. Daarom worden de meeste procesdocumenten één keer gelezen en daarna nooit meer:

De kop — de identiteit van het document, vijf velden op één regel: een ID waarnaar mensen kunnen verwijzen ("PR-HR-02"), een versie ("v1.3"), de eigenaar (één genoemde persoon die verantwoordelijk is voor het hele proces, geen afdeling), de ingangsdatum en de volgende reviewdatum. Een proces zonder reviewdatum wordt beoordeeld wanneer er iets misgaat.

1. Doel en resultaat. Een of twee zinnen: wat dit proces oplevert, voor wie en hoe goed eruitziet, met een getal als je dat hebt. "Een nieuwe medewerker heeft op dag één accounts, apparatuur, een plan en een genoemde buddy, en op dag 30 een review van 30 dagen."
2. Trigger en eindstatus. De gebeurtenis die het proces start en het resultaat dat het afsluit. "Start wanneer het ondertekende contract in de HR-map belandt; eindigt wanneer de review van 30 dagen is vastgelegd." Alles tussen die twee zinnen is het proces; alles daarbuiten is een ander document. Als het proces geen duidelijk einde heeft, zijn het twee processen.
3. Reikwijdte. Wanneer dit proces van toepassing is en wanneer niet, met de naburige processen genoemd bij ID. "Medewerkers met een contract bij ons, in elk land. Niet: freelancers (PR-HR-04); niet: interne overplaatsingen (PR-HR-06)."
4. Rollen. Elke rol die in de fasen voorkomt, met wat die beheert. Rollen, geen namen, zodat het document een nieuwe aanstelling overleeft. Een van die rollen is de procesEigenaar, verantwoordelijk voor de hele stroom, inclusief de overdrachten die standaard van niemand zijn.
5. Fasen en overdrachten. Het hart van het document: de fasen op volgorde, elk met de rol die het doet, wat binnenkomt (de input), wat vertrekt en waar dat is vastgelegd (de output), naar wie het gaat en de tijdslimiet. De overdracht wordt expliciet opgeschreven ("naar: IT, uiterlijk dag −5"), omdat processen op de overdracht stranden: beide kanten denken dat de ander het heeft.
6. Uitzonderingen en escalatie. De vertakkingen buiten het ideale pad: wat er gebeurt als de vergunning te laat is, de kredietcheck mislukt of de eigenaar afwezig is. Elke uitzondering noemt een rol of persoon die beslist, nooit "vraag het iemand". De laatste regel dekt wat je gemist hebt: "Alles wat hier niet is gedekt: de procesEigenaar beslist, en de zaak wordt bij de volgende review ingebracht."
7. Meetwaarden. Twee of drie getallen die de eigenaar in de gaten houdt: doorlooptijd van trigger tot eindstatus, aantal zaken per maand, het aandeel dat in een uitzondering terechtkwam. Geen dashboard, maar de getallen die de eigenaar vertellen dat het proces wegdrijft voordat iemand klaagt.
8. Gerelateerde documenten en versiegeschiedenis. De SOP's onder elke fase, het beleid dat het proces uitvoert, de link naar het schema; daarna één regel per versie: datum, wat er veranderde, wie het goedkeurde. De geschiedenis voorkomt dat dezelfde fout onder een nieuw versienummer opnieuw wordt ingevoerd.

Wat er niet in hoort: de onderbouwing van elke regel (het werk van het beleid), het klik-voor-klikdetail van een fase (het werk van de SOP) en alles waar iemand niets mee kan doen. "Wij hechten waarde aan een soepele onboarding" is een sentiment, geen fase.

Zo documenteer je een proces zodat het wordt gevolgd

Drie redenen verklaren bijna elk procesdocument dat niet wordt gevolgd, en elke reden heeft een oplossing die bij het schrijven hoort, niet bij handhaving achteraf.

Reden één: het beschrijft het proces zoals ontworpen, niet zoals uitgevoerd. Het document is geschreven in een workshop door de mensen die het werk aansturen, en de mensen die het doen hebben een andere versie, met het spreadsheet ernaast en de collega die bij fase 3 wordt gebeld. De oplossing is om het in kaart te brengen vanuit bewijs voordat je schrijft. Volg drie echte zaken van trigger tot eindstatus en schrijf op wat er werkelijk gebeurde: de e-mails, de berichten, de formulieren, het wachten. Als het proces in een groepschat leeft, zoals bestellingen van distributeurs die via WhatsApp binnenkomen of ruilafspraken voor diensten in een Telegram-groep, dan is die chat het bewijs en begint de walkthrough met de geschiedenis ervan. Wat Export chat je geeft en waar het ophoudt staat in how to export a WhatsApp chat. Waar de drie zaken verschillen ligt de reden dat het document bestaat. Beslis bij elk verschil of het een fase is die je in de tekst moet repareren of een gesprek dat je met het team moet voeren.

Reden twee: niemand kan de actuele versie vinden. Het document staat in een map met veertig andere, een kopie staat op iemands bureaublad, een derde versie staat in de wiki, en wie het op een dinsdagochtend nodig heeft vraagt het aan een collega. De oplossing is om te publiceren waar het team al leest, met de kop zichtbaar. Eén plek, de actuele versie bovenaan, de naam van de eigenaar en de reviewdatum bovenaan, zodat "klopt dit nog?" wordt beantwoord door de kop en niet door rond te vragen. En de fasen zijn geschreven als overdrachten tussen rollen, zodat iedereen zijn eigen fase en de twee fasen ernaast in minder dan een minuut vindt.

Reden drie: het is gewijzigd en de mensen van wie de fase veranderde, zijn het nooit verteld. Een review verplaatste de kredietcheck naar vóór het picken, of voegde een stap toe voor medewerkers die verhuizen, en het document werd bijgewerkt, maar het magazijn en de leidinggevenden bleven doen wat ze eerder deden. De oplossing is om het proces door te lopen met de mensen die het uitvoeren, en elke wijziging aan te kondigen met de regels die veranderden. De walkthrough is een meeting: de eigenaar en één persoon per rol, de actuele versie op ieders scherm, elke fase hardop voorgelezen door de persoon die het doet, elke overdracht bevestigd door beide kanten. Wat de walkthrough verandert wordt een nieuwe versie met één regel in de geschiedenis, en de drie regels die veranderden gaan dezelfde dag naar de mensen wier fase ze raken, op de plek waar ze al lezen. Een beslissing die een regel wijzigt in plaats van een fase komt ook in de decision log, met het proces-ID in het item.

De volgorde dus: kies één proces met een duidelijk begin en einde; volg drie echte zaken; schrijf eerst de fasen in de template, met de overdrachten expliciet; vul de uitzonderingen in vanuit wat de zaken lieten zien; loop het door met één persoon per rol; publiceer waar het team leest, met de eigenaar en de reviewdatum in de kop; zet de reviewdatum in de agenda. Het document dat hieruit komt wordt gevolgd omdat het waar, vindbaar en aangekondigd is, de drie eigenschappen die de template alleen niet kan geven.

Een template voor procesdocumentatie

[Proces-ID] — [Procesnaam]
Versie: [n.n] · Eigenaar: [naam, rol] · Geldig vanaf: [datum] · Volgende review: [datum]

1. Doel en resultaat
[Een of twee zinnen: wat dit proces oplevert, voor wie en hoe goed eruitziet, met een getal als je dat hebt.]

2. Trigger en eindstatus
Start wanneer: [de gebeurtenis] · Eindigt wanneer: [het resultaat dat dan bestaat]

3. Reikwijdte
Omvat: [zaken, locaties, klanten, landen] · Omvat niet: [wat een ander proces afhandelt, met het ID ervan]

4. Rollen
Proceseigenaar: [de ene persoon die verantwoordelijk is voor de hele stroom]
[Rol] — [wat die in dit proces beheert]
[Rol] — [wat die in dit proces beheert]

5. Fasen en overdrachten
5.1 [Fase] — [rol] — input: [wat binnenkomt] — output: [wat vertrekt, waar het is vastgelegd] — naar: [volgende rol] — uiterlijk: [tijdslimiet]
5.2 [Fase] — [rol] — input: … — output: … — naar: … — uiterlijk: …
5.3 [Fase] — [rol] — input: … — output: … — naar: … — uiterlijk: …

6. Uitzonderingen en escalatie
Als [voorwaarde]: [wat er gebeurt, wie beslist]
Als [voorwaarde]: [wat er gebeurt, wie beslist]
Alles wat hier niet is gedekt: [rol] beslist; de zaak wordt bij de volgende review ingebracht.

7. Meetwaarden
[Twee of drie getallen die de eigenaar in de gaten houdt — doorlooptijd, zaken per maand, aandeel dat in een uitzondering terechtkwam — en waar ze worden afgelezen.]

8. Gerelateerde documenten en versiegeschiedenis
SOP's: [ID's, één per fase waar nodig] · Voert uit: [beleid] · Schema: [link naar het diagram]
v[n.n] — [datum] — [wat er veranderde] — goedgekeurd door [naam]
v[n.n] — [datum] — [wat er veranderde] — goedgekeurd door [naam]

De template is platte tekst met vetgedrukte labels, dus je plakt hem zonder opmaakwerk in een Word-bestand, een Google Doc, een wikipagina, een Slack canvas of een chatnotitie. De twee onderdelen die het vaakst leeg blijven zijn de overdrachten ("naar wie, uiterlijk wanneer") en de reviewdatum. Zij bepalen of het proces over een jaar nog zo wordt uitgevoerd als het document zegt.

Een uitgewerkt voorbeeld: een nieuwe medewerker onboarden, van getekend contract tot dag 30

Een bedrijf van zestig mensen met medewerkers in drie landen; het proces loopt over vier rollen en eindigt wanneer de review van 30 dagen is vastgelegd.

PR-HR-02 — Een nieuwe medewerker onboarden
Versie: 1.3 · Eigenaar: Hoofd operations, Inés M. · Geldig vanaf: 1 okt 2026 · Volgende review: 1 apr 2027

1. Doel en resultaat — Een nieuwe medewerker heeft op dag één werkende accounts, apparatuur, een plan voor de eerste maand en een genoemde buddy, en op dag 30 een vastgelegde review van 30 dagen, in welk land die ook begint.
2. Trigger en eindstatus — Start wanneer: het ondertekende contract in de HR-map belandt. Eindigt wanneer: de review van 30 dagen is vastgelegd in het dossier van de medewerker.
3. Reikwijdte — Medewerkers met een contract bij ons, in elk land, op kantoor of remote. Niet: freelancers (PR-HR-04); interne overplaatsingen (PR-HR-06).
4. Rollen — Proceseigenaar: hoofd operations. HR: het dossier, documenten, salarisadministratie, het welkomstpakket. IT: accounts, apparatuur, toegang. Leidinggevende: het plan, de buddy, de check-ins. Finance: inrichting van de salarisadministratie.

5. Fasen en overdrachten
5.1 Het dossier openen — HR — input: het ondertekende contract — output: het onboardingdossier met startdatum, land, leidinggevende, taal; het welkomstpakket verstuurd in de taal van de medewerker — naar: IT en de leidinggevende — uiterlijk: twee werkdagen na ondertekening
5.2 Accounts en apparatuur — IT — input: het dossier — output: accounts aangemaakt, laptop verzonden naar het adres van de medewerker, toegang volgens het rolprofiel; bevestiging in het dossier — naar: HR — uiterlijk: vijf werkdagen vóór de startdatum
5.3 Documenten en salarisadministratie — HR, daarna finance — input: het dossier, de documenten van de medewerker (vergunning of registratie waar het land die vereist) — output: de medewerker in de salarisadministratie, documenten in het dossier — naar: de leidinggevende — uiterlijk: de startdatum
5.4 De eerste maand, gepland — leidinggevende — input: het dossier — output: een plan voor 30 dagen in het dossier, een genoemde buddy, de eerste week in de agenda van de medewerker, het welkomstgesprek met het team ingepland — naar: de medewerker, op dag één — uiterlijk: de dag vóór de start
5.5 Dag één — leidinggevende en buddy — input: het plan — output: het welkomstgesprek gehouden, het plan doorgenomen, de openstaande vragen van de medewerker vastgelegd in het kanaal van het team — naar: de medewerker — uiterlijk: einde van dag één
5.6 Check-ins — leidinggevende — input: het plan, de vastgelegde vragen — output: een check-in op dag 7 en dag 30, de review van 30 dagen vastgelegd in het dossier — naar: HR, om het dossier af te sluiten — uiterlijk: dag 30

6. Uitzonderingen — Vergunning of registratie niet rond op de startdatum: de medewerker begint met de taken die de leidinggevende aanmerkt als toegestaan zonder; HR beheert de opvolging en de datum komt in het dossier. Laptop niet geleverd op dag −2: IT verstuurt een leenlaptop uit de voorraad van het kantoor; het hoofd operations wordt dezelfde dag geïnformeerd. Medewerker in een land waar we nog niet eerder hebben aangenomen: fase 5.3 pauzeert; het hoofd operations beslist binnen drie werkdagen over de employer-of-record-route (PR-HR-05).
7. Meetwaarden — Werkdagen van ondertekening tot accounts gereed (doel ≤ 7); aandeel medewerkers met een vastgelegde review van 30 dagen op dag 30 (doel 100 %); vragen vastgelegd in week één, bij de kwartaalreview gelezen om te zien welke fase ze blijft opleveren.
8. Gerelateerd — SOP-IT-03 "Nieuwe accounts en toegang"; SOP-HR-08 "Inrichting salarisadministratie per land"; Onboardingbeleid §2; schema: het swimlane-diagram in de HR-map.
v1.3 — 1 okt 2026 — welkomstpakket wordt nu verstuurd in de taal van de medewerker; check-in op dag 7 toegevoegd — goedgekeurd door Inés M.
v1.2 — 3 jun 2026 — verzending van de laptop verplaatst naar vijf dagen vóór de start na twee late leveringen — goedgekeurd door Inés M.

Let op wat het voorbeeld doet. Elke fase noemt de rol, wat binnenkomt, wat vertrekt en waar het is vastgelegd, wie het daarna krijgt en uiterlijk wanneer. Een overdracht die niet plaatsvond is zo zichtbaar als een lege plek in het dossier, niet als een verrassing op dag één. Elke uitzondering noemt wie beslist. De meetwaarden zijn drie getallen, geen dashboard. En de geschiedenis legt uit waarom de fasen zijn zoals ze zijn: fase 5.2 heeft haar datum omdat twee laptops te laat waren, en de check-in op dag 7 bestaat omdat de review van dag 30 steeds vragen vond die in de eerste week beantwoord hadden moeten worden.

Een korter tweede voorbeeld, de vorm van een verkoopproces voor een exporteur met distributeurs:

PR-SA-01 — Van bestelling tot levering · Eigenaar: Exportmanager · Start wanneer: een bestelling van een distributeur binnenkomt · Eindigt wanneer: de levering is bevestigd en de factuur is verstuurd
1. Ordercontrole — accounteigenaar — input: de bestelling — output: bestelling bevestigd in het systeem, of een vraag terug naar de distributeur — naar: finance — uiterlijk: één werkdag
2. Kredietcheck — finance — input: de bevestigde bestelling — output: vrijgegeven, of vastgehouden met een reden — naar: magazijn — uiterlijk: één werkdag
3. Picken en inpakken — magazijn — input: de vrijgegeven bestelling — output: ingepakt, met de paklijst — naar: logistiek — uiterlijk: drie werkdagen
4. Documenten en verzending — logistiek — input: de ingepakte bestelling — output: de zending geboekt, de documenten van de bestemming bijgevoegd, tracking in het systeem — naar: finance en de accounteigenaar — uiterlijk: één werkdag
5. Factuur en bevestiging — finance, daarna de accounteigenaar — input: de zending — output: factuur verstuurd; levering bevestigd bij de distributeur en vastgelegd — Als het krediet wordt vastgehouden: de accounteigenaar belt de distributeur binnen één werkdag; de exportmanager beslist over vrijgave of vooruitbetaling.

Twaalf regels, en een nieuwe medewerker bij de distributeur en een nieuwe persoon in het magazijn weten allebei op wie ze wachten.

Waar het procesdocument en de walkthrough leven in de tools die je al gebruikt

Het document zelf leeft waar de documenten van het team leven: een Word-bestand in een gedeelde bibliotheek, een Google Doc, een pagina in een wiki, een canvas in een kanaal. De walkthrough is een meeting, en elk platform heeft een plek voor wat de walkthrough achterlaat; elk houdt op een ander punt op. Alleen gedocumenteerd gedrag, van de eigen pagina's van de leveranciers, met de maand waarin elke pagina is gecontroleerd:

Twee dingen zijn overal hetzelfde. Het procesdocument is een bestand in de ene taal waarin het is geschreven, en de collega die een andere taal leest, leest dat bestand of een kopie die iemand maakte; en wat de walkthrough veranderde, komt pas in het document als iemand het achteraf intypt, in diezelfde taal. De vertaling die deze suites documenteren hoort bij het gesprek, niet bij het document: Microsoft documenteert live vertaalde ondertiteling in Teams-meetings wanneer de organisator een Teams Premium- of Microsoft 365 Copilot-licentie heeft, en Google documenteert vertaalde ondertiteling in Meet bij geschikte Workspace-abonnementen (beide gecontroleerd in augustus 2026). Wat elk dekt en waar elk ophoudt staat in Microsoft Teams live translation en Google Meet live translation. Het proces dat de nieuwe medewerker op dinsdag opent, en de walkthrough die het veranderde, zijn andere objecten dan die ondertiteling, en ze worden gelezen in de taal waarin ze zijn getypt.

Hoe het proces, de walkthrough en de geschiedenis leesbaar blijven voor elk lid

InterMIND is een communicatieruimte waarin het werk van een team in een kanaal leeft, dus het afgeronde procesdocument heeft een vanzelfsprekend thuis: het kanaal van het team dat het proces uitvoert, één kanaal voor de mensen van HR, IT, finance en de leidinggevenden die elk een fase beheren. Geplaatst als notitie (een rich-textbericht met koppen en genummerde lijsten, later te bewerken via het eigen menu) wordt het door elk lid in de eigen taal gelezen, met het origineel een schakelaar verderop, en vastgepind zodat de actuele versie het eerste is wat een nieuwe collega vindt. Met bewerkingsgeschiedenis ingeschakeld verschijnt de eerdere formulering van een gewijzigde fase boven de actuele tekst als een diff op woordniveau, met tijdstempel. Geüpload als bestand (een pdf of een Word-document) krijgt het op elk abonnement een AI-samenvatting in de taal van de lezer, met elk punt gelinkt aan de alinea waaruit het komt, zodat de lezing van één pagina bestaat voordat iemand haar heeft geschreven; op betaalde abonnementen opent het bestand zelf vertaald in de taal van de lezer (30 talen voor documenten). Als het hoofdexemplaar in een documenttool blijft, komen de updates per e-mail in het kanaal terecht: de host van het kanaal geeft het een eigen adres, en een bericht dat daarheen wordt gestuurd verschijnt als gewoon bericht met de afzender genoemd en bijlagen behouden.

De walkthrough begint vanuit dat kanaal. Tijdens het gesprek komt de actuele versie op ieders scherm naast de videotegels met Share to conference: een notitie, of een Google Docs- of OneDrive-document dat in de chat is gelinkt. Elke deelnemer scrolt er zelfstandig doorheen en leest het in de eigen taal; een gedeelde notitie wordt live bewerkt door degene die deelt, terwijl de zaal toekijkt hoe de gewijzigde overdracht vorm krijgt. Als het gesprek eindigt, wordt de recap geschreven vanuit de meeting zelf: een samenvatting, de punten gemarkeerd als afgesproken, open of betwist, de actiepunten met eigenaren, elke regel met behoud van tijdstempel. De documenten die tijdens de sessie zijn gedeeld dragen hun samenvattingen bij naast wat er is gezegd. De recap komt aan per e-mail, als bericht in het kanaal en als link in het agenda-item, en elk ingelogd lid leest hem in de eigen taal: het verslag wordt per lezer vertaald, niet eenmalig geschreven in de taal die de zaal toevallig gebruikte. Elk lid kan hem bewerken, elke bewerking bewaart auteur en revisiegeschiedenis, en het kanaal bewaart de recap van elke eerdere sessie, zodat de walkthrough die v1.3 opleverde één klik verwijderd is van de notitie die v1.3 is. De eigen assistent van een lid (Claude, ChatGPT, Copilot of Gemini, verbonden via de MCP-connector) doorzoekt recaps, transcripten, chats en de tekst van gedeelde bestanden in één vraag, "waarom wordt de laptop vijf dagen vóór de startdatum verzonden?", en leest het document zelf; dit werkt voor organisaties met AI-functies ingeschakeld. Naast de tabel hierboven gezet is het verschil een nuchtere vaststelling: de ondertiteling die die suites documenteren vertaalt het gesprek terwijl het loopt; hier zijn het proces, de walkthrough en de geschiedenis één verslag, door elk lid gelezen in de eigen taal.

De mensen die aan een proces deelnemen zijn niet altijd medewerkers. De ordermedewerker van een distributeur, een salarisverwerker in een ander land, een freelancer die één fase beheert: een extern lid van het kanaal sluit per e-mail aan met een gratis account en leest het proces en de geschiedenis zoals iedereen. Iemand zonder account is gast van één meeting: die sluit via een link aan bij de walkthrough, vanaf een telefoon, kosteloos, hoort het live in de eigen taal en krijgt achteraf geen verslag. De host biedt de ruimte en betaalt op een betaald abonnement alleen voor de leden die in de voorgaande 28 dagen actief waren: wie een meeting joinde, in een chat schreef of de assistent iets vroeg. Leden die stil worden behouden hun toegang zonder kosten.

• Open een volledige recap — een echt verslag, weergegeven door dezelfde code die het jouwe schrijft.
• Probeer de live demo — zonder aanmelding; spreek, en hoor de zaal per luisteraar vertaald.

Procesdocumentatie als vak overleeft elke tool: iemand moet nog steeds drie echte zaken volgen, de fasen schrijven als overdrachten die een tweede persoon kan controleren, en het geheel doorlopen met één persoon per rol. Wat niet hoeft te overleven is het tweede karwei: van elke versie met de hand een vertaalde kopie bijhouden, en wat de walkthrough veranderde in één taal overtypen voor mensen die andere talen lezen.

FAQ

Wat is procesdocumentatie?

Procesdocumentatie is de schriftelijke beschrijving van hoe een stuk werk door een organisatie stroomt, van de gebeurtenis die het start tot het resultaat dat het afsluit: de fasen op volgorde, de rol die elke fase beheert, wat van de ene rol naar de volgende gaat, wat elke fase achterlaat, de uitzonderingen buiten het normale pad en wie die beslist, en de paar getallen die de eigenaar in de gaten houdt. Het zit tussen het processchema, het diagram, en de SOP's die beschrijven hoe elke fase stap voor stap wordt uitgevoerd.

Wat hoort er in procesdocumentatie?

Een kop met het ID, de versie, de eigenaar, de ingangsdatum en de volgende reviewdatum; het doel en resultaat; de trigger en de eindstatus; de reikwijdte, inclusief wat het proces niet omvat; de rollen, met één genoemde procesEigenaar; de fasen op volgorde, elk met de rol, de input, de output en waar die is vastgelegd, de volgende rol en de tijdslimiet; uitzonderingen en escalatie met per uitzondering een beslisser; twee of drie meetwaarden; en de gerelateerde SOP's, het beleid dat het uitvoert en een versiegeschiedenis.

Hoe documenteer je een proces stap voor stap?

Kies één proces met een duidelijke trigger en eindstatus. Volg drie echte zaken van begin tot eind en schrijf op wat er werkelijk gebeurde, inclusief de vertakkingen. Schrijf eerst de fasen in de template, elk als overdracht: rol, input, output, volgende rol, tijdslimiet. Voeg de uitzonderingen toe die de zaken lieten zien, met wie elk beslist. Vul het doel, de reikwijdte, de rollen en de kop in. Loop het document door met één persoon per rol, die elk de eigen fase hardop voorleest en de overdrachten bevestigt. Publiceer het waar het team al leest, met de eigenaar en de reviewdatum zichtbaar, en zet de reviewdatum in de agenda.

Wat is het verschil tussen procesdocumentatie en een SOP?

Procesdocumentatie beschrijft hoe werk over rollen en teams stroomt (fasen, overdrachten, wat elke fase achterlaat) op het niveau van één pagina per proces. Een SOP beschrijft hoe één van die fasen door één rol stap voor stap wordt uitgevoerd, tot en met het resultaat dat elke stap oplevert. Het procesdocument vertelt je waar de SOP's nodig zijn en wie wat aan wie overdraagt; één SOP vertelt één persoon wat te doen op dinsdagochtend. Een SOP schrijven voor een heel teamoverstijgend proces levert een handleiding op die niemand opent; een procesdocument schrijven op SOP-detail levert hetzelfde op.

Wat zijn voorbeelden van procesdocumentatie?

Elke terugkerende stroom die over rollen loopt met een duidelijk begin en einde: een nieuwe medewerker onboarden van getekend contract tot dag 30; een bestelling van een distributeur tot een bevestigde levering en een factuur; een klantklacht van intake tot afsluiting; een patiënt van verwijzing tot eerste afspraak; een nieuw product van goedgekeurde briefing tot opgenomen in de catalogus; de maandafsluiting van urenstaten tot verstuurde facturen. Het uitgewerkte voorbeeld in deze gids is de onboarding van een medewerker, met zes fasen over vier rollen, drie uitzonderingen en een geschiedenis van drie versies, met daarna een korter voorbeeld van bestelling tot levering.

Is er een template voor procesdocumentatie in Word of Google Docs?

De template in deze gids is platte tekst met vetgedrukte labels, dus je plakt hem zonder opmaakwerk in een Word-document, een Google Doc, een wikipagina, een Slack canvas of een chatnotitie. Het formaat is belangrijker dan het bestand: wat het document ook bevat, het heeft de kop met de eigenaar en de reviewdatum nodig, de trigger en de eindstatus, fasen geschreven als overdrachten tussen rollen met een tijdslimiet, een genoemde beslisser voor elke uitzondering en een versiegeschiedenis. Bovendien moet het leven waar de mensen die het proces uitvoeren al lezen.

Wie moet procesdocumentatie schrijven?

De procesEigenaar: één genoemde persoon die verantwoordelijk is voor de hele stroom, meestal de manager van het gebied waar het proces grotendeels doorheen loopt, samen met één persoon van elke rol die een fase heeft. De eigenaar houdt de pen en de reviewdatum vast; de mensen die de fasen uitvoeren zijn medeauteurs, omdat een document dat over hen wordt geschreven in plaats van met hen het proces beschrijft zoals ontworpen, terwijl het echte proces in hun hoofd zit. Een nieuwkomer is de tester: als die zijn fase en de twee ernaast in minder dan een minuut kan vinden, werkt het document.

Hoe vaak moet procesdocumentatie worden bijgewerkt?

Op de reviewdatum in de kop, meestal elke zes of twaalf maanden, korter waar het proces gereguleerd is, en eerder wanneer een van vier dingen gebeurt: een overdracht mislukte en niemand was eigenaar, een tool of formulier waarvan een fase afhangt veranderde, de regel die het proces uitvoert veranderde, of de meetwaarden verschoven. Elke update is een nieuwe versie met één regel in de geschiedenis die zegt wat er veranderde en wie het goedkeurde; de oude versie blijft bewaard, en de mensen van wie de fase veranderde worden dezelfde dag geïnformeerd, met de regels die veranderden.

Bronnen: Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Use live captions in Microsoft Teams meetings; Zoom — Using Meeting Summary with AI Companion; Google — Calendar & Meet settings for "Take notes for me"; Google Meet — "Take notes for me" in Google Meet; Google Meet — Use translated captions; Slack — Meeting agenda template (canvas). De pagina's van Microsoft, Google en Slack over meetingnotities en templates zijn gecontroleerd in oktober 2026; de pagina over meetingsamenvattingen van Zoom en de pagina's over ondertiteling van Teams en Meet in augustus 2026. Leveranciers wijzigen na verloop van tijd abonnementen, functies en talenlijsten; raadpleeg hun pagina's voor de actuele stand.