TL;DR:
An SOP is a short written way to do a repeated job so it comes out the same whoever does it.
Include purpose, who it is for, numbered steps, screenshots where a screen could confuse, and an owner and review date.
Test it by having someone who has never done the job follow it with you silent.
Someone is away, and a customer order sits unprocessed because only that person knows the way. A standard operating procedure, or SOP, is the written answer: the job explained so a capable stranger can do it correctly the first time. It is not a policy binder. A good one is a page or two that people actually open.
When a job deserves an SOP
Write one when a task repeats, when mistakes cost money or time, when more than one person might do it, or when you are about to hand it to someone new. Do not write one for a task you do once a year with no consequences. A note will do.
Before you write
Do the task yourself once, slowly, and write down what you actually do, not what you think you do.
Decide who will read it. Write for someone smart who has not done this job, which means no unexplained shortcuts or initials.
Collect what the task needs: logins you will refer to by name only, links, templates, and example files.
Safety: Never put passwords, card numbers or one-time codes in an SOP. Write "sign in with your own account" or "ask the owner for access" and say where the credentials are kept. Check with whoever manages your company's rules if you are unsure what may be written down.
Step by step
Name it by the job: Use a title that starts with a verb: "Process a new order". People search by what they need to do.
Write the purpose in one or two sentences: Say what the job is for and what done looks like. This lets a reader decide what to do when a step does not quite fit.
List what is needed before starting: Access, files, forms, and any approval required.
Number the steps: One action per step, starting with a verb. Keep each step short enough to do without re-reading.
Add screenshots where a screen could confuse: Crop to the part that matters and mark the button or field. Skip screenshots for obvious steps, since they go out of date when an app changes.
Say what to do when it goes wrong: Add a short "If this happens" list for the usual failures and a person to ask.
Add an owner and review date: The owner keeps it correct; the date says when it must be checked again.
Worked example: an SOP for processing orders
Here is a full short SOP for a small online shop. It is written as a reader would see it.
SOP: Process a new order
Owner: Dana (operations) Last reviewed: 2026-11-09 Next review: 2027-02-09
Purpose
Get every paid order packed, labelled and marked shipped within one working day,
with the right items and the right address.
Before you start
- You can open the shop's order list and the shipping label tool.
- Packing supplies are stocked (boxes, tape, labels).
Steps
1. Open the order list and filter to "Paid, not shipped".
2. Open the oldest order first.
3. Check the items and quantities against the shelf. Count, do not guess.
4. Check the address has a street, a city and a postal code. If anything is missing, go to "If something is wrong".
5. Pack the items and add the packing slip.
6. Create the shipping label and stick it flat on the box.
7. Mark the order "Shipped" and paste the tracking number into it.
8. Move to the next order. Stop when the filter shows none.
If something is wrong
- Out of stock: message the customer the same day with the choices (wait, swap, refund). Ask Dana before refunding.
- Address unclear: email the customer and leave the order unshipped.
- Label will not print: try a second browser; if it still fails, tell Dana.Look at what this SOP does. The purpose lets a reader judge edge cases. Each step is one action. The owner and review dates mean somebody is responsible. And the "If something is wrong" list covers the common failures instead of leaving the reader stuck.
Where screenshots help
In this SOP, two steps deserve a screenshot: step 1 (where the "Paid, not shipped" filter is) and step 6 (where the label button sits). The other steps are physical or obvious. Two images keep the page light and easy to update. Mark each image with a box or arrow, and write the label name in the step too, so the step still works if the picture is out of date.
A quick count: eight steps, two screenshots, three exceptions. If your own draft has thirty steps, split it into two SOPs, such as "Process an order" and "Handle a return".
Writing steps that survive a busy day
Start each step with a verb: open, check, paste, send. Put the reason in a short clause when it is not obvious, for example "Count, do not guess, because a wrong count means a second shipment." People follow a rule more carefully when they know what it protects.
Name things exactly as they appear on screen. If the button says "Create label", write "Create label", not "make the shipping thing". When an app renames a button, update the step and the review date together.
Test it before you publish
Give the SOP to someone who has never done the job and watch them follow it without helping. Every question they ask is a missing line. Fix it, then run it again. This takes twenty minutes and finds more problems than reading it over yourself.
Mistakes to avoid
Writing from memory instead of doing the task as you write.
Steps that hide two actions: "Check the order and pack it".
No owner, so the document goes stale and people stop trusting it.
Pasting screenshots of whole screens. Crop them.
Storing it where nobody looks. Link it from the place the job starts.
Doing it faster
Record yourself doing the job once, narrating, then turn the narration into numbered steps. If you want a second pair of eyes, DuckyHelper can look at what is on your screen and talk through whether a step is clear while you draft. You still decide what the procedure says.
Frequently asked questions
How long should an SOP be?
As long as the job needs and no longer. One to two pages is typical, and a job that needs more probably wants to be split.
How often should I review it?
Pick a date when you write it, and also review whenever the tool or the way you do the job changes.
Should I use a checklist or paragraphs?
Numbered steps for the actions, short paragraphs for the purpose and for explaining why.
Get started
