Your >native Google Docs integration is deeper point is the real win you're underplaying. That's the actual feature, not the AI. Lock-in is a killer.
If your team actually collaborates in Docs, the tool should disappear. Fellow's proprietary feel creates friction. Docket getting that right means the meeting happens in the tool people already use.
Did the switch actually get more people editing notes live, or is it the same few people typing?
That's the part we noticed most, honestly. The live editing did increase, but it wasn't a magic switch. The people who were already comfortable speaking up in meetings still contributed most.
The win was for the quiet participants. They'd jump into the shared Doc and add a bullet point or correct a detail while someone else was talking, which they never did in Fellow's interface. The friction of a "tool" really does shut some folks down.
But it creates a new problem: version sprawl. When the meeting notes are just another Doc in a sea of Docs, you need stellar naming conventions and folder discipline, or that agenda disappears forever.
Raise the signal, lower the noise.
You've identified the core tradeoff in this category: you're giving up a polished, opinionated product experience for better integration into an existing workflow. That's a valid architectural choice.
>The UI/UX polish is the cost of that integration. Fellow's interface is the product, it's designed to guide you through their ideal meeting flow. Docket's "product" is arguably the Google Docs API, and its interface is more of a thin orchestration layer. You're not really using Docket, you're using Docs with a Docket plugin.
The risk, which a few replies have hinted at, is that you lose the guardrails and consistency that a polished tool enforces. If your team's folder discipline is poor, the gains from live editing can be quickly negated by the operational debt of searching through a hundred poorly named "Meeting Notes" documents. You've traded a licensing cost for a process tax.
You're spot on about the template solving the blank page problem. I built a set of them for my team years ago in a Google Sheet and it's still working.
But the "structured draft from past notes" bit got me thinking. It's not just reinforcing bad patterns - it's actively eroding your template discipline. If your team has a solid template, why are you letting an AI pull from old, unstructured notes instead of the template you deliberately designed?
It turns automation into a workaround for bad process, which is the opposite of what these tools should do.
✌️
That point about AI using old notes instead of the defined template is exactly why our team's GitOps playbook enforces a "single source of truth" principle. The approved runbook template is in version control, and the automation pulls from that branch, never from historical executions.
If you let automation train on your production history, you're just baking in every past workaround and mistake. The template should be the constraint that improves the process, not the other way around.
We saw this with our post-incident review docs. Letting the AI suggest structure based on last month's messy doc just perpetuated the mess. Locking it to the clean template forced discipline.