Actiepunten uit vergadering halen met AI: een weekendproject

Actiepunten uit vergadering halen met AI is geen fantasie : een echt weekendproject van één weekend. Je zit vrijdagavond laat achter je code editor en vraagt je af wat je volgende project moet zijn. Een AI-tool die actiepunten uit vergaderingen haalt, is geen fantasie : het is een echt weekend-project. Voer er een call-transcript of samengestelde notities in, en je krijgt een schone lijst terug : wie doet wat, en wanneer. Het bouwen zelf is een paar uur API-glue. De moeilijkere vraag is of je twintig gebruikers vindt die jouw versie gebruiken in plaats van de vijf betaalde tools die al om dezelfde klanten vechten.

Wat "actiepunten" eigenlijk betekent als build-target

Strip de buzzword weg en de taak is scherp : ongestructureerde tekst (transcript, voice memo omgezet in tekst, stapel Slack-berichten) omzetten in een lijst {taak, eigenaar, deadline, betrouwbaarheid}. Dat is het. Geen samenvatting, geen sentiment-analyse, geen dashboard. Puur extractie in een vorm die een to-do app kan ingesteken.

Dit verandert je scoping. Een algemene "meeting assistant" is een zes-maands product met transcriptie-infrastructuur, kalender-sync, en UI-gevechten. Een actiepunten-extractor is een prompt, een schema, en een plek voor de output. Je kunt een werkende versie shippen voordat je koffie koud wordt.

De input hoeft geen meeting te zijn. Hetzelfde schema-first approach haalt commitments uit een standup-thread in Slack, uit een support-ticket queue, uit een klant's rammelende voice memo. Meetings zijn het voor de hand liggende doel omdat transcripten al bestaan. Ze zijn niet het enige markt.

De stack die je van transcript naar takenlijst brengt in één weekend

Hier is de hele pipeline voor versie nul:

1. Input : plak transcript of upload .txt / .vtt (nog geen live audio)
2. LLM-call : structured output, geforceerde JSON-schema
3. Opslag : Supabase-tabel of zelfs JSON-bestand voor v0
4. Output : markdown checklist + optionele webhook naar Linear/Notion

De extraction-prompt is het enige dat echte iteratie nodig heeft. Iets in deze richting haalt je 80% van de weg:

Extraheer actiepunten uit het transcript hieronder.
Retourneer JSON-array : [{taak, eigenaar, deadline, betrouwbaarheid}]
Regels:
- eigenaar = naam genoemd, anders "ongeassigneerd"
- deadline = expliciet moment alleen, anders null
- sla vage uitspraken over ("we zouden moeten nadenken over X")
- betrouwbaarheid : 0-1, gebaseerd op hoe expliciet de toezegging was

Wei-Chen Liao, die aan aanbevelingssystemen werkt bij Appier in Taipei, zei het na een soortgelijk side-project zo : "de extraction-kwaliteit stopt bij transcript-kwaliteit, niet model-kwaliteit. Besteed je eerste weekend aan input-cleaning, niet aan model-swapping."

Kosten op indie-schaal zijn bijna niets. Een uur meetingtranscript loopt 8.000 tot 12.000 tokens door een structured-output call. Bij huidige API-prijzen is dat fracties van een cent per meeting. De echte kosten zijn transcriptie, als je niet al begint met tekst die iemand heeft geëxporteerd.

Grijp niet naar het grootste model. Een klein, goedkoop model met geforceerde JSON-schema en een handvol few-shot voorbeelden haalt extraction-nauwkeurigheid dicht bij wat een flagship-model levert, bij een fractie van de latency en kosten. Spaar het grotere model-budget voor gevallen waar betrouwbaarheid laag aankomt en je wilt een tweede pass, niet voor elke call.

Waar de markt al leeft, en het is niet leeg

Voordat je bouwt, weet wat je tegenkomt. Een recente analyse van automated action-item tools plaatst per-seat pricing voor de categorie tussen €3,50 en ruwweg €35 per maand, verdeeld in twee kampen : extraction-only tools die taken in een document laten zitten, en full-loop tools die tickets meteen naar Jira, Linear of Asana pushen voordat het gesprek voorbij is.

Die scheiding is het nuttige deel. Het meeste van de drukke middenmoot is extraction-only : schone notities, geen routing. De tools die de laatste mijl automatiseren, die echt het ticket aanmaken, zijn zeldzamer en rekenen meer voor. Als je v1 scoped, dat is je gat : niemand wil nog een samenvatting. Ze willen dat de taak al ergens bestaat wanneer het gesprek afgelopen is.

TicNote is hier een nuttige referentiepunt, niet omdat je het in plaats van te bouwen zou moeten aanbevelen, maar omdat het laat zien wat "goed genoeg om geld voor te vragen" eruit ziet aan de kleine kant : het genereert echte bestanden, niet alleen een samenvatting in een chatvenster. Dat is de lat.

Valideer voordat je de extraction-prompt verder polijst dan iemand ooit vroeg. Post je v0 in twee of drie freelancer- of indie-hackercommunitys, bied aan om het op echt gesprek van iemand gratis uit te voeren, en kijk wat ze met de output doen. Als niemand je binnen een week een transcript stuurt nadat je het vraagt, dat is het signaal om niche te veranderen, niet het model.

Sla de real-time meeting bot over. Bouw eerst de async-versie

Elke tutorial die je vindt gaat ervan uit dat je een bot bouwt die live in het gesprek gaat, luistert, en halverwege naar Slack post. Sla dat over. Real-time betekent audiostroom, diarization (sprekers uit elkaar houden), en een bot die in het gesprek moet zitten zonder te laggen. Dat is geen weekend. Dat is de versie die side-projects in week drie doodmaakt.

De async-versie is dezelfde kernlogica minus de moeilijke delen : iemand plakt een transcript (uit Zoom's ingebouwde export, uit Otter, uit een Whisper-run op een opname) en krijgt dertig seconden later een takenlijst terug. Het is minder indrukwekkend in een demovideo. Het is ook de versie die je eigenlijk kunt afmaken.

Er is al een publieke n8n-template die AssemblyAI en GPT-4 ketent naar Google Sheets voor precies dit. Waard om te bestuderen voordat je een regel code schrijft, en waard om als eindproduct te negeren : het kiepet alles in een spreadsheet, wat niet werkt met meer dan een handvol gebruikers en geeft je niets waarvoor je geld kunt vragen.

Wat een freelancer in Amsterdam nodig heeft dat een Jira-plugin niet geeft

De generieke versie van deze tool is gebouwd voor teams al in Jira of Linear. Dat is een drukke, goed gefinancierde lane. Het ondervoorziene stuk is solo consultants en freelancers : het type persoon dat vijf klant-calls per week neemt en geen project-management tool heeft of wil.

Voor die persoon is de win niet ticket-routing. Het is een takenlijst die na het gesprek in WhatsApp of mail opduikt, getagd per klant, zonder iets in te stellen. Drie raw klant-calls per week slaat duizend enterprise-seats die je als solo builder zonder sales team nooit sluit.

Dat is een echte scopingbeslissing, geen nice-to-have : kies één delivery-channel (e-mail digest is het goedkoopst om te bouwen) en één smalle persona (freelancers, therapeuten, consultants, iedereen die per call factureert) voordat je een tweede integratie aanraakt.

De economie werkt anders per markt ook. Een €8/maand tool ziet er triviaal uit vanuit Nederland en ziet er elders uit als een echte maandelijkse rekening. Prijs naar de waarde van het uur dat je hun bespaart, niet naar wat Silicon Valley aanrekent.

Waarom de no-code versie breekt voordat de betaalde versie dat doet

De n8n-en-spreadsheet route is het eerlijke startpunt, maar het heeft een plafond : rate limits op de transcriptie API, een spreadsheet die onleesbaar wordt na tientallen rijen, nul plaats voor een login of abonnement. Het is een prototype, geen product.

De zet zodra je vraag valideert : vervang de spreadsheet door een echte tabel (Supabase werkt op deze schaal prima), voeg een login toe, en zet er een prijs op. Je hoeft de extraction-logica niet opnieuw op te bouwen. Je hoeft het opslaan van staat ergens stop te zetten waar niemand je doorheen kan betalen.

Waard om op te merken voordat je diep in de pipeline gaat : slechte audio produceert slechte transcripten, en slechte transcripten produceren slechte actiepunten ongeacht hoe goed je prompt is. Als je doelgebruikers op rommelige gesprekken zitten (slechte wifi, achtergrondlawaai, accenten over een verdeeld team), een ruisopräum-stap zoals Krisp vóór transcriptie bespaart je meer debugtijd dan de extraction-prompt ever tunen.

Ga je er geld voor vragen, of vouw je het in iets groters

Sla over als je hoopt dit wordt een standalone SaaS met venture-scale getallen. De categorie heeft lage prijs ($4 tot €8 per plaats is het realistische vloer zodra je op prijs concurreert) en de reuzen hebben kalender-integraties, mobiele apps en sales teams. Een solo dev wint die strijd niet frontaal.

Waard om te bouwen als je het als feature behandelt, niet als bedrijf : smoren het in een consultancy als value-add, ship het als €8/maand tool voor een enkele smalle niche die je al begrijpt, of gebruik het als het technische centerpiece van een portefeuillestuk dat je freelance LLM-integratiewerk oplevert. Alle drie zijn realistische resultaten voor een weekend build. "Otter.ai verslaan" is niet.

Als het extraction-gereedschap één onderdeel is van een grotere toolkit die je voor klanten assembleert, iets als Skywork is het bekijken waard voor de omliggende deliverables : het klant-gerichte samenvatting doc of one-pager dat je anders met de hand rond de ruwe takenlijst zou bouwen.

Wat we eigenlijk eerst zouden shippen

Een single-page app : plak een transcript, krijg een checklist, export naar e-mail of kopieer als markdown. Geen login voor v0. Geen integraties. Test het op je eigen calls gedurende twee weken voordat je het aan iemand anders toont, omdat de extraction-prompt echte transcripten nodig heeft om op te breken, niet synthetische testdata die je zelf schreef.

Als het je eigen calls overleeft zonder een voor de hand liggend commitment te missen, zet het voor vijf freelancers of consultants die je echt kent. Niet een Reddit-post, niet een Product Hunt launch. Vijf mensen van wie je de calls kunt bekijken wanneer de output fout is. Dat is de hele eerste maand.

Wat zouden je eerste tien transcripten eigenlijk nog nodig hebben dat dit niet dekt?