An SOP that exists but is not followed is worse than no SOP at all: it gives leadership the impression a process is controlled while the real work happens somewhere else. The gap is rarely technical. Documents fail at rollout because of how they are introduced — usually as an announcement, from the top, with no room for the people doing the work to push back.
Involve the person who does the task
The person performing a process every day knows where it breaks. If they are handed a finished document, their first instinct is to look for the step that is wrong — and they will find one. If they help write it, the same knowledge goes into the document instead of becoming resistance. This does not require a committee; a single conversation and one review pass is enough.
Frame it as protection, not surveillance
People hear "we are documenting your job" and assume the next step is replacement or blame. Say the actual purpose out loud: consistency for customers, faster onboarding, fewer interrupted evenings, and a shared answer when someone asks "how do we do this?". An SOP protects the person following it as much as the business.
Publish in one place
An SOP in three folders, two inboxes, and a printed copy behind the till is not a single source of truth. Choose one location — a shared library, a wiki, or a documentation tool — and make that the only place documents live. If people cannot find the current version in under a minute, they will ask a colleague instead, and the process will drift back to tribal knowledge.
Train with the document open
Training that happens verbally while the SOP sits unopened teaches the team that the document is decoration. Walk new hires through the process with the SOP visible on screen, ticking each step as it happens. The association matters: the document is how the work is done, not a record of it.
Practical move
Ask one team member per week to run a process using the SOP and report the first thing that was unclear. Rotating that role keeps documents current and gives everyone ownership of the library.
Make feedback cheap
If the only way to change an SOP is to escalate to a manager, nobody will bother and the document will rot. Add an obvious path: a comment field, a named owner, a short form. Then close the loop — when someone points out a wrong step, fix it and say thank you publicly. Two or three of those cycles and the team starts treating the library as theirs.
Version, do not overwrite silently
When a process changes, keep the previous version and note what changed and why. People who learned the old way need to see the difference, and the change history is often the fastest way to answer "why do we do it like this now?" Overwriting with no trace creates quiet confusion about which version is real.
Adoption is a habit, not an event. The teams that succeed are the ones where the SOP is opened during work — at the machine, on the call, at the till — rather than only during training. Once the document is genuinely the easiest way to answer a question, following it stops being a policy and becomes the path of least resistance.