How to write an SOP: 7 steps, an example and a checklist

A standard operating procedure (SOP) is a set of written instructions for a routine or repeated task. The US Environmental Protection Agency’s SOP guidance (QA/G-6) defines it in much the same words: written instructions that document a routine or repetitive activity. The aim is consistent results, whoever does the work.

To write one: pick a single task, watch someone do it, write numbered steps with one action each, add an owner and a review date, test it on someone new, and store it where the work happens. The sections below explain each step. There is a full example and a checklist at the end.

Why SOPs stop being used

Three problems are common:

• The SOP describes the ideal process, not the real one. People notice and stop trusting it.
• It is too long. A long document for a 10-minute task will not be read mid-task.
• Nobody owns it. Tools, prices and people change. The document does not.

The EPA guidance makes a related point: even a well-written SOP fails if it is not followed, and copies need to be easy to reach where the work is done. Most of what follows is about avoiding these three problems.

Step 1: Decide which tasks need an SOP

Not every task needs one. Start with work that is:

• repeated at least weekly,
• done by more than one person, or likely to be handed over,
• costly when done wrong (money, customers, compliance),
• or something new hires always ask about.

List 10 to 15 candidates, then pick the three that hurt most when they go wrong. Write those first. If you want a sense of what manual work is costing you overall, the time leak calculator gives a rough yearly figure.

Some work must be written down. In the UK, for example, food businesses need a food safety management system based on HACCP principles, and they must record their controls, checks and corrective actions (GOV.UK). If your work is regulated, check your regulator’s rules before you decide what to document.

Step 2: Keep each SOP to one process

Write one SOP per process, with a clear start and a clear end. “Onboard a new client” is too wide. “Set up a new client in the billing system” is right.

A useful test: can you name the trigger (what starts it) and the finished state (how you know it is done)? If not, the scope is still vague.

Step 3: Capture what really happens

Do not write from memory or from a manager’s idea of the process. Sit next to the person who does the task and watch them do it once, start to finish. Ask them to talk through each step. The EPA guidance also says SOPs should be written by people who know the activity, and ideally the people who do the work.

Note down:

• the exact tools and screens they use,
• the decisions they make (“if the order is over the limit, I ask for approval”),
• the workarounds they use,
• the things that go wrong.

The workarounds matter most. They often hold the knowledge that makes the process work. If the process is large or crosses teams, map it first. Our guide to process mapping for small businesses shows how.

Step 4: Choose a format and write the steps

Pick the simplest format that fits the task.

A flowchart or checklist can sit inside a numbered SOP. The EPA guidance treats a checklist as part of an SOP, not a replacement for it.

For the steps themselves, use a numbered list. Start each step with a verb. Put one action in each step.

Good: “Open the order in the admin and check the shipping address.” Weak: “The address should be verified prior to dispatch.”

A few rules that keep steps usable:

1. One action per step. If a step has “and” in it, split it.
2. Name the exact place. “Click Orders, then Export” beats “export the data”.
3. Show the decision rules. Write “If X, do Y. Otherwise, do Z.” Do not hide rules in paragraphs.
4. Add a screenshot only where people get lost. Screenshots are the first thing to go out of date when a tool changes its screens.
5. Say what done looks like. For example, “The invoice shows status Sent.”

Write the way you would talk to a capable new colleague on day two. Plain words, short sentences, no jargon you would not use out loud. The EPA guidance asks for the same: concise, active voice, not wordy. It also says to write with enough detail that someone with limited experience, but a basic understanding, can do the task unsupervised.

Step 5: Add the parts people skip

A good SOP is more than steps. Add a small header and a few short sections:

The owner and the review date do the most work. They turn a document into something that is maintained. Free starting points are in our SOP templates.

Step 6: Test it with someone new

Give the draft to a person who has never done the task. Watch them follow it without help. Do not explain anything.

Every time they stop, ask a question or do something different, the SOP has a gap. Fix it, then test again. The EPA guidance also recommends that drafts are tested by someone other than the writer before they are finalised. Authors read what they meant to write. A new reader reads what is on the page.

Step 7: Put it where the work happens

An SOP in a folder nobody visits is the same as no SOP. Store it where people already work, and make it one click away. Link it from the tool, the ticket template or the team chat channel. Keep one current copy. Old copies in email attachments are how people end up following the wrong version.

Then set a review rhythm. The EPA guidance suggests reviewing SOPs on a regular cycle, for example every one to two years, and updating them whenever the procedure changes. For a small team with tools that change often, a shorter cycle such as every quarter is a reasonable choice. Record the review date each time. If a process is no longer followed, archive its SOP so it does not mislead anyone.

Add a line: “If a step is wrong, tell the owner or fix it and flag it.” People will use a document they are allowed to correct.

Example SOP: process a customer refund request

Here is a short example in a format you can copy. The numbers in it (30 days, 200) are placeholders for illustration. Use your own rules.

Purpose: Refund customers correctly and record why. Owner: Support lead. Version: 1.0. Last reviewed: 12 Nov 2026. Trigger: A customer asks for a refund by email or chat. Tools: Helpdesk, store admin, finance sheet.

Steps

1. Find the order in the store admin using the order number or email.
2. Check the request against the refund policy and the consumer law where the customer lives. If the order is older than 30 days or the item is marked final sale, go to Exceptions. Do not decline until you have checked what the law allows.
3. Reply to the customer and confirm the refund amount and method. Use the saved reply “Refund confirmed”.
4. Open the order and choose Refund. Enter the item or amount. Choose whether to restock the item.
5. Add the reason code to the order note (damaged, wrong item, changed mind, other).
6. Add one line to the finance sheet: order number, amount, reason code, date.
7. Tag the helpdesk ticket “refunded” and close it.

Exceptions: For refunds above 200, ask the support lead for approval before step 4. For orders outside the policy window, send the ticket to the support lead.

Done when: The customer has a confirmation, the order shows as refunded, and the finance sheet has a new line.

Notice what it does not contain: background, history, long explanations. It says what to do, in order, and what to do when the normal path fails. A fuller version is in our customer refund request template.

SOP checklist

Before you publish an SOP, check that it:

• covers one process with a clear trigger and end,
• was written from watching the real task,
• uses numbered steps with one action each,
• states the decision rules and exceptions,
• names an owner, a version and a review date,
• was tested by someone who had never done the task,
• is stored where the work happens,
• is short enough to read in a few minutes.

Common questions

How long should an SOP be?

As short as the task allows. If the steps do not fit on one or two pages, the process is probably too wide. Split it into smaller SOPs that link to each other.

Who should write the SOP?

The person who does the task, or someone who watches them do it. A manager’s version of the process is often different from what happens on the floor.

How is an SOP different from a process map?

A process map shows how work flows across people and systems, so you can find problems. An SOP tells one person how to do one task. Map first if the process crosses teams, then write SOPs for the steps that need them.

How is an SOP different from a checklist?

A checklist reminds a trained person what to confirm. An SOP also explains how to do each step and what to do when something goes wrong. Many SOPs end with a checklist.

Do small businesses need SOPs?

No general law requires a small business to have SOPs, but some regulated work needs written procedures, such as food safety in the UK. Outside those cases, they pay off most for tasks that are repeated, costly when wrong, or handed between people.

When an SOP is not enough

Some tasks are better fixed than documented. If an SOP has 25 steps, three copy-and-paste moves between systems, and a note that says “be careful here”, the process itself needs work. Simplify it first. Then decide whether to document it or automate it. Our guide on what to automate first explains how to choose.

If you want help with the documentation itself, our consulting and SOPs service covers mapping, writing and rollout.

Key takeaways

• Write SOPs for repeated, costly or handover-prone tasks, and start with three.
• One SOP covers one process, with a clear trigger and finished state.
• Watch the real task being done. Do not write from memory.
• Use numbered steps, one action each, with decisions written as if/then.
• Name an owner, a version and a review date, or the SOP will decay.
• Test with someone new, and store the SOP where the work happens.

If you want a second pair of eyes on which processes to document first, we offer a free audit.