Standard operating procedure. The phrase alone makes small business owners tired, because it sounds like a binder that takes six months to write and lives in a drawer.
That version is useless. The useful version takes about twenty minutes.
What an SOP is actually for
One thing: so that someone other than the person who normally does it can do it correctly.
Not compliance. Not a manual. Not a training program. Just: could a competent person who has never done this task get it right by reading this?
That is the whole test, and it changes what you write.
The twenty-minute version
Pick a task you do regularly. Then do it — actually do it, right now, in real time — and record yourself doing it.
Screen record if it is on a computer. Voice memo if it is not. Narrate what you are doing and, more importantly, why you are doing it that way.
Then have the recording transcribed and clean it into steps. That is it. You have an SOP and it took the length of the task plus fifteen minutes.
This works because the hard part of documentation is not writing, it is remembering all the small decisions you make automatically. Doing the task surfaces them. Sitting down to write it from memory does not.
What to include
- The trigger. What starts this task? A form submission, a phone call, a day of the week, a customer request.
- The steps, in order, with enough detail that someone could follow them.
- The decisions. This is the part people leave out and it is the most valuable part. "If the customer is more than 30 miles out, add the travel charge." "If they ask for a discount, you can go to 10 percent without asking me."
- What done looks like. How does the person know they finished correctly?
- Who to ask when something is not covered.
What to leave out
- Background, philosophy and the history of why the business does it this way.
- Anything about a system nobody uses anymore.
- Screenshots that will be out of date in a month. Describe what to click, not what the button looked like in 2026.
- Perfect formatting. A working document in plain text beats a beautiful one that does not exist.
Where to put it
Somewhere your team already goes. If they live in a group chat, put it where the group chat can find it. If they use a shared drive, use that.
The single most common reason SOPs fail is that they are stored somewhere nobody opens. A mediocre document in the right place beats an excellent one in the wrong place.
Which ones to write first
In order:
- The thing you get asked about most. Every repeated question is an undocumented process. If three people have asked you the same thing this month, write that one.
- The thing only one person knows. That is a single point of failure and it will become a crisis on their last day. See what happens when your key employee leaves.
- The thing that goes wrong most. Errors usually mean the process is undefined, not that people are careless.
- The thing you want to hand off. You cannot delegate what does not exist in writing.
Do not try to document everything. Four good SOPs covering your most frequent work is transformational. Forty covering everything is a project you will abandon.
Keeping them alive
An SOP written once and never touched becomes wrong, and a wrong SOP is worse than none because people stop trusting all of them.
The lightest version that works: whoever follows the procedure and finds it wrong fixes it, right then. Not a review cycle. Not a quarterly audit. The person who hit the problem edits the document.
That only works if editing is easy and if nobody gets in trouble for changing it. Make both true.
Where this leads
Once a process is written down, two things become possible that were not before.
You can hand it to a person. And you can hand it to a system — because the moment a process is explicit enough for a new hire to follow, it is usually explicit enough to automate the boring half of it.
That is the actual payoff. Documentation is not the end goal. It is the step that makes everything after it possible.