Fix the process before you write the SOP

When a business decides it needs to get organized, the first instinct is often to start writing standard operating procedures. It feels productive. Documents get created, folders fill up, and there is a sense of progress.

Then, a few months later, nobody is using them.

One common reason is that the SOPs describe a process that was never working well in the first place. Writing it down did not fix it. It only made the problems official.

Why documenting first backfires

A process that has grown informally usually carries a lot of workarounds. Extra approvals someone added after a mistake years ago. Duplicate data entry because two tools never got connected. Steps that exist only because one person prefers them.

If you document that process exactly as it is, you lock all of it in. Your team reads the SOP, sees steps they know are pointless, and quietly goes back to doing it their own way. The document loses credibility, and so does the next one.

A better sequence

Here is the order we use with clients. It takes a little longer up front and saves a great deal of rework later.

1. Map what actually happens. Not what should happen. Sit with the people who do the work and walk through a real example from start to finish. Write down every step, every handoff, and every tool.
2. Mark the friction. Circle anywhere work waits, gets repeated, gets re-entered, or depends on a single person. Ask the team where things most often go wrong.
3. Remove before you add. For each step, ask: what would happen if we stopped doing this? Many steps can be dropped, combined, or moved to someone better placed to do them.
4. Assign clear ownership. Every step needs one owner. Not a department, a role. Shared ownership usually means no ownership.
5. Test the new version. Run it for a few weeks. Expect to adjust.
6. Then write the SOP. Now you are documenting a process that works, and your team helped build it. That is a document people will use.

What a useful SOP looks like

Good SOPs are short. They tell the reader why the process exists, who is responsible, what triggers it, the steps in order, and what “done” looks like. They link to templates and tools rather than describing them at length. And they have an owner and a review date, so they do not quietly go stale.

If an SOP is longer than a few pages, it is often two processes pretending to be one. Split it.

Keep it alive

A process is never finished. Tools change, people change, and clients change. Build a light review habit: each SOP owner checks their documents on a regular schedule and updates anything that has drifted. Ten minutes of maintenance beats a full rewrite later.

The goal of documentation is not to have documents. It is to make good work repeatable. Start with the process, and the documents will follow.