The Slack message pinned two years ago is the real SOP. The document nobody reads is the decoy.
Your Gorgias macro for a wrong item shipped tells the agent to send a replacement. It says nothing about what to do when that item is out of stock, which happens on roughly one in five of these tickets.
Everyone on the team knows what to do anyway. They check a message pinned in the support channel. It says: offer 15 percent off or a free replacement once restocked, agent's choice. The message is two years old. The person who wrote it left in March.
That pinned message is the real SOP. The Gorgias macro is the decoy. This happens on every team, and almost nobody notices it happening.
The related problem. Drift is when the official document is wrong. This is what fills the gap while nobody fixes it.
Nobody decided to replace the macro. It happened in stages, the way these things always do.
An agent hit the out-of-stock case for the first time and asked in Slack. Someone senior answered. The answer worked, so the next agent who hit the same case searched Slack instead of opening the macro. A few weeks in, someone pinned the answer so it was easier to find than searching.
At that point the pin had become the procedure. The macro kept existing. Nobody used it for this case anymore.
This is not a story about one broken macro. It is what happens every time an official document stops covering a real case. The team solves the problem anyway, without waiting for someone to fix the document.
A shadow SOP is a procedure your team actually follows that nobody wrote into the official documentation. It lives in a pinned Slack message, a personal spreadsheet, a sticky note on someone's monitor, or a sentence that gets repeated out loud every time the situation comes up.
That is a different failure from drift. Drift is when the written document is wrong. A shadow SOP is when a second, unwritten document exists next to the official one and quietly does its job instead.
| Drift | Shadow SOP | |
|---|---|---|
| What exists | One document, and it is wrong | Two versions, one written and one not |
| Where it lives | The SOP itself | Slack, a spreadsheet, someone's memory |
| Who notices | Whoever follows the wrong steps | Almost nobody, because it works |
| What fixes it | Update the document | Find it, then decide whether to promote it |
A drifted document sends someone the wrong way and they notice, usually the hard way. A shadow SOP quietly does its job for months. That is exactly why it is more dangerous. Nothing about it looks broken.
Three situations produce a shadow SOP almost every time.
The official document does not cover the case. This is the Gorgias example. The happy path is written down. The edge case is not, so the team invents an answer and shares it the fastest way available, which is never the SOP.
The official document is too slow to use. A 1,400-word procedure with the answer buried in paragraph six loses to a two-line Slack pin every time. Speed wins, especially with a customer waiting.
Someone found a better way. A rep figures out that checking order history before answering a refund question cuts the conversation in half. They start doing it. They tell the person next to them. Neither of them updates anything, because updating a document has never felt like part of the job.
All three have the same root. The channel where knowledge actually travels, a person, a chat message, a shared habit, moves faster than the channel where knowledge is supposed to live.
One of the four triggers there is the same question asked twice. A shadow SOP is what forms in the gap before anyone notices the trigger fired.
It is tempting to treat every shadow SOP as a discipline problem. Resist that. A lot of them exist because someone on the front line solved something the person who wrote the original SOP never encountered.
The rep who checks order history first did not break a rule. They improved one. The senior agent who wrote the pinned Slack answer was not going around the process. They were doing the job the macro should have been doing.
The problem was never that the shadow SOP exists. The problem is that it is invisible to everyone except the people currently doing the work.
Ask what happens if the two or three people who know the shadow version are all out sick on the same day. If the answer is that everyone else guesses, you have a real gap. If the answer is that anyone could look it up somewhere, it was never really a shadow SOP, just a fast reference.
Try it on one of your own procedures.
Record a process once, AI writes the structured SOP. 3 free SOPs, no credit card.
A shadow SOP has no owner, no version history, and no review date. Nobody is accountable for keeping it accurate, because officially it does not exist.
It also does not travel. A new hire, a VA, or a Q4 seasonal contractor is handed the official document, the one with the gap. Nobody hands them the pinned message, because nobody thinks of the pinned message as documentation. They only learn it exists the first time they get the out-of-stock case wrong.
It fragments, too. Two support agents each invent their own answer to the same uncovered case. Neither is written down, so neither one corrects the other. A customer who contacts you twice gets two different resolutions, and you have no record explaining why.
And it disappears with the person who holds it. The pinned message survives because someone pinned it. Most shadow SOPs are not pinned. They are a fact one person carries, and they leave with that person on their last day.
The handoff moment where a shadow SOP costs the most. A VA who only gets the official document inherits the gap, not the fix.
You will not find shadow SOPs by rereading your documentation. They live outside it. Four places to look instead.
That last one is worth taking seriously on its own. If the honest answer to how does this work is a name, you already know exactly where your risk sits.
The instinct once you find one is to fix the official document immediately and move on. That is only half the job, and it is the easy half.
The harder part is the conversation with the person who has been running the shadow version. Approach it as gratitude, not correction. They solved a problem the document did not. Treating that as a violation teaches everyone else to keep their workarounds quiet, which is the opposite of what you want.
Write the update with them, not about them. They know the edge cases better than whoever owns the document. Ten minutes with the person who actually does the task beats an hour guessing at their process from the outside.
Then retire the shadow version deliberately. Update the macro or the SOP, tell the team the pinned message is now official and outdated, and unpin it. A shadow SOP that gets promoted but not retired just becomes a second shadow SOP with better PR.
Once you fold a shadow SOP back in, it needs an owner. The person who caused the change, in this case the person who built the workaround, is usually the right one.
The best moment to hunt for shadow SOPs is not a quarterly cleanup. It is any handoff, a new hire, a VA taking over a task, an agency picking up an account. Someone is about to learn the process for the first time, which makes every gap visible in a way it never is to the person who already knows it.
Run this before the handoff instead of after it goes wrong.
This takes about thirty minutes per role. It is the highest-leverage half hour available before a handoff. It is the only moment guaranteed to surface knowledge that would otherwise leave with the person who has it.
Not every shadow procedure needs promoting. Some are just personal habits with no real stakes attached.
If someone has a personal shortcut for organizing their own inbox and it does not affect anyone else's work or any customer outcome, leave it. Documenting every individual preference turns the SOP library into noise, and noise is how people stop trusting it.
The line is whether the outcome changes depending on who is doing the task. If two people would resolve the same ticket differently because one of them knows the shadow answer and the other does not, that gap is worth closing. If the outcome is identical either way, it is a personal preference, not a procedure, and it does not belong in the library.
What happens after a shadow SOP gets exposed badly, usually because a customer got two different answers. Trust in the whole library takes the hit, not just the one document.
A shadow SOP is a procedure your team actually follows that was never written into the official documentation. It usually lives in a pinned Slack message, a personal spreadsheet, or a piece of knowledge one person carries and repeats out loud whenever the situation comes up. It forms quietly, once an edge case appears that the official document never covered, and it can run a team's real process for years without anyone treating it as documentation.
No. Many exist because someone on the front line solved a problem the original document never anticipated, and their fix is genuinely better than what is written. The risk is not that an unofficial answer exists. The risk is that it has no owner, no version history, and does not survive the person who holds it leaving the company.
Look outside the documentation itself, since that is where shadow SOPs live. Check pinned messages in support and ops channels, note any question that has been asked more than once in the last month, ask directly whether anyone keeps a personal cheat sheet, and watch for any task where the real instruction is a person's name rather than a document.
An outdated SOP does not stop the work, it just pushes the real procedure into an unofficial channel. That costs you in three ways: the workaround has no owner or audit trail, it does not transfer to new hires or VAs who only ever see the official document, and different people invent different answers to the same gap, so customers get inconsistent resolutions with no record explaining why.
No. Treat it as information, not a violation. The person running the shadow version usually solved a real problem faster than the documentation did. Punishing them teaches everyone else to keep their workarounds quiet, which is the opposite of what surfaces the next one. Write the update with them, then retire the shadow version deliberately so it does not linger alongside the fixed document.
3 free SOPs to start. No credit card required. See if drift detection keeps your docs honest.
Start for freeI 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 13, 2026
Most SOPs are wrong within 90 days of publishing. Here's how to detect it before it costs you a customer.
A review calendar is the weakest trigger you can build a maintenance habit on, because the calendar has no idea whether anything changed.
Non-compliance is almost never a discipline problem. It is a credibility problem, and credibility has a memory.
We use essential cookies for sign-in and a small amount of analytics to improve the product. Privacy policy.