How to Write SOPs Your Team Will Actually Follow
You wrote the process down once. Nobody followed it. Here is how to write standard operating procedures people actually use, so the business does not stop when you step away.
Most SOPs die in a folder nobody opens. The owner spends a Sunday writing a 12 page document, shares it, and two weeks later the team is still texting them questions. The problem usually is not your team. It is how the SOP was written, where it lives, and whether anyone ever tested it. This is how to fix that.
Start with the tasks that interrupt you most, not the whole business
Do not try to document everything. You will burn out by task four. Instead, track your interruptions for one week. Every time someone asks you a question or you fix something nobody else can, write it on a sticky note or in a notes app.
At the end of the week you will have a list. Sort it by how often each thing happened. A bakery owner I worked with found that 40 percent of her interruptions were two things: how to handle a custom cake order, and what to do when a delivery was late. Those two SOPs alone gave her back about six hours a week.
Pick the top three. Those are your first SOPs. They have the highest return because they stop the questions that pull you back in every single day.
- Track interruptions for 5 working days
- Group them by topic
- Count how often each happens
- Write SOPs for the top 3 first
- Ignore anything that happened only once
If it interrupts you weekly, it deserves an SOP. If it happened once, it does not.
Write it as a checklist, not an essay
Nobody reads a wall of text while a customer is standing in front of them. The SOPs people actually follow look like a recipe or a flight checklist, not a policy manual.
Use short numbered steps. One action per step. Start each step with a verb: open, click, send, check, call. Compare these two. Essay version: 'When a customer requests a refund you should first verify their order details and consider whether it falls within our policy window before processing.' Checklist version: 'Step 1. Open the order in Stripe. Step 2. Confirm the purchase date is within 30 days. Step 3. If yes, click Refund. If no, send template R2.'
The second version can be done by someone on their second day. The first one needs you to interpret it, which means it still needs you.
- One action per step
- Start every step with a verb
- Add exact button names and screen labels
- Note the decision points with if/then
- Keep most SOPs under one page
Show, do not just tell: use screenshots and short screen recordings
Text alone leaves room for guessing. A screenshot with an arrow removes the guesswork. For anything done on a computer, record your screen while you do the task once. Loom and the built in screen recorder on most phones and laptops are free and take two minutes.
Keep recordings short. A five minute video gets watched. A 40 minute video gets skipped. If a process is long, break it into three short clips by stage.
Pair the video with the written checklist. People use the checklist daily once they know the task, and the video is there for the first few times or when something feels off. A landscaping company cut their new hire training from two weeks of shadowing to four days using six short clips plus printed checklists.
A 90 second screen recording prevents more questions than three pages of text ever will.
Have the newest person test it before you call it done
The single biggest reason SOPs fail is that the person who wrote them already knows the job. You skip steps without realizing because they are automatic to you. The fix is simple and a little uncomfortable: hand the draft to someone who has never done the task and watch them try.
Do not help. Do not explain. Just watch and note every place they hesitate, ask a question, or do the wrong thing. Each of those moments is a gap in your SOP. A cleaning business owner watched a new hire follow her 'close out the property' SOP and discovered she had never written down where the alarm code lived. Obvious to her, invisible to everyone else.
Rewrite based on what you saw, then test again with a second person. After two rounds, most SOPs hold up on their own.
Put the SOP where the work happens
An SOP saved in a folder called Operations on your desktop helps nobody. People follow processes that are within reach at the exact moment they need them.
If the task happens in your booking software, link the SOP from inside that tool or pin it in the team chat channel where that work gets discussed. If it is a physical task, print it and laminate it and stick it on the wall where the task is done. The refund SOP belongs next to the till. The opening checklist belongs on the back of the front door.
Build one simple index so nothing gets lost. A single shared doc or a free tool like Notion or Google Drive with clear folders works fine. The rule is two clicks or less to find any SOP. If it takes longer, people will text you instead.
- Link digital SOPs inside the tool where the task happens
- Print and post physical task SOPs at the spot
- Keep one master index, two clicks to anything
- Name files plainly: 'Refund process' not 'SOP v3 final'
Name an owner and a review date for every SOP
Processes rot. Software updates, your prices change, a supplier closes. An SOP nobody owns becomes wrong within a few months and then people stop trusting all of them, even the good ones.
Put two things at the top of every SOP: who owns it and when it was last reviewed. The owner is the person responsible for keeping it accurate, and it does not have to be you. For most small teams, the person who does the task most often should own its SOP.
Set a review rhythm. Quarterly is enough for most things. Block 30 minutes every three months, pull up your five most used SOPs, and check they still match reality. This takes far less time than re-explaining a broken process to confused staff.
Common mistakes that quietly kill your SOPs
Most owners do not fail at writing SOPs. They fail at a handful of avoidable mistakes that make people quietly ignore the documents.
The biggest one is writing for the expert instead of the beginner. If your SOP assumes the reader already knows the jargon, the shortcuts, and where things live, it only works for people who do not need it.
The second is making them too long. A 15 step SOP for a 3 step task signals that following the process is a hassle, so people freelance instead. The third is never updating them, which teaches the team that the documents lie.
- Writing for experts, not the newest hire
- Cramming too much into one document
- Letting them go stale and never reviewing
- Saving them somewhere nobody looks
- Skipping the test with a real person
How to roll them out so the team buys in
Drop ten new SOPs on your team in one email and they will ignore all ten. Roll them out one at a time and treat them as the answer to a real frustration, not extra paperwork.
Introduce each SOP by tying it to a problem the team already feels. 'You know how delivery delays turn into a mess? Here is the exact steps so nobody has to scramble.' Now it is a tool that makes their day easier, not a rule from management.
Then enforce the simplest habit of all. When someone asks you a question that an SOP already answers, point them to the SOP instead of just answering. Do it kindly, but do it every time. Within a few weeks people check the document first, which is the whole point. The business keeps running because the answers no longer live only in your head.
This is the kind of work we handle behind the scenes. If you would rather have it set up properly than figure it out alone, our SOP and process documentation, project management setup, a tech stack audit services are built for exactly this.
