Before You Write a Single Step, Decide Where It Starts and Stops

Every procedure needs a defined beginning and a defined end before it needs a
single step, and the end is where most owners quietly wing it. Here's how to draw both boundaries, and how big to let the middle get.

Every small business that closes its books at the end of the month eventually has the same argument, usually right after something has gone wrong. Two team members handle the monthly close. Where does the job actually end? One team member thinks it ends when the numbers are entered into the spreadsheet. Another thinks it ends when the report gets sent to the owner. A third thinks it isn't finished until the owner has actually reviewed and signed off on it. None of them are wrong exactly. Each of them is working off a different, unspoken guess about where the procedure stops, and the gap between those guesses is exactly where a discrepancy sat unresolved for two weeks last spring.

That gap is the whole argument for settling a start and a stop before writing a single step in between.

Most people writing an SOP for the first time start in the middle. They open a blank document and type whatever comes to mind first, usually a step that feels central to the work: "check the customer's payment history" or "diagnose the leak." That instinct is understandable and it produces a weak document almost every time, because a step in the middle only makes sense once you know what it's the middle of. Before any of that, answer two questions. What single event kicks this procedure off? What single, checkable condition means it's finished?

The start is usually the easy half. A new hire's onboarding procedure starts the moment a signed offer letter comes back, not "sometime before their first day." A customer complaint procedure starts the moment the customer reaches out, not "when someone gets around to it." Pick a start that's a specific, nameable event, something you could point to on a calendar or in an inbox, and it rarely gets argued about later.

The stop is where the real disagreement lives, and it's also the part people skip because they assume it's obvious. "The job is done" is not a stop. "The customer's happy" is not a stop, because happiness isn't something you can check off a list at three in the afternoon while closing out a work order. A real stop is a specific, verifiable condition: the invoice has been sent and payment has been logged, a narrower target than simply finishing the work. The deposit has cleared and been recorded in the books, a step past just having the money counted. A new hire has completed their first shift and their access to the shared calendar has been confirmed, more concrete than saying they're all set.

Write the stop in a form a second person, someone who wasn't there, could check without asking anyone a question. If checking whether a procedure is done requires a conversation, the stop wasn't defined precisely enough yet.

Once the start and stop are pinned down, the steps in between mostly write themselves, because the boundaries are fixed and all that's left is filling in what has to happen to get from one to the other. This is also where a second problem tends to show up, and it's the opposite of a fuzzy stop: too many steps.

It's tempting, once you're on a roll, to capture everything. Every judgment call, every exception, every "and also sometimes we check this." Big topics invite this the worst: how a business manages an entire client account over a year, how a team runs a new client relationship end to end. Write instructions for something that large and the result runs thirty or forty steps, which sounds thorough and functions terribly, because nobody reads a forty-step instruction sheet in the middle of a busy day. It also breaks the moment reality deviates even slightly from the one path written down, and reality deviates constantly.

The useful ceiling sits around eight steps. A little over is fine. Well under is even better. Eight is a rough signal. Past it, you're usually looking at several procedures stacked together and treated as one.

Splitting a bloated SOP into smaller, linked procedures is the same move as before, instead of cutting content until it barely fits into one long one. A business's "manage a major client account" instruction breaks cleanly into "onboard a new client," "schedule recurring check-ins," and "handle a mid-contract change," each one short enough to read in under a minute, each one pointing to the next at the exact spot where one hands off to another. A team member doesn't carry one binder that covers every situation. She keeps a set of short reference guides, one per task, and grabs the one she needs.

The last piece of scoping a procedure well is how you name each step once you know what belongs in it. Most first drafts name steps after activities: "talk to the customer about the invoice," "look over the estimate," "check in with the team." Activities describe what someone is doing while the step is in progress, and that's the wrong information for a document someone is going to skim in the middle of a busy day.

Name each step after its outcome instead: not "talk to the customer about the invoice" but "customer has confirmed the invoice total." Not "look over the estimate" but "estimate is checked against costs and approved." Not "check in with the team" but "the team has confirmed today's task list and start time." The difference sounds small on the page and it isn't small in practice. Someone skimming a list of outcomes can tell at a glance which step they're on and what "done" looked like for the step before it. Someone skimming a list of activities can only tell that work is happening somewhere in that step, which isn't information at all.

Get the start, the stop, the size, and the outcome-based naming right, and you've built the skeleton of a procedure that will actually hold up under use. What's still missing is the connective tissue: what someone needs before they can start, what they're handing off when they finish, and a fast way to double-check they didn't miss anything. That's next, and it's also where most people either rush through in five minutes or spend three hours trying to make perfect, when the right answer is neither.