Why SOPs are hard to follow and how to make them easier

A customer asks for an update. One person checks the order system, another asks a colleague, and someone else sends an answer from memory. The business has a written procedure, but the work still depends on who picks up the request.

Writing a standard operating procedure, or SOP, is a useful start. Making it usable means checking whether people can find it, understand its decisions and perform its actions during an ordinary working day.

This guide brings together human-factors research and official procedure guidance, then applies the findings to everyday business work. The examples are illustrative; the template needs your own rules, responsibilities and approval limits.

Why SOPs break down

The written process does not match the job

An SOP might require information that arrives late, an approval from someone who is unavailable, or a screen that the employee cannot access. People then improvise to keep the work moving.

A 2024 industrial interview study found that procedure users reported more deviation than administrators estimated, and the groups differed in how they explained it. These were self-reports in a chemical company, rather than a measured compliance rate for all businesses. The useful lesson is to compare the written process with what happens during work. 1

Watch someone perform the task. Ask which steps are difficult, what they do when an input is missing, and which parts depend on a colleague's knowledge. Examine shortcuts before deciding whether to formalize them or remove them.

Understanding the procedure is only part of the problem

The COM-B behavior framework distinguishes capability, opportunity and motivation. People need the skills to act, conditions that make the action possible, and reasons or habits that support it. This is a way to diagnose behavior, rather than proof that a particular document format works. 2

For your process, ask:

• Does the person know how to perform the action?
• Do they have the information, access, equipment and time?
• Do the team's targets and everyday habits support following the procedure?

If the required system permission is missing, fix access. If quality checks are expected but performance is judged entirely on speed, review the target. These changes make the written instruction executable.

Interruptions make people lose their place

Someone pauses halfway through a task to answer a call. When they return, they remember starting the check but cannot remember finishing it.

In a controlled laboratory experiment, very brief interruptions increased errors in keeping the correct task sequence. The findings concern a specific sequence task, so they should not be treated as an error-rate prediction for your office. 3

Use numbered steps and a visible record of important completed actions. Define how to resume a consequential task. For example, before retrying a submission, check whether the first attempt already succeeded.

The document is difficult to use at the point of work

A long folder path, an unclear filename or three competing versions can turn a simple instruction into a search task. Dense text can hide the decision the user needs.

The UK's Health and Safety Executive recommends matching procedures to the user, task and consequences, involving users in their development, and supporting them with competence and appropriate job design. It also cautions against making a procedure the only defense against error. 4

Put the approved instructions where the task starts. Use a title someone would search for, such as “Send a customer order update.” Keep essential actions visible and link to supporting detail when it is needed.

More training does not fix every missed step

An unfamiliar task may require teaching and practice. A familiar task missed during distraction may need a clearer prompt or better workflow. HSE distinguishes knowledge mistakes from slips and lapses, and notes that training alone cannot eliminate the latter. 5

Before repeating the training, identify what went wrong. Did the person misunderstand, forget, encounter an obstacle, or deliberately bypass a control? The response should fit the cause.

Write a step someone can use

Consider this instruction:

Check the customer details and send an update.

It leaves several decisions unanswered. Which record should be checked? What counts as current information? What happens if two systems disagree?

A more usable version is:

1. Open the order using the order number in the customer's request. If the order cannot be identified, request the missing information and put the case on hold.
2. Compare the recorded status with the latest approved update. If the information conflicts or has no reliable source, refer the case to the order owner before confirming a status.
3. Send the confirmed status using the approved message format. Include the next action or update point that the order owner has agreed.
4. Record when the message was sent and who owns the next update. Close the task only when that record is complete.

This example gives the user an action, a completion condition and a response to a problem. Your business must define what qualifies as an approved update and who owns the order.

For each important step, specify:

• Action: what the user should do.
• Result: what they should see or record when it is complete.
• Exception: what to do if the expected result is absent.

Add a screenshot when a screen or field is easy to confuse. Add a worked example when a decision is hard to interpret. Keep each visual close to the action it explains.

Build and test the process

Start with one recurring task

Choose something that repeatedly creates questions, inconsistent results or rework. Define where it starts and ends. “Handle every customer issue” is broad; “Send an update for an existing order” gives you a process you can observe and test.

Walk through a real case

Ask an experienced user to demonstrate the task. Include whoever supplies the input and receives the output. Capture the ordinary path, the common exception and any point where work waits for another person.

Keep necessary checks and approval boundaries explicit. Adapt the process when the existing sequence is impractical, while preserving the controls it needs.

Write the draft with its users

The EPA's SOP guidance recommends knowledgeable authors, clear sequential instructions and validation by someone other than the author. It also recognizes that the right format depends on the activity and intended users. 6

Use the downloadable template to capture the trigger, inputs, owner, steps, exceptions and output. Add rows or pages when needed. A quick checklist can support an experienced user while fuller instructions help someone learning the task.

Test it through a task

Give the draft to a suitably trained person who did not write it. Let them try a normal case and a common exception. Observe where they search, ask a question, make an assumption or become blocked.

If you must explain a step aloud, consider whether the missing explanation belongs in the document or in training. Fix the issue, then repeat the relevant case. Use the pack's test sheet to record what changed and whether the problem was resolved.

Introduce it through practice

Demonstrate the process, let the user perform it, and inspect the result. Confirm access to the approved version. A reading acknowledgment records that someone acknowledged the document; a task demonstration tells you more about their ability to use it.

Keep it useful

Give the SOP an owner, version and revision date. Review it when software, responsibilities or rules change, and when feedback exposes a mismatch. Remove obsolete copies from active use.

Make reporting a blocked step easy. The report should reach someone who can resolve it, with a response explaining what changed. Keep the review proportionate to the process: a routine update task and a consequential approval need different levels of control.

Measure a few things that matter, such as:

• Whether intended users can find the instructions and complete the task correctly.
• How often they need help or encounter a blocked step.
• Whether important checks are performed and recorded.
• Whether rework or customer corrections change.

Checklist studies show why adoption alone is an incomplete measure. A randomized study in two Norwegian hospitals found fewer surgical complications after checklist introduction, while a large Ontario adoption study found no statistically significant reduction in mortality or complications. Those clinical results cannot be transferred numerically to everyday business SOPs. They do support testing the actual process rather than assuming publication guarantees improvement. 7 8

Start with a task your team repeats this week. Observe it, draft the instructions and test them with another user. Use what you learn to improve both the document and the work it describes.

Download the SOP starter pack ↑

Sources and further reading

These sources combine primary research with official guidance. The small-business recommendations above are practical applications of the findings, not a tested universal formula.

1. Mendoza et al. (2024). The realities of procedure deviance. Interviews comparing procedure users and administrators in industrial work.
2. Michie, van Stralen and West (2011). The behaviour change wheel. Original COM-B framework paper.
3. Altmann, Trafton and Hambrick (2014; online 2013). Momentary interruptions can derail the train of thought. Controlled sequence-task experiment.
4. UK HSE. Human factors: Procedures. Guidance on design, user involvement and competence.
5. UK HSE. Managing human failures. Guidance on errors, deviations and working conditions.
6. US EPA (2007). Guidance for Preparing Standard Operating Procedures, QA/G-6.
7. Haugen et al. (2015). Effect of the WHO checklist on patient outcomes. Stepped-wedge cluster randomized trial.
8. Urbach et al. (2014). Introduction of surgical safety checklists in Ontario, Canada. Study of adoption across 101 hospitals.