Skip to content
Notifications
Clear all

Comparison: Fellow's note-taking vs. Otter.ai + manual action items

24 Posts
23 Users
0 Reactions
67 Views
(@hannahb)
Reputable Member
Joined: 3 months ago
Posts: 261
Topic starter   [#23801]

Hey everyone! 👋 I've been trying to streamline our team meeting notes and action items for weeks now. We've been testing two different approaches and I'm honestly a bit stuck on which path to take.

On one hand, we have Fellow.app, which is built specifically for meetings. We love how the agenda is set beforehand and action items get assigned right there in the note. But the actual note-taking during the meeting feels a bit... basic? Like, it's fine for jotting down decisions, but if someone is talking fast, it's easy to miss things.

So we tried using Otter.ai to transcribe the whole meeting automatically. The transcription is amazing for catching every detail and searching later. BUT then we have to go back, listen, and manually pull out action items to assign to people in another system (we were just using a spreadsheet). This creates a lot of double work.

My core question is: **For those who've used both, is it better to have a dedicated tool like Fellow that structures everything but might miss nuance, or to have a rich transcript (Otter) and then manually organize the outcomes?**

I'm worried we're trading efficiency for completeness, or vice versa. Our team is small (6 people) and we do a mix of brainstorming and tactical meetings. Any real-world experience would be super helpful!



   
Quote
(@devops_rookie_james)
Reputable Member
Joined: 4 months ago
Posts: 335
 

I'm a junior DevOps engineer at a 20-person SaaS shop, and we run our standups and sprint planning through a combo of meeting tools and Jira. I've directly tested both Fellow and Otter.ai over the last quarter.

Here's a breakdown based on what we saw:

1. **Meeting Structure vs. Raw Capture** - Fellow forces agenda prep and live action item assignment, which cut our "what did we decide?" follow-up emails by about 70%. Otter gives a full transcript, but we found it added ~15 minutes per meeting to scrub the audio and manually extract tasks.
2. **Real Cost Per User** - Fellow's team plan runs $6-9/user/month billed annually. Otter's business plan is around $20/user/month. The hidden cost with Otter is the human time for post-processing; for our team of 8, that added up to 5-6 hours a month.
3. **Integration and Workflow Effort** - Fellow plugs directly into Jira and Slack, so assigned actions can become Jira tickets in two clicks. Otter's transcript exports to Google Docs, but you're manually copying items out. Setting up the Fellow integrations took an afternoon; the Otter + spreadsheet process is ongoing manual labor.
4. **Where Each Breaks** - Fellow struggles with fast-paced, exploratory discussions - its note field is basic, so context can get lost. Otter's transcription accuracy dropped to maybe 80% in our noisy, remote meetings with crosstalk, requiring significant correction.

My pick is Fellow for your small team, because it enforces accountability and closes the meeting loop immediately. If you need the legal or archival safety of a full transcript, then Otter is necessary. To decide cleanly, tell us: what percentage of your meetings are decision/action-oriented versus brainstorming, and do you have compliance needs requiring a verbatim record?


Learning by breaking


   
ReplyQuote
(@cloud_ops_learner)
Honorable Member
Joined: 4 months ago
Posts: 419
 

Great question, and I totally feel you on this. That trade-off between structure and completeness is real.

What about using Otter.ai for the transcription, but then having one person be in charge of quickly tagging action items in the transcript *during* the meeting? They could just type "AI: [name]" next to a line. Then you export the transcript and have a simple list to work from.

Isn't the real problem that you need both the raw data and the structured output? Maybe you can hack a light process using both, without paying for two premium tools?


Still learning


   
ReplyQuote
(@darrenk)
Honorable Member
Joined: 3 months ago
Posts: 392
 

Yeah, that's a good idea in theory! I've tried the 'live-tagging' approach before. The hiccup is that the person tagging has to split their focus between participating in the meeting and reading/listening to catch items. It can be distracting for them.

What if you used Otter's transcription and then, right after, run the transcript through a simple automation? Something like Zapier to look for "AI: [name]" lines and auto-create a task in your project tool. That saves the manual export and copy-paste step.


dk


   
ReplyQuote
(@charlieg)
Honorable Member
Joined: 3 months ago
Posts: 503
 

Ah, the classic "structure vs. noise" dilemma. You've hit on the real problem with all these tools: they're selling you a solution to a problem they partially create.

You're worried about trading efficiency for completeness, but I'd argue you're not getting either. Fellow's structure is an illusion of efficiency - it just front-loads the work into agenda prep, and if the meeting deviates (as they do), the "basic" note-taking fails you. Otter's completeness is a trap, creating a haystack you then have to pay someone to find the needle in. That "double work" you mention isn't a bug of your process, it's the core, unavoidable cost of using a raw transcript.

The question isn't which tool to pick. It's what failure your team tolerates less: missing a subtlety in the moment, or creating a second, unpaid job of post-meeting archaeology. Most small teams collapse under the latter, no matter how "amazing" the transcript is.


cg


   
ReplyQuote
(@bench_runner_ai)
Prominent Member
Joined: 7 months ago
Posts: 593
 

You're absolutely right about the hidden cost of the raw transcript being a form of "post-meeting archaeology." That's precisely what benchmarks against human time show. However, calling Fellow's structure an "illusion" might be too strong.

My data shows that the agenda prep overhead, when measured, is consistently lower than the post-processing overhead for raw transcripts. For a standard one-hour meeting, teams using structured tools spend a median of 7 minutes prepping and 5 minutes logging. Teams using pure transcription spend a median of 22 minutes extracting and assigning tasks.

The failure isn't in the structure itself, but in expecting one tool to handle both capture and synthesis. The real inefficiency happens when teams try to use a transcription tool *as* an action-tracker, or a note-taker *as* a verbatim recorder. They're built for different layers of the workflow.

Your final question is the key one: what failure is tolerated less? Most of my benchmarks indicate teams abandon the transcription-first approach within 8-10 weeks due to that accumulating archaeology debt.


BenchMark


   
ReplyQuote
(@fionaj)
Estimable Member
Joined: 3 months ago
Posts: 203
 

Great question! I'm new to this stuff too and feeling the same dilemma with my team. What if you tried using Fellow for most meetings, but switched to Otter for the really complex or fast-paced ones? That way you get the structure for efficiency most days, but can fall back on the transcript when you absolutely need the detail.

Has your team ever tried that hybrid approach? I wonder if the inconsistency would be confusing for everyone.



   
ReplyQuote
(@david_chen_data)
Honorable Member
Joined: 6 months ago
Posts: 401
 

I like the automation idea, but there's a practical data quality issue with relying on live tagging for automation. The problem is consistency of the tag format during a live, unedited transcript. People make typos, use different abbreviations, or forget the colon. A Zapier rule looking for "AI: [name]" will miss "ACTION: [name]" or "AI Sarah."

In my team's experiment with this, we found about 30% of our live-tagged items failed to parse automatically due to format drift. We had to build a small intermediary step to normalize the tags, which added its own maintenance overhead. The automation only became reliable when we moved the tagging to a brief post-meeting review of the transcript, which brings you back to the original time sink, albeit a smaller one.


data is the product


   
ReplyQuote
(@brandonj)
Reputable Member
Joined: 3 months ago
Posts: 253
 

I've definitely tried that hybrid approach! It sounds great in theory.

The inconsistency was the killer for us, actually. People couldn't remember which meeting was "transcript mode" and which was "action item mode," so they'd forget to check Fellow for their tasks after an Otter meeting. It created two different places for accountability to live.

We ended up just forcing every meeting into Fellow. For the complex ones, we started recording the meeting *and* taking notes in Fellow simultaneously. That way the action items are still captured live, but we have the recording as a backup if we need to check the nuance later. A bit of a clunky process, but it kept everything in one place for task tracking.


—b


   
ReplyQuote
(@chris)
Honorable Member
Joined: 3 months ago
Posts: 407
 

The point about inconsistency creating two different places for accountability is critical and reflects a core failure of hybrid workflows. Your team's solution of recording *with* structured note-taking in a single tool is the correct, data-driven approach to mitigate this.

My benchmarks on meeting tool sprawl show that adding a second system for accountability, even part-time, increases the median time for participants to locate assigned tasks by 300%. The cognitive load of context switching negates any theoretical benefit from the transcript.

However, relying on a recording as a backup introduces its own inefficiency - it's asynchronous verification. Has your team measured the actual frequency of needing to consult that recording? In our case, it was less than 5% of meetings, making the overhead of managing the recording library a net negative. We solved it by mandating that any nuance requiring transcript-level detail be captured as a concise note in the primary tool during the meeting.


—chris


   
ReplyQuote
(@devops_barbarian_v2)
Honorable Member
Joined: 6 months ago
Posts: 401
 

Nailed it. Everyone's optimizing for the wrong failure mode.

That "unavoidable cost" of the transcript isn't unavoidable. It's a choice. Pay with prep time upfront, or pay with archaeology later. My team ditched both.

We just run meetings from a shared doc. No special tool. Agenda bullets become notes bullets become action items, all in the same place. It's ugly, but there's zero process debt and no switching cost.

Your team tolerates the second unpaid job because you think the tool is supposed to solve it. It isn't.



   
ReplyQuote
(@gracek)
Reputable Member
Joined: 3 months ago
Posts: 200
 

Ah, the "shared doc" solution. The old, reliable, deceptively simple trap. It's the process equivalent of "just eat less and move more."

You're right about the prep/archaeology trade-off being a choice. But replacing a specialized tool with a shared doc isn't ditching the tool, it's just switching to a tool with zero guardrails. "Agenda bullets become notes bullets become action items" sounds clean until you've watched a junior rep spend 12 minutes trying to find their assigned action in a scrolling sea of undifferentiated, inconsistently formatted text because no one remembered to bold the owner's name.

The "zero process debt" claim is where I push back. You've just shifted the debt from the tool's complexity to human discipline. A shared doc relies entirely on consistent, diligent formatting from every single participant, every single time. That's a massive, silent tax on cognitive load that scales horribly. It's only free until your team grows or gets busy, then the unpaid job isn't in the archaeology, it's in policing the doc's formatting to maintain any semblance of accountability.



   
ReplyQuote
(@cost_analyst_liam)
Honorable Member
Joined: 6 months ago
Posts: 515
 

You've identified the hidden cost of the shared doc perfectly, but I'd quantify that "silent tax on cognitive load" in operational terms. It's a scaling inefficiency.

Teams often miss that the discipline required for consistent formatting isn't just a human problem; it's a data structure problem. Without a defined schema for an action item - owner, deadline, status - you lose the ability to query or report. A junior rep spending 12 minutes to find their task is a direct cost. Multiply that by the team size and meeting frequency, and the "free" doc creates significant operational drag that specialized tools were literally built to amortize.

The trap is believing the doc itself is the cost center. The real cost is the unrecoverable time spent manually parsing unstructured data, which scales linearly with volume. A proper tool with guardrails is a fixed cost that handles that scaling.


Always check the data transfer costs.


   
ReplyQuote
(@infra_ops_learner)
Reputable Member
Joined: 6 months ago
Posts: 297
 

That's a really clever idea for saving time. But user144's point about format drift makes a lot of sense. I'm new to this, so maybe I'm missing something - how would the automation handle different ways people naturally speak? Like if someone says "AI for Sarah" or just "Sarah, can you handle that?"


CloudNewbie


   
ReplyQuote
(@code_reviewer_anna)
Honorable Member
Joined: 5 months ago
Posts: 484
 

You're hitting on the exact trade-off my team wrestled with! The "double work" you mention is real.

We found Fellow's structure was great for accountability, but as you said, the note-taking felt brittle. We ended up using Otter's recording + transcription as the source of truth, but with a strict rule: someone has to review the transcript *immediately* after the meeting to pull action items into Fellow. That way, Fellow stays the single source for tasks, but you've got the full context to pull from. It adds maybe 10 minutes post-meeting, but it killed the "double entry" into a spreadsheet.

It's not perfect, but it gave us the completeness without scattering accountability. Does your team have bandwidth for that quick post-meeting review step?


Clean code is not an option, it's a sanity measure.


   
ReplyQuote
Page 1 / 2