How to write an SOP your team will actually follow

Here is the uncomfortable truth about most SOPs: they are written to feel productive, not to be used. Someone spends an afternoon documenting a process, files it in Notion or a shared drive, and moves on. Six months later a new hire asks how to do that exact thing, and everyone points them to a person instead of the doc. The doc failed at the one job it had.

A good standard operating procedure is different. It is short, it is specific, and a person who has never done the task can follow it start to finish without asking anyone. That is the whole bar. Everything below is about clearing it.

What an SOP actually is (and what it is not)

A standard operating procedure is a written set of steps for doing a recurring task the same way every time. That is it. It is not a policy, and it is not a training course. A policy says what the rule is. Training explains the why. An SOP tells one person exactly what to do, in what order, to get a specific result.

The test is simple. If you handed the doc to a capable person who had never done the task, and left the room, could they finish it correctly? If yes, it is an SOP. If they would need to interrupt someone halfway through, it is a set of notes.

When it is worth writing one

You do not need to document everything, and trying to will burn out your team fast. Write an SOP when a task is at least two of the following:

• Recurring. It happens often enough that doing it consistently matters. A one-off does not need a doc.
• Risky to get wrong. A mistake costs money, time, a client, or trust. Payment runs, client onboarding, and anything customer-facing usually qualify.
• Stuck in one head. Only one or two people know how, and the business stops if they are out. This is the key-person risk that quietly caps how far you can grow.
• Handed off soon. You are about to delegate it, hire for it, or scale it. You cannot hand off what you have never written down.

If you are not sure where to start, rank your processes by how much pain they cause versus how hard they are to document. The high-pain, low-effort ones pay back the fastest. That prioritization is the entire point of a proper documentation audit.

The anatomy of a good SOP

Every SOP worth keeping has the same bones. Miss one and the doc gets ambiguous exactly where people need it to be clear. Here is the structure we use on every single one:

• A plain title. Name the process the way people say it out loud, not in corporate-speak. "Monthly payment run," not "Accounts payable disbursement workflow."
• One named owner. A role, and ideally a person. Never "the team." If everyone owns it, nobody does.
• A clear trigger. What starts this process? A date, an event, an approval landing in a queue. If people are not sure when to run it, they will run it late or not at all.
• Numbered steps. Short, in order, one action each. Start each with a verb. Assume the reader knows nothing.
• A RACI line. Who is Responsible, Accountable, Consulted, and Informed. This is what makes handoffs stop being a guessing game.
• A definition of done. The single clearest thing in the doc. What does finished look like? "Payment released and confirmation logged" leaves no room to argue.
• Common mistakes. The two or three things people always get wrong. This is the part that turns a decent doc into a great one.

How long should all of that come to? As long as it needs to be and no longer. Most SOPs that follow this shape sit between half a page and two pages. If a step is obvious to a brand-new hire, cut it. If it is the kind of thing people get wrong, keep it and add a note about the common mistake.

Below is that structure filled in for a real process, so you can see how tight it can be.

How to write one, step by step

Do not write from memory at your desk. The best SOPs come from watching the work happen and then getting out of the way. Here is the process that actually produces docs people follow.

1. Sit with the person who does it

   Not their manager. The person whose hands are on the work. Ask them to walk through it while you take notes, and record it with their consent so you are not scribbling. The gold is in the little "oh, and you have to remember to" asides.

2. Draft it lean

   Write the steps in order, one action per line, starting with a verb. Add the owner, trigger, and definition of done. Resist the urge to explain every why. An SOP is instructions, not a lecture.

3. Test it on a fresh pair of eyes

   Hand the draft to someone who has never done the task and ask them to follow it exactly, doing nothing that is not written. Every place they get stuck or ask a question is a gap your draft was hiding. Fix those and only those.

4. Add the common mistakes

   Ask the expert: what do people always get wrong here? Add those as a short "watch out for" note. This is the difference between a doc that is technically correct and one that actually prevents errors.

5. Publish it where people already look

   Put it in the tool your team already opens every day, Notion, Confluence, Google Docs, or Airtable. A perfect SOP in a place nobody visits is a dead SOP.

A real example, start to finish

Take the payment run above. From memory, someone might write "process the monthly payments." Useless. Following the method, you sit with the finance lead and learn that the real risk is not the paying, it is the bank details. Vendors change accounts, and a stale record sends money to the wrong place.

So step one becomes "verify bank details against the vendor record," and the common-mistakes note becomes "never trust a bank-detail change that arrives by email alone, confirm it by phone." That single line, which only surfaced because you watched the work, is worth more than the rest of the doc combined. That is what documenting from reality gets you.

Common mistakes that kill SOPs

• Writing for yourself. You know the shortcuts, so you skip them. The new hire does not. Write for the person who knows nothing.
• No owner, or "the team" as owner. Shared ownership is no ownership. Name one role.
• Explaining instead of instructing. Paragraphs of context bury the actual steps. Keep the why short and the what clear.
• No definition of done. Without it, "finished" is a matter of opinion, and things get left half-complete.
• Documenting the org chart, not reality. How work is supposed to flow and how it actually flows are rarely the same. Document what really happens.
• Writing it once and never touching it again. The next section is entirely about this one.

Keeping SOPs from going stale

An SOP is only true on the day it is written. Tools change, people change, steps change. A doc that no longer matches reality is worse than no doc, because people follow it and get the wrong result. Three habits keep them alive:

• Give every doc an owner who is also its maintainer. The owner is responsible for the doc being current, not just the process running.
• Review on a schedule, not a whim. A quick quarterly pass, or a review triggered whenever the tool or team changes, catches drift before it bites.
• Make updating easy. If fixing a doc takes ten minutes and a request to IT, it will not happen. Keep them somewhere anyone can edit in seconds.

Do it yourself, or hand it off

You now have everything you need to write a solid SOP. For a handful of processes, that is genuinely all it takes: block the time, sit with your people, follow the steps above. Plenty of teams should just do that.

Where it breaks down is scale. Documenting five processes is a project. Documenting fifty, keeping them consistent, and maintaining them while everyone still has a day job is a different animal, and it is the point where most in-house efforts stall at 30 percent done. If you want an honest look at the real cost of the DIY route, we wrote a whole piece on doing it yourself versus handing it off.

Baselinify does this for a living: we interview your team, map how work really moves, and turn it into a documented system your people actually open. If that sounds like the shortcut you need, book a short call and we will tell you honestly whether it is worth it for you.