Nobody Writes a Good Procedure in One Sitting, and You Shouldn't Try

A list of steps needs three more pieces before it becomes a procedure people trust, plus a discipline about how it gets written. Here's what to add, and why doing it all in one sitting works against you.

A business owner sits down on a Sunday night to write her first real procedure: how to prepare a proposal for a new client. She's got the steps mapped out already, a clean start, a clean stop, six outcome-named steps in between. She reads it back and something's missing. A new hire could follow those six steps and still send a proposal with the wrong pricing, or miss a detail because nobody told them to check which package the client actually asked about. The steps are right. The gap is in the context around them.

That context lives in three short pieces most people either skip entirely or bury inside the steps themselves: purpose, inputs, and outputs.

Purpose answers a question nobody thinks to ask until it's too late: why does this procedure matter, beyond just getting the task done? For the proposal, the purpose might be a sentence or two: get an accurate proposal in front of the client within twenty-four hours, because the two biggest reasons this business loses a deal to a competitor are a slow proposal and a proposal that changes once the client asks a follow-up question. That sentence tells whoever's using the procedure what to protect when a judgment call comes up that the steps don't cover.

Inputs are the ingredients someone needs in hand before they can even start. For the proposal, that's the client's contact information, the package or service they asked about, and any special requirements they mentioned on the call. Skip this piece and a new hire finds out halfway through the job that they're missing something they needed from the very first minute.

Outputs define what finished actually looks like, in terms specific enough to check. Not "the client has a proposal," which is the same kind of vague stop that caused problems earlier, but "a written proposal has been sent to the client's email and logged in the file, including pricing, scope, and a start date within five business days." Outputs and stops are close cousins. The stop defines where the whole procedure ends. The outputs describe what a correct ending actually contains.

Together, purpose, inputs, and outputs turn a bare sequence of steps into something closer to a briefing. Someone picking this up for the first time doesn't just know what to do. They know why it matters, what they need before they start, and what correct looks like when they're done.

One more piece belongs at the very bottom, and it's the one that pays off for the people who need it least: a completion check. This is a short gut-check list, three to five items, phrased so someone who has done the job a hundred times can glance at it and confirm they didn't skip anything on autopilot. For the proposal: did you confirm which package the client asked about before pricing it. Did you include the full scope, not just a summary. Did you give a specific start date instead of "sometime next month." This is a faster, blunter version of the steps, aimed at someone who stopped reading them months ago because the job is internalized, and who still occasionally forgets one anyway. Everyone does, no matter how long they've been doing the work.

Now for the harder discipline, and the one almost nobody follows naturally: none of this gets written in one sitting.

The instinct, once you've decided to finally document something, is to sit down and knock it all out, purpose through completion check, in one focused hour, because that feels efficient and because stopping halfway feels like leaving a job unfinished. Resist that instinct. It produces worse procedures, not better ones, and it's also a big reason procedures never get written at all, because an hour is a lot to ask of someone with a business to run.

Write a procedure in short passes instead, with real time between them. The first pass, just the start, the stop, and the steps in between, takes somewhere around five to twenty minutes. Set a timer if that helps you actually stop. Then close the document and walk away. Come back a few days later, ideally not the same day, and do a second pass: read what you wrote with fresh eyes, add the purpose, the inputs, and the outputs. Another five to twenty minutes. Walk away again. A third pass, whenever you get to it, next week or next month, fills in the completion check and any detail someone actually asked about in the meantime, a photo, a link, a note about the one customer who always wants it explained twice.

Each pass stays short on purpose. A five-to-twenty-minute limit is a discipline that keeps you from writing detail nobody needs yet. If someone gets stuck on step four later, add detail to step four later, once you know it's actually needed. Detail written today for a problem that hasn't happened yet is a guess, and most guesses about what will confuse people turn out wrong.

The gaps between passes matter as much as the passes themselves. A procedure looks different after a week away from it than it does the moment it got finished, the same way an email reads differently after sleeping on it before hitting send. If a second person is available, even better: let someone else do one of the passes. A first draft written by the person who knows the job cold, reviewed a few days later by someone newer to it, catches gaps neither person would catch alone. The expert has forgotten what confused her. The newer person hasn't yet.

None of this needs to be precious. A procedure that's roughly right and actually written beats a procedure that's perfectly detailed and still living in someone's head three months from now. Perfectionism is the reason most small businesses have zero procedures instead of a dozen decent ones. Write it in passes, keep each pass short, and let the gaps between them do the polishing work that no amount of concentration in a single sitting ever quite manages.