SOPs your team actually follows

Every company has tried documentation. A shared Google Drive. A Confluence wiki. A Notion workspace someone built on a Friday afternoon. Six months later, nobody uses it.

The problem isn't the tool. It's the approach. Most documentation projects start from the top — what leadership thinks the process should be. Not what actually happens day to day.

The result: SOPs that describe an ideal workflow nobody follows. The team ignores them because they don't match reality. They're aspirational, not operational.

SOPs that stick have three qualities. They're written from observation, not imagination. They use the team's language, not management jargon. And they live where the work happens — embedded in the tools, not buried in a folder.

The first step is always the same: talk to the people who do the work. Not managers. The person who actually processes the order, handles the return, onboards the client. Watch them work. Record what they do. Capture the workarounds.

Then you write the SOP from that reality. Every step matches what someone actually does. The edge cases are documented. The decision points are clear. A new hire can follow it on day one.

The final piece is placement. An SOP in a shared drive is a dead document. An SOP linked directly in your project management tool, triggered at the right moment in the workflow — that's infrastructure. That's the one your team actually follows.

Documentation isn't a project. It's an operating system. The companies that treat it that way are the ones where it sticks.