Non-compliance is almost never a discipline problem. It is a credibility problem, and credibility has a memory.
Most advice on this topic treats non-compliance as a behavior problem. People are described as careless, resistant, or badly trained, and the fix is framed as enforcement. That explanation is comfortable for whoever wrote the documentation, and it is almost always wrong. Teams that ignore SOPs are usually behaving rationally, based on evidence they collected themselves.
This post covers what breaks, why accurate documentation does not win a team back on its own, and a 30-day plan for rebuilding the habit. If your problem is that the documents are out of date rather than ignored, that is a different failure with a different fix, and it is covered separately.
The companion problem. Drift is when the documents are wrong. This post is about what happens to a team after they find out.
A support agent has 40 tickets in the queue. One is a return request for a damaged item bought with a 30% discount code, which is not the normal case. They open the SOP.
The SOP says to escalate discount-code returns to the ops lead. The ops lead left in March. There is no mention of who took that over. The agent spends 90 seconds working this out, gives up, and asks in Slack. Somebody answers in four minutes.
That is the entire event. Ninety wasted seconds against a four-minute Slack answer that also came with a human who could handle a follow-up question. The next time an unusual return lands, the agent does not open the SOP. They go straight to Slack, because Slack has now beaten the documentation once and there is no reason to believe the rematch goes differently.
Nobody made a decision to stop using the documentation. Nobody announced it. An experiment ran, the documentation lost, and the result stuck.
Here is the part that makes this expensive. Your team does not evaluate documents individually. They hold one belief about the library as a whole, and it is a single yes or no: are the docs reliable enough to check first?
One wrong document flips that to no. Fifty accurate documents do not flip it back, because after the first failure nobody runs the experiment again. A source that wasted your time does not get re-tested. It gets routed around, quietly, by everyone who experienced it and then by everyone they told.
This is why documentation adoption tends to fall off a cliff rather than decline gradually. You are not watching interest fade. You are watching a small number of bad experiences propagate through a team as a shared conclusion.
One bad experience costs you the library. One good experience wins back nothing, because a person who has stopped checking never sees it. Prevention is worth far more here than repair, which is the opposite of how most teams budget their documentation time.
When you ask people why they did not follow the SOP, they say they forgot or they were busy. Watch what happens instead and it is one of four things.
One: it describes a workflow that no longer exists. The Gorgias view was renamed, the Klaviyo flow was rebuilt in April, the 3PL changed how they file damage claims. The steps are still there and they no longer map onto anything on screen.
Two: it is too long to use during the work. A 1,400-word document is a reading assignment, not a reference. Nobody reads 1,400 words with a customer waiting. If the procedure cannot be scanned in under 20 seconds while a ticket is open, it will only ever be read during onboarding and never again.
Three: it documents the happy path. This one is nearly universal and rarely noticed. People do not open documentation for the normal case, because they already know the normal case. They open it for the edge, the exception, the thing that looks slightly wrong. Most SOPs describe the straightforward version in detail and go quiet exactly where the reader got stuck.
Four: they cannot tell whether it is current. This is the trust-specific one. A correct SOP still gets skipped if it might be stale, because verifying it costs more than asking a colleague. Accuracy the reader cannot see is worth nothing to them.
These get confused constantly and they need opposite responses. The distinction is whether people are following bad documentation or ignoring good documentation.
| Signal | Drift problem | Trust problem |
|---|---|---|
| What is wrong | The documents are inaccurate | The documents are fine |
| What you observe | People follow the SOP and get a wrong outcome | People never open the SOP at all |
| Where errors show up | In the work: wrong refunds, missed steps | In the inconsistency: five people, five methods |
| View counts | Normal, then errors climb | Near zero regardless of how good the content is |
| Who complains | The customer, or the person auditing | Nobody. It is silent. |
| What fixes it | Updating the content | Re-earning the habit |
| Realistic timeline | Days | Weeks |
The tell is silence. Drift generates complaints, because somebody followed the instructions and something went wrong. A trust problem generates nothing at all. Work still gets done, every person just does it their own way, and the cost only becomes visible when someone leaves or a customer gets a different answer than the last time they asked.
The instinct is to spend a weekend correcting all 40 SOPs. It is a satisfying weekend. On Monday nothing changes, and this is the point where most teams conclude their people are the problem.
Your team's decision to stop checking was made months ago, and it does not get revisited on your schedule. There is no notification for the thing you gave up on being good now. From where they sit, nothing happened over the weekend.
Announcing it in Slack does not clear this either. Everyone has heard that the documentation is updated before, usually shortly before opening a document that was wrong. The announcement is evidence of nothing, and people who have been burned discount it accordingly.
The only thing that rebuilds the habit is being right at the moment of need, repeatedly, in the place they already go. Which means you have to go to them, because they have stopped coming to you.
A procedure written for a reader with a customer waiting looks different from one written for a reader in onboarding. Five rules cover most of it.
The second rule matters more than the rest combined. Vague decision rules are the most common reason a technically accurate SOP is useless, because the reader was never stuck on the steps. They were stuck on the judgment call, and the document handed it back to them.
Reason four from earlier is the cheapest to fix and the most often skipped. If a reader cannot tell at a glance whether a procedure is current, they price in the risk that it is not, and asking a colleague wins.
Three things need to be visible without opening the document: when it was last verified, who owns it, and whether anything it depends on has changed since. A name and a date at the top of every SOP costs nothing and removes the entire calculation.
A document edited yesterday to fix a typo is not more trustworthy than one verified against a live run last month, but every tool that shows you a modified date implies otherwise. Track verification as its own field, or the freshness signal you are showing your team is close to noise.
Score your procedures on how fast the underlying tools change and how long since anyone checked. The high-risk ones are where trust gets lost.
This works because it is small. The instinct is to fix everything, which takes a month, during which the team experiences no change and their conclusion hardens.
Week 1. Pick the five procedures your team runs most often. Not the five that worry you most, the five with the highest volume, because those are where habits form. Run each one against live work and note every place the document is wrong.
Week 2. Rewrite those five to the rules above. Real numbers in the decision rules, edges documented, one screen per step, a named owner and a verified date at the top. Five documents is one afternoon. Forty is a project that never ships.
Week 3. Re-enter the workflow. Every time somebody asks one of those five questions in Slack, reply with the answer and the link, in that order. Not the link alone, which reads as a brush-off and rebuilds nothing. The answer proves you are useful, the link shows where it lived. Do this every single time for a week.
Week 4. Measure whether the five are being opened without prompting. If they are, extend the same treatment to the next five. If they are not, the documents are still failing at the moment of need, and week 2 needs another pass before you widen the scope.
Thirty days gets you five procedures people trust, not forty they ignore. The second batch is faster, because you are no longer fighting a conclusion, and by the third batch the default has usually flipped back.
Two cases where this whole framework is the wrong tool, and it is worth checking before you spend the month.
The procedure might be worse than what people invented. If three agents independently route around step 4, step 4 is probably wrong. Skipping is data. Before treating deviation as non-compliance, sit with the person who deviates most and ask what they do instead, because there is a reasonable chance they have improved the process and nobody wrote it down.
Or there may be no cost to improvising. If inconsistency has never had a consequence and nobody is accountable for the outcome, documentation is not your constraint and better documentation will not become one. That is a management problem wearing a documentation costume, and no tool fixes it.
Everything else is recoverable. Teams do come back to documentation they can trust, they are just slower to return than they were to leave, and they need to see it be right several times before the habit re-forms.
What to document first, how to structure it by department, and how to keep the library small enough to stay accurate.
Usually because following the SOP once cost them more than asking a colleague. The four common causes are a document that describes a workflow that no longer exists, a document too long to read mid-task, a document that covers the normal case but goes quiet on the edge case people actually opened it for, and a document whose currency the reader cannot verify at a glance. All four are rational responses to evidence, which is why enforcement does not fix them.
Fix five procedures rather than forty, choosing the five with the highest volume so habits form fastest. Then re-enter the workflow: for one week, every time somebody asks one of those questions in Slack, reply with the answer and the link, in that order. Sending only the link reads as a brush-off. The team has to see the documentation be right at the moment they needed it, several times, before they start checking on their own.
Short enough to scan in about 20 seconds with a customer waiting. If a procedure needs more than roughly 400 words, it is usually two procedures that got merged, or it is carrying background that belongs at the bottom. Length is the second most common reason a technically accurate SOP goes unused, behind decision rules that are too vague to resolve anything.
Mandates work on the assumption that people are choosing not to comply, which is rarely the case. If the document is wrong, too long, or silent on the edge case, a mandate makes people follow a bad procedure or quietly ignore it and stop telling you. Fix credibility first. If procedures are genuinely trustworthy and still ignored, the problem is accountability rather than documentation, and that is a management conversation.
Look at whether anyone is complaining. Drift produces complaints, because somebody followed the instructions and got a bad outcome. A trust problem is silent: the work still gets done, everyone does it their own way, and nothing surfaces until someone leaves or a customer gets a different answer than last time. Near-zero views on documentation that is actually accurate is the clearest signal of a trust problem.
I built ReccordSOP after watching too many DTC ops teams lose months to undocumented workflows. These SOPs are battle-tested with Shopify operators running $1M to $50M brands.
Last reviewed August 9, 2026
Most SOPs are wrong within 90 days of publishing. Here's how to detect it before it costs you a customer.
Most SOP projects don't fail because the docs are bad. They fail because nobody follows them and nobody updates them.
Most VA hires fail at the handoff, not the hire. The 30-day ramp, the order to give tasks in, and what to write down before day one.
We use essential cookies for sign-in and a small amount of analytics to improve the product. Privacy policy.