One describes a process across people. The other describes a task inside one screen. The distinction only earns its keep when you notice they go stale for completely different reasons.
A standard operating procedure describes a whole process: every step, who owns each one, and the decisions along the way. A work instruction describes how to carry out a single task inside that process, usually in one tool, in enough detail that someone who has never done it can follow along.
The SOP is the route. The work instruction is the close-up of the one junction people keep getting wrong.
| SOP | Work instruction | |
|---|---|---|
| Scope | A process, start to finish | One task within it |
| Spans | Several people, several systems | Usually one person, one screen |
| Answers | Who does what, when, and why | Which button, in what order |
| Contains decisions | Yes: thresholds, approvals, exceptions | Rarely, and it should not |
| Typical length | One to three pages | As long as the clicks take |
| Goes stale when | The business changes | The software changes |
| Review cadence | Twice a year, or on policy change | Whenever the tool ships a redesign |
That last pair of rows is the part almost every explanation leaves out, and it is the one that actually changes what you do. More on it below.
An SOP documents a process that more than one person touches. It names the trigger that starts it, the sequence of steps, the role responsible for each one, and the points where somebody has to approve, escalate, or make a judgement call.
The defining feature is ownership. A list of steps with nobody's name against them is a checklist. Add the owner and the approval threshold and it becomes a procedure the business can actually hold together when the person who normally runs it is on holiday.
An SOP is also where policy lives. The refund limit, the escalation trigger, the service level you promise, the point at which a discount needs a second pair of eyes. Those are business decisions, and they belong in the document that survives your next software migration.
A work instruction takes one task and spells it out completely. Where to click, what to type, what the screen looks like when it worked, and what it looks like when it did not. It assumes no prior knowledge, because the person reading it is usually doing the task for the first time.
The term comes from manufacturing, where a work instruction sat at a workstation and told an operator how to run one machine. In a DTC brand the workstation is a browser tab. The task is issuing a partial refund in Shopify, or building a suppression segment in Klaviyo, or attaching a return label in your helpdesk. The principle is unchanged: one task, total detail, no assumed context.
If removing a step would leave someone unable to click the next thing, it belongs in a work instruction. If removing a step would leave someone unsure whether they are allowed to act at all, it belongs in the SOP.
Take a refund request arriving in your helpdesk. Here is the SOP, which spans three people and two systems:
Six steps, three roles, two decision points. Nothing in it tells you where any button is, and it does not need to. That document stays accurate if Shopify redesigns its admin next week.
Now the work instruction for step five, the only step with fiddly clicking in it:
Notice what happened at step three. The work instruction points back to the SOP rather than restating the rule. That is deliberate, and it is the habit that keeps the pair maintainable.
Try it on one of your own procedures.
Record a process once, AI writes the structured SOP. 3 free SOPs, no credit card.
Most articles on this topic stop at scope. Broad versus narrow, process versus task. Accurate, and it does not help you decide anything on a Tuesday morning.
The difference that matters operationally is that the two documents go out of date for completely different reasons, on completely different clocks.
An SOP goes stale when the business changes. You raise the refund threshold, add a warehouse, hire a support lead, switch 3PL. These are things you decide, which means you know the moment they happen and can update the document deliberately.
A work instruction goes stale when the software changes, and nobody tells you. Shopify moves a button. Klaviyo renames a menu. Your helpdesk ships a redesign on a Tuesday. Every screenshot in the document is now subtly wrong, the steps still read as though they are correct, and you find out when a new hire gets stuck and asks in Slack.
Reviewing both documents on the same annual cycle guarantees your work instructions spend most of the year wrong. Their review cadence should follow your vendors' release cycles, not your policy calendar.
This is also the strongest argument for keeping policy out of work instructions. If the $200 approval threshold exists only inside the click-by-click guide, then the next time somebody rewrites that guide around a new interface, the threshold leaves with the old screenshots. The rule you actually run the business on disappears during what looked like a formatting update.
The mechanics of how a correct document quietly becomes a wrong one, and why nobody notices until it costs something.
SOPs should be written. They are about sequence, ownership and thresholds, and those come out of a conversation between the people who run the process. Recording somebody thinking about who should approve a refund produces a worse document than simply asking them.
Work instructions should be recorded, not written from memory. This is not a preference, it is a defence against a specific and very reliable failure.
Ask an experienced person to write down how they do a task and they will leave things out. Not carelessly: they have done it four hundred times, and the steps they have automated in their own heads no longer register as steps. Those omissions are precisely the ones a newcomer gets wrong, because the omitted step is usually the unobvious one. Recording the real run captures the clicks the expert forgot they were making, along with the exception they handle by reflex.
Why screenshots at each decision point beat paragraphs, and how to keep the visuals from becoming the thing that rots first.
Plenty of teams create both for everything, which is how a documentation library becomes something nobody opens. Most tasks need one or the other.
A reasonable default: write the SOP first. Then write a work instruction only for the steps people actually ask about twice. Two questions about the same step is the signal that the step needs its own document.
The pair fails in a predictable way. Somebody updates the SOP because policy changed, and the work instruction still shows the old threshold on a screenshot. Now you have two documents disagreeing, and staff quietly pick whichever one they saw first.
The ownership question underneath all of this. Documentation without a named owner degrades at a predictable rate.
None of this requires special software. It requires deciding which document holds the rules, which holds the clicks, and who is responsible when a vendor moves a button. Get that settled and the terminology question stops mattering, which is the point.
An SOP documents a whole process: the steps, the people responsible for each one, and the decisions along the way. A work instruction documents a single task within that process in click-by-click detail. The SOP tells you who refunds a customer and when approval is needed. The work instruction shows you exactly how to issue that refund in the software.
Usually it supports one step of an SOP rather than sitting inside it. Keeping them as separate linked documents works better in practice, because the work instruction needs updating far more often. If the click-by-click detail lives inside the SOP, every interface change forces you to reopen the document that holds your policy, and rules get lost during what should have been a cosmetic edit.
The SOP. It establishes who owns the process and where the decisions sit, which is the part that breaks a business when it is missing. Add work instructions afterwards, and only for the steps people actually ask about. A useful trigger is the second question about the same step: once is a one-off, twice means the step needs its own document.
SOPs twice a year, plus immediately after any policy, org or supplier change, since you know when those happen. Work instructions need reviewing whenever the underlying tool ships a visible change, which for most ecommerce software is several times a year and never announced in a way that reaches your documentation. Putting both on the same annual cycle leaves the work instructions wrong for most of it.
Often not. A team of three running one tool between them can get a long way with work instructions alone, because everyone already knows who does what. The SOP starts earning its place at the point where a process crosses more than one person, or where somebody has to be told they are allowed to make a decision without asking first.
3 free SOPs to start. No credit card required. See if drift detection keeps your docs honest.
Start for freeI built ReccordSOP after watching too many DTC ops teams lose months to undocumented workflows. These SOPs are battle-tested with Shopify operators running $1M to $50M brands.
Last reviewed September 1, 2026
Most SOPs are wrong within 90 days of publishing. Here's how to detect it before it costs you a customer.
Most SOP projects don't fail because the docs are bad. They fail because nobody follows them and nobody updates them.
More pictures is not the rule. The rule is matching the format to what the step is actually asking someone to do.
We use essential cookies for sign-in and a small amount of analytics to improve the product. Privacy policy.