A standard operating procedure (SOP) is a short written description of how a task is done in your business, step by step, so anyone trained to do it gets the same result. A useful SOP names the task, who does it and when, what they need, the steps in order, and how they know it is done correctly. The hard part isn't the format. It's writing SOPs people actually use, and keeping them up to date.
What an SOP is (and isn't)
An SOP covers one task that is repeated, such as processing a supplier invoice, onboarding a subcontractor or closing a job. It is not:
- A policy. A policy says what must happen ("purchases over a set amount need approval"). An SOP says how it is done.
- A process map. A process map shows how work flows between people and systems. SOPs sit underneath it, one for each task that needs detail.
- A training manual. SOPs assume the person knows the basics of their role and the systems they use.
What to put in an SOP
Keep the same headings for every SOP so people know where to look:
- Title and purpose. One line: what the task is and why it matters.
- Who and when. The role that does it (not a person's name), what triggers it and how often.
- What you need. Systems, access, documents or information the person needs before starting.
- Steps. Numbered, one action per step, starting with a verb: "Open", "Check", "Enter", "Send".
- Checks. How the person knows each important step worked, and what to do if it didn't.
- Owner and date. Who is responsible for keeping it current, and when it was last checked.
How to write one, step by step
- Pick the right tasks first. Start with tasks that cause problems: the ones only one person knows, the ones that go wrong, and the ones new staff struggle with.
- Watch it being done. Sit with the person who does the task best and record what they actually do, including the workarounds and the shortcuts. Don't write from memory or from how it is supposed to work.
- Write it in plain words. Short sentences, the names people actually use for things, and screenshots where a screen is confusing.
- Test it on someone else. Ask someone who doesn't normally do the task to follow the SOP. Every place they get stuck is a gap.
- Put it where the work happens. Link the SOP from the system or checklist where the task starts, not in a shared drive folder nobody browses.
- Set a review date. Systems and suppliers change. A yearly check, or a check whenever the system changes, keeps SOPs honest.
A short example
For example, an SOP for entering supplier invoices might read:
Purpose: Get supplier invoices into Xero correctly and on time.
Who and when: Accounts officer, daily, for invoices in the accounts inbox.
1. Open the accounts inbox and save each invoice to the bills folder.
2. Check the purchase order number on the invoice against the open purchase orders.
3. If the amounts match, enter the bill in Xero against the job code on the purchase order.
4. If they don't match, forward the invoice to the person who raised the order and flag it in the tracker.
Check: The bill shows in Xero with the job code and the PDF attached.
Why SOPs end up in a binder nobody opens
Most SOPs fail for the same reasons: they are written once by someone who left, they describe how things should work rather than how they do, they live somewhere nobody looks, and nobody owns them.
There is another reason worth noticing. If writing an SOP shows that a task involves copying the same details between two or three systems, checking a spreadsheet against an export, or chasing approvals by email, the SOP is documenting a problem. That is usually the point to fix the process, or automate the hand-off, and write a shorter SOP for what is left. If your processes are not written down at all, see process documentation and SOPs.
Frequently asked questions
What does SOP stand for?
Standard operating procedure: a written set of steps for doing a repeated task the same way every time.
How long should an SOP be?
As short as it can be while still being followed correctly. One to two pages is common. If an SOP runs much longer, it usually covers more than one task and should be split.
Should I use an SOP template?
A template helps keep SOPs consistent, so people know where to find things. But the template is the easy part. The value comes from watching the task being done, testing the SOP on someone else, and keeping it up to date.
Who should write SOPs?
The person who does the task best should help write it, with someone else asking questions and writing it down. The manager responsible for the work should approve it and own its review.
How often should SOPs be reviewed?
At least once a year, and whenever the system, supplier or rule behind the task changes. Put the review date on the SOP itself.
If your team runs on knowledge that lives in a few people's heads, book a free initial chat. We'll talk through which processes to document first, and which are worth fixing before you write them down.