How to Write SOPs for Your Small Business
Updated: Sep 8
You handed something off, it came back wrong, and you spent more time fixing it than you would have spent doing it. You keep telling yourself you'll write it down "when things slow down,” but things don't slow down.
A good SOP breaks the loop. A Standard Operating Procedure (SOP) is a written, step-by-step document that explains how a specific task gets done in your business. Not a vague description. Not "ask me if you have questions." A clear instructional guide that someone who's never done the job before can do it correctly without pulling you in.
SOPs aren't complicated to understand. What makes them hard to write is figuring out what to include, how much detail is enough, and where to start when you're staring at a blank page. This post gives you a framework for all of that.
Highlights
An SOP is only useful if it's specific enough that someone new to the task can execute it correctly without asking you.
You don't need SOPs for everything. Start with repeatable tasks that are important enough to be done right every time.
The biggest mistake people make is writing from memory instead of walking through the process as they actually do it.
SOPs don't need to be long. A one-page numbered list with a few screenshots is often enough.
Documenting a process once makes every version of that process better training, delegation, handoffs, and scaling all get easier.
Why SOPs Feel Hard
Writing an SOP should be simple. You already know how to do the thing. You've done it dozens of times. So you sit down to document it and immediately hit a wall.
Part of the problem is that when you know a process well, you stop seeing the individual steps. The decision points become automatic. The assumptions become invisible. You skip the part where you check the settings because you always check the settings, it's just something you do. But the person reading your SOP doesn't know that.
The other problem is format. Most people approach SOP writing like they're writing an essay: starting at the beginning, trying to capture everything in one go, rewriting the same sentence four times. That's the wrong approach for this kind of document.
And then there's the "I'll make it perfect" trap. You want it to be thorough. You want it to cover every scenario. So you keep putting it off until you have the time to do it right, which means you never do it at all.
The result is a business where processes live in your head. When key tasks depend on one or two people mentally retaining all the information, that's an expensive way to run a business. What if they're sick, they go on vacation or worse, resign and you have no idea how to get their part of the job done.
A Panopto study on workplace knowledge found that employees spend an average of five hours per week waiting to get information from the one person who knows how a task gets done. [1] Five hours a week, every week, just waiting. That’s throwing money out the window.
What a Good SOP Fixes
The surface-level benefit of an SOP is consistency, the same task gets done the same way every time. But that's just the beginning.
SOPs simplify training for new employees, ensuring they understand their roles quickly and accurately. They help to reduce errors and inconsistencies in important tasks, which can be particularly harmful in smaller businesses where margins are tight and resources are limited.
Beyond training, SOPs protect you from the "only I know how to do this" problem. When a process lives in a document instead of your head, you can delegate it knowing it will get done right the first time. Imagine taking a week off without your phone blowing up because your staff constantly needs you.
The Slack State of Work Report found that 77% of workers say being able to automate or hand off routine tasks would significantly improve their productivity. [2] SOPs make that handoff possible.
There's also a compound effect. Every time you improve an SOP, it improves the process. You catch the thing you forget to tell people and fix it.
Which Processes Need an SOP First
You don't need to document everything. You need to document the right things first and then build from there.
Start with processes that meet one or more of these criteria:
It happens repeatedly. If you or someone on your team does a task more than a few times a month, it belongs in a document.
It's a huge problem if done wrong. Think: client onboarding, invoicing, data handling, anything that touches money or compliance. One mistake in these areas costs more than the time it takes to write the SOP.
Only one person knows how to do it. Single points of knowledge are single points of failure. If the answer to "who handles this?" is always the same name, document it.
It's a common source of confusion or re-do. If you're fielding the same questions or fixing the same mistakes over and over, the problem isn't the person, it’s their lack of knowledge on the steps to complete the process.
You're about to hand it off or hire for it. The best time to write an SOP for a task is right before you stop being the one who does it.
How to Write an SOP: A Practical Framework
The goal here is to get the process out of your head and into a format someone else can follow. Keep it simple.
Step 1: Name the process clearly. Write it as a task, not a category. "How to send a client invoice in QuickBooks" is a process. "Billing" is not. Specificity makes the document easier to find and easier to follow.
Step 2: Define who it's for and when it applies. One sentence each. Who runs this process? What triggers it? ("This SOP is for [role]. It applies every time a new client signs a contract.")
Step 3: Walk through it while you do it, not from memory. This is the most important step. Do the task in real time and narrate it as you go. Voice memo, screen recording, rough notes - anything works. What you capture in motion will be more accurate than what you recall from memory.
Step 4: Write the steps in plain numbered sequence. Each step should be one action. Not "log in and navigate to the dashboard and then click on clients" that's three steps. Break them apart. Write at the level of someone who's competent but unfamiliar with your specific system.
Step 5: Note where visuals belong. Anywhere a screenshot would make a step clearer, flag it. Anywhere you'd normally show someone rather than tell them, that's a short screen recording. You don't have to create the visuals right now - just note "screenshot needed here" or "Loom video: show how to apply the discount code" so you or someone else can add them later.
Step 6: Do a "did I forget anything" pass. Read the whole thing assuming you've never done this task before. What would make you stop and ask a question? What decision would you face that the document doesn't address? Add those details.
Step 7: Have someone else test it. Give the SOP to someone who hasn't done the task and have them follow it. If they get stuck, fix the SOP. This step is better than a self review.
Questions I Hear All the Time
How long does an SOP need to be? As long as it needs to be. Some processes are a one-page numbered list with a few screenshots. Some are multi-section documents with tabs. The complexity of the process will dictate the length.
Do I need special software to create SOPs? No. Google Docs, Notion, Word, ClickUp - whatever your team already uses.
What's the difference between an SOP and a checklist? A checklist confirms that steps were completed. An SOP explains how to do them. Your SOP may be to add a checklist to a task or add a checklist at the end of the SOP to ensure all important steps were taken.
How often should I update my SOPs? Review them when the process changes, when a tool changes, or when someone runs the process and gets a different result than expected.
What if the process is different every time? Then you probably don't need a standard SOP, you need a decision framework. Write down the variables and the decision rules instead of a fixed sequence. That's still documentation, just a different format.
What Changes When You Do This
The first SOP you write won't feel like much. It's one document, one process, maybe two pages. Not exactly a transformation. But when you stop carrying that process someone else can run it. And if/when something goes wrong you have a place to go fix it.
In the beginning it may feel like a chore but after a while, documenting processes becomes how you think about your business. New task comes in: you're already mentally outlining the steps. Hiring someone new: you point them to the folder. Going on vacation: you update the doc before you go.
The "do it myself" approach feels efficient in the short term but the cost to you and your business will show up later in places like training a new hire, fixing repeated mistakes, and in the ceiling you hit when you try to grow.
Written processes are about not being the bottleneck in your own business.
Need a prompt format to get help from your AI chat - grab my PREP template here.
[1] Panopto. Workplace Knowledge and Productivity Report. https://www.panopto.com/resource/valuing-workplace-knowledge/
[2] Slack. State of Work Report 2023. https://slack.com/intl/en-us/blog/news/the-state-of-work-in-2023
