Almost every business I work with has SOPs somewhere. Usually they’re in a forgotten Google Drive folder, written two years ago, slightly wrong, and ignored. The team does things the way they’ve always done them, and the founder still answers the same questions every week.
SOPs (standard operating procedures) only work if people use them. Here’s how to write ones that get used.
Why most SOPs fail
- They’re too long. A 12-page document for a 10-minute task won’t be read.
- They’re written from memory, so they describe how the process should work, not how it does.
- They’re hard to find, buried in folders nobody opens.
- They go stale. The tool changes, the price changes, and nobody updates the document.
- Nobody owns them. If everyone is responsible for updating SOPs, nobody is.
Step 1: Choose what to document first
You don’t need an SOP for everything. Start with processes that are:
- Frequent: done weekly or more.
- Error-prone: where mistakes happen or clients notice problems.
- Founder-dependent: where only you know how.
- Handed over often: where new team members or contractors keep asking.
List your processes, score each one from 1 to 3 on those four criteria, and start with the top five. For most service businesses, these are client onboarding, project kickoff, invoicing and payment chasing, the weekly reporting process, and offboarding.
Step 2: Capture the process as it really happens
Don’t write from memory. Capture the real thing:
- Record yourself doing the task with a screen recording tool like Loom, talking through each step and why you do it.
- Get a transcript. Most recording tools create one automatically.
- Note the decision points: the places where you choose between options (“if the client hasn’t paid, I…”).
This takes about as long as doing the task once, and it captures details you’d forget if you wrote from scratch.
Step 3: Use a consistent structure
Every SOP should follow the same simple format, so people know where to look:
- Title: what the process is, in plain words. “Onboarding a new client”, not “CLIENT-OB-PROC-v2”.
- Purpose: one sentence on why it matters.
- When to use it: the trigger. “When a contract is signed and the first invoice is paid.”
- Owner: the role responsible for doing it, and the role responsible for keeping the SOP up to date.
- Tools and access needed.
- Steps: numbered, one action per step, in the order they happen.
- Decision points: “If X, do Y. If not, do Z.”
- Common mistakes: the three things people get wrong.
- What done looks like: how you know the process is complete.
- Last reviewed: a date.
Keep most SOPs to one or two screens. If a process is longer, split it into smaller SOPs and link them.
Step 4: Use AI to draft, then edit carefully
AI is excellent at turning a messy transcript into a clean, structured SOP. Paste your transcript into ChatGPT or Claude with this prompt:
Turn this transcript into an SOP using this structure: title, purpose, when to use it, owner, tools needed, numbered steps (one action each), decision points, common mistakes, and what done looks like. Use only what’s in the transcript. Where I was vague or skipped something, write [CHECK] instead of guessing.
Then edit it line by line. AI sometimes tidies a process into something that sounds right but isn’t. The [CHECK] markers show you where to add detail.
Step 5: Make SOPs easy to follow
- Use screenshots or short clips for anything involving a tool. Seeing the button is faster than reading about it.
- Bold the key actions so people can scan.
- Link templates directly: the email template, the form, the checklist.
- Turn the steps into a checklist inside your project tool. In ClickUp or Notion, a task template with the SOP steps as subtasks means people follow the process without opening the document.
That last point matters most. The best SOP is one people follow without realising they’re following an SOP.
Step 6: Put them where the work happens
Store SOPs in your project hub, not a separate drive:
- In ClickUp, use Docs in an SOP space, linked from the task templates that use them.
- In Notion, use an SOP database with tags for area and owner, linked to the related projects.
Add a simple index page: every SOP, its owner and its last review date.
Step 7: Test with someone else
Ask a team member, ideally someone who doesn’t usually do the task, to follow the SOP without help. Watch where they hesitate or ask questions. Every question is a gap in the document. Fix them.
Step 8: Keep them current
- Give every SOP an owner.
- Review quarterly. Put a recurring task in your hub to check each SOP’s review date.
- Update straight away when something changes. A new tool, a new price or a new step should trigger an update the same week.
- Encourage feedback. Add a line at the bottom: “Something wrong or unclear? Tell [owner].”
SOPs and AI workflows
SOPs now have a second audience: your AI tools. A clear, current SOP can be loaded into a Claude Project or a custom GPT, so AI drafts and answers follow your real process. It can also be the blueprint for an automation in Zapier or Make. That’s another reason to keep SOPs accurate. An outdated SOP doesn’t just mislead your team; it misleads your AI too.
Where to start this week
Pick your most painful repeatable process. Record yourself doing it, turn the transcript into an SOP with the structure above, and have someone else test it. One good SOP is worth more than twenty you never open.
If you’d like help documenting your core processes and keeping them current, that’s part of my Build and Run stages.