If your operation has SOPs that nobody uses, the problem is almost certainly not the team — it is the document. Most SOPs fail not because the processes they describe are wrong, but because they were written by the wrong person, in the wrong language, at the wrong level of detail, and placed somewhere inaccessible at the moment the operator actually needs them.
The result is a folder full of documents that satisfy an audit, produce no operational consistency, and generate resentment — because the team is blamed for not following procedures that were never designed to be followed. The same errors recur. The same training is repeated. The same questions are asked.
This article gives you a six-step process for writing SOPs your team will actually use. Not because they are told to — because the document is clear enough, specific enough, and accurate enough to be genuinely useful at the moment the task is being performed.
Why most SOPs don’t get followed — five root causes
Before the writing process, it is worth naming the failure modes that the six steps below are designed to prevent.
A manager writes the SOP from memory without observing the task. The document describes what should happen, not what does happen. Operators can see the difference and ignore the document, defaulting to the method they know is accurate.
Go to the source. Observe the task performed by the person who does it best. Write the SOP from direct observation, not from assumption or procedure templates.
A five-page Word document for a twelve-step process. Dense paragraphs without visual breaks. The operator looks at it, concludes it will take longer to read than to do, and sets it aside. It is never consulted again.
Write the shortest document that allows a competent person to perform the task correctly. If a simple process requires more than one page, the SOP is almost certainly over-written.
“Ensure compliance with the applicable specification parameters prior to commencement of operations.” The operator needs to know the gap should be 1.5 to 3mm and measured with a gap gauge — not that compliance should be ensured.
Write for the person who performs the task. Use the words the operator uses. Specify the tool, the measurement, the action, and the trigger.
A text-only description of what correct weld bead profile looks like, or correct label placement, or correct assembly orientation. Words describe these things; a photograph communicates them instantly and unambiguously.
Add a photo, diagram, or reference image at every step where “what good looks like” cannot be communicated with words alone.
The process evolves. The SOP stays at revision 1. Operators learn the new method from a colleague. Trust in the documentation system collapses. Future SOPs are treated as wallpaper before they are even read.
Every process change triggers an SOP update as a mandatory step in the change process. Every SOP has a scheduled review date — at least annually.
The same step written two ways — welding inspection
Step 7:
Step 7: Check the joint before welding
b) Wipe the joint clean. No scale, rust, or oil.
c) If preheat required (see WPS), check surface temp with infrared thermometer. Must reach 80°C before welding starts.
d) Sign the job traveller. Only then begin welding.
The content of Step 7 is identical in both versions. The difference is entirely in the writing. The right-hand column takes the same requirement and makes it immediately actionable: each sub-task on its own line, every measurement specific, a clear completion trigger before the next step begins. A new operator following the right-hand version performs the step correctly. One following the left-hand version relies on their own interpretation of “applicable WPS requirements” — and that interpretation is where variation enters the process.
Define the scope — what does this SOP actually cover?
Before writing the first step, define precisely what the SOP covers. Scope determines length, specificity, and usefulness. A scope that is too broad produces a document too long to navigate and too abstract to be accurate. A scope that matches one specific, repeatable task produces a document that is manageable to write, easy to follow, and straightforward to maintain.
A well-scoped SOP fits in one sentence: “This SOP covers the CNC turning setup from drawing receipt to first-article approval, performed by the machinist responsible for the operation.” Start point: drawing received. End point: first article approved and documented. Performer: the machinist. Everything outside that boundary belongs in a different SOP.
Three tests for a well-scoped SOP: (1) it covers one specific, repeatable task; (2) it has a defined start and end point that both performers and reviewers can agree on; and (3) it can be fully described by someone who has performed it twice. If any of these is absent, narrow the scope before writing a single step.
If you cannot describe the scope of the SOP in one sentence, it is covering too much. An SOP that covers everything covers nothing reliably — it is a general overview, not a usable procedure.
Observe the process with the person who performs it
This is the most important step in the process. The single most reliable predictor of whether an SOP will get used is whether it was built from direct observation of the actual task — not from memory, not from an existing procedure template, and not from a management description of how the task should work.
Watch the task performed at least twice by the person who does it best. Record every step in the sequence it actually happens. Pay attention to the decisions the operator makes that are not captured in any formal procedure — the moment they verify something before proceeding, the way they handle a common variation, the small check at the end that prevents the most common error. These are the steps the final SOP will depend on.
Questions to ask during the observation: “Why do you do it in that order?” “What do you check at this point before proceeding?” “What happens if this is out of range?” “How do you know when this step is complete?” Each answer adds specificity that the SOP will need. The operator is the expert; the writer is the observer and recorder.
One important note: if this SOP is documenting a process that was just improved through a Lean workshop, observe the new method — not the old one. The SOP is the mechanism that prevents the old method from reasserting itself over time.
An SOP written from observation is a record of what actually works. An SOP written from assumption is a record of what someone thinks should work. In practice, only one of these gets used — and it is not the one from assumption.
Draft in plain, active language at the operator’s level
The writing itself is where most SOPs diverge from usable to filed. Four rules that determine whether an SOP will be followed:
- One action per line. Never bundle multiple actions into a single step. “Check the fit-up, clean the joint, and verify preheat” is three steps written as one. Separate them. Each line is one thing to do — confirmed complete before the next begins.
- Active voice only. “Check the diameter” not “The diameter should be checked.” “Record the result on the traveller” not “The result is to be recorded.” Passive voice creates ambiguity about who does what and when — the ambiguity that produces inconsistency.
- Specific numbers, not general guidance. “1.5 to 3mm using a gap gauge” not “within acceptable limits.” “Torque to 45Nm” not “tighten firmly.” If a measurement is not specified, the operator uses their own judgement. That judgement is the source of the variation the SOP is meant to eliminate.
- Plain language at the operator’s reading level. Write for the person performing the task, not the manager reviewing it. If the operator would not use the word in conversation, do not use it in the SOP. The purpose of the document is comprehension, not formality.
The level of detail test: write at the level where a competent but new team member could perform the task correctly on their first attempt without verbal guidance from anyone. Every step that requires explanation to be understood needs to be rewritten until it does not.
Write for the person performing the task, not the person approving the document. The SOP that satisfies the auditor but confuses the operator has failed the only test that actually matters.
15-Point SOP Quality Checklist
Quality-check any SOP before release: 15 yes/no questions covering scope, language, format, visual support, naive-reader testing, and document control. If any answer is “no,” revise before publishing.
Download the Free Checklist →Add visuals for every critical checkpoint
The standard for adding a visual: if a new operator could misinterpret the step without one, add one. This applies to any step involving a spatial orientation words cannot reliably communicate, a judgment about what correct looks like across a range of acceptable conditions, or a reference state that is faster to recognise than to describe.
Visuals worth including consistently in engineering and manufacturing SOPs: a photograph of the correct assembly orientation at the step where orientation matters; an annotated diagram of measurement points for dimensional inspection steps; a reference image of acceptable vs unacceptable surface finish for finishing or coating steps; and a photo of the correctly completed output at the step that defines completion.
Placement guidance: embed the visual immediately adjacent to the step it illustrates. Do not place visuals in an appendix — by the time the operator reaches an appendix, the moment when the visual was needed has passed. Label every image with what it shows and what the acceptable condition is.
A practical note: smartphone photos at sufficient resolution in good light are entirely adequate for most SOP visuals. A usable photo taken today is worth more than a perfect diagram that never gets produced. Do not let the perfect be the enemy of the good.
A photo of the correct assembly orientation communicates more than three paragraphs of description — and leaves no room for the interpretation that three paragraphs always create.
Test it with someone who has never done the task
This step takes 20 to 30 minutes and will reveal at least three improvements in almost every SOP. Ask a team member from a different area, or a new hire, to follow the SOP step-by-step without any verbal guidance from the writer or the process operator. Watch without intervening. Record every moment of hesitation, every question asked, and every action that was not what the SOP intended.
Every question the test reader asks is a gap in the document. Every hesitation is a step that is unclear. Every mistake is an assumption the writer made that the document fails to communicate. These are the improvements the SOP needs before it is released — found now at zero cost, rather than discovered during a quality failure or an audit non-conformance.
Who should not be the test reader: the person who wrote the SOP, or the person who normally performs the task. Both know too much to find the gaps. The test reader must be someone without prior knowledge of the specific task who can interact only with the document — not with the people who produced it.
After the test: revise every step that produced a question, a hesitation, or an unintended action. If significant revisions were made, run the test a second time. The SOP is ready for release when a naive test reader can follow it to a correct result without any verbal assistance.
The test reader is the most honest reviewer your SOP will ever have. They cannot be told what the document means — they can only be shown what it says. If what it says is not enough, the test reveals it at no cost.
Control, version, and place it at the point of use
An SOP that cannot be found when it is needed is operationally equivalent to one that does not exist. Placement is as important as content. Three requirements for an SOP to remain useful after release:
- Document control. Every SOP must carry a revision number, an approval date, a review date, and a named owner — clearly displayed at the top of the document. These fields tell the reader whether the version they are holding is current. Without them, operators cannot know whether to trust the document or ask someone. In an audit, a document without revision control is a non-conformance.
- Point-of-use placement. The SOP must be physically present where the task is performed — at the workstation, on the machine, at the inspection station. A laminated copy in a document holder at the point of use gets used. An electronic file in a shared drive does not. If the operator has to leave the work area to find the procedure, they will not use it.
- Update triggers. Every process change initiates an SOP revision as a mandatory step in the change approval process. In addition, every SOP has a scheduled review date — at least annually — where the current method is verified against the written procedure and any discrepancies are resolved before they become audit findings.
For businesses building toward ISO 9001 certification, clause 7.5 explicitly requires that documented information be controlled, available at the point of use, and protected from unintended changes. A well-structured SOP system — with version control, access management, and review cadence — satisfies this requirement directly and simplifies the Stage 2 audit significantly.
An SOP in a filing cabinet is evidence of documentation. An SOP at the workstation is evidence of a management system. The auditor will ask to see the workstation copy — not the one in the quality manager’s office.
What format should an SOP be in?
The format should match the task and the environment where the SOP will be used — not the organisation’s preferred template. Three formats cover the vast majority of engineering and manufacturing SOP requirements:
| Format | Best For | Example |
|---|---|---|
| Numbered step list | Sequential linear processes with a fixed order and no decision branches | Machining setup, weld inspection, incoming material check, coating application |
| Decision flowchart | Processes with conditional branches — if X do Y, if Z do W | Non-conformance disposition, customer complaint handling, change request approval |
| Job aid / visual card | High-frequency simple tasks at a fixed workstation where portability matters | Operator daily checks, pre-start safety inspection, standard setup checklist |
The selection criterion: use the format that makes the process easiest to follow where it is performed. An operator at a CNC machine in PPE with greasy gloves does not use a five-page Word document — they use a laminated A4 card mounted on the machine. Match the format to the context, and the SOP will be used because it is designed to be.
Your first SOP starts with a 20-minute observation.
Pick the process that causes the most inconsistency in your operation. Spend 20 minutes watching it performed. Write down every step as it happens, in the language the operator uses. That is the foundation of an SOP that will get used — because it describes what actually happens, not what should. If you want Innovengg to facilitate your SOP development, our process improvement team can run the observations, draft the first procedures, and set up the document control system.
Book Your Free SOP Consultation →