User research interviews are the one meeting type where most AI notetakers actively hurt you: the moment a recording bot joins the call, your participant starts performing instead of talking. This guide compares six tools researchers actually use in 2026 - Earmark, Granola, Otter, Fathom, Fireflies, and Dovetail - and scores them on what research work demands: capture that stays out of the participant's way, synthesis across many sessions, and outputs that ship as insight summaries, PRDs, and tickets. It is written by the team at Earmark, so we have a horse in this race; we have kept the comparison factual and linked every claim so you can check our work.

Why user research breaks normal AI notetakers

A research interview is not a status meeting. The entire value of the session depends on the participant forgetting they are being studied, and a bot named "Notetaker.ai has joined the meeting" works directly against that. Researchers see it in the first five minutes: answers get shorter, hedges multiply, and the candid stories that make a session worth running never surface. Observer effects in interviews are well documented in research-methods literature, and a visible recording agent is the bluntest possible observer.

Consent is the second break point. With a bot, consent happens implicitly and awkwardly - the participant sees a third attendee and has to decide in real time whether to object to it. Good research practice is the opposite: you ask for consent before the session, in plain language, and you can explain exactly what is captured and where it goes. That explanation is much easier when the answer is "a transcript saved to my machine" than "audio processed and stored by a third-party cloud service under a policy neither of us has read."

The third break point is what happens after the call. General-purpose notetakers produce a summary with action items, which is the wrong artifact for research. A researcher does not need "Sarah will follow up with the team" - they need verbatim quotes with context, patterns that hold across fifteen sessions, and a path from raw conversation to a decision-ready document. Most meeting tools summarize one meeting at a time and stop there.

What researchers actually need

Strip away the feature lists and research work makes five demands of a meeting tool.

1. Unobtrusive capture. No bot in the participant list, and ideally nothing the participant sees at all. The tool should work the same way for a Zoom call, a Google Meet session, a Teams interview, or an in-person conversation, because discovery work happens in all four.

2. Verbatim fidelity. Summaries are lossy by design. Research needs the actual transcript, with speaker attribution, so a quote can be traced back to its context months later.

3. Cross-session synthesis. The unit of insight is not one interview, it is the pattern across a sprint of them. The tool should let you ask questions over a batch of sessions, not just summarize each one in isolation.

4. Outputs that ship. Research only matters when it changes what gets built. The shortest path from interviews to impact is a tool that drafts the insight summary, the PRD section, and the tickets, instead of leaving you with fifteen summaries to reconcile by hand.

5. Data you control. Participant conversations are sensitive by default. Where transcripts live, how long they are retained, and who can access them should be answers you can give a participant - and your own IT and legal teams - in one sentence.

The comparison: six tools, scored for research work

Earmark and Granola capture without a bot; Otter, Fathom, and Fireflies are built around one; Dovetail is not a notetaker at all but the repository many teams pair with one. Here is how they line up against the five demands above. Capability notes are accurate as of October 2026; pricing changes often, so check each vendor's site.

The per-tool verdicts, briefly. Otter, Fathom, and Fireflies are capable general-purpose notetakers, and if your research sessions are a small slice of a sales-heavy calendar they may already be in your stack. But all three default to a visible bot, which is precisely the thing a research interview cannot afford, and their summaries flatten the verbatim detail research depends on. Granola solved the capture problem elegantly and deserves its reputation; its limits for research are on the back end - notes and summaries live in Granola's cloud, and there is no native path from a batch of sessions to a PRD or a ticket queue. Dovetail is the strongest pure synthesis environment and makes sense for dedicated research teams with budget for a repository, but it still needs something upstream to capture the conversation.

Earmark is the only tool in this set built end to end for the research-to-delivery pipeline: botless capture with nothing visible to the participant, transcripts written as plain markdown to your own machine, and generation of the documents that come after research - insight summaries, PRD sections, Linear and Jira tickets, and decision logs. The honest tradeoff: it is Mac-first, and if you want a hosted searchable archive for a large team, a repository like Dovetail still has a place downstream.

The Earmark workflow: a real discovery sprint, before, during, and after

Last week our own team ran fifteen research and feedback sessions in five working days - product managers, founders, and product coaches across legal tech, health tech, ed tech, and biotech - all on the question of how teams move from conversation to shipped product. Here is what that looked like with Earmark doing the capture and the paperwork.

Before: each session gets a 30-minute slot and a short discussion guide. Because there is no bot to configure, invite, or explain, prep is just the guide and the calendar link. The consent ask happens in the invitation email, in one sentence: the session will be transcribed to a local file on the interviewer's machine, shared with no third party.

During: the interviewer opens Earmark and talks. The participant sees one human on the call and nothing else - no bot joining, no banner, no third tile. Earmark captures system audio on-device and writes the transcript as a markdown file to a local folder as the session runs. Back-to-back sessions need no cleanup between them; the next call simply becomes the next file.

After: this is where the week of interviews becomes a product decision. At the end of the sprint, the full set of transcripts is sitting in one folder as plain markdown - readable, searchable, and owned. Earmark batch-synthesizes across them: recurring themes with supporting quotes traced to their source sessions, a drafted PRD section for the strongest pattern, and tickets pushed to Linear so the findings land in the same queue the engineers already work from. What used to be a week of post-sprint synthesis in spreadsheets becomes an afternoon of reviewing and editing drafts.

The quiet advantage of local markdown files deserves a sentence of its own: your research archive is not trapped in a vendor's database. You can grep it, feed it to your own AI tools, version it, or walk away from Earmark entirely and keep every word.

Consent and participant data, done properly

Botless does not mean covert. If anything, removing the bot raises the bar for doing consent well, because the participant will not see a visual reminder that capture is happening. Our recommended practice, and the one we use ourselves: state the transcription plainly in the session invitation, repeat it verbally at the start of the call, and record the participant's agreement in the transcript itself. Many jurisdictions require all-party consent for recording conversations, so treat explicit consent as mandatory everywhere rather than tracking legal minimums by region.

Local-first storage then makes the rest of the privacy conversation short. When a participant asks where the recording goes, the answer is a folder on your machine, not a vendor's retention policy. When they ask you to delete their session, you delete a file and it is gone - no support ticket, no 30-day backup window, no copies in a training corpus. When your own legal or IT team asks the same questions, the answers are identical, which is why this architecture tends to clear security review in days rather than quarters.

Frequently asked questions

Does Earmark work for in-person user interviews? Yes. Because capture is on-device rather than tied to a meeting platform's bot API, an in-person session is captured the same way as a Zoom, Google Meet, or Teams call: open Earmark, run the conversation, get a local markdown transcript.

Does the participant see anything during the session? No. There is no bot in the participant list, no banner, and no third attendee. That is exactly why your consent process has to carry the disclosure - see the section above.

Where do transcripts live, and who can access them? Transcripts are written as markdown files to a folder on your own machine. They are yours: readable in any text editor, searchable with any tool, and deletable by you alone.

Can it really produce PRDs and tickets, or just summaries? Deliverables are the point of the product. Earmark drafts PRD sections and decision logs from one session or a batch of them, and pushes tickets to Linear and Jira so findings land in the queue your engineers already use.

How does it synthesize across a whole sprint of interviews? Because every session is a markdown file in the same library, Earmark can run synthesis across any set of them - a week, a project, or every session with a given segment - and return themes with quotes linked back to the source sessions.

What does it cost? Pricing is on tryearmark.com, including a startup program with three months free.

Sources

Comparison notes draw on vendor documentation and independent 2026 roundups: TechRepublic's AI note taker review, ScreenApp's notetaker comparison, tl;dv's Granola review, and the product pages for Otter, Fathom, Fireflies, Granola, and Dovetail. Capability notes as of October 7, 2026.