Objectieve samenvatting met AI: de /summarize workflow

Een objectieve samenvatting is niet hetzelfde als een goede samenvatting. De ene meldt wat er is gebeurd. De andere meldt wat er is gebeurd, gefilterd door wie het heeft opgeschreven. In een GTM-team van tien mensen, met drie daily standups en een kwartaal-QBR, telt dat verschil snel op.

Acht maanden lang werkte ik met een Series A B2B SaaS-team in Utrecht: geen CRM-proces (Customer Relationship Management), drie verschillende Notion-wiki's en de gewoonte om meetingverslagen te schrijven die meer op meningen leken dan op notulen. De oplossing was geen beter template. Het was het team leren wat een objectieve samenvatting werkelijk vereist, en dat daarna automatiseren.

Het resultaat: voorbereiding voor deal reviews ging van 40 minuten naar minder dan 10. Board updates hadden nog maar 1 revisieronde nodig in plaats van 3. Post-mortems stopten met schuldvraag-sessies te zijn, omdat het verslag neutraal was en iedereen het eens was over de bewoordingen. Dit artikel is het playbook dat ik had willen hebben aan het begin van dat traject.

Wat een objectieve samenvatting echt betekent (niet de leerboekversie)

De meeste definities stoppen bij "schrijf de feiten op, geen gevoelens." Dat klopt, maar is niet genoeg. In een ops-context betekent een objectieve samenvatting:

• Alleen genomen beslissingen: niet het debat dat ertoe leidde

• Alleen toegewezen actiepunten: niet de stemming van de persoon toen die akkoord ging

• Alleen genoemde data: niet jouw interpretatie van wat die data betekent

Mijn praktijktest: als twee mensen dezelfde meeting bijwoonden en allebei een objectieve samenvatting schrijven, zouden die bijna identiek moeten zijn. Zo niet, dan is een van de twee niet objectief.

Waar het in de praktijk misgaat: iemand schrijft "de CEO leek zich zorgen te maken over de pipeline" in plaats van "de CEO vroeg om een bijgewerkte pipeline-prognose voor Q3, uiterlijk vrijdag." De eerste zin is een observatie met een interpretatie erbovenop. De tweede is wat er daadwerkelijk gebeurde. Het verschil klinkt klein. Op 50 meetings per kwartaal opgeteld levert het een kennisbasis op die niemand meer vertrouwt.

Nederlandse ops-teams hebben hier een eigen uitdaging: de directe overlegcultuur zorgt er soms juist voor dat mensen hun eigen mening als feit presenteren, "gewoon eerlijk zeggen wat je denkt" wordt dan onbedoeld het verslag zelf. "Marieke gaf aan dat de planning krap zat" klinkt feitelijk, maar is nog steeds een parafrase, geen citaat.

Waarom AI-meetingsamenvattingen vaak niet objectief zijn

Hier wordt het interessant, en hier lopen de meeste teams zich vast.

AI-gegenereerde meetingsamenvattingen van tools als Otter, Fireflies of de ingebouwde Zoom-transcriptie zijn getraind om nuttig te zijn, niet neutraal. Nuttig betekent vaak: context toevoegen, scherpe randjes afvlakken, of intentie afleiden. Alle drie voegen subjectiviteit toe.

Ik heb AI-samenvattingen gezien die schreven "het team besloot door te gaan", terwijl het transcript liet zien dat twee mensen het oneens waren en een derde zei: "oké, laten we het proberen." Niet hetzelfde.

Noota, een van de bekendste tools voor meetingverslagen, claimt 6,4 uur per week te besparen en de post-meeting-inspanning bij meer dan 100.000 gebruikers met 80 procent te verminderen. Die cijfers zijn reëel, maar gaan over snelheid, niet over objectiviteit. Sneller zijn betekent niet neutraler zijn.

Het patroon is consistent: het AI-model vult gaten op met aannemelijk klinkende taal. Voor bepaalde taken is dat waardevol. Voor een objectieve samenvatting die een juridisch dossier, een board update of een post-mortem voedt, is het een risico.

De oplossing is niet stoppen met AI gebruiken. Het is de output van het model beperken met een prompt die inferentie expliciet verbiedt.

Stap 1: bouw de /summarize command met een Objective Constraint

30 seconden briefing: de prompt hieronder is de versie die ik met CommanderGPT inzet voor teams die objectieve samenvattingen nodig hebben uit calls en documenten. Fork hem, test hem op een van je laatste vijf meetings en meet het verschil.

Dit is de command-structuur:

/summarize [plak hier transcript of notities]

Instructie: Schrijf een objectieve samenvatting van bovenstaande tekst.
Regels:
1. Rapporteer alleen wat expliciet is gezegd: geen inferentie, geen interpretatie.
2. Format: genomen beslissingen, actiepunten (eigenaar + deadline), genoemde datapunten.
3. Als iets in de bron onduidelijk is, markeer het als [onduidelijk] in plaats van te gokken.
4. Maximaal 150 woorden.

De [onduidelijk]-vlag is de belangrijkste regel. Zonder die vult het model gaten automatisch op. Met die vlag breng je onduidelijkheden aan de oppervlakte in plaats van ze te verbergen. Een objectieve samenvatting met drie [onduidelijk]-vlaggen is nuttiger dan een gepolijste samenvatting die duidelijkheid verzint.

In CommanderGPT wordt dit een slash command die je één keer definieert en toepast op elk transcript, elke call-opname-samenvatting of elk document. De output landt in één stap in je Notion of Linear-ticket: /summarize + plakken = objectief verslag van 150 woorden.

Wat er gebeurt als je deze command op echte meetings toepast: bij de eerste run vind je doorgaans twee tot vier plekken per meeting waar het oorspronkelijke verslag een mening bevat in plaats van een feit. Na twee weken gebruik zijn dat precies de plekken waarover het team had gediscussieerd als het verslag de QBR had gehaald.

Waar objectieve samenvattingen de meeste tijd besparen in de ops-stack

Niet elk gebruiksscenario heeft er een nodig. Dit zijn de vier plekken waar ze zich bewijzen:

Deal reviews: sales ops teams die call-opnames samenvatten voor een QBR (Quarterly Business Review). Objectieve samenvatting = wat de prospect daadwerkelijk zei, niet wat de account executive zich herinnert. Bij een deal van 300.000 euro is dat verschil niet triviaal.

Board- en investor updates: het bestuur heeft geen interpretatie van de cijfers nodig. Het heeft de cijfers en de beslissingen nodig. Een objectieve samenvatting van elk initiatief, gelimiteerd tot 100 woorden, is sneller te lezen en lastiger verkeerd te citeren.

Post-mortems: als er iets misgaat, is het nuttigste document er een dat beschrijft wat er in welke volgorde is gebeurd, zonder schuld of oordeel. Objectieve samenvatting is post-mortem-format.

Async standups: verspreide teams die async standups doen via Loom of Slack hebben samenvattingen nodig die andere teamleden in 30 seconden kunnen lezen zonder erbij te zijn geweest. Objectief = geen context nodig.

De workflow van 3 commando's: /research, /summarize, /flag

Voor GTM ops teams die prospect research of account reviews doen, passen objectieve samenvattingen natuurlijk in een keten van commando's:

1. /research [bedrijfsnaam]: haalt publieke data op: laatste financieringsronde, recent aangenomen mensen, persvermeldingen, productwijzigingen

2. /summarize: destilleert die output tot een objectief verslag van 100 woorden over de actuele status van het bedrijf

3. /flag [criteria]: toetst de samenvatting aan je ICP-criteria (Ideal Customer Profile) en markeert afwijkingen

Recon compleet voordat je de eerste e-mail verstuurt. De account executive krijgt in minder dan 90 seconden een output in drie delen: wat het bedrijf doet, wat er recent is veranderd en of het bij het ICP past. Geen inferentie. Geen redactie. Alleen de data.

Dit is de workflow die de handmatige voorbereiding van 40 minuten voor het Utrechtse team verving. Niet omdat de AI sneller leest (dat doet ze), maar omdat de stap van de objectieve samenvatting het gesprek wegneemt over of de data correct wordt gelezen.

Het Utrechtse team draaide deze workflow op vijf prospects per dag. Week één: de AE's waren sceptisch. Week drie: niemand wilde nog handmatig research doen. Het verschil zat niet in de snelheid van AI. Het zat in het verdwijnen van de discussie "maar heeft hij dat echt gezegd?" na elke call.

Wat een objectieve samenvatting om zeep helpt (en hoe je het herkent)

Zelfs met een beperkte prompt kunnen objectieve samenvattingen afdrijven. Dit zijn de vier foutpatronen die ik het vaakst zie:

Zachte toeschrijving: "het team voelde dat de planning te ambitieus was" in plaats van "drie teamleden zeiden dat de planning te krap was; twee zeiden niets." Markeer elke zin met een emotioneel werkwoord: voelde, leek, kwam over, maakte zich zorgen.

Ontbrekende deadlines: een samenvatting die een beslissing vastlegt zonder deadline en eigenaar, is niet uitvoerbaar. Bouw een check in je command: als de output geen eigenaar/deadline-paar heeft voor elk actiepunt, is de samenvatting onvolledig.

Weggewerkte tegenspraak: als twee mensen tegenovergestelde dingen zeggen, legt een objectieve samenvatting beide standpunten vast. Een AI-model dat getraind is om behulpzaam te zijn, kiest vaak het redelijker klinkende standpunt en presenteert dat als consensus. Dat is geen objectiviteit.

Scope creep: de samenvatting begint context toe te voegen die niet in de meeting zat: sectortrends, voorgeschiedenis, implicaties. Dat is allemaal redactie. Schrap het.

De snelste check: lees de samenvatting en vraag per zin: "komt dit rechtstreeks uit de bron?" Als je niet kunt aanwijzen waar het vandaan komt, hoort het er niet in thuis. Bouw deze check als 60-secondencontrole in je workflow in, voordat de samenvatting verstuurd wordt. Zo vang je het grootste deel van de afdrijving af voordat het een team-alignmentprobleem wordt.

Laat het "Insights"-blok weg

Veel AI-samenvattingstools voegen standaard een "Insights"- of "Takeaways"-blok toe aan het einde. Laat dat weg bij objectieve samenvattingen. Insights zijn interpretaties. Takeaways zijn redactie.

Wil je analyse, draai dan een apart command: /analyze [samenvatting]. Houd het objectieve verslag en de analyselaag gescheiden. Zo kun je de objectieve samenvatting breed delen (cross-team, naar legal, naar het bestuur), terwijl de analyse blijft waar ze hoort.

De meeste ops leads met wie ik werk, houden aan het eind van elke belangrijke meeting twee documenten over: de objectieve samenvatting (gedeeld) en de analysenotitie (intern). De objectieve samenvatting is de bron van waarheid. De analysenotitie is de inschatting van het team over wat er nu moet gebeuren.

Een nuttig neveneffect: als deze lagen gescheiden blijven, kun je wisselen wie de analyse schrijft zonder het gedeelde verslag te veranderen. Nieuw teamlid sluit aan bij een QBR? Die krijgt de objectieve samenvatting om op de hoogte te raken van genomen beslissingen. De analyselaag blijft intern totdat er genoeg context is om bij te dragen. Deze structuur schaalt natuurlijk mee als teams groeien van 5 naar 20 mensen en het aantal cross-functionele stakeholders toeneemt.

Voor CS-ops teams die renewal reviews doen, is deze scheiding extra nuttig. De objectieve samenvatting van een renewal call gaat naar het CRM. De analysenotitie ("dit account loopt risico omdat...") blijft in de interne CS-tool. Twee bronnen van waarheid voor twee verschillende doelgroepen, allebei herleidbaar tot hetzelfde gesprek.

Je volgende command om nu in te richten

Gebruik je CommanderGPT, begin dan hier: bouw de /summarize command met de hierboven beschreven Objective Constraint en draai hem op je laatste vijf meetingverslagen. Vergelijk de output met wat er daadwerkelijk is genoteerd. Het gat toont je precies hoeveel redactionele afdrijving je huidige samenvattingen bevatten.

Is dat gat groot, wat meestal zo is, dan heb je net zo goed een meetprobleem als een schrijfprobleem. De objectieve samenvatting is de baseline. Al de rest bouwt daarop voort.

Command opzetten. Output lezen. Ship.