How to Write SOPs That People Actually Follow

Nearly every small team has a documentation graveyard. A folder of half-finished process documents written during a quiet week, none of them updated since, none of them trusted, all of them technically still there.

The failure is rarely effort. It is that the documents were written for the wrong reader at the wrong moment. Somebody sat down to write documentation as a project, in the abstract, and produced a description of the process rather than instructions for running it. Descriptions are pleasant to write and useless to follow.

The second cause is that they were written by the person who knows the process best, which sounds right and is a trap. An expert writing about their own routine skips the parts that have become automatic, which are exactly the parts a new person gets wrong. The document says update the client record, and the new hire does not know which system, which fields, or what happens if the record does not exist yet.

The third cause is that no decision rules were captured. Real processes are full of branches. What if the input is missing. What if the client asks for something out of scope. Who can approve an exception. A document that covers only the happy path fails on its first real use, and one failure is enough for people to stop consulting it.

The result is the state most teams live in: the process exists, it works, and it lives entirely in one person's habits. This is fine until that person is on holiday, leaves, or gets busy, and then it is the most expensive problem in the company.

A usable SOP has six parts, and it is usually shorter than the unusable version.

A trigger. What causes this process to start. A contract is signed. An invoice passes thirty days. A customer requests a refund. Documents without triggers describe work that nobody knows when to do.

An owner. One named role responsible for the process running, not a committee. Steps can have different owners, but the process needs a single person who notices when it did not happen.

Numbered steps in the order they occur, each specific enough to act on. Not update the CRM but create the account record in the CRM with company name, plan, and start date, then set the owner to the account manager. If a step requires a tool, name the tool. If it requires a template, link the template.

A definition of done for each step, or at least for the process. What visible state indicates this step is complete. This is the part most documents omit, and it is why work gets marked finished in five different states of completeness.

Decision rules for the branches. If the client has not provided access by day three, send the reminder and flag the milestone as at risk. If the refund is over five hundred dollars, get founder approval. These rules are the difference between a document and a description.

Open questions, written down as open. Anything you could not answer while writing should be listed explicitly rather than quietly guessed at. An SOP that admits it does not yet cover disputed invoices is far more trustworthy than one that pretends the case does not arise.

The fastest way to produce a good SOP is to stop trying to write one. Writing documentation from scratch is slow, it invites idealization, and it produces the polished-but-wrong version of the process.

Instead, narrate the process while doing it, or immediately after. Talk through what you actually did on the last real instance: what triggered it, what you opened, what you checked, what you decided and why, where you got stuck, and what you would have told someone standing next to you. This produces the true process, including the improvisations, which are usually the most valuable part.

The difference matters because the narrated version contains the decision points. When you describe a process in the abstract you produce a clean sequence. When you describe what you actually did last Tuesday, you say things like and then I checked whether they had already been invoiced, because sometimes they have, and that is a rule you would never have thought to write down.

This is exactly the input the Turn Recurring Work into an SOP pack is built for. You talk or type through how the work gets done, messily, and it produces numbered steps with owners, triggers, and a definition of done for each one. More usefully, it interrogates the walkthrough: what starts this, what does finished look like, what happens when the input is missing. Anything you could not answer comes back as an open question rather than an invented step.

The practical version of this takes twenty minutes per process. Twenty minutes of talking beats two hours of writing, and the output is closer to reality.

A document that is written and then not used is a slightly more expensive version of no document. Adoption is a design problem, not a discipline problem.

Put the SOP where the work happens. If the process runs in a project tool, the SOP should be linked from the task template. If it runs from an inbox, it should be linked from the saved reply. A document in a wiki that requires someone to remember it exists, find it, and search it will not be consulted under time pressure, which is the only time it matters.

Make the first use a real one. Do not review the SOP in a meeting. Hand it to the next person who has to run the process and let them attempt it without help. Everything they have to ask you is a gap, and those gaps are the entire value of the exercise. Fix them the same day, while both of you remember the question.

Update at the point of failure. The rule that keeps documents alive is that whoever finds it wrong fixes it right then, in one line, without a process for updating processes. Teams that require a review cycle to correct a document end up with documents that are known to be wrong and stay wrong.

Keep them short enough to stay current. A one-page SOP with eight steps gets maintained. A twelve-page process manual does not, because updating it feels like a project, so it decays until nobody trusts any part of it.

And resist the urge to document everything. A team with six trustworthy SOPs covering their highest-risk work is in a much better position than a team with forty documents of unknown accuracy. Coverage without trust is worse than gaps you know about.

A written SOP is the prerequisite for automating the work, and this is the argument that convinces most founders to write them.

An automated workflow needs exactly what a good SOP contains: a defined trigger, ordered steps, explicit decision rules, and a clear definition of done. If you cannot state those, you cannot automate the process, and any attempt will produce something that handles the happy path and breaks on everything else.

Once the SOP exists, the automation decision becomes concrete rather than aspirational. Go step by step and label each one. Steps that follow fixed rules on structured input are candidates for a workflow pack. Steps that require judgment on ambiguous input stay human, at least for now. Steps that are just moving data between systems are candidates for straightforward integration. Most processes turn out to be roughly half automatable, and knowing which half is the useful output.

The practical sequence for a small team is: write the SOP, run it manually a few times to confirm it holds, then automate the highest-frequency mechanical steps and leave the judgment steps in place. Client onboarding is the common example. The kickoff email, the access list, the internal checklist, and the recap format are all mechanical and can be generated from the signed scope. The conversation about goals and the decision about what to prioritize are not.

The underlying point is that automation is not an alternative to documentation. It is documentation that executes. Teams that treat SOPs as a chore to skip on the way to automating end up automating a process nobody agreed on, which is a more permanent version of the problem they started with.