Insights / Article / SOP optimisation and continuous improvement
ArticleThe SOP nobody reads, and how to fix it
Many procedures are written once and ignored. The fix is to make them short, visual and part of the work itself.
Most organisations have a shared drive full of standard operating procedures. Many were written for an audit, signed off and never opened again. Ask people on the floor how they learned the job and they will name a colleague, not a document.
That gap is expensive. When the written procedure and the real one differ, quality varies by shift, training takes longer and nobody can tell which way of working is correct. The fix is not to write more procedures. It is to make them short, visual and part of the work.
Why good intentions produce unread documents
SOPs usually go wrong for three reasons. They are written by someone who does not do the task, so the language and sequence feel foreign. They are written to satisfy a reviewer, so they are long and defensive. And they are stored somewhere the user never goes during the working day.
None of these is a failure of effort. They are failures of design. A procedure is a tool, and like any tool it has to fit the hand of the person using it.
There is a quick way to tell whether your procedures have this problem. Pick a routine task and ask three experienced people to describe how they do it. Then compare their answers with the written SOP. If the three accounts differ from each other and from the document, the procedure is not doing its job, however well it reads.
We had a procedure for everything and a different way of working on every shift. The documents were accurate on the day they were approved and wrong a month later.
Quality manager, manufacturing client
Write for the user, not the auditor
Use the words operators use. If the team calls it the blue screen, do not call it the order entry interface. If a step is known as the double check, use that name. Familiar language lowers the effort of reading and signals that the document reflects real work.
Put steps in order with one action per line. A sentence that contains three actions will be read as one, and the middle action is the one people skip. Start each line with a verb: open, scan, check, confirm.
- Keep the core procedure to one page or one screen where you can.
- Move background, policy and exceptions to a separate reference section.
- State the outcome of each critical step so people know what good looks like.
- Flag safety and quality points visually, not in a paragraph.
Auditors still get what they need. Version control, ownership and review dates sit in the header. The difference is that the body is written for the person doing the job.
Use visuals wherever they beat words
Photos, diagrams and checklists work faster than paragraphs. A photograph of a correctly packed carton explains more than a paragraph about orientation and padding. A screenshot with the right field circled removes doubt about where to click.
Choose the format by the task. Sequential physical tasks suit photo sequences. Decisions suit simple flowcharts. Routine checks suit tick lists. System tasks suit annotated screenshots or short screen recordings under two minutes.
Keep visuals current
Outdated images are worse than none, because they teach the wrong thing with authority. When equipment, packaging or screens change, update the images in the same release.
Put the procedure where the work happens
A procedure in a drawer will not be used. If someone has to stop, walk to a computer, find a folder and open a file, they will ask a colleague instead. Place the instruction at the workstation or inside the system the person is already using.
On a production line, that means a laminated card or a screen at the station. In an office, it can mean a help link next to the form field, a checklist built into the workflow tool or guidance that appears when a record reaches a certain status. Many ERP and service platforms support this without custom development.
A practical example
Consider a typical customer service team handling returns. The procedure lived in a forty-page manual. Agents relied on memory and their neighbours. The team replaced it with a short decision tree inside the case screen and a one-page reference for unusual cases. New agents became productive faster, and supervisors spent less time answering the same questions.
The manual did not disappear. It became the reference for edge cases and for audits, while the decision tree handled the everyday work. Splitting the two kinds of content is often the single biggest improvement, because it lets the everyday instruction stay short without losing the detail that specialists and reviewers still need.
Test it the way it will be used
The simplest test of an SOP is to hand it to someone new and watch them follow it without help. Every hesitation, wrong turn or question marks a line that needs work. Do this before publishing and again after any significant change.
- Ask a new starter or a colleague from another team to perform the task using only the SOP.
- Observe silently and note where they pause or deviate.
- Ask what they expected at each pause.
- Revise the wording, sequence or visuals and repeat with someone else.
This takes an hour, and it catches problems that a desk review never will. It also shows whether the visuals are clear, because a new starter will look at the pictures first and the text second.
Make someone responsible for keeping it alive
Procedures decay as processes change. Give each SOP a named owner who does the work or leads the team that does, and a review date. Encourage people to flag errors on the spot, with a simple way to do so, and fix confirmed problems quickly so the team sees that feedback matters.
Start with the three procedures that cause the most errors or the most questions. Rewrite them in the users’ words, add visuals, put them where the work happens and test them with a new starter. The results will make the case for doing the rest.
Source: Intelliversal analysis.
