How to turn Notion AI meeting notes into trackable feature requests
You promote them yourself, one relation property at a time. Notion's AI Meeting Notes turns a call transcript into an organized summary and a list of action items, and if you used @ mentions while taking notes, it tags the right teammate on each one automatically. What it doesn't do is decide that an action item is a feature request, dedupe it against the version another rep logged last week, or hand it to Linear. That's a page with a checklist on it, sitting wherever the meeting happened to get filed.
Notion's own guidance is explicit about the next step being manual: "Keeping your meeting notes in a Notion database lets you easily connect them to related projects, tasks, or people using Relation and Rollup properties." You build that connection yourself, once per note, and only if you remember to.
What the feature gives you
To be fair to it, the parts that exist work as advertised:
- Transcription and summarization across whatever call tool you're on. Notion's product page lists compatibility with the major video conferencing platforms, and the summary is generated from both the transcript and any notes you typed live.
- Action items with owners tagged. Type
@teaganunder an action item during the call, and it carries into the summary tab with Teagan already assigned. - A path into a database, if you build it. The meeting notes template ships with a section for connecting the page to a projects or tasks database via a relation property, so a note isn't necessarily a dead end. It's a dead end unless someone takes that extra step.
None of that requires the action items to already be deduplicated, or requires the resulting record to be structured enough to count. A checklist item and a database row that can be filtered, grouped, and rolled up into a count are different objects, and Meeting Notes only gets you the first one automatically.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionThe two calls Benedetta almost missed
Benedetta Marrone runs customer success at Cutwater, which sells incident-alerting tooling to fintech engineering teams. She sits in on renewal and onboarding calls and lets Notion's AI Meeting Notes handle the transcript so she can listen instead of typing.
Nine days apart, two different calls produced action items that read like separate requests:
Call 1 summary: "Customer wants alerts to route to a specific on-call engineer, not the whole channel."
Call 2 summary (nine days later): "Ask if we can assign an alert to one person instead of pinging the whole team."
Benedetta tagged herself on both and moved on. "They read like two different requests until you actually sit with them," she said. "One says 'route to a specific engineer,' the other says 'assign to one person.' I only caught that they were the same ask because I was scanning both notes pages back to back before a roadmap call, and even then I had to reread the second one twice to be sure."
Both action items were accurate summaries of what each customer said. Neither Notion nor the transcript had any way to know a third customer had asked for the identical thing in a support ticket the month before, because that ticket lived in Zendesk, not in a Notion meeting notes page. Benedetta ended up with one Linear issue instead of two, and only because she happened to be the one person who sat in on both calls and did the rereading herself.
Where the native path stops working
Past a handful of calls a week, three things break down, in this order:
- Dedupe depends on one person's memory. Notion has no mechanism for noticing that "route to a specific engineer" and "assign to one person" describe the same feature. Catching it requires a human to reread two notes pages side by side, and that gets less reliable every time another call gets added to the pile.
- Promotion to a tracker is a manual, per-page step. The relation property Notion recommends connects one note to one database row. Someone still has to open the note, decide the action item is worth tracking, and build that link. Skip it, and the request lives as an unchecked checkbox on a page nobody reopens.
- The company and person behind the ask don't travel with it. A relation property can point at a task, but it doesn't automatically carry which account said this, how many times, or whether it's the same account that asked before. That context has to be typed in separately, if it gets typed in at all.
Past a few calls a week, per-page manual promotion is the bottleneck, not the transcript quality. Cutwater's calls were accurate. What was missing was something reading across all of them at once.
The workaround teams try before Modem
Before reaching for a dedicated layer, most teams try to patch the gap with more Notion. Two variations show up a lot:
- A shared "requests" database that every note links back to, with the relation property from earlier pointed at one central table instead of a scattered set of task pages. This helps with visibility, since at least everything lands in one place, but it does nothing for dedupe. Cutwater's two alert-routing requests would still sit as two separate rows in that same database, just next to each other instead of in different notes.
- A Notion AI prompt run over the requests database periodically, asking it to summarize themes. This is a real capability, not a workaround that only sort of works, but it inherits the same limit any summarizer has: it reports what the rows say, and if two rows describe one request in different words, it reports two things, not one thing said twice.
Both are worth doing regardless of what else you add, because a central database beats a pile of orphaned notes even without dedupe. Neither one closes the gap on its own.
Where Modem picks it up
That's the layer Modem is built to be. Rather than relying on someone to reread meeting notes pages looking for repeats, Modem's Notion integration reads the pages and databases you connect, alongside calls, support tickets, and Slack, and matches differently worded mentions of the same ask, "route to a specific engineer" and "assign to one person," into one counted topic with every requester and account attached. Once a request crosses your threshold, Modem can file the Linear issue directly, carrying the quotes and the requester list with it, and write the resulting topic back into Notion as a page or database row, with your approval rather than silently. The dedupe step Benedetta did by memory becomes the thing the system checks by default. We build Modem, so weigh that recommendation with that in mind; for a couple of calls a week, catching repeats yourself the way Benedetta did is still a perfectly workable system.
If Notion is where you're already tracking requests, our guide on building a feature request tracker in Notion covers the database schema worth using once requests land there. And for the wider version of "how do I know this is the same context I already have," see what a customer context graph is.
The smallest version you can start this week
Add one habit before AI Meeting Notes gets any further out of hand: at the end of each call, before closing the note, ask "have I heard this exact ask before?" and check it against your last few notes pages if the answer isn't obviously no. It won't scale past a handful of calls a week, but it's the manual version of the thing that eventually needs to run automatically, and it will catch the Benedetta-and-Cutwater case before it becomes two tracked issues instead of one.
