A procedure that nobody can follow while doing the work is not a procedure, it is a record that the work was described once. The usual failure is not a missing document. It is a document written to satisfy an auditor, stored where the auditor looks, and never opened by the person holding the scanner.
The template below is written the other way round: for the person doing the task, at the moment they are doing it. Everything an auditor needs is still in it, in the header and the revision history, where it belongs.
The whole template is written out below as well, section by section, with why each one is there. If you only want the file, take it and go.
An SOP describes how one task is done, by whom, in what order, to a result you could check. That is the whole of it, and the boundaries matter more than the definition.
A policy says what must be true and why. A process says which steps happen in what order across a whole flow, usually across several people or teams. A procedure says how one of those steps is carried out. A work instruction goes one level lower still, into a specific machine or screen.
The practical test: if the document tells you what is not allowed, it is a policy. If it spans several roles and ends somewhere else in the company, it is a process. If one person could do the whole of it in one sitting, it is a procedure. If it names a button, it is a work instruction.
Getting this wrong is the most common reason a procedure runs to fourteen pages. A document that starts as a procedure and quietly turns into a policy, a process map and three work instructions is a document nobody reads, because the person looking for step four has to walk past all of it.
One procedure, one job. If the title needs the word "and", you have two procedures. Split them and link them. A procedure that covers receiving a delivery and also handling a damaged one is a procedure that is wrong half the time.
Every step starts with a verb. Scan. Check. Sign. Not "the item should then be verified against the delivery note", which hides who does it and leaves the reader to work out whether it has already happened. A step that does not begin with an action is not a step, it is background, and background belongs in Scope.
If a step needs a picture, give it one. A photograph of the actual label, the actual screen, the actual valve. One picture beside the step removes the paragraph that was trying to describe it, and removes the argument about whether the reader found the right thing.
Everything else in this template is bookkeeping. These three decide whether the document survives contact with the floor.
Everything that makes the document findable and accountable, at the top, in one block.
If a reader cannot tell in three seconds whether the sheet in their hand is current, the rest of the document does not matter.
Two sentences. What this procedure achieves, and why it exists. Written so that someone can decide, from this alone, whether they are reading the right document.
Not the place for policy, background, or the history of the department.
Where this procedure starts and where it stops, and who it applies to. State the boundary in both directions, including what it explicitly does not cover, with a link to the procedure that does.
This is the section that keeps a procedure from growing. Every "what about..." that arrives later either fits inside the stated scope or becomes a different document.
Only terms whose meaning is not obvious to a new person, and only the ones actually used in the steps. Three or four entries at most. A glossary of twenty terms is a sign the procedure is written in a language its readers do not speak, and the fix is to change the steps, not to grow the glossary.
Who does what, by role, not by name. Names change and documents do not get updated when they do.
Keep it to the roles that appear in the steps. If a role is listed here and never appears below, delete it.
What the person needs in hand before they start, including access: the tool, the form, the system, the permission. Written as a list somebody can check against before beginning, so a procedure does not stop halfway because a login was missing.
The steps. Numbered, in order, one action each, each beginning with a verb.
Where a step depends on a condition, state the condition first and the action second: "If the seal is broken, stop and call the supervisor." Where a step has a checkpoint, say what the correct result looks like, so the person can tell whether they did it right without asking.
Sub-steps only one level deep. If you need a third level, that part of the task is its own procedure.
What gets kept, where it goes, and for how long. A signature, a photograph, a form number, a system entry. If a step produces evidence and nobody says where it lives, the evidence is lost by the end of the week.
The policy this procedure serves, the related procedures either side of it, the standard or regulation it satisfies, if any. Links, not descriptions.
One row per version: version, date, what changed, who changed it, who approved it. Newest first.
This is the section people skip when writing and rely on when something has gone wrong. Write it every time, even when the change is one word, because the question later is always "when did this line change and who agreed to it".
The sections above are the shape. Here is one of them made real, so the level of detail is visible rather than described.
Title: Receiving a pallet delivery Document ID: WH-004 · Version: 3 · Owner: Warehouse supervisor Approver: Operations manager · Effective: 4 March · Next review: 4 September
Purpose. To confirm that what arrived is what was ordered, and that any damage is recorded before the carrier leaves. Signing a delivery note without checking transfers the loss to us.
Scope. Applies to all palletised deliveries at the goods-in door. Covers the check, the record and the signature. Does not cover putaway, which is WH-005, or supplier claims, which is PU-002.
Responsibilities. Goods-in operator carries out the check and signs. Warehouse supervisor approves any refusal. Buyer is informed of shortages the same day.
Materials and equipment. Handheld scanner, current purchase order on the handheld, delivery note from the driver, camera on the handheld, pallet knife.
Procedure.
Records. Signed delivery note, scanned and filed against the PO, kept for seven years. Photographs attached to the system receipt.
References. Goods receipt policy PO-001. Putaway WH-005. Supplier claims PU-002.
Revision history. v3, 4 March, added the photograph requirement in step 3 after two disputed claims, changed by the warehouse supervisor, approved by the operations manager.
Eight steps, each starting with a verb, one page, and it fits beside the work.
A procedure decays in a predictable way: the work changes, the document does not, people learn the real method from each other, and the document becomes something you show visitors.
Three habits prevent it.
Put a review date on it, as a date, and let it go overdue visibly. An overdue document is a fact somebody can act on.
Review after incidents, not only on schedule. If something went wrong and the procedure did not prevent it, one of the two has to change, and the review is the moment to decide which.
Let the people doing the task file changes. The fastest way to kill a procedure is to make correcting it harder than working around it.
A written procedure and a short video answer different questions. The document is the reference: it settles an argument about step four. The video is what gets watched once, before the first time, and it is what makes the document worth opening later.
The rules are the same in both. One procedure, one job. Every step starts with a verb. If a step needs a picture, give it one. A procedure written to those rules is already a script.
If you want to see what that looks like, we took this exact material and made it: one script, drawn in every style we have, including what the engine got wrong. Or take your own procedure, paste it in, and get the video back.
A checklist for the first ninety days, split by who actually does each item: HR, the manager, IT. Free PDF, no email required, with the five places onboarding usually fails, what to measure, and the extra lines a remote hire needs.
We wrote one script about a standard operating procedure and drew it again in every look we had. Here is what survived the change of hand, what drifted, and what the engine got wrong.