Most people put off documenting their processes because it feels like a big, complicated project. And then one day they hire someone, or go on leave, or lose a client because something fell through the cracks — and they wish they’d done it sooner.
Here’s the truth: documenting a single business process doesn’t have to take more than 60 minutes. I’ve been doing process documentation for clients across different industries for years, and I’ve refined a method that gets it done quickly without cutting corners on quality.
The framework is adapted from Six Sigma — a methodology originally developed for large-scale manufacturing that turns out to be remarkably useful for small service businesses. I use Fathom to capture the process walkthrough and ClickUp to store and manage the finished document.
Affiliate Disclosure: This post contains affiliate links. I only recommend tools I personally use and trust. Using my links supports my content at no extra cost to you.
What Six Sigma Actually Teaches About Process Documentation
Six Sigma is a data-driven quality improvement methodology focused on reducing variation and eliminating defects in processes. At its core is a simple insight: if you can’t describe what you do, you can’t improve it.
For small business documentation, the two Six Sigma principles I borrow most heavily are:
- Define the process boundary first — know exactly where the process starts, where it ends, and what falls inside and outside its scope. Without boundaries, documentation sprawls.
- Document what actually happens, not what should happen — the gap between the two is where most problems live.
These two principles shape every step of the 60-minute framework below.
The 60-Minute Process Documentation Framework
Phase 1: Prepare (10 minutes)
Before you record or write anything, get clear on scope:
- Name the process clearly (e.g. “Client Onboarding — From Signed Contract to Kickoff Call”)
- Define the trigger: what event starts this process?
- Define the endpoint: what does “done” look like?
- List the tools, templates, or resources used in the process
- Note who is responsible for each part (you, a VA, the client)
This preparation step is the one most people skip — and it’s why their documentation ends up being a vague wall of text rather than something a new hire can actually follow.
Phase 2: Record the Walkthrough with Fathom (20 minutes)
This is where Fathom earns its place in the workflow. Instead of typing out every step from memory, I record myself doing the process — or talking through it out loud — in a Zoom or Google Meet call with Fathom running.
Here’s the exact approach:
- Start a Zoom call with yourself (or with the team member who owns the process).
- Open Fathom and let it join as a notetaker — it will record, transcribe, and summarise the session automatically.
- Walk through the process out loud, step by step, as if you’re explaining it to someone for the first time. Show your screen as you go through relevant tools.
- Call out decision points explicitly: “At this stage, if X happens, we do Y. If Z happens, we do W.”
- Flag anything you want to revisit by saying it out loud: “Note: I need to add the template link here.”
When the session ends, Fathom gives you a transcript and a structured summary. This becomes your first draft — without you having typed a single word.
Honest take: Fathom’s AI summary won’t be perfect — it will miss nuance and occasionally misattribute steps. But it gives you 70–80% of the structure in one go, which is far faster than starting from a blank page. The editing phase cleans it up.
Phase 3: Structure and Edit (20 minutes)
Take Fathom’s summary and turn it into a clean, structured SOP. Every process document I write follows the same template:
- Process name and purpose (one sentence: what does this process achieve?)
- Trigger (what starts the process?)
- Who is involved and their roles
- Step-by-step instructions, numbered, with sub-steps where needed
- Decision points clearly called out (“If X, then Y”)
- Tools, templates, and resource links embedded inline
- Definition of done (what does a completed process look like?)
Keep the language simple and direct. Write for your least experienced future team member, not for yourself.
Phase 4: Store in ClickUp and Link to Tasks (10 minutes)
Once the SOP is written, it goes straight into ClickUp Docs. Here’s how I set it up for maximum usability:
- Create the Doc under a dedicated “Operating Procedures” folder in ClickUp.
- Tag it with the relevant service area (Onboarding, Delivery, Admin, etc.) so it’s easy to filter.
- Link the SOP directly inside the relevant recurring task in ClickUp — so when your VA opens the task, the procedure is one click away.
- Add a “Last reviewed” date at the top of the Doc and set a recurring reminder to review it quarterly.
Pro tip: The first time a new VA uses a process, ask them to flag anything that was unclear or missing. Their feedback is gold — they’re seeing the process with fresh eyes and will catch gaps that you’ve become blind to.
The Two Mistakes That Make Process Documentation Useless
Even with a solid framework, I see these two mistakes consistently:
- Documenting the ideal process instead of the real one. Your SOP should describe what you actually do today, not what you wish you did. You can optimise later — but you have to start with reality.
- Writing it once and never updating it. Processes evolve. A SOP that’s 18 months out of date is almost worse than no SOP — it breeds confusion. Build the quarterly review into your calendar the day you finish writing.
Want Your Processes Documented for You?
Process documentation is one of the core deliverables in my systems service. I run the walkthroughs, handle the writing and structuring, and set everything up in ClickUp so your team can use it from day one.
Book a free discovery call and let’s talk about getting your processes out of your head and into your systems.
