The Standard Operating Procedure That Actually Gets Followed

The standard operating procedure has a credibility problem. In most organisations, SOPs exist in large numbers, are updated infrequently, are difficult to navigate, and are referenced primarily during audits and onboarding, after which they return to the shared drive from which they were retrieved. The people doing the work the SOP describes often have a detailed working knowledge of how the job is actually done that diverges significantly from the documented procedure — divergences they could not reference the SOP for because the SOP does not reflect how the work currently runs. An SOP that is not used is not a procedure. It is a record of how something was once intended to work.

Why SOPs get ignored

SOPs get ignored for consistent reasons. They are too long, written in a format that optimises for comprehensiveness rather than usability. They are too static, reflecting a moment in time rather than the current state of the process. They are too difficult to find, buried in folder structures that require knowing where to look. And they are too disconnected from the work itself — stored somewhere separate from the tools and systems in which the work happens, requiring a deliberate context switch to consult. There is also a deeper problem: SOPs are usually written by people who are not doing the work describing it, or written during a process-design phase before the process has been executed enough times to reveal what it actually requires. The result is a procedure that is accurate in its intent but incomplete or inaccurate in its specifics — which means the people doing the work cannot follow it literally even when they try.

What makes an SOP usable

An SOP that gets followed has several characteristics that distinguish it from the filed variety. The first is specificity of authorship: it was written by, or in close collaboration with, the people who actually perform the process. Their knowledge of the exceptions, the judgement calls, and the workarounds is in the document rather than existing parallel to it as undocumented tacit knowledge. The second characteristic is appropriate length. An SOP should be exactly as long as it needs to be to guide someone through the process correctly, and no longer. Comprehensiveness that produces a document too long to scan in the moment of need is counterproductive. For complex processes, a layered approach works well: a short navigational summary at the top, with linked detail for each step for the user who needs it. A user performing a familiar process needs the summary. A user encountering an edge case needs the detail. One document can serve both.

The accessibility requirement

Usable SOPs are accessible at the point of need, not stored in a location that requires navigation to reach. This means integrating SOP access into the tools and systems where work happens — so that the person performing a process in a CRM, a project management tool, or a client portal can access the relevant procedure without leaving the context of their work. It also means the SOP is searchable in plain language, so that a user who knows the task they are trying to perform can find the procedure without knowing its title or its location in a folder hierarchy. The integration of intelligent retrieval into SOP access is one of the clearest applications of custom AI systems in operations. When an employee can ask a question — how do I handle a client who has missed two invoice payments, or what is the escalation path if this approval is not received within 24 hours — and receive the relevant procedural guidance immediately from the organisation's own documented procedures, the SOP is accessible in the moment it is needed. This is the version of SOP accessibility that reliably gets followed.

Keeping SOPs current

An SOP that was accurate when written becomes inaccurate as the process evolves, and an inaccurate SOP is worse than no SOP — it produces errors made with confidence. Keeping SOPs current requires two things. A process owner who is responsible for the procedure's accuracy, not just for executing the process. And a review trigger that causes the SOP to be reviewed when significant changes occur to the process, rather than on a fixed annual schedule that may not align with when the changes happen. Organisations that have invested in intelligent knowledge systems find that SOP maintenance becomes more tractable, because the system surfaces when its answers to procedural questions are inconsistent with current practice — a signal that the underlying procedure needs updating. This feedback loop between how the system is being used and what it contains is one of the less obvious benefits of intelligent knowledge management, and it is one of the most practically valuable for keeping operational documentation genuinely current.

For further reading on this topic, check out our guide on [How to build a partner ecosystem around your product or service](/how-to/how-to-build-a-partner-ecosystem-around-your-product-or-service).

For further reading on this topic, check out our guide on How to evaluate whether a strategic partnership is worth pursuing.