# Actiepunten post-mortem die daadwerkelijk worden afgesloten

URL: https://upstreamapi.com/nl/journal/actiepunten-post-mortem
Type: blog
Locale: nl
Published: 2026-09-05
Updated: 2026-09-06

---

> Minder dan 50% van post-mortem actiepunten wordt daadwerkelijk afgesloten. Leer hoe je dat verandert met bewezen procesaanpassingen.

Je team heeft vorige week dinsdag een post-mortem gedraaid. Zes **actiepunten post-mortem** zijn opgeschreven. Twee hebben inmiddels een Jira-ticket gekregen. Een heeft een eigenaar die ondertussen met een andere brand bezig is. Drie staan nog onaangeroerd in het Google Doc onder "Follow-ups."

Dit is geen uitzondering. Onderzoek van incident.io laat zien dat de completion rate bij de mediane SRE-teams onder de 50% ligt. Bij teams met een zwakke incidentcultuur loopt dat op tot boven de 70% verlies. De gemiddelde post-mortem levert daarmee ruwweg evenveel structurele verandering op als een retro-sticker-sessie: het proces draait, de schuld blijft blameless, en hetzelfde failure mode is zes weken later terug in productie.

De oplossing is niet een beter template. Het is een ander begrip van wat een actiepunt functioneel maakt.

## Waarom de meeste actiepunten structureel fout zijn

"Monitoring verbeteren" opschrijven in een post-mortem voelt productief. Het is geen actiepunt -- het is een werkcategorie met geen eigenaar, geen deadline en geen definitie van done.

Een werkend actiepunt heeft drie onherleidbare onderdelen: wat er gedaan moet worden (specifiek en meetbaar), wie het bezit (een benoemde engineer, geen team), en wanneer (een concrete datum, geen "Q4" of "zo snel mogelijk"). Ontbreekt een van die drie, dan is de kans groot dat het item nooit sluit.

Niet omdat iemand het actief weigert. Maar omdat het nooit opduikt op de plek waar werk echt ingepland wordt.

Teams bij wie de completion rate laag is, missen doorgaans het derde onderdeel. Deadlines van post-mortem items concurreren niet met de sprintplanning -- ze bestaan buiten die cyclus en zijn daardoor structureel onzichtbaar voor de planningsgesprekken die werk prioriteren. De sprint is de enige cadans die consistent wordt bijgehouden onder operationele druk; alles wat er buiten valt, verdwijnt.

## Het getal dat iedere teamlead zou moeten onthouden

42%.

Dat is de gemiddelde completion rate bij teams zonder gestructureerd opvolgingsproces. Bij teams met een zwakke incidentcultuur daalt dat tot onder de 30%. De handmatige stap van post-mortem document naar ticketsysteem is verantwoordelijk voor 40% van het verlies bij die stap alleen al.

Teams die named owners koppelen aan sprint-integratie en een wekelijkse review van open items halen 75-80% completion rate binnen twee kwartalen. Dat verschil is niet te verklaren door commitment of discipline. Het is procesontwerp.

[DORA-onderzoek](https://sre.google/sre-book/postmortem-culture/) verbindt lagere change failure rates aan het sluiten van post-mortem actiepunten -- niet aan de kwaliteit van het post-mortem document zelf. Een perfect uitgeschreven five-whys analyse zonder opvolging verandert niets aan de volgende deployment. Het document bewijst dat je nagedacht hebt; de gesloten actiepunten bewijzen dat het iets veranderd heeft.

## Mitigatieve en preventieve actiepunten zijn geen dezelfde queue

Er zijn twee functioneel verschillende soorten actiepunten en ze horen in twee aparte queues.

**Mitigatieve actiepunten** verkleinen de blast radius van een fout die zich herhaalt, voordat de onderliggende oorzaak is opgelost. Ze zijn urgent. Ze zouden binnen de eerstvolgende sprint geshipped moeten worden. Voorbeeld: een alertingregel toevoegen zodat de volgende keer niet dertig minuten ongedetecteerd degradatie optreedt.

**Preventieve actiepunten** verwijderen het failure mode zelf. Ze zijn architectureel, duurder in uitvoering en verdienen een plek op de roadmap met expliciete engineering-time. Voorbeeld: de tight coupling tussen de payment-service en de inventory-service wegnemen die de cascade veroorzaakte.

Als je ze in dezelfde Jira-backlog mixt en ze laat concurreren met feature work op prioriteit, wint feature work -- altijd. Mitigatieve items zijn te klein om op de roadmap te verschijnen, preventieve items zijn te groot om als bug-tickets door te komen. Beide verdwijnen.

![Kanban-bord met openstaande post-mortem actiepunten die gemarkeerd zijn als te laat, engineer wijst naar de kaarten](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/07c92a-inline1.webp)

De oplossing is een aparte queue voor post-mortem items, met wekelijkse zichtbaarheid op teamlead-niveau, structureel onderscheiden van de feature-backlog.

## Waar actiepunten gaan sterven

Er zijn drie plaatsen waar post-mortem actiepunten structureel verdwijnen.

**Ambigue eigendom.** "Backend-team" is geen eigenaar. Een eigenaar is een naam. Als de follow-up in een document staat zonder dat iemand expliciet eigenaar is aangewezen, heeft niemand een verplichting. Ambiguiteit beschermt iedereen behalve het systeem.

**Geen verbinding met de sprintcyclus.** Post-mortem items die niet in de sprintplanning van dezelfde week of de volgende week opduiken, verdwijnen. De sprint is de enige planningscadans die consistent wordt bijgehouden in teams onder operationele druk. Alles wat buiten die cyclus valt, heeft geen vanzelfsprekende plek in het werk.

**De handmatige doc-naar-ticket handoff.** Teams die actiepunten handmatig overzetten van een post-mortem document naar een ticketsysteem verliezen gemiddeld 40% van de items bij die stap. Wie schrijft, wie kopieert, wie assignt -- als dat niet geautomatiseerd of strak geprotocolleerd is, is verlies structureel.

Notion AI kan de doc-naar-ticket stap gedeeltelijk automatiseren. Het parseert een post-mortem document en stelt actiepunten voor met eigenaar en due date als velden. De native Jira-integratie vereist een tussenstap, maar het elimineert de copy-paste-verliesstap voor teams die toch al in Notion werken.

## Vergaderingen die actiepunten vasthouden voor ze verdampen

Een post-mortem eindigt. De opvolging niet.

Teams met hogere completion rates plannen een korte wekelijkse review van open post-mortem items -- los van de retro, los van de sprintplanning. Vijftien minuten. Niet om status te geven maar om blokkades te identificeren: wie heeft hulp nodig, welk item past in de sprint van deze week, wat is al drie weken geblokkeerd en waarom.

De tool-keuze voor het capteren van actiepunten tijdens de post-mortem sessie zelf maakt al uit. Real-time transcriptie helpt -- niet voor de transcriptie zelf maar voor het vastleggen van eigenaar en datum terwijl de context aanwezig is en de call nog niet voorbij is. Actiepunten die na afloop worden opgeschreven vanuit onvolledige notities verliezen de nuance over scope en eigendom die tijdens de sessie wel aanwezig was.

Granola transcribeert vergaderingen en markeert acties automatisch. Voor post-mortem sessies betekent dat: actiepunten worden opgeschreven terwijl ze worden besproken, niet daarna vanuit een onvolledige aantekening.

## Het eigenaarsprobleem: teams ronden taken niet af

Teams ronden geen taken af. Mensen wel.

"Het platform-team regelt dit" is een zin die actiepunten doodmaakt. In een team van vijf engineers is er geen gedeelde verantwoordelijkheid die iemand op maandagochtend wakker houdt. Er is een naam die op maandag in de standup gevraagd kan worden hoe het er voorstaat.

Dit is ongemakkelijk in teams met een flat hierarchy. Die ongemakkelijkheid is functioneel. Als niemand eigenaar wil zijn van een actiepunt, is dat een signaal over het item -- te vaag, te groot, niet realistisch geprioriteerd -- niet per se over de teamcultuur.

![Engineering team in post-mortem bespreking rond een whiteboard met incident timeline](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/b55433-inline2.webp)

Eigenaars die zien dat ze een actiepunt niet kunnen leveren binnen de afgesproken termijn, moeten dat melden voor de volgende sprintplanning -- niet op de dag van de deadline. Dat vereist een psychologisch veilige omgeving. Het vereist ook dat de teamlead actief vraagt, niet passief afwacht tot de deadline verstrijkt.

Een concret patroon dat werkt: het actiepunt staat als agenda-item in de standup van de eigenaar totdat het gesloten is. Geen statusupdate vereist als alles op schema ligt. Wel een vlag als er een blokkade is. Dat is de minimale overhead die een item zichtbaar houdt zonder het te verdrinken in vergaderdruk.

## Observeerbaarheidstekorten als apart geval

Observeerbaarheidstekorten als actiepunten verdienen aparte aandacht omdat ze structureel moeilijk te sluiten zijn.

"Betere traces toevoegen" heeft geen meetbare eindtoestand. De definitie van done moet zijn: "Dashboard X toont P95 request latency per service edge binnen 48 uur na incident, geautomatiseerd gealarmeerd bij overschrijding van de SLO-drempelwaarde." Pas dan is de definitie binair en kan iemand het item daadwerkelijk sluiten.

Datadog en Grafana zijn de standaardtools voor dit patroon. Het actiepunt is pas gesloten als de alert bestaat, getest is en gedocumenteerd is in het runbook -- niet als de PR gemerged is. Het verschil lijkt klein; in de opvolgingscyclus is het het verschil tussen een item dat na twee weken heropend wordt en een item dat blijft dicht.

Observeerbaarheidstekorten die als vage items worden opgeschreven worden vrijwel nooit gesloten. Dezelfde tekorten, geformuleerd als meetbare alertingregels, worden structureel hoger geprioriteerd omdat de definitie van done duidelijk is.

Een praktische vuistregel: als je het actiepunt niet als acceptatiecriterium in een ticket kunt schrijven, is het nog geen actiepunt. Het is een thema. Herschrijf het totdat het als testbare conditie leesbaar is.

## De feedbackloop die niemand sluit

Het meest over het hoofd geziene onderdeel van post-mortem opvolging: de verbinding maken tussen een gesloten actiepunt en een verhinderd incident.

Als een engineer zes weken na de post-mortem een alertingregel toevoegt die een uur later een degradatie detecteert die anders dertig minuten onopgemerkt zou zijn gebleven -- wie weet dat? Wie vertelt het team? Wie schrijft het op in het volgende incident review?

Niemand, tenzij je een systeem hebt voor gestructureerde terugkoppeling.

![Developer bij laptop met bevestiging van afgesloten post-mortem actiepunt op scherm](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/899b10-inline3.webp)

Teams met een gezonde incidentcultuur koppelen gesloten items aan verhinderde incidenten in hun maandelijkse incidentreview. Dat is geen administratief ritueel -- het is de enige feedback die engineers doet inzien dat post-mortems de moeite waard zijn en dat actiepunten sluiten effect heeft op de stabiliteitsmeting van het systeem.

Completion rates van 75-80% worden niet bereikt met betere Jira-labels of mooiere post-mortem templates. Ze worden bereikt wanneer de verbinding tussen gesloten actiepunt en verhinderd incident zichtbaar is voor het hele team en terugkeert in de incidentreview.

De vraag na elk afgesloten item: als dit incident zich morgen zou herhalen, wat zou dan anders gaan? Als het antwoord onduidelijk is, is het actiepunt misschien wel gesloten, maar het werk niet.

## FAQ

### Wat is de gemiddelde completion rate voor actiepunten post-mortem?

Onderzoek van incident.io laat zien dat de mediane SRE-teams minder dan 50% van hun post-mortem actiepunten daadwerkelijk afronden. Bij teams zonder gestructureerd opvolgingsproces ligt het gemiddelde op 42%. Met named owners, sprint-integratie en wekelijkse review halen teams 75-80% binnen twee kwartalen.

### Wat maakt een actiepunt post-mortem effectief?

Een werkend actiepunt heeft drie onderdelen: een specifieke en meetbare actie, een benoemde eigenaar (geen team), en een concrete deadline. Ontbreekt een van de drie, dan valt het item buiten de planningscyclus en sluit het vrijwel nooit.

### Wat is het verschil tussen mitigatieve en preventieve actiepunten?

Mitigatieve actiepunten verkleinen de blast radius en zouden binnen de eerstvolgende sprint geshipped moeten worden. Preventieve actiepunten verwijderen het failure mode zelf en verdienen een plek op de roadmap. Ze horen in aparte queues omdat ze verschillende prioriteringslogica vereisen.

### Hoe voorkom je dat post-mortem actiepunten verdwijnen?

De drie voornaamste oorzaken van verlies zijn: ambigue eigendom, geen koppeling met de sprintcyclus en een handmatige doc-naar-ticket stap die 40% van de items kwijtraakt. De effectiefste maatregel is named ownership plus integratie in de sprintplanning van dezelfde of volgende week.

### Hoe weet je of een actiepunt post-mortem echt gesloten is?

Een actiepunt is gesloten als de definitie van done bereikt is, niet als de PR gemerged is. Voor observeerbaarheidstekorten betekent dat: de alert bestaat, is getest en gedocumenteerd in het runbook. De feedbackloop sluit pas als het team de verbinding kan maken tussen het gesloten item en een verhinderd incident.

### Welke tools helpen bij het opvolgen van post-mortem actiepunten?

Notion AI kan de handoff van post-mortem document naar ticket automatiseren. Granola legt actiepunten vast tijdens de sessie zelf. Datadog en Grafana bieden de meetbare eindtoestand voor observeerbaarheidsgerelateerde items. Tools ondersteunen het proces maar vervangen named ownership en sprint-integratie niet.