SOP vs Process vs Work Instruction vs Policy: The Differences
Policies, processes, SOPs and work instructions answer different questions at different levels of detail. Here is what each one is, how they fit together and when you need which.
The short answer
A policy says what must happen and why. A process shows the overall flow of work from start to finish. An SOP explains how to do one task in that flow, step by step. A work instruction shows exactly how to perform a single step in detail. Each level is more specific than the one before it, and each one serves a different reader.
Comparison table
| Term | What it is | Who uses it | Example | Who owns it |
|---|---|---|---|---|
| Policy | A rule or principle: what must or must not happen, and why | Anyone whose work it applies to, across many tasks | Refunds over a set amount need manager approval | Leadership or the owner of that area |
| Process | The end-to-end flow of work: stages and hand-offs | The people and teams the work passes between | Order to cash: quote, order, fulfil, invoice, collect | Process owner, often a department head |
| SOP | Numbered steps for completing one recurring task | Anyone who performs the task, including someone new to it | Issue a customer refund | The manager or lead of the team that performs it |
| Work instruction | Exact directions for one step: clicks, settings, values | Whoever performs that step, especially someone unfamiliar with the tool | Issue a partial refund in the payment system | The person or team closest to the tool |
The differences people ask about most
SOP vs policy
A policy states the rule; an SOP applies it. “Refunds over a set amount need manager approval” is a policy. “Issue a customer refund” is an SOP, and one of its steps is to request that approval. A policy tells people what must or must not happen and why; it does not tell them how to do the work.
SOP vs work instruction (procedure vs work instruction)
An SOP covers a whole task and who does it. A work instruction zooms in on a single step of that task, with the exact clicks, settings or values needed to perform it. The SOP says “issue the refund to the original payment method”; the work instruction shows how to do that in the payment system. “Procedure” on its own usually means the same thing as SOP, so the same difference applies.
SOP vs process
A process is the end-to-end flow of work, often across several people or teams. An SOP is the step-by-step instructions for one task within that flow. If a document covers five people and three departments, it is a process, and each task in it gets its own SOP.
SOP vs training manual
An SOP is one document for one recurring task. A training manual is a collection: a selection of SOPs in learning order for one role. Our guide on how to create a training manual shows how to build one from your SOPs.
Definitions
People use “SOP,” “process,” “procedure,” “work instruction” and “policy” as if they meant the same thing. They do not, and mixing them up produces documents that are either too vague to follow or too detailed to maintain.
Policy
A policy is a statement of a rule or principle the business commits to: what is required, what is allowed, what is not, and usually why. It does not tell you how to do the work. “All refunds over a set amount require manager approval” is a policy. So is “customer data is never shared outside the company without written consent.”
Policies change rarely, are usually approved by leadership, and apply across many tasks.
Process
A process is the end-to-end sequence of activities that turns an input into an outcome, often passing between several people or teams. “Order to cash,” “hire to onboard” and “lead to signed deal” are processes. A process answers: what happens, in what order, and who hands off to whom?
Processes are often drawn as flowcharts or swimlane diagrams. They show the shape of the work, not the detail of each task.
SOP (standard operating procedure)
An SOP (standard operating procedure) is a written, step-by-step document that explains how to complete one recurring task within a process, so that anyone with the right access can do it correctly and consistently. It includes the purpose, the trigger, who performs it, the steps and what “done” looks like. “Issue a customer refund” is an SOP. It follows the refund policy and sits inside the order-to-cash process.
“Procedure” on its own usually means the same thing as SOP in a small or mid-sized business. Some regulated industries use the terms more precisely, but for most teams they are interchangeable.
Work instruction
A work instruction is the most detailed level: exact directions for performing a single step or activity, often with screenshots, settings or specific values. “How to issue a partial refund in the payment system: click Payments, find the charge, select Refund, enter the amount…” is a work instruction. It is the zoomed-in view of one step in an SOP.
Work instructions are most useful where the step is technical, easy to get wrong, or performed by someone unfamiliar with the tool.
What about checklists, guidelines and standards?
A few other terms come up often enough to place on the same ladder:
- Checklist: a format, not a level. An SOP or a work instruction can be written as a checklist when the reader already knows how and just needs to not forget anything. Our guide to SOP format covers when a checklist beats numbered steps.
- Guideline: a recommendation rather than a rule. Where a policy says “must,” a guideline says “should, unless you have a good reason.” Guidelines sit at the policy level but leave room for judgment.
- Standard: a measurable requirement the output has to meet, such as a response time or a quality bar. Standards usually live inside a policy or at the end of an SOP as the definition of “done.”
- Playbook or manual: a collection. A sales playbook or an operations manual is a bundle of processes, SOPs and work instructions for one area, not a separate type of document.
If a document does not fit neatly on the ladder, ask what question it answers. “What is the rule?” is a policy. “What happens overall?” is a process. “How do I do this task?” is an SOP. “How exactly do I do this step?” is a work instruction.
Level of detail at a glance
| Term | What it answers | Level of detail |
|---|---|---|
| Policy | What must or must not happen, and why? | Low: a rule or principle |
| Process | What happens from start to finish, and who hands off to whom? | Low to medium: stages and hand-offs |
| SOP | How do I complete this task correctly every time? | Medium: numbered steps for one task |
| Work instruction | Exactly how do I perform this one step? | High: clicks, settings, values |
How they fit together: one worked example
Take refunds at a small online homewares shop (an invented example).
Policy: “Customers can return unused items within a set window for a full refund. Refunds above a set amount require manager approval. Refunds go back to the original payment method.”
Process: Returns and refunds. The customer requests a return, support approves it, the warehouse receives and inspects the item, finance issues the refund, support confirms with the customer.
SOP: “Issue a customer refund,” owned by the finance lead.
- Open the approved return in the order system.
- Confirm the warehouse has marked the item received and in resaleable condition.
- If the refund amount is above the approval threshold, request manager approval and wait for it.
- Issue the refund to the original payment method (see work instruction).
- Mark the order refunded and send the confirmation email template.
Work instruction: “Issue a refund in the payment system,” a click-by-click guide with screenshots for step 4, including how to handle a partial refund when only some items were returned.
Notice how each level points to the next. The SOP does not repeat the policy; it applies it in step 3. The SOP does not contain every click; it links to the work instruction for the technical step. That separation is what keeps each document short and easy to update. When the payment system changes its screens, you update one work instruction and the SOP stays correct.
When you need each one
Write a policy when a decision needs to be made the same way every time regardless of who makes it, or when there is a legal, financial or safety reason for a rule.
Map a process when work passes between people or teams and things fall through the gaps at the hand-offs, or when you are designing or redesigning how something works.
Write an SOP when a task recurs, someone new needs to be able to do it, and consistency matters. This is the document most small businesses need most of. For the method, see how to write an SOP for your business.
Write a work instruction when a single step is technical enough that people get it wrong, or when the step happens in software that people rarely use.
Common mistakes
Writing a policy and calling it an SOP. A document full of “must” and “never” with no steps tells people what to avoid but not what to do.
Cramming a process into one SOP. If a document covers five people and three departments, it is a process. Split it into one SOP per task and link them in order.
Putting every click in the SOP. An SOP that includes every screen becomes hard to read and breaks every time the software updates. Move the clicks into a work instruction, or attach screenshots to the relevant step instead of writing them out.
Leaving ownership vague. Each document type has a different natural owner. A policy owned by “the team” or an SOP owned by nobody will drift out of date. Our page on keeping SOPs current covers owners and review intervals.
A practical setup for small and mid-sized teams
Most teams do not need four separate document libraries. A simple setup that works:
- A short set of policies, kept in one place under a Company heading: the handful of rules that apply across the business.
- An SOP for each recurring task, organized by business area, with each SOP citing the policy it applies.
- Work instructions folded into SOPs as screenshots or detailed sub-steps, split out only when a step is complex enough to need its own page.
- Processes represented by the order of your SOPs, and a simple flowchart where hand-offs are complicated.
In SOPCompass, that structure maps onto Company plus five business pillars that follow the customer journey, with department tags as a second way to browse. For software steps, you can record your screen once and get a step-by-step guide with screenshots, which covers most of what a separate work instruction would.
Whatever tool you use, the distinction is what matters. Once your team knows that a policy is a rule, a process is the flow, an SOP is the task and a work instruction is the step, documents become easier to write, easier to find and much easier to keep correct. For a look at how the step layout of an SOP can vary, read our guide to SOP format, and for more complete examples, see 10 SOP examples from real business functions.