SOP template (free Word download)
This is a free standard operating procedure (SOP) template in Word. It has every section an SOP needs: purpose, scope, roles, the steps themselves, exceptions, records and a revision history. Below it you'll find how to write one, a filled-in example and the mistakes that stop SOPs being used.
Running a company of 30 to 200 people? Documents like this are now worth money.
An SOP is a written, step-by-step description of how your company carries out one recurring process, so that anyone trained on it gets the same result. Write one for anything that happens often, is done by more than one person, or is expensive to get wrong.
What's in the template
Standard operating procedure
| SOP title | |
|---|---|
| SOP number | e.g. SOP-FIN-004 |
| Version | 1.0 |
| Effective date | |
| Process owner | |
| Approved by | |
| Next review date | |
| Applies to | Teams, sites or systems |
1. Purpose
One or two sentences: what this procedure achieves and why it matters.
2. Scope
What the procedure covers and what it doesn't. Name the teams, locations or systems it applies to.
3. Roles and responsibilities
| Role | Responsible for |
|---|---|
| Process owner | Keeps this SOP current and approves changes |
| Performer | Carries out the steps |
| Checker or approver | Reviews the output before it moves on |
| Back-up | Covers when the performer is away |
4. Definitions
| Term | Meaning |
|---|---|
5. Before you start
- Trigger: what starts this process
- Systems and access needed
- Inputs: documents or data
- Tools or materials
6. Procedure
| Step | Action (start with a verb) | Who | Output or check |
|---|---|---|---|
| 1 | |||
| 2 | |||
| 3 | |||
| 4 | |||
| 5 | |||
| 6 | |||
| 7 | |||
| 8 |
7. Exceptions and escalation
| If | Then | Escalate to |
|---|---|---|
8. Quality checks and records
- What is checked, by whom
- Which records are kept, and where
- How long records are kept
9. Related documents
- Policies, work instructions, forms and process maps this SOP relies on
10. Revision history
| Version | Date | What changed | By | Approved |
|---|---|---|---|---|
| 1.0 | First issue | |||
How to write an SOP
- Pick the right process first. Start with work that happens often, goes wrong in costly ways, or that only one person knows how to do. If the answer to "what happens when they're on holiday?" is "it waits", that process needs an SOP.
- Watch it being done, then write. Sit with the person who does it best and write down what actually happens, including the judgement calls, rather than the official version.
- Write one action per step, starting with a verb. "Match the invoice to the purchase order" is clearer than "the purchase order should be checked". If the reason for a step isn't obvious, put it in the output column.
- Choose a format that fits. A simple numbered list works for short, linear processes. Use numbered sub-steps for longer ones, and add a process map when there are many decisions or handoffs between people.
- Test it on someone new. Ask a colleague who has never done the task to follow it without help. Every question they ask is a gap in the document.
- Approve it, date it and publish it where the work happens, then link it from your operations manual so people can find it.
- Review it on a schedule, at least yearly and whenever the process, system or rules change, and record each change in the revision history.
Example: paying a supplier invoice
A filled-in procedure for a fictional 60-person distribution company, to show the level of detail that works.
Purpose: make sure supplier invoices are checked against what we ordered and received, approved by the right person, and paid on time. Scope: all supplier invoices sent to the finance inbox; payroll and expense claims are excluded.
| Step | Action | Who | Output or check |
|---|---|---|---|
| 1 | Save the invoice from the finance inbox and log it in the payables tracker | Accounts assistant | Logged with the date received |
| 2 | Match it to the purchase order and the delivery note | Accounts assistant | Quantities and prices agree |
| 3 | If anything differs, email the buyer and put the invoice on hold | Accounts assistant | Hold reason logged |
| 4 | Code it to the right cost centre and account | Accounts assistant | Coded in the accounts system |
| 5 | Send it for approval: the budget holder up to £5,000, the finance director above that | Accounts assistant | Approval recorded |
| 6 | Add approved invoices to the Thursday payment run | Finance manager | Payment run list |
| 7 | Release the payments and send remittance advice | Finance director | Remittances sent |
Exception worth copying: if a supplier's bank details change, phone them on a number you already hold (never one from the email that announced the change) before paying. Invoice redirection fraud relies on that step being skipped.
Common mistakes
- Writing the ideal process instead of the real one. People follow what works for them; if the SOP doesn't match, they ignore it.
- Steps that hide a decision, such as "process the order as appropriate". Spell out the rule, or point to who decides.
- One document trying to do everything. If an SOP keeps growing, split it into separate processes, or move the fine detail into a work instruction.
- No owner and no review date, so it quietly goes out of date.
- Stored where nobody looks. An SOP in a folder nobody opens is the same as no SOP.
Frequently asked questions
What's the difference between a policy, an SOP and a work instruction?
A policy states a rule and why it exists. An SOP describes how a whole process runs, usually across several people. A work instruction shows one person how to do one task in fine detail. See the work instruction template.
How long should an SOP be?
As short as it can be while still being complete. One process per SOP; if you need several pages of detail for a single step, that detail belongs in a work instruction.
Who should write SOPs?
The person who does the work writes the first draft, because they know the real steps. The process owner reviews and approves it.
How often should SOPs be reviewed?
At least once a year, and whenever the process, the software or a rule changes. Record each change in the revision history so people know they have the current version.