Okay, so I've been bouncing between Otter, Fireflies, and Gong for a while now, and Otter's automation is solid. But here's my eternal gripe: the auto-generated file names are a mess in my cloud storage. "Meeting with John 2024-10-27" is fine until you have six Johns and need to search by project or client code.
I've finally pieced together a method to enforce a consistent naming convention. It's not native in Otter, so you need to use a middleman automation tool. I use Zapier, but Make or even Power Automate would work.
The core workflow is:
* Otter.ai triggers the zap when a new note is created.
* You use a Formatter step to parse the meeting title/date/participants from Otter.
* You then build your custom filename string using that data.
* Finally, you use a Google Drive or Dropbox step to rename the file.
My naming formula looks like this: `[ClientCode]_[YYYY-MM-DD]_[MeetingType]_Otter.md`
To make this work, you **have to be disciplined with the Otter meeting title** going in. I set mine as `ClientCode - Brief Description`. The zap then splits that title to extract the code.
The real trick is handling the Otter-to-Drive sync. You can't rename *within* Otter's own sync. You have to:
1. Turn off direct Otter to Drive sync.
2. Let Otter send the note to the automation app.
3. Have the app create/rename the file in Drive.
It adds a slight delay, but having all my transcripts uniformly named for reporting and linking to my CRM (currently testing HubSpot Sales Hub again, by the way) is worth it. Has anyone else tried a similar hack? Curious if you found a way to include the first speaker's name dynamically.
Still looking for the perfect one
Love that you've worked this out with Zapier. The discipline on the meeting title is key - it's a classic case of garbage in, garbage out.
One caveat I've run into: if someone in your team doesn't follow the title convention, the whole zap breaks for that file. I ended up adding a filter step before the formatter to check for the hyphen pattern, routing non-conforming files to an "unprocessed" folder for manual review.
Also, for anyone reading, this kind of workaround can get brittle across Otter updates. I'd recommend setting a quarterly reminder to test the zap, especially if Otter tweaks its field names in the API.
Trust the data, not the demo.
Quarterly reminder? That's optimistic. The API field name I was using changed twice last year without a version bump or clear changelog. You're not just testing the zap, you're playing whack-a-mole.
The "unprocessed" folder is a sensible band-aid, but it becomes a policy black hole. In my experience, anything that goes there for manual review never gets reviewed. It just becomes a dusty archive of process failures, which defeats the point of automation.
There's a deeper issue: this whole approach reinforces the idea that a meeting title should be a structured data field, which it's not. It's a free-text note. Any system that treats it otherwise is fundamentally brittle. We're all just building a rickety shed on top of a swamp.
You're spot on about the unprocessed folder becoming a black hole. I've seen it happen with our Terraform state files - anything that needs manual intervention just accumulates until it causes a real problem.
But I actually disagree that a meeting title can't be a structured field. We enforce a strict format (clientcode-projectname-type) in our calendar invites, and it works because it's a team-wide policy with real buy-in. The brittleness isn't from expecting structure, it's from relying on an external API you don't control.
That's why my current stack uses a local script that parses the Otter export .zip directly. No API, no whack-a-mole. If their export format changes, I know the second my pipeline breaks.
K8s enthusiast
Nice work putting this together! You've hit on the core challenge with any external automation: the initial discipline on the meeting title. It's the linchpin.
You mentioned the trick is handling the Otter-to-Drive sync. This is where a lot of people stumble - if the rename happens before Otter's native sync finishes, you can end up with conflicts or duplicate files. A short delay in your Zap can be a lifesaver here.
Also, have you considered adding the meeting ID from Otter as a failsafe? Something like `[ClientCode]_[Date]_[OtterID]`. That way, even if two meetings have identical metadata, you still have a unique handle.