Your SOPs Exist. So Why Doesn't Anyone Follow Them?

There's a folder on the shared drive called "Procedures". It was last opened in 2023. Inside is a 40-page operations manual, three versions of the same onboarding checklist and a document called "FINAL_v2_updated".

When a new starter needs to know how to raise a purchase order, they don't open the folder. They ask the person sitting next to them. When an audit comes up, someone spends a weekend updating the dates on the cover pages.

You did the work. You wrote the SOPs. And the business still runs on asking around.

A procedure nobody uses is just paperwork

Most businesses don't have a documentation problem. They have an adoption problem. The SOPs exist, they're just not part of how the work gets done.

The usual signs:

• Staff ask a colleague before they check the procedure
• Nobody can say who owns a given SOP
• The documents describe how things worked two systems ago
• Procedures live in a folder, separate from the tasks they describe
• Updates only happen when an auditor or a client asks for them

Why SOP libraries die

The insight most people miss is simple: an SOP stops being used the first time it's wrong.

Someone follows the steps, hits a screen that doesn't exist anymore, and goes and asks a colleague instead. From that moment the whole library has lost their trust, and getting it back is much harder than keeping it.

A few other things speed that up:

• They're written for the auditor, not the operator. Long paragraphs of policy language, when the person doing the job just needs the next step.
• They're written by someone who doesn't do the job. Small but important steps get skipped because the writer didn't know they existed.
• They live away from the work. If the procedure is three clicks away from the task, it may as well not exist.
• Nobody owns them. No owner means no review, and no review means drift.

How to build SOPs people actually follow

1. 1

   Write for the person doing the job. One task per SOP. Start with the purpose in a sentence, then who's responsible, what they need, and numbered steps that each start with a verb. Add screenshots for anything involving a system.

2. 2

   Keep it short. If an SOP runs longer than two pages, it's probably two SOPs. Link them together instead.

3. 3

   Attach it to the work. Link the SOP to the recurring task or task template it supports, so the instructions appear at the moment they're needed. This is the single biggest change you can make.

4. 4

   Give every SOP an owner, a number and a review date. A document number and version make it easy to know you're looking at the current one. An owner and review date make sure it stays current.

5. 5

   Make it easy to flag a problem. Anyone who finds a wrong step should be able to flag it in a minute, and the owner should fix it within the week. Fast fixes are how you keep trust.

6. 6

   Watch whether the questions stop. The best measure of a good SOP isn't whether it exists. It's whether people stop asking how to do the thing.

These steps sit across the Capability Building and Sustained Performance phases of our Operational Excellence Framework. Writing the SOP is the easy part. Keeping it alive is where the value is.

What this looks like in practice

We run BVIRTUAL this way. Every SOP has a document number, a list of related SOPs, a named owner and a sign-off when the wording is confirmed. Each one sits alongside the recurring task it supports, so when a quarterly client report is due, the procedure for creating and sending it is right there in the task.

The result is that the procedure is used every single time the job is done, which means any step that's wrong gets noticed and fixed quickly. That's the loop that keeps a library trustworthy.

Quick self-check

Open your three most important SOPs and ask:

If you answer "no" to more than one, that SOP isn't protecting your business. It's just taking up space.

Your task for this week

Pick the SOP your team asks about most. Sit with the person who does that job and walk through it together. Fix what's wrong, then link it directly to the task it belongs to.