A client once handed me a binder labeled "Policies and Procedures" and asked me to fix it. Inside were forty pages of policy, procedure, and work instruction stacked on top of each other with no line drawn between them. Nobody on her team could tell which page to open when a machine jammed, and that confusion was costing her more than the binder itself was worth.
What is the difference between an SOP and a policy?
A policy states a rule or a position the company holds. A standard operating procedure tells one person how to perform one task, step by step, to reach a specific result. A policy answers what is required and why; an SOP answers how the work actually gets done. They serve different readers and belong in different documents.
A safety policy might state that all operators wear hearing protection on the floor. The SOP for changing a filter never mentions hearing protection unless the step itself calls for it. Fold the two together and you get a document too abstract to guide the hands and too procedural to state the company's actual position.
What is a work instruction, and how is it different from an SOP?
A work instruction is narrower than an SOP. Where an SOP covers a full task from start to finish, a work instruction covers a single step within that task, usually one that needs extra detail: a torque setting, a screen sequence, a diagram of where a part goes. Work instructions live inside or alongside an SOP. They don't replace it.
Think of the SOP as the map and the work instruction as the close-up photograph of one intersection. A procedure for closing the month might reference a separate work instruction for reconciling a specific account, because that one step carries more variables than the rest of the process and has earned its own page.
Why do companies confuse these three documents?
Most companies never separated them in the first place. Documentation usually starts with one overworked person writing down whatever seems useful at the time, and policy, procedure, and instruction end up on the same page because nobody assigned different jobs to different formats. The confusion isn't a writing problem. It's a structural one.
I saw this constantly on the manufacturing floor. A "procedure" would open with a paragraph about why quality mattered to the company, which is policy, move into numbered steps, which is the actual SOP, then drop into a table of torque specs halfway through, which belonged on its own work instruction. Anyone reading it had to hold all three registers in her head at once.
What happens when you use the wrong document for the job?
The reader either gets too little detail to perform the task or too much detail to find the step she needs. Both failures cost the same thing: time. A worker hunting through policy language for a single instruction will interrupt a supervisor rather than keep reading, and that interruption is the real price of the wrong format.
It also shows up in audits. An auditor asking for evidence of a control wants the procedure, not the philosophy behind it. Handing over a policy statement when a step-by-step SOP was requested reads as a document that was never actually followed, whether or not the work itself was done correctly.
How do you decide which document you actually need?
Ask what question the reader is bringing to the page. If she's asking what the company requires or why, write a policy. If she's asking how to perform a task from start to finish, write an SOP. If she's asking how to execute one specific step correctly, write a work instruction. The reader's question decides the format, not how much you have to say about it.
This sounds simple, and it is, but it takes discipline to hold to. The temptation is always to explain the reasoning behind a step in the middle of the step itself. Save the reasoning for the policy, or leave it out entirely. The person performing the task at six in the morning doesn't need the rationale in front of her. She needs the action.
Can one document combine an SOP and a work instruction?
Sometimes, if the task is short enough that a reader can hold the whole thing in view without flipping pages. Once a single step needs more than a few lines of detail, split it into its own work instruction and link to it, rather than letting one step balloon and bury the rest of the procedure.
A rule of thumb I use with clients: if a step needs a diagram, a table, or more than three sentences to explain, it has earned its own page. Everything else can stay inline.
Where should you start if you don't have any of these?
Start with the task someone interrupts a colleague about most often, and write it as a straight, single-purpose SOP before worrying about policy language or work instructions. Getting one document right teaches you the standard the rest of the set should follow, and it gives the team something usable while the rest gets built.
Most companies I've worked with don't need a full library on day one. They need the three or four procedures currently living in one person's head, written down in a form a new hire can follow alone. The policies and the work instructions get sorted out once that foundation exists.
Sorting policy from procedure from instruction is document architecture, not writing style, and it's the first thing I look at on the technical writing side of my practice. If what you have is close but tangled, that's usually a matter of splitting one document into three rather than starting over. Questions about scope are answered on my FAQ page, and if you'd rather talk through what you actually have, book a discovery call.
Frequently asked questions
What is the difference between a policy and an SOP?
A policy states a rule or position the company holds. An SOP tells one person how to perform one task, step by step, to reach a specific result.
What is a work instruction?
A work instruction covers a single step within a larger procedure, usually one that needs extra detail, such as a torque setting or a screen sequence. It supports an SOP rather than replacing it.
Can a work instruction stand on its own?
No. A work instruction only makes sense in the context of the procedure it belongs to. If a step doesn't connect to a larger task, it isn't a work instruction, it's its own SOP.
How do I know which document to write first?
Start with an SOP for the task people interrupt a colleague about most often. That single procedure sets the standard the rest of your documentation should follow.
