SOP 03-08 — Klantdossier-conventie (levend dossier, kennisborging)
Doel (uitkomst) Alle kennis over een klant staat op één vaste, voorspelbare plek — niet uitsluitend in het hoofd van de founder. Dit is het grootste bus-factor-risico van een solo-/klein bureau: valt de founder uit of is die er even niet, dan moet iedereen die de klant overneemt binnen 10 minuten de context hebben.
Wanneer Doorlopend — dit is geen los moment maar de vaste plek waar elke andere klanten-SOP naar terugschrijft (kickoff, rapportage, QBR, upsell, health-score, klacht, offboarding).
Eigenaar Accountmanager
Uitvoerder Iedereen die klantcontact heeft
Duur Bijwerken: 2-5 min per gebeurtenis, direct erna (geen batching aan het einde van de week)
Benodigd vooraf Vaste locatie/structuur (zie hieronder)
🎥 Video — nog opnemen

Klaar = (controleerbaar)

  • Elke actieve klant heeft één dossier op de vaste locatie, met de vaste structuur.
  • Elk relevant moment (kickoff, rapportage-highlights, QBR-besluiten, upsell- signalen, health-score, klacht, offboarding) is bínnen dezelfde dag vastgelegd — niet retroactief gereconstrueerd.
  • Een collega die het dossier voor het eerst opent, kan binnen 10 minuten antwoorden: wie is de klant, wat is de status, wat speelt er, wat is de volgende actie.

Waarom dit een aparte SOP is en geen los "notities"-gewoonte

Kennisborging per klant is de tegenhanger van het bus-factor-risico: vandaag zit alle klantkennis in het hoofd van de founder. Een levend dossier — bijgewerkt uit sessies/notities in plaats van achteraf samengesteld — is de structurele oplossing. Dit is een conventie, geen aparte tool: het dossier leeft in de bestaande klant-mappenstructuur, niet in een nieuw systeem.

Vaste structuur per klantdossier

Elk klantdossier volgt exact deze indeling (kopjes, geen vrije vorm — vergelijkbaarheid tussen klanten is het hele punt):

# Klantdossier — <klantnaam>

## Kerngegevens
- Contactpersoon(en) + rol
- Startdatum samenwerking
- Diensten/scope (huidige overeenkomst)
- SLA-afspraken (link naar sla-communicatie-template ingevuld voor deze klant)

## Status (actueel — bovenaan, altijd het eerst bijgewerkte blok)
- Health-score (huidig + trend, zie SOP 03-05)
- Openstaande acties / toezeggingen
- Eerstvolgende vaste momenten (volgende rapportage-datum, volgende QBR)

## Geschiedenis (chronologisch, nieuwste bovenaan)
- Kickoff-verslag (link/samenvatting)
- QBR-besluiten per kwartaal
- Upsell-signalen + uitkomst
- Klachten + afhandeling + leerpunt
- Overige belangrijke momenten (contactpersoonwissel, scope-wijziging, etc.)

## Offboarding (alleen invullen bij vertrek)
- Reden van vertrek
- Exit-interview-antwoorden
- Leerpunt voor het bedrijf

Locatie

Eén map per klant, in de bestaande klant-structuur (zie convention_sites_directory.md voor de sites-conventie; voor het klantdossier zelf geldt: één markdown-bestand per klant in de klant-specifieke map, bestandsnaam klantdossier.md). Geen aparte losse tool of database — het dossier is een bestand, geen systeem.

Stappen

  1. Maak het dossier aan bij de kickoff (SOP 03-01) met de vaste structuur — dit is de eerste vulling van "Kerngegevens".
  2. Werk het Status-blok bij na élk contactmoment dat de status raakt (nieuwe health-score, nieuwe toezegging, nieuw gepland moment).
  3. Voeg toe aan Geschiedenis (nooit overschrijven) bij: QBR, upsell-signaal, klacht, of ander noemenswaardig moment — chronologisch, nieuwste bovenaan.
  4. Vul Offboarding pas in bij daadwerkelijk vertrek (SOP 03-07).
  5. Archiveer (niet verwijderen) na afronding van de offboarding.

Checklist

  • Dossier aangemaakt bij kickoff met de vaste structuur
  • Status-blok altijd actueel (binnen dezelfde dag na een wijziging)
  • Geschiedenis wordt aangevuld, nooit overschreven
  • Andere klanten-SOP's verwijzen terug naar dit dossier i.p.v. losse notities
  • Bij vertrek: offboarding-blok ingevuld vóór archivering

Toekomstige automatisering (niet in scope van deze SOP)

Dit dossier is bedoeld als bron voor toekomstige automatisering (bijv. een levend-dossier-samenvatting uit sessies/notities, of een dashboard dat health- scores over klanten samenvat). Deze SOP legt uitsluitend de conventie vast — de structuur en locatie — zodat die automatisering later op een consistente databron kan bouwen. Er wordt hier geen tool gebouwd.

Valkuilen / veelgestelde vragen

  • Dossier alleen retroactief bijwerken → context gaat verloren, precies het bus-factor-risico dat deze SOP moet oplossen. Altijd binnen dezelfde dag.
  • Vrije vorm per klant → onvergelijkbaar en onvoorspelbaar voor wie het overneemt. Altijd de vaste structuur.
  • Los van de andere klanten-SOP's bijgehouden → elke andere SOP in dit domein (rapportage, QBR, upsell, health-score, klacht, offboarding) schrijft terug naar dít dossier — nooit een eigen, aparte notitieplek per SOP.

Gerelateerd

Laatst bijgewerkt: 2026-07-12 · Eigenaar: Accountmanager