How to Write a Business SOP That Someone Else Can Actually Follow

The short version

• Most SOPs fail for one reason: the owner is still in the room when the document gets used, quietly filling every gap.
• A real SOP is not a record of how you work. It is the thing that lets the work happen while you are gone.
• Every usable SOP has five parts, and one test that proves it before you trust it.
• Documentation is part of what moves a business from a 1.65x multiple toward 3.5x, a $555,000 spread on a $300,000-SDE business.
• Below: how to document a process in five parts, how to write the steps, and the handoff test that separates a real SOP from a record.

Most business SOPs do not fail because they are badly formatted. They fail because the owner is still standing there when someone uses them, answering the questions the document never anticipated.

The root cause is who the document was written for. Almost every SOP is written by the person who already knows the job, for a reader they unconsciously assume also knows it, so every judgment that person makes without thinking gets left off the page.

That is the part nobody tests for. The SOP looks complete on the page, and then the work only runs because the owner is in the room to patch every gap in real time.

So before any formatting or software question, ask the only one that matters. Could someone who has never done this task run it from your document while you are unreachable for two weeks?

If the honest answer is no, you have written a record of how you work, not a procedure someone else can follow. This article is about writing the second thing.

What a business SOP is actually for

An SOP is a transfer instrument, not a record. How to document a process so someone else can follow it: write a single process as a triggered sequence of steps, name who owns each decision inside it, and define the standard for "done," then hand it to a person who has never run the task and confirm the work holds while you stay out of the room.

That last clause is the whole point. The purpose of the document is to move the work off you, which is the entire premise of building a business that runs without you.

Put plainly, an SOP is knowledge moved out of your head and into the company. Until it is written down in a form someone else can run, the process is not an asset the business owns, it is a thing you happen to know how to do.

A buyer reads it the same way. Undocumented work is one of the clearest signals that a business depends on its owner, and it gets priced as risk.

Here is why that matters in dollars. A business that runs without its owner tends to sell near 3.5x its earnings; one that depends on the owner sells near 1.65x.

On a $300,000-SDE business, that spread is $555,000. Documentation that truly transfers the work is one of the moves that crosses it, which is why an SOP is worth doing right or not at all.

The five parts every usable SOP has

A documented process that misses any of these parts breaks the moment the owner is not there to fill the gap. The gap is always the thing you do without thinking, which is exactly what does not survive being left off the page.

A usable SOP has five parts:

• The trigger. What event starts this process, stated plainly. Without it the reader knows the steps but not when to begin, so the process only runs when you tell them to.
• The owner. The one person accountable for the outcome, named by role. A process owned by everyone is owned by no one, and it quietly routes back to you.
• The steps. The actual sequence, written so a new hire can run it from the page. This is where most SOPs are thin, because the writer skips what feels obvious to them.
• The decision rights. What the runner decides alone, and what they escalate. This is the part that lives in your head today, and leaving it out is what keeps you in the room.
• The done standard. What a finished, correct result looks like, in observable terms. Without it the work gets done to the runner's standard, not the standard the business needs.

Notice that two of the five parts have nothing to do with the steps. The owner and the decision rights are about authority, and they are what separate a procedure from a recipe.

This is also where delegation lives. Writing the steps is documentation; assigning the owner and the decision rights is handing the work off rather than just writing it down.

How to write the steps so someone else can follow them

The hard part is not formatting the steps. It is that you no longer see the small decisions you make automatically, the ones that are invisible to you and load-bearing for everyone else.

Here is the method that surfaces them.

1. Write it while you do it, not from memory. Run the task once and narrate every action as it happens, including the parts you would skip. Memory smooths over the exceptions, and the exceptions are where a new person gets stuck.
2. Write to the new hire, not to yourself. Assume the reader knows the job category but nothing about your business. Every "obviously" in your draft is a place the process will stall when you are gone.
3. Name the decisions you make in your head. For each judgment call, write the rule you actually use and the threshold where it changes. This is the institutional knowledge a buyer is afraid will walk out with you.
4. Cut the steps that need you to interpret them. If a step only works because you are available to clarify it, it is not written yet. Rewrite it until it stands without you.
5. Document the most expensive process first. Start with the task that breaks worst when you are away, which is usually the bottleneck you have quietly become. One transferred bottleneck buys back more of your week than ten tidy checklists.

The output of step five compounds. Each process you truly transfer is a piece of the path toward running the business in a handful of hours a week, instead of being the person every task routes through.

The handoff test: proof the SOP works

A finished SOP is a hypothesis, not a result. You believe the work transfers; the test is whether it actually does when you are not there to prop it up.

Run the handoff test before you trust any SOP:

1. Hand it to someone who has never done the task. Give them the document and nothing else, no verbal walkthrough. Your explanation is the variable you are trying to remove.
2. Leave the room and stay unreachable. The whole point is the absence, so do not hover and do not answer questions. Every question they have to ask you is a gap in the document, not a gap in the person.
3. Compare the result against the done standard. Did the output meet the standard the SOP defined, without you. If not, the SOP failed the test, not the runner.
4. Fix the document, not the person. Every place they got stuck marks a missing step, an unnamed decision, or an undefined standard. Patch the page and run the test again with a fresh person.

A process that passes this test twice with two different people is documented. One that only works when you are reachable is still yours, no matter how clean the formatting looks.

Then watch that it keeps holding. Once a process runs without you, a simple dashboard of the few numbers that matter tells you it is still meeting the standard, instead of you checking by being present.

Do this across your core process documents and the business starts to look different to a buyer. Documented, owner-light operations are what make a company read as a semi-absentee business rather than a job with your name on it.

FAQ

How do you write a business SOP that someone else can follow?

Write a business SOP by documenting one process as a triggered sequence of steps, naming who owns each decision, and defining what "done" looks like. Then hand it to someone who has never done the task and confirm the work holds while you stay out of the room.

What should a business SOP include?

A usable business SOP includes five parts: the trigger that starts the process, the role accountable for the outcome, the steps written for a new hire, the decision rights that say what the runner decides alone, and the done standard. The two most often missing are the decision rights and the done standard, and their absence is what keeps the owner in the loop.

How do you know if an SOP actually works?

You know an SOP works when someone who has never done the task completes it to the done standard from the document alone, while you are absent and unreachable. If they have to ask you questions, the document has gaps, and the work has not transferred off you yet.

---

You cannot transfer work off yourself until you know which work is discounting your value most.

The free Keystone diagnostic gives you three scores and an estimated sale price, calibrated against 10 years of BizBuySell Insight Reports and 1.6M+ SBA 7(a) loan records. It shows you where undocumented, owner-dependent work is pulling your number down.

Get your three scores and an estimated sale price, free, at app.trykeystone.io.

Writing the SOPs is the work. Installing them across a business in 30 days is the Systems Sprint.

The Sprint documents your core processes, names the decision rights, and puts the operating layer in place so the work runs without you. Pricing is $1,500 Beta, $1,900 Standard, and $4,500+ for the Portfolio Edition.