How I write an SOP someone will actually follow.

Why do most SOPs go unused?

A standard operating procedure, or SOP, is just a written answer to "how do we do this here." The problem is that most of them are written to prove the process exists, not to help someone run it. They read like a policy manual. The person who needs them opens the document, cannot find the step they are stuck on, and asks me instead.

When that happens, the document failed. Not the person. So I started writing SOPs for one test: can someone finish the task without messaging me?

What goes at the top?

Every SOP I write opens with the same short block, before any steps:

1. The one job. One sentence on what this process does. If I need two sentences, it is probably two processes.
2. The input. What has to be true or in hand before you start. A signed form, a list, a request from a specific person.
3. The output. What exists when you are finished, and where it lives.
4. Done means. The check that tells you the task is complete, written so there is no argument about it.
5. Never. The few actions that are off limits no matter what, like spending money or sending something under my name without a yes.

Someone who reads only that block should already know whether they are in the right document and what finished looks like.

How do I write the steps?

One action per step, starting with a verb. "Open the lead record." "Check the last note." "Mark the status." If a step has the word "and" in the middle, I usually split it.

I write the steps while doing the task, not from memory afterward. Memory skips the small moves that feel obvious to me and are not obvious to anyone else, like which tab a setting hides under or which field has to be filled before the save button works.

Where a step needs judgment, I say so plainly and give the rule I use. "If the seller gave a date, set the follow up for that date. If not, set it for two weeks out." A judgment call with no rule attached is where people stall.

What about the things that go wrong?

The most useful section in any SOP I own is the short one near the bottom that says what to do when the normal path breaks. A login fails. The data is missing. The person you were supposed to hand it to is not answering.

I do not try to predict everything. I write down the failures that have actually happened, and I add a new one each time something surprises us. Over time that section becomes the part people read most.

Every SOP also names who to hand off to. Not "escalate as needed." A specific role, and what to send them so they do not have to ask follow up questions.

Does this change when the reader is software?

Less than you would think. I now hand a lot of routine work to AI agents, and the same document structure works for them. The one job, the input, the output, the done check, and the never list are exactly what an agent needs to stay inside its lane.

If anything, writing for an agent made my documents better for people. An agent does exactly what the words say, so every vague step shows up fast. Fixing those steps for the agent fixed them for everyone else too.

How do I keep an SOP from going stale?

Every time someone asks me a question the document should have answered, I update the document before I answer the question. Then I send them the link. That one habit does more than any scheduled review.

I also keep a short line at the top with the date of the last real change. If a document has not changed in a long time and the process has, the date tells on it.

What is the actual lesson here?

An SOP is not finished when it is written. It is finished when someone can follow it without you. Write the top block first, write the steps while doing the work, keep a running list of what breaks, and treat every question as a bug report against the document.