What Good SOPs Look Like
Standard operating procedures that live in a binder on a shelf are not SOPs. They are fiction. Here is how to write ones that people actually follow.
Every company I work with says they have SOPs. Most of them have documents that were written once, filed somewhere, and never opened again. A procedure that no one follows is not a procedure; it is a liability.
The Problem With Traditional SOPs
Traditional SOPs are long, text-heavy documents that describe a process in narrative form. They read like a textbook and feel like homework. The people who need them most — new hires, cross-trained staff, part-time workers — are the least likely to read a twenty-page PDF.
Short, Visual, and System-Linked
Good SOPs are short. They use screenshots, numbered steps, and decision trees. They reference the actual system the user is working in, with specific field names and button labels. And they are stored where the user can find them — ideally inside the system itself, not in a separate document management platform.
SOPs as Part of Implementation
At Infraxio, we build SOPs into every implementation. When we configure a new workflow, we document it as we go, in the language the team uses, with screenshots from their environment. The SOP is not a post-project deliverable; it is a training tool that is ready when the system goes live.
The Maintenance Question
An SOP that is not updated when the system changes becomes a trap. The instructions say to click a button that no longer exists, and the user loses trust in the documentation entirely. That is why we tie SOP updates to system change management: when a workflow is modified, the corresponding SOP is flagged for review.
The Standard
A good SOP answers one question: if the person who normally does this task is out sick, can someone else do it correctly by following these steps? If the answer is yes, the SOP works. If the answer is no, rewrite it.