Building SOPs That People Actually Follow

I once spent three weeks writing a 47-page operations manual for a client. It covered every process in their business with excruciating detail. It had screenshots, flowcharts, and color-coded sections. It was beautifully formatted and completely ignored. Within two months, not a single team member had opened it after the initial training session.

That failure taught me something I now consider the first rule of process documentation: if nobody follows it, it doesn’t exist. The most comprehensive SOP in the world is worthless if it sits in a Google Drive folder gathering digital dust.

The problem wasn’t the team’s discipline. The problem was my approach. I was documenting for completeness instead of documenting for usability. The people who needed to follow these processes didn’t need a reference manual — they needed a checklist they could glance at while doing the work.

Since that expensive lesson, I’ve developed a completely different approach to SOPs. One that gets followed because it respects how humans actually work. Here’s the system.

Why Most SOPs Fail (Three Structural Problems)

Problem 1: They’re too long. When a team member needs to check how to do something, they’re in the middle of doing it. They don’t have twenty minutes to read a chapter. They need thirty seconds to verify a step. Long SOPs create a barrier between the question and the answer, so people stop consulting them and rely on memory instead — which is exactly what SOPs are supposed to prevent.

Problem 2: They’re written by the wrong person. Most SOPs are written by the founder, a manager, or a consultant (guilty). But the person who writes the SOP is rarely the person who follows it. The writer documents what they think the process should be. The follower discovers that the actual process has edge cases, exceptions, and practical realities the writer didn’t account for.

Problem 3: They’re never updated. Processes change. People find better ways to do things. New tools get adopted. But the SOP stays the same, gradually diverging from reality until it’s a historical document about how things used to work rather than a guide for how they work now.

These three problems share a root cause: SOPs are treated as documents rather than tools. A document is static and meant to be read. A tool is dynamic and meant to be used. The shift from document-thinking to tool-thinking changes everything about how you create SOPs.

This principle connects to the broader EAOS framework — before you systematize, make sure your system is designed to actually function in the real world.

The One-Page Checklist Format

Every SOP I create now fits on one page. Not because I’m cutting corners, but because one page forces clarity and prioritization. If a process can’t be described in one page, it’s either too complex (and should be broken into sub-processes) or you’re including unnecessary detail.

Here’s the format:

Title and purpose (1-2 lines). What this process is and why it matters. “Client Onboarding: Ensure every new client has a smooth first week experience.”

Trigger (1 line). What initiates this process. “Triggered when: A new client signs the engagement agreement.”

Steps (5-10 items). Numbered checklist of actions in order. Each step is one sentence. No paragraphs, no explanations of why — just what to do.

1. Send welcome email using template in [link]
2. Create client folder in Google Drive using structure in [link]
3. Schedule kickoff call within 5 business days
4. Send pre-kickoff questionnaire using [link]
5. Add client to project management board
6. Set up recurring check-in meetings
7. Send “What to Expect” document from [link]

Resources (2-3 links). Links to templates, tools, or reference materials mentioned in the steps.

Owner and review date. Who is responsible for following this SOP and when it was last updated.

That’s it. One page. A team member can glance at it in 30 seconds and know exactly what to do next. No scrolling, no searching, no interpretation.

Who Should Write Your SOPs (Not You)

The person who follows the process should write the SOP. Not the founder, not the manager, not a consultant. The person who does the work.

Here’s why: they know the actual process, including the shortcuts, the common problems, and the practical details that never make it into a top-down document. When they write it, they write what actually works, not what theoretically should work.

How to facilitate this:

Step 1: Record the process. Have the team member record a screen share or voice memo while performing the process. They narrate what they’re doing as they do it. This takes 15-20 minutes and captures the real process, including details the person might not think to write down.

Step 2: Transcribe and simplify. Convert the recording into the one-page checklist format. Remove explanation and narrative — keep only the action steps. The team member (or you) can do this in about 30 minutes.

Step 3: Test with a fresh pair of eyes. Have someone who’s never done the process attempt it using only the SOP. Where they get stuck or confused, the SOP needs improvement. This testing step is critical and most people skip it.

Step 4: Finalize and store. Put the SOP in a centralized, easily searchable location. Not buried in a folder tree — one click away from where the work happens. If you use Notion, create a dedicated SOPs section. If you use Google Drive, create a single “SOPs” folder with clear naming conventions.

This bottom-up approach produces SOPs that are 3-5x more likely to be followed than top-down documentation. The difference is that the SOP reflects reality rather than aspiration.

I use this approach with every client through my process documentation method, which I’ll cover in more detail separately.

Making SOPs Stick: The Adoption System

Creating the SOP is 50% of the work. Getting people to actually use it is the other 50%. Here’s the adoption system:

Integrate into workflow. Put SOPs where the work happens. If your team uses Asana, embed the SOP checklist as a task template. If they use Slack, pin the SOP to the relevant channel. The SOP should appear at the moment of need, not require a separate search.

Make it the default, not the exception. New team members learn processes from SOPs on day one. Existing team members reference SOPs when training others. The SOP is the authoritative source of “how we do things here.”

Review and update quarterly. Every 90 days, the SOP owner reviews each document and asks: “Is this still how we actually do it?” Any process that has changed gets updated. Any SOP that hasn’t been used in 90 days gets flagged for review — maybe the process was eliminated or automated.

Celebrate improvements. When someone finds a better way to do something and updates the SOP, acknowledge it. “Sarah updated our client onboarding process and cut two steps. That saves us about 30 minutes per new client.” This creates a culture where SOPs are living tools, not bureaucratic burdens.

The technician trap happens when processes live in the founder’s head. SOPs that people actually follow are how you escape that trap — but only if the SOPs are maintained as the business evolves.

When to Create SOPs (And When Not To)

Not everything needs an SOP. Creating SOPs for everything creates bureaucracy. Creating them for nothing creates chaos. Here’s how to prioritize:

Create SOPs for:

• Processes performed more than once per week
• Processes involving multiple people or handoffs
• Processes where errors have significant consequences
• Processes that new team members need to learn
• Processes you want to delegate or outsource

Don’t create SOPs for:

• One-time activities
• Creative work that varies significantly each time
• Processes still in experimentation phase (wait until they stabilize)
• Tasks so simple that documentation would be patronizing

For most small businesses (under 20 people), you need 15-25 SOPs to cover the critical processes. Not 100. Not 200. Just the ones that matter for consistency, quality, and delegation.

The owner dependency score helps identify which processes most urgently need documentation. If you’re the only person who knows how to do it, and the business would suffer if you couldn’t, that’s your first SOP.

The SOP-First Hiring Approach

Here’s a powerful principle: write the SOP before you hire the person. When you document the process first, you accomplish three things:

1. You clarify what the role actually requires. The SOP reveals the skills needed, the tools involved, and the time commitment. This makes your job description accurate rather than aspirational.

2. You create a training tool. Day one, the new hire has a clear guide to every process they’re responsible for. Training time drops by 50% or more.

3. You maintain quality from the start. The new hire follows the documented process, producing consistent results immediately. Without an SOP, they improvise, and quality varies until they figure things out through trial and error.

I used this approach when I last expanded my team and the difference was dramatic. Previous hires without SOPs took 4-6 weeks to get up to speed. The SOP-first hire was producing quality work within 2 weeks.

This connects directly to the clockwork business model — documented processes are the foundation of a business that can operate without the founder present for every decision.

Takeaways

1. One-page checklists beat 40-page manuals. If it can’t fit on one page, break the process into sub-processes. Five to ten steps, each one sentence.

2. Have the person who does the work write the SOP. Record the process, transcribe it, test it with fresh eyes, and finalize. Bottom-up documentation is 3-5x more likely to be followed.

3. Integrate SOPs into the workflow. Put them where the work happens — in task templates, pinned to channels, one click from the point of need. Don’t make people search.

4. Review and update every 90 days. SOPs that don’t reflect reality are worse than no SOPs because they create false confidence. Keep them current.

5. Write the SOP before you hire. It clarifies the role, creates a training tool, and maintains quality from day one. SOP-first hiring cuts onboarding time by 50%.