A usable SOP is short, written in the order the work actually happens, kept where the work happens rather than in a folder nobody opens, and built with the person who does the job rather than for them. Most SOPs fail not because they are badly written but because they were written by the owner alone, in one sitting, describing an idealized version of the task nobody recognizes.
You have probably written one already. It took an afternoon, it was thorough, and three weeks later everyone was still asking you the same questions. That is not a discipline problem on their end. It is a design problem in how the document was made. Getting this right is the foundation of the systems work we do with professional services and local teams.
Why the last one didn't work
Four common reasons, and it is usually more than one at once:
It described the ideal, not the real. You wrote how the task should be done in perfect conditions. Your staff does it on a Saturday with three customers waiting and one thing already broken.
It was too long. Nobody reads twelve pages while a customer is standing in front of them. If it cannot be scanned in under a minute during the actual task, it will not be used during the actual task.
It lived in the wrong place. A document in a Drive folder is a document nobody opens. The SOP needs to be where the work happens.
Nobody was asked. The person doing the job daily knows things you have forgotten or never knew. Writing it without them produces something that is subtly wrong in ways that make the whole thing feel untrustworthy.
Step 1: Pick one task, and pick the right one
Do not start by documenting your whole business. Start with a single task that meets these conditions:
- It happens often, at least weekly
- More than one person does it, or will
- It goes wrong occasionally in ways that cost money or goodwill
- You get asked about it repeatedly
That last one is the strongest signal. The questions you answer most often point directly at the process that is least documented.
Step 2: Watch it being done, once
Before writing anything, watch the person who does this task actually do it. Do not correct them while watching. Just note what actually happens, including the steps that are not in your head, the workarounds, and the small decisions they make without thinking. This step is where most of the value comes from, because the gap between how you think the task is done and how it is done is almost always larger than expected.
Step 3: Write it in the order it happens
Number the steps in the real sequence. Not grouped by category, not organized by importance. Sequence. For each step, three things:
- What to do, in plain words
- How to know it's done right, meaning the visible result
- What to do if it goes wrong, for the one or two most common failures
That middle one is the part almost everyone leaves out, and it is what turns instructions into something a person can check themselves against without asking you.
Step 4: Cut it in half
Write the full version, then remove everything that is explanation rather than instruction. Background, reasoning, and history belong somewhere else, or nowhere. A person mid-task needs to know what to do next, not why the policy exists. A good target: one page, or one screen on a phone. If a task genuinely cannot fit, it is probably two tasks.
Step 5: Put it where the work happens
- A printed sheet taped inside the cabinet where the supplies are
- A laminated card at the counter
- A pinned note in the team's group chat
- A photo in a shared album on their phone
The right location is wherever the person will actually be standing when they need it. A beautiful document in the cloud loses to an ugly printout in the right place, every time.
Step 6: Have someone else test it
Give the SOP to someone who does not normally do the task and ask them to follow it exactly, without asking questions. Watch where they hesitate. Every hesitation is a gap in the document. This test takes twenty minutes and catches more problems than another hour of writing would.
Step 7: Name one owner and one review date
Every SOP needs a single named person responsible for keeping it current, and a date when it gets looked at again. Without both, it slowly becomes wrong, and a wrong SOP is worse than none because people follow it into a mistake. Quarterly is enough for most processes. After any change to the task, immediately.
The language question
Write it in the language your staff actually works in. If your team speaks Taglish on the floor, write it in Taglish. An SOP in formal English that gets mentally translated at every step is an SOP with friction built into it. This feels informal. It is not. The document's only job is to be followed correctly, and clarity in the reader's real language beats formality every time.
What to do when they don't follow it anyway
Before assuming resistance, check three things honestly:
- Do they know it exists, and where?
- Is it accurate? If one step is wrong, people stop trusting all of it.
- Does following it make their job harder than the workaround? If the documented way takes longer than the way they already do it, they will keep doing it their way, and they may be right.
That third one deserves real consideration. Sometimes staff resistance to an SOP is useful information that your process is genuinely worse than theirs.
Start with three, not thirty
Pick your three most-asked-about tasks and document those. Live with them for a month. The habit of writing and using these matters far more than the coverage, and a business with three SOPs people actually follow is in better shape than one with thirty nobody opens. Those same documents become your training material and your insurance against a resignation.