---
title: Documentation and SOPs
summary: The specific format and process that makes documentation actually run the business instead of getting filed.
est_minutes: 18
sort: 2
---

Welcome to Module 3.2.

Every operator has tried documenting before. Most attempts produce SOPs that live in a folder no one opens. This module is about why most SOP attempts fail, and the specific Standard that makes them actually run the business.

By the end of this module, you'll have an SOP Operating Standard, your bottleneck process documented to that standard, a handoff test result, and a schedule for the remaining 9 SOPs.

**Why Most SOPs Fail**

Operators sit down on a Sunday afternoon, ambitious. They write 6 SOPs. They save them in a Google Drive folder called "SOPs." They never look at them again. Six months later they're frustrated that "documentation doesn't work."

Documentation didn't fail. The conditions for documentation to be useful weren't met.

Five common SOP failure modes:

1. **Lives in a separate library.** The SOP is in a folder. The work happens in a different tool. No one opens the folder while doing the work.

2. **No version control.** The SOP from 18 months ago is still in the folder. No one knows if it's current. People stop trusting it.

3. **No named owner.** Whose job is it to keep the SOP accurate? Unclear. Drifts.

4. **Never tested.** The SOP "looks right" to the founder. But it's never been used by anyone other than the founder. The first time someone tries to run it, they discover it's missing 40% of the actual process.

5. **No review cadence.** Months pass. Reality drifts from documentation. Documentation becomes wallpaper.

The SOP Operating Standard fixes all 5.

**The SOP Operating Standard**

Five properties. Every SOP in your business will meet these.

**Property 1 — Lives where the work happens.**

Not in a separate "SOP library." Embedded in the tool or workflow where the process runs.

If the sales process runs in HubSpot, the sales SOP lives as notes attached to the deal pipeline. If onboarding runs through ClickUp templates, the onboarding SOP IS the ClickUp template. The SOP and the work are co-located.

**Property 2 — Versioned and dated.**

Every SOP has a version number (v1.0, v1.1, v2.0) and a "last updated" date. SOPs over 90 days old without an update trigger a review.

**Property 3 — One specific owner per SOP.**

Not "the team." Not "operations." A named human. The owner is accountable for keeping the doc accurate. If the doc is wrong, the owner is the one who failed to update it.

**Property 4 — Tested by handoff.**

The SOP is "done" only when someone who has never run the process can execute it from the doc and produce the expected result. Until that test passes, the SOP isn't done, it's a draft.

**Property 5 — Reviewed quarterly.**

The operating cadence (Module 3.7) includes SOP review. The owner reviews their SOPs quarterly. Outdated SOPs trigger an update or a deletion. No SOP sits unreviewed for more than 12 months.

These five properties are what separates SOPs-as-leverage from SOPs-as-decoration.

**Choosing The Top 10**

Most operators want to document everything. That's how they get nothing done.

The right approach: document the 10 highest-leverage processes. The ones that produce the most revenue, consume the most operator time, or break most often.

The 10 typical SOPs for an operator business:

1. **New lead intake.** From inquiry to qualified.
2. **Discovery call.** The Module 2.5 sales script with scoring.
3. **Proposal generation.** Template + workflow.
4. **Customer onboarding.** Module 2.6's First 30 Days.
5. **Standing customer meeting.** The weekly delivery call format.
6. **Project kickoff.** Internal: how a signed deal becomes work.
7. **Invoice + payment collection.** Cash side of the operation.
8. **New hire onboarding.** First 14 days.
9. **Vendor management.** Any recurring vendor relationship.
10. **End-of-month close.** Financial close-the-books.

Your specific 10 may differ. The principle is the same: 10 highest-leverage, no more.

When you've documented 10 to the Standard, the next layer of 10 becomes obvious. Don't try to do 30 at once.

**How To Write A SOP**

A real SOP has 6 sections. No more. No less.

**Section 1 — Purpose.** Why does this process exist? What outcome does it produce? One paragraph.

**Section 2 — Trigger.** What event starts this process? Specific. Named.

**Section 3 — Steps.** Numbered. Each step has: who does it, what they do, what tool they use, what the output is.

**Section 4 — Decision points.** Inside the process, what decisions get made? Who decides? What criteria?

**Section 5 — Output / Exit criteria.** What does "done" look like? How do you know the process worked?

**Section 6 — Escalation.** What conditions require someone other than the owner to be involved?

A well-written operator SOP is 1–3 pages. Not 15. Not 20. If your SOP is 20 pages, it's actually a textbook, break it into smaller SOPs.

The writing principle: **write for the person doing the work, not for an auditor.** "Click the green Submit button in the upper right" beats "Submit the form to the central processing queue." Be specific.

**The Handoff Test**

The SOP is done only when it passes the handoff test.

The test: someone who has never run the process reads the SOP, then executes it. The output matches the expected result within 20% on the first attempt.

Common handoff test failures:

- **Assumed context.** The SOP assumes the reader knows what "the standard onboarding deck" means. The reader doesn't. Add the link / location.
- **Missing tool access.** The SOP says "open the customer record in HubSpot." The reader doesn't have HubSpot access. Document the access prerequisite.
- **Implicit decisions.** The SOP says "if the customer is high-risk, flag it." High-risk isn't defined. Define it.
- **Missing edge cases.** The SOP covers the happy path. The reader encounters a non-standard situation. Add escalation criteria.

Run the handoff test BEFORE you call the SOP done. The test usually surfaces 4–8 gaps. Each gap is a fix. After the fixes, run the test again.

A SOP that passes the test the first time is suspicious, likely the tester filled in the gaps from their own knowledge. A real handoff test reveals the gaps.

**The Quarterly Review**

SOPs go stale. Reality drifts. Without a review cadence, your SOP library becomes archeology.

The review cadence:

- **Every quarter (4× per year)**, each SOP owner reviews their SOPs
- Three questions per SOP:
  1. Is this still accurate?
  2. What changed in the last 90 days that the SOP doesn't reflect?
  3. Is anyone actually using this, or is it dead weight?
- Outcomes: update / archive / merge with another SOP

The review takes 2–4 hours per quarter for a 10-SOP library. Block it on the calendar. Make it part of the operating cadence (Module 3.7).

Without the review, your library decays. Decayed SOPs are worse than no SOPs because team members trust them and the SOP gives wrong instructions.

**Writing SOP #1 — Your Bottleneck**

The first SOP you write is the process at the heart of your Module 3.1 bottleneck.

That process is:

- The single most leveraged thing to document
- The process you most need to hand off
- The process you've been doing yourself for 18+ months because "no one else can"

Block 60–90 minutes. Write the SOP using the 6-section structure. Run the handoff test with a peer or team member. Iterate based on the test.

After SOP #1, the next 9 SOPs each take 30–45 minutes, because the Standard is set and you know how to write to it.

**What To Do Right Now**

Four things:

1. **Open the workbook.** Identify your top-10 SOPs (Section A). The list should be 10 processes that, documented, would change the business most.

2. **Write your SOP Operating Standard** (Section B). One page. Define what every future SOP looks like.

3. **Write SOP #1**, your bottleneck process from Module 3.1, using the 6-section structure (Section C).

4. **Run the handoff test** (Section D). Pass it or iterate.

Schedule the remaining 9 SOPs and the quarterly review (Section E). Take the quiz.

I'll see you in Module 3.3 — Delegation & Org Design — where we hand off the work the documentation now makes hand-off-able.
