How to write standard operating procedures your team will actually use
Most businesses run on knowledge that lives in a few people's heads. Good standard operating procedures get that knowledge onto the page, so work gets done the same way every time, whoever is doing it.
Key takeaways
- An SOP should describe how the work is really done today, written with the people who do it, not how a manager imagines it.
- Start with processes that are frequent, error-prone or known by only one person. You do not need to document everything at once.
- Match the format to the task: a checklist for routine work, numbered steps for detailed procedures, a flowchart where decisions branch.
- Give every SOP an owner and a review date. A procedure nobody updates quickly becomes one nobody trusts.
What an SOP is, and what it is not
A standard operating procedure, or SOP, is a written set of instructions for completing a routine task the same way every time. It tells someone what to do, in what order, with which tools, and what "done" looks like.
An SOP is not a policy. A policy says what the rules are, for example "refunds over a set amount need approval". The SOP says how to follow them: where to raise the request, who approves it, and what to record once it is done.
Written well, SOPs pay off quickly:
- Consistency: customers get the same result whoever handles their request.
- Faster onboarding: new starters learn from a document instead of shadowing a busy colleague for weeks.
- Resilience: holidays, sick days and resignations stop being a risk to the business.
- A base for improvement: you cannot automate, outsource or fix a process that nobody has written down.
Decide which processes to document first
Trying to document every process at once is the fastest way to stall. Start with a simple list of the recurring tasks in each team, then pick the ones that score high on any of these:
- Frequency: tasks done daily or weekly, such as invoice processing, order updates or account onboarding.
- Error cost: tasks where a mistake is expensive or hard to reverse, such as payments, compliance checks or customer data changes.
- Single points of failure: tasks only one person knows how to do. These are the ones that hurt most when that person is away.
- Change on the way: tasks you plan to hand to a new hire, a partner or a piece of software in the next few months.
Five to ten well-written SOPs covering your most important work will do more than fifty half-finished ones.
Write it with the people who do the work
The person who does a task every day knows the shortcuts, the exceptions and the reasons behind the odd steps. A manager writing from memory usually describes the process as it was designed, not as it is done.
The simplest method is to watch and ask. Sit with the person while they complete the task, or ask them to record their screen and talk through what they are doing. Note every step, every system they open and every judgement call they make. Pay special attention to the moments they say "it depends": those are the exceptions the SOP must cover.
Then write a first draft and give it to someone who has never done the task. Wherever they get stuck, the document is missing something.
If a new starter cannot follow it on their own, it is not finished yet.
Pick the right format for the task
There is no single right template. Choose the format that makes the task easiest to follow:
- Checklist: for short, routine tasks where the person already knows how, but order and completeness matter. Month-end close and new-account set-up are good examples.
- Numbered steps: for detailed procedures that someone may be doing for the first time. Add screenshots for any step inside a software tool.
- Flowchart: for processes with decisions, where the next step depends on an answer, such as whether a document is valid or a request needs escalating.
- Short video: for visual, hands-on tasks. Pair it with written steps, because nobody wants to scrub through a video to find step seven.
Whatever the format, give every SOP the same header: a clear title, its purpose, who it is for, the tools needed, the owner and the date of the last review.
Write steps anyone can follow
The test of a good SOP is simple: can a capable person who has never done the task complete it correctly using only the document? A few habits make that far more likely.
- Start each step with a verb: "Open", "Check", "Send", "Record". One action per step.
- Use the exact names people see on screen, such as button labels, field names and folder paths.
- Say what good looks like. "The status changes to Approved" tells the reader they did it right.
- Cover the common exceptions, and say who to ask when something falls outside the document.
- Explain the why behind any step that looks unnecessary. People skip steps they do not understand.
Keep the language plain. Short sentences and everyday words work better than jargon, especially for teams working in a second language or across different locations.
Keep your SOPs alive
An SOP that is out of date is worse than none, because people follow it and get the wrong result. Most SOP libraries fail not because they were badly written but because nobody kept them current.
Give every SOP a named owner, usually the lead of the team that does the work, and a review date, typically every six or twelve months. Update it straight away whenever a tool, a rule or a team changes. Keep all SOPs in one searchable place that everyone can reach, and make it easy for anyone to flag a step that no longer matches reality.
Once your processes are documented and stable, you have more options. Repetitive, rule-based steps become good candidates for automation, and whole workflows can be handed to an extended team through back-office outsourcing without losing quality. Clear SOPs are also what help support teams answer customers faster.
Frequently asked questions
As short as possible while still being complete. Many good SOPs fit on one or two pages. If a procedure runs much longer, it is often several processes that should be split into separate documents and linked together.
The best tool is the one your team already opens every day. A shared drive, an internal wiki or a knowledge base all work, as long as SOPs are in one place, easy to search, and show who owns each document and when it was last reviewed.
It helps a great deal. A documented process shows exactly what needs to be done, where the exceptions are and what good output looks like. A good partner can help you write SOPs as part of the handover, but starting with your own draft makes the move faster and safer.
