Turning meeting transcripts into SOPs with Claude, in twenty minutes

The problem with "we should document this"

Every company with fewer than 50 people has a list of processes living in someone's head. The founder's. The operations manager's. The senior engineer's. When that person goes on holiday, something breaks.

Everyone agrees the fix is documentation. Nobody writes it. Why? Because writing an SOP from scratch requires stopping the work, remembering the steps, ordering them properly, and producing a clean document — all while the work is still happening around you.

The shortcut: reverse-engineer from meetings

You already have the raw material. Every time you explain a process to a new hire, a client, or a teammate in a call, you're producing the content of an SOP in spoken form. Record the call. Transcribe it (Fathom, Otter, Granola — all fine). Hand Claude the transcript and say:

Below is a transcript of me explaining [process name]. Turn this into a clean SOP. Format: purpose (one line), when to use, inputs needed, steps in order, outputs, edge cases mentioned, open questions. Quote me directly where the language is clear. Flag anywhere you had to guess.

Claude reads thirty minutes of you talking and produces a three-page document. Usually 80% right. You edit the other 20% in ten minutes.

An example

Last month a client of ours was explaining how they onboard a new property manager onto their platform. The call was 42 minutes. Claude produced:

• Purpose (2 lines)
• Inputs needed (9 items)
• Steps 1 through 14, in order
• Three edge cases the founder had mentioned in passing
• Two open questions — things Claude flagged because the founder had contradicted himself

The founder edited it in 15 minutes. Their new hire used it the next day. No one argued about "the right way to do it" for the next three months.

The discipline that matters

Two rules make this actually work.

Rule 1 — Record the explanation once, don't re-record. If you try to "record a clean version" for the SOP, you'll produce a worse one than your normal explanation. Your real explanation has the edge cases and caveats that matter. Use the real one.

Rule 2 — The SOP is a draft forever. Every time someone runs into an edge case not in the doc, they add it. Claude helps: paste the new situation and ask it to update the relevant section. The SOP grows with the work.

What to feed Claude, exactly

The best input is a transcript with speaker labels. Fathom and Granola both produce these. Claude's output is noticeably worse if you hand it an unstructured wall of text.

Also: include the meeting's purpose in your prompt, not just the transcript. "This was the weekly ops meeting" produces a different output than "This was me training a new VA." Tell Claude what the meeting was for.

Why not ChatGPT?

You can use ChatGPT. The output is slightly worse for this specific task because Claude handles long transcripts better without losing context. For 30+ minute calls, the difference is visible — Claude remembers things said at minute 4 when writing about minute 28. GPT often doesn't.

The 100-SOP rule

The first ten SOPs are the hard ones because you don't have the habit yet. After that, the marginal cost of a new SOP is 15 minutes. We aim to have 100 in the library before we consider a company's ops "documented." Claude makes that target actually reachable.

---

We do this for clients as part of Operations. Or do it yourself — it genuinely is this simple.