How to write an SOP your team actually uses
Quick answer
An SOP is a written, step-by-step instruction for one repeatable task, so the work gets done the same way every time. To write one: pick one task, watch it being done, name an owner, write the steps in order, add screenshots or a short video, test it with someone new, and set a review date.
What an SOP is (standard operating procedure)
An SOP, or standard operating procedure, is a written, step-by-step instruction for one repeatable task.
It exists so the work gets done the same way every time, without you explaining it again. One task per SOP. If it covers two, split it.
A good SOP is short and plain. It names roles, not people, so it still works when someone leaves or goes on vacation. And it lives where the work happens, not in a folder nobody opens.
Why SOPs matter in a small business
In most small businesses, the process lives in the owner’s head. Every question comes back to you, every new hire learns by shadowing, and the work changes depending on who’s doing it. SOPs fix that.
- The owner stops being the bottleneck. The answer is written down, so the team doesn’t wait on you.
- Training gets faster. New people learn from the SOP, not from whoever has time that week.
- The work stays consistent. The same task gets done the same way, whoever does it.
- You can step away. A business that runs on written processes keeps running when you take a week off.
SOPs are also the first thing a good operator builds. If you’re weighing outside help to run operations, our guide on how to find a fractional COO covers what that looks like.
Which processes to document first
You don’t need an SOP for everything. Start with the tasks that cost you the most when they go wrong:
- Repeated tasks: anything done every day or every week, like processing orders, onboarding clients, or sending invoices.
- Error-prone tasks: the ones where a skipped step means a refund, a rework, or an unhappy customer.
- Tasks stuck in one person’s head: if only one person knows how it’s done, that’s a risk, not a skill.
- Tasks you explain more than once: if you’ve walked someone through it twice, it should be written down.
Pick one. Write it well. Then do the next.
How to write an SOP, step by step
- Pick one process. Name the task. One task. If it covers two, split it.
- Write the purpose and the trigger. One sentence on why the task exists, and one on what starts it.
- Watch it being done. Sit with the person who does it today and note every step, including the ones they do without thinking.
- Name an owner. The role that keeps it up to date, not a person’s name.
- Write the steps in order. Start each one with a verb. Name the role, not the person. List what has to be true before it starts.
- Add screenshots or a short video. Show the step where people usually get stuck.
- Write what done looks like, and what to do if something goes wrong.
- Test it with someone new. Have someone who has never done the task follow it. Every question they ask is a gap to fix.
- Set a review date. Put it on the calendar, and review it any time the process changes.
Once a process is documented, it’s ready to automate. Our guide on where AI fits in a small business covers what to hand off first.
What goes in an SOP
Every SOP we write covers the same core sections. Here’s what each one does, using a customer refund as the example:
| Section | What it covers | Example line |
|---|---|---|
| Purpose | Why the task exists, in one sentence. | Return the money when the request meets the rules, and close the ticket. |
| Scope | What starts it, and what it covers. | Starts when a refund request arrives in the inbox. |
| Owner | The role that keeps the SOP current. | Customer support lead. |
| Steps | The work in order, each starting with a verb. | Check the order date. Confirm it’s inside the refund window. Process the refund. |
| Tools | The systems and logins the task uses. | The order system and the support inbox. |
| Definition of done | How you know it’s finished. | The refund is processed and the customer has the confirmation. |
Add a last-reviewed date at the top. If you want a starting point, copy this structure into a blank document and use it as your process documentation template.
SOP examples for a small business
These are short, generic examples of how a few common tasks look as SOPs. Yours will be specific to your tools and your team.
Order fulfillment
Trigger: a new order is paid. Steps: confirm the address, pick and pack the items, print the label, mark the order shipped, and send tracking. Done: the customer has tracking and the order shows shipped.
Client onboarding
Trigger: a client signs. Steps: send the welcome email, set up their account and folders, schedule the kickoff, and share what you need from them. Done: the kickoff is booked and the client has everything they need to start.
Month-end close
Trigger: the last business day of the month. Steps: reconcile the bank and card accounts, review open invoices and bills, categorize anything unmatched, and send the summary to the owner. Done: the books are reconciled and the summary is sent.
Closing a location
Trigger: the scheduled closing time. Steps: close out the register, secure cash, check equipment is off, set the alarm, and lock up. Done: the closing checklist is signed off and the alarm is set.
Notice the pattern: every example names a trigger, a short list of steps, and a clear finish line. If you can’t write those three things for a task, the process itself needs work before the SOP does. That’s usually where we start.
Checklist, SOP, or full process doc: which you need
| Format | Best for | Example |
|---|---|---|
| Checklist | A short task the person already knows how to do, where the risk is skipping a step. | Closing a location |
| SOP | One repeatable task that someone new should be able to do from the page. | Processing a refund |
| Full process doc | Work that crosses several people or teams, from start to finish. | Order to delivery |
Most small businesses need a handful of good SOPs before anything bigger. Mapping how work moves across the whole business is what our operations consulting starts with.
Why teams ignore SOPs, and how to fix it
Most SOPs fail for the same few reasons:
- It’s too long. Keep it to one page.
- It covers more than one task. Split it.
- The steps name people instead of roles. Name the role, so it survives turnover.
- It was written once and never updated. Review it when the work changes.
- It sits in a folder nobody opens. Put it where the work happens.
The fix is almost always the same: write it with the people who do the work, keep it short, and put it in front of them at the moment they need it. That’s the core of our SOP and systems work: SOPs built with your team, and the system around them that keeps steps from getting skipped.
How to keep SOPs up to date
- One owner per SOP. Name the owner so someone is responsible for keeping it current.
- A review cadence. Review each SOP at least once a year, and any time the process changes.
- One home. Every SOP lives in one place the whole team knows, linked from where the work happens.
When something changes, update the SOP first, then tell the team. If the page and the practice disagree, people trust the practice, and the SOP stops getting used. The simplest check during a review is to have someone follow it exactly as written. If they get stuck, fix the page, not the person.
Once the core SOPs are in place, a few key numbers tell you whether the processes are working.
Once it’s documented, it can be automated. Our guide on how to automate business processes covers what to automate first and how to do it without breaking what works.
FAQ
What is an SOP?
An SOP, or standard operating procedure, is a written, step-by-step instruction for one repeatable task. It exists so the work gets done the same way every time, by anyone trained on it.
How long should an SOP be?
As short as it can be while someone new can still follow it, and usually no more than one page. If it’s getting longer, it probably covers more than one task and should be split.
Who should write SOPs in a small business?
The person who does the work, with someone who owns the process reviewing it. The owner shouldn’t write every SOP. The people closest to the task know the real steps, and a fresh reader catches the gaps.
What’s the difference between an SOP and a checklist?
A checklist reminds someone who already knows the task not to skip a step. An SOP teaches the task: the purpose, the trigger, the steps in order, and what done looks like. Many SOPs end in a checklist.
How often should SOPs be updated?
At least once a year, and any time the process changes. Name an owner for each SOP and put the review date on the calendar so it actually happens.
What’s the best format for an SOP?
The one your team will open at the moment they need it. A short document works for most tasks, a checklist for tasks people already know, and a short screen recording for anything done inside software. Many good SOPs combine a written page with a video.
A note from us
An SOP exists so the work gets done the same way every time, without you explaining it again.
The SOPs we write follow a few rules. Keep it to one page. Put it where the work happens. Review it when the work changes. Name the owner so someone is responsible for keeping it current.
What to do next
Pick one task that you explain more than once. Write the SOP. Put it where the team can find it. That is the start.
If you’d rather have it built with your team, send it over. We’ll tell you what it would take.