Write the Process So a New Hire Can Actually Run It Without You

It's finished when they can do the task without you. Page count doesn't enter into it.

At a commercial cleaning company, the gap shows up fast. A new client signs on a Tuesday, and by Wednesday morning your phone's already ringing with questions about their account, because you're the only one who can set one up right. The onboarding "process" lives in your head and comes out one phone call at a time.

Why nobody reads the binder

You'd probably say you've trained your crew. What you've actually done is stay reachable, and that's the more expensive option.

Why nobody reads the binder

Most owners who try to write SOPs for a small business write the steps and stop there. They end up with a thick binder that captures the motion and leaves out the judgment.

The new hire reads "set up the new account" and still doesn't know which products to assign, which crew lead to flag, or what counts as done. So they call you. The binder didn't take you out of the task. It just added paperwork to the same phone call.

A 40-page SOP that still sends people to your phone is worth less than a one-page sheet they can run alone. What you want is a document a new hire can run unsupervised on the first try, and that's a very different thing from a complete one.

Three parts to every step

Every step in a process someone else can run has three parts. Skip one and the new hire's back on the phone.

The decision point is where almost every undocumented process falls apart. You've made that call ten thousand times, so it stopped feeling like a step at all. And instinct doesn't transfer to a new hire.

In some fields this standard isn't optional. In high-consequence work, a written procedure is judged on one thing: can someone who's never done the task run it correctly from the document alone?

Your account setup needs that same bar, even though nobody's safety is on the line. Write the action, name the decision, define done, and the document carries your judgment along with your motion.

Hand it over and watch

A document nobody else has run is a guess. Turning it into a process takes one person and about thirty minutes.

1. Hand it over. Give the written process to someone who's never done the task, and don't say anything else.
2. Watch them run it. Sit behind them, quietly, while they work through it cold.
3. Write down every question. Each time they pause, guess, or ask you something, note exactly where in the document it happened.
4. Fix the gap. Every question is a hole in the document. Rewrite that step so the next person doesn't have to ask.

Here's 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 fix the page and leave the person alone.

That changes who owns the problem. If you blame the hire, you'll be doing onboarding by phone forever. Blame the document, and you write it once and you're done.

Run this once and you'll usually find five to ten questions in a process you were sure was complete. Each one's a spot where the job would've come back to you in the field.

Expect the first version to be wrong

Every first draft is wrong in a few places. That's exactly why the watch-and-fix pass exists.

You can't think your way to a complete document sitting at your desk. You only find the gaps when a real person runs into them, so the test is the method itself.

When the same question comes up twice, you've found a recurring fix that deserves its own step in the document. Writing the recurring problem into the procedure is how you fix the cause of a repeat question, so you stop explaining it all over again every quarter.

Treat the document like a living thing with a version number. A process on its third revision, hardened against the last ten real questions, is worth a lot more than a first draft nobody's run. Do the writing once and it onboards the next hire without you. Skip it and you're on the phone for every new account, for as long as you own the place.

What it's worth, and where it lives

Documented proceedures a new hire can run 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're not the one doing it.

Buyers read that score as repeatability, which is what they're really paying for. Documented operations are part of what moves a business toward a higher multiple.

The same document does a second job, too. It captures the decisions the new hire used to bring you, so those calls stop landing on 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 off the daily line. For the full walkthrough on writing the document itself, format and structure included, see how to write a business SOP.

Put the three-part step and the new-hire test together and you've got one sheet you'll use again and again. It's a single page: action, decision point, and done-right check for each step, plus the rule to hand it over, watch, and fix every question.

That sheet is item H6-NHT in the Operator's Reliability Toolkit. In Keystone it's designed to live in your operating record, where filling it out starts a running history and feeds the AI SOP Generator that regenerates these documents as the work changes.

Keystone is closed right now while we finish the build, so none of that is open yet. When it opens, the free diagnostic will take 18 questions and about four minutes and return three scores and a value range with the most likely figure locked, including where your Systems Maturity Score sits today.

The waitlist is at https://app.trykeystone.io.

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.