Hoe schrijf je een samenvatting die jouw ops-team aanstuurt

Hoe schrijf je een samenvatting die jouw ops-team aanstuurt

Hoe schrijf je een samenvatting die echt gelezen wordt? Niet de schoolversie met academische omschrijvingen, maar een samenvatting die een gedistribueerd ops-team aanstuurt zonder vervolgdiscussie in Slack. De meeste teams schrijven te lang, sturen te laat en adresseren niemand specifiek. Dit artikel geeft je het 3D-raamwerk, de vier formats die je elke week nodig hebt en een AI-commando dat de eerste versie in 90 seconden genereert.

Waarom vergadernotities van ops teams ongelezen blijven

Ik begeleidde vorig jaar een GTM-team (go-to-market) bij een Series A SaaS-bedrijf. Na drie maanden vroeg ik hun vergaderdocumentatie op. Wat ik vond: lange alinea's, geschreven als officiële notulen, verstuurd 24 uur later, in CC aan iedereen, zonder namen bij de actiepunten.

Niemand las ze. De teamlead wist het. Ze schreef ze nog steeds, omdat ze het gevoel had dat het erbij hoorde.

Het probleem was niet de inzet. Het was het format. Academische samenvattingen draaien om begrip: je laat zien dat je de bron hebt begrepen. Ops-samenvattingen draaien om coördinatie: een verdeeld team weet wat de volgende actie is, zonder dat er een vervolgthread nodig is.

Schoolversie: "De vergadering behandelde de Q3 pipeline review, uitdagingen in de EMEA-regio en een update van het CS-team (Customer Success) over de verlengingsbacklog." Ops-versie: "Beslissing: EMEA outbound versnellen. Owner: Marcus, AE lead (Account Executive). Deadline: vrijdag EOD. CS-backlog: verschoven naar volgende sprint."

Zelfde vergadering. Zeventien woorden minder. Geen ruimte voor interpretatie.

De vier formats die je elke week schrijft

Niet elke ops-samenvatting vraagt hetzelfde format. Dat door elkaar halen is de eerste fout die je kunt maken, en de moeilijkste om terug te draaien als het patroon eenmaal ingesleten is.

Vergadersamenvatting. Het standaardformat. Dekt genomen beslissingen, actiepunten met owners en de datum van de volgende vergadering. Max 200 woorden. Klaar binnen 2 uur, niet 24. Dit is het format dat de meeste teams te lang maken en te laat versturen. Die twee fouten samen maken het nutteloos.

Deal review samenvatting. Schrijf je na een pipeline review of call debrief. Dekt dealstatus, blokkades, volgende stap en kansinschatting. Komt in de CRM-notitie (Customer Relationship Management), niet in een e-mailthread. Max 150 woorden. Korter dan je denkt, maar een AE die terugkijkt in het CRM leest 150 woorden. Die leest geen 400.

Research handoff samenvatting. Je schrijft deze wanneer je prospect- of concurrentieonderzoek overdraagt aan een AE, CS lead of SDR (Sales Development Representative). Dekt wat je hebt gevonden, wat het betekent voor het pitch en wat je kunt overslaan. Max 300 woorden. De ontvanger moet genoeg context hebben om te handelen zonder het brondocument te lezen. Als ze het brondocument nodig hebben, heb je gefaald.

Async statusupdate. Wekelijkse of tweewekelijkse schriftelijke update die een statusvergadering vervangt. Dekt wat er is opgeleverd, wat geblokkeerd is en wat de volgende stap is. Max 250 woorden. Het format dat je manager leest op vrijdagavond voor een maandag-boardcall. Ze moeten het in twee minuten kunnen lezen, niet in tien.

Elk format heeft een andere kernvraag. Vergadersamenvatting: "Wat hebben we afgesproken?" Deal review: "Waar staat deze deal?" Research handoff: "Wat moet ik weten voor dit gesprek?" Async update: "Liggen we op schema?"

Schrijf het verkeerde format voor de context en je samenvatting wordt genegeerd, ook als de inhoud klopt.

Het 3D-raamwerk: Beslissing, Delta, Deadline

Drie elementen verwerken 90% van het werk in elke ops-samenvatting. Het 3D-raamwerk: Beslissing, Delta en Deadline.

Beslissing: wat er is bepaald, gekozen of bevestigd. Niet "we hebben gesproken over de prijsstelling." Maar: "We stellen het Q3-dealsdoel op 280.000 euro, omhoog van 240.000 euro."

Delta: wat er is veranderd ten opzichte van de vorige keer. Dit element wordt het vaakst overgeslagen. Ops leads vergeten het omdat ze bij de vorige vergadering waren. Hun lezers misschien niet, of ze zijn het vergeten. De delta beantwoordt: "Wat is er anders dan vorige week?"

Deadline: wanneer komt de volgende actie binnen, en wie is de owner. Een naam, een datum. Niet "het team volgt dit op." Maar: "Priya levert de herziene compensatieanalyse voor donderdag 12.00 uur."

Schrijf die drie regels eerst. Voeg daarna context toe, alleen als de lezer die nodig heeft om te handelen. Dat is de meeste keren niet nodig. Het Beslissing-Delta-Deadline-blok is de samenvatting. De rest is bijlage.

Een 3D-samenvatting voor een deal review ziet er zo uit:

• Beslissing: Doorsturen naar Fase 4, aangepaste prijsdeck versturen deze week.

• Delta: Champion verschoven van IT naar CFO na het gesprek van vorige week. Budget-autoriteit is gewijzigd.

• Deadline: Alex stuurt prijsdeck voor woensdag. Priya plant CFO-introductie voor donderdag.

Dat zijn 42 woorden. Het wordt gelezen. Een verslag van 400 woorden van dezelfde vergadering niet.

Waar samenvattingen mislopen

Het is bijna altijd de actiepuntenlijst.

Hoe een kapot actiepunt eruitziet: "Opvolgen met de klant." Vier woorden, nul eigenaarschap. Een week later heeft niemand het gedaan, en niemand weet wie het had moeten doen.

Hoe een werkend actiepunt eruitziet: "Derek stuurt het herziene SLA-document (Service Level Agreement) naar contact@klant.nl voor vrijdag 17.00 uur CET."

Naam, taak, ontvanger of bestemming, deadline met tijdzone. Die ene stap van vaag naar specifiek is het verschil tussen een samenvatting die actie genereert en een die de illusie van coördinatie schept.

De tweede plek waar samenvattingen instorten: timing. Een samenvatting die 24 uur na een vergadering binnenkomt is bijna nutteloos. Mensen hebben inmiddels doorgepakt. Beslissingen worden betwist in Slack omdat niemand het schriftelijke verslag heeft. Verstuur binnen 2 uur. Het liefst voordat mensen de vergadercontext kwijt zijn.

Het derde probleempunt: distributie. Een volledige samenvatting sturen naar 20 mensen terwijl er 3 actiepunten hebben, creëert ruis. De 17 zonder taak stoppen met toekomstige samenvattingen lezen. Segmenteer: stuur het volledige document naar de kerngroep, stuur een extract van 3 bullets naar de bredere lijst.

Een samenvatting schrijven met AI in 90 seconden

Dit is de werkwijze die ik gebruik met ops-teams die CommanderGPT hebben ingesteld.

Stap 1. Maak ruwe aantekeningen tijdens de vergadering. Net genoeg om Beslissing, Delta en Deadline vast te leggen. Geen transcriptie. Mikken op 10 tot 15 bullet-fragmenten.

Stap 2. Plak je aantekeningen na de vergadering in het /samenvatten-commando met dit suffix: "Format als: 1. Beslissing 2. Delta ten opzichte van vorige sessie 3. Actiepunten (owner en deadline). Max 200 woorden. Geen inleiding."

Stap 3. Lees de output. Corrigeer de namen en datums (het model generaliseert deze soms als je aantekeningen vaag waren). Verstuur.

Totale tijd van einde vergadering tot verstuurde samenvatting: 8 minuten. Ik heb dit gemeten op drie klantteams in de afgelopen zes maanden. De range was 6 tot 12 minuten, afhankelijk van de kwaliteit van de input-aantekeningen.

De hefboom zit in het prompt-suffix, niet in het basiscommando. Een generiek /samenvatten levert een proza-samenvatting die veel bewerking vraagt. Het gestructureerde suffix dwingt de 3D-output zodat de modeloutput direct bruikbaar is, zonder herformatteren.

Als je nog geen aangepast slash-commando hebt ingesteld, kom je 80% van de weg met een opgeslagen prompttemplate in een AI-interface. Het voordeel van CommanderGPT is dat het prompt leeft in een gedeeld Team Playbook. Elke AE, CS lead en SDR op je team gebruikt hetzelfde format zonder aan het suffix te hoeven denken. Dat is de consistentie op schaal waar je stopt met het ontvangen van 12 verschillende samenvattingformats van hetzelfde team. Meten is weten: vergelijk het aantal verduidelijkende Slacks per week voor en na de implementatie.

De samenvatting distribueren zodat hij wordt gelezen

Versturen is niet distribueren. De meeste ops leads verwarren dit.

Een samenvatting in een e-mailthread met acht andere berichten wordt niet dezelfde dag gelezen. Een samenvatting in het juiste Slack-kanaal, met beslissingen vastgepind en actiepunten direct gethreaded aan de owners, wordt binnen 15 minuten gelezen.

Het distributieformat dat werkt voor GTM ops-teams:

• Post de volledige 3D-samenvatting in het vergadering-specifieke Slack-kanaal of op de Notion-pagina

• Stuur in het kanaal waar actie-owners actief zijn een extract van 3 bullets: genomen beslissing, volgende actie, wie doet wat en wanneer

• Tag de actie-owners direct, niet het kanaal, met hun specifieke taak

Dit geeft twee lagen: het volledige verslag voor verantwoording en referentie, en de gerichte melding voor mensen die moeten handelen. Niemand hoeft door een volledige samenvatting te zoeken om zijn taak te vinden.

Voor wekelijkse async updates: maak de distributie nog strakker. Je manager heeft geen 15 bullets nodig over wat je de afgelopen week hebt gedaan. Ze hebben nodig: opgeleverd, geblokkeerd, volgende stap. Drie regels. Als ze meer willen, weten ze waar het volledige document staat.

Volgende stap: bouw een samenvattingworkflow die zichzelf draait

De ops leads die dit duurzaam hebben opgelost, hebben een ding gemeen: ze zijn gestopt met samenvattingen zien als een losse schrijftaak en beginnen ze te behandelen als een pipeline.

Input: ruwe aantekeningen tijdens het event. Verwerking: AI-commando met een vast format-suffix. Output: 3D-samenvatting klaar om te versturen. Distributie: twee-laags aanpak (volledig verslag plus gericht extract). Archief: getagd in de relevante Notion-pagina of het CRM-veld.

De hele pipeline draait in minder dan 10 minuten per vergadering, per deal review, per research handoff. Op schaal, 8 tot 12 gesommeerde events per week per ops lead, is dat maximaal 80 tot 120 minuten documentatietijd. Voor deze systematisering besteedden de teams die ik begeleid 3 tot 4 uur aan documentatie die vaak nooit gelezen werd.

Fork het 3D-raamwerk. Bouw het /samenvatten-commando met het format-suffix. Stel de twee-laagse distributie in. Voer het twee weken uit en meet de bestede tijd versus het aantal verduidelijkende Slacks. Op dag vijf weet je of het werkt.