Work Instructions and SOPs: Why Nobody Reads Them

The work instruction for goods receipt is fourteen pages. It has a version history, a document owner, an approval table and a change log. It was reviewed by three people and is genuinely accurate.

Nobody on the receiving bay has opened it. When someone gets stuck they ask Marek, and when Marek is on leave they guess.

Two different documents, one name

Organisations conflate two things that have almost nothing in common, and then wonder why one artefact fails to do both jobs.

Both are legitimate. The failure is producing only the left-hand column, calling it user documentation, and expecting it to function at the point of work.

Markus and Tanis list poor-quality documentation and training materials among the characteristic problems of the project phase, alongside data cleanup and inadequate end-user training. It is a documented failure mode, not a local one.

Write for the moment of need

Someone consulting a job aid is mid-task, under mild time pressure, and looking for one specific answer. That situation has design implications, and the UK Government Digital Service’s clear language guidance covers most of them: plain English throughout, split sentences over 25 words, paragraphs of no more than five sentences, active voice, and no buzzwords — which it condemns for being too vague and leading to misinterpretation rather than for being ugly.

Applied to work instructions, four rules do most of the work:

• Lead with the exception, not the standard path. Nobody consults documentation to do the thing they already do daily. They consult it when something is unusual, so the unusual cases should be findable first.
• Use the words the team uses. If the team says “short delivery” and the document says “quantity variance notification”, the document is unsearchable to its own audience.
• One task, one page. A page covering a whole process is a reference document. A page covering “what to do when the pallet does not scan” is a job aid.
• Say what to do when it goes wrong, including who to contact by role. This is the most-wanted content and the most-often absent.

Findability beats quality

An excellent job aid three clicks into a document management system is worse than a mediocre one taped to the workstation, because the cost of retrieving it exceeds the cost of asking a colleague.

This is the practical form of a general point in the transfer-of-training literature: Baldwin and Ford identify the work environment — including the constraints and opportunities to perform the learned behaviour — as a determinant of whether training transfers. If the environment makes the correct route slower than the workaround, the workaround wins, and documentation is no exception.

For deskless populations this decides the matter entirely. A laminated card at the workstation is used; a PDF on an intranet reachable only from a shared terminal is not, and no digital mechanism substitutes for that.

Let the questions write it

The cheapest way to produce genuinely useful job aids is to stop guessing what people need and record what they ask.

During hypercare, every recurring question is a documentation defect rather than a support incident. A question asked by five people should become a one-page aid that same week, written in the words the questioner used. Within a month this produces a small set of documents that are demonstrably about real problems, which is more than any pre-written library achieves.

It also gives super users something durable to produce, which is how individual knowledge becomes organisational knowledge rather than a dependency on whoever happens to know.

Keep the fourteen-page document. Audit and onboarding need it. Just stop expecting it to help anyone at 7am on the receiving bay.

More on capability and enablement in the ERP Readiness Hub, or read how to build training around roles and tasks.