Home / Workflows / Automatic Meeting Notes
Workflow

Automatic meeting minutes that file themselves as project notes

The goal is not a nicer write-up, and it is not automatic meeting minutes in the old sense either. It is a meeting that ends with the right project file already updated, and nothing left for you to type up later.

Minutes, as most people mean the word, are a record of what was said, written up afterwards by whoever drew the short straw. Automatic meeting minutes tools have mostly automated that write-up and stopped there. Most "AI meeting notes" tools give you a cleaner transcript and a bullet-point summary, then leave both sitting in a separate app, disconnected from the project the meeting was actually about. That is not filing. Filing means the note ends up in the same place as every other fact about that client, deal, or decision, dated, so you can find it again in six months without remembering which tool you used that week.

Automatic meeting notes that file themselves do one more thing than a transcription tool: they decide where the note belongs, and they update the thing it belongs to, not just a running log of meetings.

Automatic meeting minutes vs. what this actually does

Search for "automatic meeting minutes" and most results are transcription or summary tools: they turn a recording into a clean write-up faster than a person could. That solves the writing problem. It does not solve the filing problem, which is the one that actually costs time — minutes that live in a separate app from the project they're about get read once and then never found again. This workflow treats the minutes as an input, not the output: the write-up still happens, but it lands inside the project it belongs to, dated, next to every other fact about that client or decision.

What triggers it

A recording finishes, or you paste a transcript in. That is the only input required. No template to fill in beforehand, no tagging the meeting by project before it starts.

What the system does

1. Reads the transcript, not just the last five minutes

It goes through the full transcript rather than skimming for a summary, because the decision that matters is often made in the middle of the call, not the recap at the end.

2. Matches it to the right project or person

It checks the transcript against your existing project files and contact records and works out which one this meeting belongs to, the same way you would recognize it from the names and the subject.

3. Extracts decisions, open questions and action items, not a transcript dump

Nobody re-reads a full transcript. The useful output is what changed: what got decided, what is still unresolved, and what someone now owes someone else, matching the shape covered in turning a meeting transcript into action items.

4. Files the summary and updates the project

The dated summary lands in the right project's folder, the project's status and decision log get updated if anything changed, and any follow-up implied by the call gets drafted, never sent, as covered in the follow-up tracking workflow.

The test that matters. Two weeks after a call, can you find what was decided without remembering which meeting it was in? If the answer is no, you have a transcript archive, not a filed note.

Take a concrete case: a forty-minute client call covers three topics, a scope change gets agreed to in passing around minute twelve, and the rest of the call is logistics. A transcription tool gives you forty minutes of text back. This workflow gives you one line: the scope changed, what it changed to, filed under that client, with the logistics either dropped or held as a separate note if they matter. The forty minutes still exists if you ever need to go back to it, but you are not the one who has to read it to find the part that mattered.

What lands in front of you

A dated meeting summary attached to the correct project, an updated status line if the meeting changed anything material, a short list of action items, and draft follow-ups if the call implied any, plus a flag on anything the system was not confident about matching.

What you still decide

Whether the drafted follow-ups actually get sent, whether a note the system filed under one project really belongs there, and which of the flagged "maybe decisions" are actually settled. The system narrows a full transcript down to a short list you can clear in a minute or two; it does not act on any of it without you.

Where this fits for consultants and anyone running back-to-back calls

This workflow earns its keep fastest for anyone running many client or partner calls in a week, where the cost of a note that never gets filed is a dropped thread three weeks later. See Claude Code for consultants for how the same mechanics apply across a whole client roster, and capturing notes automatically from email, meetings and transcripts for the wider capture pattern this workflow is one piece of.

It also changes what a back-to-back call day actually feels like. Instead of ending the day with four transcripts to process, you end it with four projects already updated, and the work that is left is reviewing a short queue rather than starting from a blank page for each one. The compounding effect shows up after a few weeks, once enough of your project history has been filed this way that a new call arrives with real context already attached to it.

End a day of calls with the projects already updated

A note can only file itself if there is somewhere to file it. The book builds those project files in an hour, in plain text, and points the transcript at them.

Get the book
Skip the build, keep the notes

Watch a call file itself afterward

The same workflow, built for a company: it reads the calls you were already having and keeps every client file current. Try the demo.

See the demo