How long should an SOP be?

As long as it takes to pass the Novice Test, and not a line longer. Most single-task SOPs land between half a page and two pages. If yours runs past three, it is usually two or three separate procedures wearing one title — split it by trigger. A long SOP is not a thorough SOP; it is usually an undecided one.

What is the difference between an SOP, a process, and a policy?

A policy is the rule (we reply to every enquiry the same business day). A process is the wider flow across people and stages (how a lead becomes a client). An SOP is the step-by-step instructions for one task inside that flow, specific enough to run the same way every time. Owners often try to map the whole process when what they actually need first is three SOPs.

Who should write the SOP — the owner or the person doing the task?

Whoever currently does the task should narrate it, and someone else should write it down. The doer knows the real steps including the workarounds; the writer catches what the doer stopped noticing years ago. If you are both people, talk yourself through the task while you do it and write from that rather than from memory.

How do you write an SOP if you are the only person in the business?

You write it for the version of you that is not there — the you who is on a call, away, or ill. That stand-in is your novice, and it is what makes a solo SOP worth the hour. It is also the prerequisite for ever handing the task to anyone or anything else: you cannot delegate a task that only exists in your head.

How do you keep SOPs from going out of date?

Give each one an owner and a revision line at the bottom, and change the document when the work changes rather than at a scheduled review. The practical rule: when something goes wrong in a task, the fix is not finished until the SOP reflects it. A procedure nobody has edited in a year is usually one nobody is following.

How to Write an SOP: The 7-Step Method (And the Test That Decides If It Works)

You did write it down once. Sat there on a Sunday, typed out how the job gets done, sent it over — and then spent the next fortnight answering questions about it anyway. Third interruption of the week, same task, and you end up doing the thing yourself because explaining it takes longer than finishing it.

That is not a discipline problem. It is almost always the same technical fault: the document was written by someone who already knows how to do the job, for someone who does not. Every step you skipped because everybody knows that is exactly where the next person stops and comes looking for you.

Here is the method that fixes it — the seven steps professionals follow, and the one test that tells you whether what you wrote will survive contact with a real human. (If you want a blank structure to pour this into, take the free SOP template first, then come back.)

1. Pick one task with one trigger

Not “client management.” One task, with a clear starting gun: a new client signs, an invoice hits 14 days overdue, a call comes in after hours. If you cannot name the trigger in a few words, you are holding a process, not a procedure — break it into the tasks inside it and write those.

Name it verb-first: “Onboard a New Client.” Not “Onboarding.” It is a small thing that keeps the whole document honest, because it forces every line underneath to be an instruction rather than a description.

2. Write it while you do it, never from memory

This is the step that separates a usable SOP from a wishlist. Run the task once and narrate it as you go — talk it through out loud, describing each thing you touch as you touch it, and write from that.

Memory writes the version you intend to do. Doing it writes the version you actually do, including the small workarounds you invented years ago and stopped noticing: the tab you always check first, the field you leave blank on purpose, the person you always copy in. Those undocumented reflexes are the entire gap between your result and theirs.

3. Give every step a verb, one action, and a “done when”

The body of the SOP is a numbered list, and each line carries three things:

An action verb first. “Send the welcome email,” not “The welcome email should be sent.”
One action. If there is an “and” in the step, it is two steps. Split it.
A “done when” check. Send the intake form — done when it comes back completed. Without it, “done” is an opinion, and the task quietly ends up half-finished.

That last one is what most people leave out, and it is what makes a procedure testable rather than merely written.

4. Make every fork explicit

Wherever the task can go two ways, say both ways out loud: “If the deposit has cleared, book the kickoff. If it has not, send reminder two and hold.”

An implied decision is an invitation to improvise, and improvisation is precisely what you were trying to stop. Two or three named forks cover almost every real case; the genuinely rare ones go in an Exceptions section at the bottom, with who to escalate to.

5. Hunt down the vague words

Do a pass with one job: find every word that cannot be checked. The usual offenders are as needed, regularly, promptly, if appropriate, follow up, make sure it looks right.

Each one gets replaced with a number, a trigger, or a name:

“Follow up regularly” → “Call on day 1, day 3, and day 7. Stop after day 7 or on reply.”
“Respond promptly” → “Reply within one business hour, 9am–5pm.”
“Make sure it looks right” → “Check the name, the amount, and the due date against the signed proposal.”

Vagueness is how an SOP fails without anyone noticing it failed. Everybody follows it, and everybody follows it differently.

6. Run the Novice Test

Hand the document to someone who has never done the task, ask them to do it, and sit there saying nothing. This is uncomfortable and it is the whole ball game.

Every question they ask is a missing step. Do not answer and move on — write the answer into the document. The rule is that you fix the SOP, not the person. When they can get from trigger to “done when” without turning around, the procedure is finished. Until then it is a draft with a witness.

Nobody to test it on? Do the task yourself from the document only, executing exactly what is written and nothing your hands know by heart. You will find three gaps in the first pass.

7. Give it an owner and a revision line

At the bottom: who owns this procedure, and the date it last changed. Then the standing rule that keeps the whole library alive — when something goes wrong in a task, the fix is not finished until the SOP reflects it.

That single habit turns a folder of documents into something that gets better every time it breaks, instead of ageing into fiction.

Writing them faster (without writing rubbish)

The genuinely fast way is to talk, not type. Describe how you actually do the task — messy, out of order, all the caveats — and let AI structure it into the format above. Then read every line and fix what is wrong, because AI is a co-writer, not a ghostwriter, and an SOP nobody checked is worse than no SOP at all: it is wrong with authority.

What you should never do is ask AI to invent the steps. It will produce a beautiful, generic procedure for a business that is not yours, and you will not find out until someone follows it.

Which ones to write first

Start with the tasks that touch money and trust: taking an enquiry, following up, onboarding, invoicing, chasing payment. Not because they are the hardest, but because they are the ones that stall when you get busy — and stalling is expensive in a way that never shows up on a statement.

Think about what actually goes wrong in a full week. The deal that stalled. The case that went quiet. The renewal nobody called about. The patient who booked somewhere else. None of them were lost on price. They were lost because the admin around them is loud — a client is waiting, a form is due, a portal is nagging — while the revenue work is quiet. Nobody is sitting there waiting on the follow-up to a prospect who has not asked. Loud wins every day, the score is never kept, and the work dies of neglect rather than rejection.

An SOP is how that quiet work stops depending on whether you happened to have a good week. It gets the task out of your head and onto paper, where someone — or something — else can run it the same way every time.

Writing it down is step one out of that trap. Turning what you have written into an AI employee that runs it for you is step two, and that is what we build at CoreFlux.

Want to see the shape filled in before you write your own? Here are 4 real SOP examples you can copy. And if you would rather not write the first ten at all, the AI SOP Kit below has them done.