Write the Process So a New Hire Can Actually Run It Without You
Most "write an SOP" advice produces a binder nobody uses. Here is the standard a new hire can run unsupervised, and the test that proves the document works in someone else's hands.
The short version
- A commercial cleaning company at about $1.6M revenue routes every new client through the owner for the first month, because he is the only one who can set up an account correctly.
- A usable process is not a thorough document. It is one an average new hire can run correctly without you in the room.
- The test is brutal and simple: hand it to someone who has never done the task, watch them run it, and treat every question they ask as a gap in the document, not a failing in the person.
- This is the most direct lever on your Systems Maturity Score, the number a buyer reads as repeatability.
- Below: what every step needs, the test that proves it works, and the score it moves.
The process that lives in your head
To document a process so someone else can run it, write down three things for every step: the action, the decision the step hides, and what the finished work looks like when it is done right. Then hand the document to a person who has never done the task, watch them run it cold, and fix every place they have to ask you a question.
The document is finished when they can complete the task without you. That is the standard, not page count.
Picture the commercial cleaning company at about $1.6M revenue. The owner is the only person who can set up a new account correctly.
So every new client routes through him for the first month. The onboarding "process" is not written anywhere; it lives in his head and comes out one phone call at a time.
He would tell you he has trained his crew. What he has actually done is stay reachable, which is a different thing and a more expensive one.
The controlling question is the one most owners never ask plainly. How do I document what I do so someone else can do it at my standard without asking me?
Why the binder nobody reads fails
Most owners who try to create standard operating procedures for a small business write the steps and stop. They produce a thorough binder that documents the motion and leaves out the judgment.
The new hire reads "set up the new account" and still does not know which products to assign, which crew lead to flag, or what counts as done. So they ask.
The binder did not remove the owner from the task. It just added a document to the same phone call.
Thorough is not the goal, and it never was. A 40-page SOP that still sends the new hire to your phone is worth less than a one-page sheet they can run alone.
The reframe is the whole game. The goal is not a complete document; it is a document a new hire can run unsupervised on the first try.
That distinction separates the binder on the shelf from the process that takes you out of the work. One is a record of what you do; the other is an instruction someone else can execute without you.
The three things every step needs
Every step in a runnable process carries three parts, not one. Skip any of them and the new hire comes back to you with a question.
- The action. What to physically do, in plain words: "Open the account in Jobber and assign the service plan." One sentence, no ambiguity.
- The decision point. The judgment call the step hides: which plan for a 5,000-square-foot office versus a 1,200-square-foot clinic, and what "good enough" means before the job ships. This is the part owners leave out because they make it without noticing they made it.
- The done-right check. What the finished output looks like: the account shows a named crew lead, a confirmed first-clean date, and a flagged supply list. The new hire can check their own work against it.
The decision point is where almost every undocumented process breaks. The owner has made that call ten thousand times, so it feels like instinct rather than a step, and instinct does not transfer to a new hire.
There is a field where this standard is not optional. In high-consequence work, the test of a written procedure is not whether it is thorough; it is whether someone who has never done the task can run it correctly from the document alone.
That is the bar the cleaning owner needs for account setup, even though no one's safety is on the line. Write the action, name the decision, define done, and the document carries his judgment instead of just his motion.
The new-hire test: hand it to someone and watch
A document that has never been run by someone else is a guess, not a process. The test that turns the guess into a process takes one person and about thirty minutes.
- Hand it over. Give the written process to someone who has never done the task, and say nothing else.
- Watch them run it. Sit behind them and watch, in silence, while they work through it cold.
- Log every question. Every time they pause, guess, or ask you something, write down exactly where in the document it happened.
- Fix the gap. Each question is a hole in the document. Rewrite that step so the next person does not have to ask it.
Here is the line the whole method turns on: a failed handoff is a gap in the document, not a failing in the person. When the new hire gets stuck, you do not retrain the person; you fix the page.
That reframe changes who owns the problem. An owner who blames the hire keeps doing onboarding by phone forever; an owner who blames the document writes it once and is done.
Run this once and you will usually find five to ten questions in a process you were sure was complete. Each one is a place the task would have routed back to you in the field.
Write it once, then fix it where it breaks
The first version of any process is wrong in a few places. That is not a failure of the writing; it is the reason the watch-and-fix pass exists.
You cannot think your way to a complete document at the desk. You find the gaps only when a real person hits them, which is why the test is the method, not a final exam.
When the same question comes up twice, you have found a recurring fix that belongs in the document as its own step. Encoding the recurring problem into the procedure is how you fix the cause, not the symptom instead of re-explaining it every quarter.
Treat the document as a living instruction with a version, not a stone tablet. A process on its third revision, hardened against the last ten real questions, is a different asset than a first draft nobody has run.
The owner who does this once builds a sheet that onboards the next hire without him. The owner who skips it stays on the phone for every new account, indefinitely.
What a documented process is worth, and where it lives
Documented, new-hire-runnable procedures are the most direct lever on your Systems Maturity Score, the SMS in your free Keystone diagnostic. The SMS measures exactly this: how much of the work holds at standard when you are not the one running it.
A buyer reads that score as repeatability, which is what they are actually paying for. An owner-dependent business transacts near 1.65x earnings and an owner-light one near 3.5x, and documented operations are part of what moves a business toward the higher number.
The same document does a second job. It encodes the decisions the new hire used to bring you, so those calls stop routing to your desk and you can route the decision away from you for good.
This is the method layer of running the business like a system, the discipline that takes you out of the daily line. For the full step-by-step of writing the document itself, including format and structure, see how to write a business SOP.
Put the three-part step format and the new-hire test together and you have one reusable artifact. It is a one-page sheet: action, decision point, and done-right check for each step, plus the rule to hand it over, watch, and fix every question they ask.
That sheet is item H6-NHT in the Operator's Reliability Toolkit. Its durable home is your Keystone operating record, where filling it in starts an accumulating in-app history and feeds the AI SOP Generator that regenerates these documents as the work changes.
Start with the score that measures whether your operations run without you. Get your three scores and an estimated sale price, free, at app.trykeystone.io.
This is not a download to file away. It lives in, and accumulates inside, your Keystone operating record.
FAQ
How do you document a process so someone else can run it?
Write three things for every step: the action, the decision the step hides, and what the finished work looks like when it is done right. Then hand the document to someone who has never done the task, watch them run it cold, and fix every place they have to ask you a question.
What is the difference between a process and an SOP?
A process is the sequence of actions a task takes, and an SOP is that process written down precisely enough that someone else can run it. The real test of an SOP is not length: it is whether a new hire can complete the task from the page without asking you.
How do I write an SOP for a small business?
Document each step as an action plus the decision point and the definition of done, not just the motion. Keep it to one page where you can, then prove it works by handing it to someone who has never done the task and watching them run it.
How do you train someone to do your job?
Put your judgment on paper, then test the paper instead of repeating yourself. Hand the written process to the new hire, watch them run it, and treat every question they ask as a gap in the document to fix, so the next hire trains from the page and not from your phone.
You cannot close a gap you have not measured.
Keystone gives you three scores and an estimated sale price, calibrated against ten years of closed transactions and 1.6M+ SBA 7(a) loan records. Free, in four minutes, and launching soon. Join the waitlist for first access.
Join the waitlistReady to close the gap, not just measure it? The Systems Sprint installs the four operating assets in 30 days. Delivered once, no retainer, under five hours of your time.