How To Document A Process So Someone Else Can Run It

Everything you do personally is a ceiling. The business grows to the limit of your hours and then stops.

The way past it is not hiring somebody smart and hoping. It is writing down what you do, precisely enough that somebody else produces the same result.

Record it once, do not write it from memory

Writing a process from memory produces a document that skips every step you do automatically, which is most of the important ones.

So the first version is a screen recording of you doing the real thing, talking through it. Twenty minutes of you actually doing the job, including the bits where you check something, make a judgement call, or go back and fix an error.

Then the written version comes from the recording. What you get is the actual process rather than the tidy version you think you follow.

Write it for somebody who does not know why

The test of a process document is whether a competent person who has never done this job can follow it without asking you a question.

Which means:

Numbered steps, in order. Not paragraphs. Not principles.

Exact names. The real file names, the real folder paths, the real button labels, the real field names. "Go to the settings page" is useless. "Open Settings, then Conversions, then click New Conversion Action" is a step.

Screenshots on anything visual. One image saves a paragraph and prevents the most common error.

The decision rules written out. This is the part that gets left out and the part that matters. Not "use your judgement about which image to pick", but "pick the image where the person's face is visible and the product is in frame; if neither exists, send it back to the shoot list."

What finished looks like. A clear end state, so they know when they are done and so you know what to check.

Put the failure modes in

Every process has three or four ways it goes wrong, and you know all of them.

So each document ends with what to do when the thing is not there, when the number looks wrong, when the client has not replied, when the tool is down. Those four lines are the difference between somebody solving it and somebody stopping.

And it names the point at which they should come to you rather than guessing. One clear escalation line prevents both the problem of nobody asking and the problem of everybody asking.

Hand it over properly

A document is not a handover. The sequence that works:

They watch you do it once. With the document open, marking anything that does not match.

You watch them do it once. You say nothing unless they are about to break something.

They do it alone and you check the output. Not the process. The output.

They do it alone and you check a sample. Then less often.

They update the document. This is the step that makes it stick. The person doing the job owns the document from then on, because they are the one who finds out where it is wrong.

That whole sequence is what how to brief a designer and how to brief a video editor are doing at a single task level, scaled up to a repeated one.

Document the things that repeat and cost you

Not everything deserves a document. Start with the processes that are frequent, that you personally do, and that go wrong in the same way each time.

In practice that is usually onboarding a client, producing the weekly report, publishing content, handling an enquiry, and invoicing. Five documents covers most of the week, and it is the foundation under how to build business systems.

The proof it worked is simple. You take a week off and the output does not change, which is the whole of how to take a week off without the business stalling.

And it is what makes the first hire work rather than fail, because a new person with a documented process contributes in week one instead of month three. That is the difference described in hiring your first marketer.