Our team has been using MeetGeek for about six months now, primarily to capture and summarize our weekly architecture syncs. While the automatic transcripts and AI summaries are great, we found we weren't consistently extracting actionable technical follow-ups. To solve this, we built a simple post-meeting review template in Notion that we fill using MeetGeek's output. It's turned meeting recaps from a passive read into an active workflow.
Here's the basic template structure we follow for each recorded meeting:
```markdown
## Meeting: [Topic - Date]
**MeetGeek Link:** [Link to recording & summary]
**Key Attendees:** [Names]
### Summary of Decisions
* [Bullet point from MeetGeek's "Key Points"]
* [Bullet point from MeetGeek's "Key Points"]
* [Any additional decisions clarified post-meeting]
### Action Items (Owner & Due Date)
1. [Action] - @Owner (YYYY-MM-DD)
2. [Action] - @Owner (YYYY-MM-DD)
### Technical Debts & Questions Raised
* [Architecture question to research]
* [Code refactor noted]
* [Documentation gap identified]
### Reference & Links
* [Any PRs, diagrams, or docs mentioned]
```
We populate the "Summary of Decisions" directly from MeetGeek's AI summary to ensure alignment. The real value add is the "Technical Debts & Questions" section. We scan the transcript for phrases like "we should fix," "later," or "why does it..." and log them there. This prevents good ideas from getting lost in the chat.
The process takes about 10 minutes post-meeting for the meeting lead. We've found it especially useful for:
* **Onboarding:** New engineers can review past meeting templates to understand decision history.
* **Cost Discussions:** When we talk about AWS service changes, we log the estimated cost impact here for future validation.
* **Sprint Planning:** Action items feed directly into our project tracker.
It’s a lightweight system, but it bridges the gap between meeting capture and project management. I'm curious—how are others structuring their post-MeetGeek workflows? Anyone using the API to automate parts of this?
-- Amy
Cloud cost nerd. No, I don't use Reserved Instances.
Good structure. We added an 'Architecture Context' section to ours.
Key metrics we track:
* Decision-to-action lag time (median 2.4 days)
* % of action items linked to a project ticket (target 90%)
* Recurring questions count
This surfaces which meetings generate real work versus just talk.
Prove it with a benchmark.
I really like the addition of metrics. Quantifying the output of meetings is a crucial step most teams skip. The "decision-to-action lag time" is particularly telling, though I've found its utility depends heavily on the meeting type.
For our design review meetings, a short lag is good. For our more exploratory "future tech" syncs, a longer lag is actually preferable, as it indicates we're researching and validating before committing to code. It might be useful to segment that median by meeting category or tag the action items themselves with an expected latency (e.g., "immediate," "this-sprint," "backlog").
Your "recurring questions count" metric is gold. It often points to either a documentation gap or a process that isn't being followed. We started tagging those in our template, which led us to create three new runbooks last quarter.
throughput first
Segmentation is the key insight. We started categorizing meetings as "execution" vs "exploration" and track lag separately. For exploration meetings, we actually added a "research spike created" boolean field. If an action item from that meeting type doesn't have a linked research ticket within a week, it gets flagged. This prevents those speculative discussions from just evaporating.
Tagging recurring questions by topic in the template allowed us to generate a simple report. We found 70% of them clustered around three internal API contracts. That wasn't a documentation gap, it was an interface design problem. The metrics prompted a refactor we'd been postponing.
benchmark or bust