How to Write SOPs Your Team Will Actually Use

Every business we audit has a folder called "SOPs" somewhere. A shared drive. A Notion workspace. A Google Doc folder called "Processes" that hasn't been touched in 14 months.

Inside, you find documents like "Customer Onboarding Process v3 (FINAL)(actual final).docx." Written by someone who left the company a year ago. Twelve pages long. Nobody has opened it since it was written.

This is the normal state of SOPs in small business, and it's why most founders think documentation is useless. But documentation isn't useless. Documentation written like a policy manual is useless. There's a difference.

Why most SOPs fail

The person writing the SOP treats it as a legal document. They're trying to cover every edge case, every what-if, every scenario. The result is a document that's comprehensive and unreadable. Someone facing the actual task doesn't have time to wade through 12 pages to find step 3. So they ask the person who's done it before instead. The SOP goes unused.

The second failure: SOPs written in long paragraphs. Your brain doesn't read a process step in a paragraph. Your brain reads "1, 2, 3, done." The format matters enormously.

The third failure: SOPs stored somewhere people don't go. If your team lives in Slack and the SOPs are buried in a Google Drive folder, the SOPs don't exist, functionally speaking.

What actually works

Here's the format we use. It's deliberately simple.

1. Title that starts with a verb. "How to onboard a new client" beats "Client onboarding process." The first one signals "this is a guide for doing something." The second signals "this is a document describing a thing."

2. One-sentence purpose at the top. Why does this process exist? Who runs it? When does it happen? If someone can't answer those three questions in 10 seconds of reading, the SOP is useless.

3. Numbered steps. Nothing else. No paragraphs. No "also consider..." No "in some cases you might want to...". Just: do this, then this, then this.

4. Embed the actual tools. Link directly to the template. Link to the form. Link to the Slack channel. If the SOP says "create a new record in the CRM" without a direct link, it's not a usable SOP.

5. Edge cases go at the bottom under a clear heading. 90% of the time, someone just needs to follow the main steps. The edge cases are reference material, not the main content. Keep them separated.

6. Last updated date, visible. Stale SOPs are worse than no SOPs. Nobody trusts documentation that might be out of date.

The test that tells you if your SOP is good

Hand it to someone who's never done the task. Ask them to do it using only the document. If they can, the SOP works. If they come back with questions, the SOP has gaps — go fix those gaps. Repeat.

We do this test in every optimization engagement. Most existing SOPs fail it spectacularly. A new hire reads the onboarding SOP and still needs to ask three people how to actually do the first step.

Where SOPs live matters

Documentation in a place people don't go is functionally invisible. Some options that work:

• Notion — good for medium and large teams with a lot of process
• A pinned message in a dedicated Slack channel — good for high-frequency simple processes
• Embedded in the tool itself — for example, a checklist inside your CRM's deal stages, or template content in your project management tool

The worst place for an SOP is a shared drive folder with 40 other documents, because nobody opens shared drives unless forced.

The underrated benefit

When SOPs are actually used, the obvious benefit is operational — new hires ramp faster, quality stays consistent, things don't break when someone's out.

The underrated benefit is that SOPs let you improve the process, not just document it. Once a process is written down, you can actually look at it and ask "is this the best way?" and "what if we skipped step 4?" That's where real optimization happens. You can't improve what you can't see.

Our rule of thumb: every SOP should get revisited once a quarter. Not rewritten — just looked at with fresh eyes to check if it still matches reality and if any steps can be removed. Most of the time, you find at least one thing to cut.

Documentation done well isn't bureaucracy. It's the opposite — it's the thing that lets the business move faster with less chaos.