How to document a process so someone else can run it

Most owner-operators run 30 or 40 small processes a week and have 0 of them written down. How a quote gets built. How a job gets scheduled. What happens when a customer rings at 4pm to say nobody turned up. It all sits in 1 head, and that head is also doing the work.

That holds together until you want a week off, or a second pair of hands, or a business that keeps moving when you stop. Documenting a process is the least interesting item on the working on the business rather than in it list, and it's usually the one that has to happen before anything else on that list can.

What follows is how to write a process somebody else can actually run, without producing a 40-page manual nobody opens twice.

Why the version in your head isn't a process

Ask an owner to explain how they quote a job and you'll get a clear, confident 3-minute answer. Watch them do it 6 times and you'll see 6 different sequences. That's not sloppiness. It's what expertise looks like from the inside: you've collapsed dozens of small judgements into a feeling, and the feeling runs faster than the explanation.

The problem is that the feeling doesn't transfer. When you hand the task over, the steps go across and the judgements don't, so the other person does step 4 correctly and still gets the wrong answer. Then you take the task back and conclude that it's quicker to do it yourself, which is true in the short run and expensive in every other run.

A written process is worth the effort because it forces those judgements out into the open. The steps are the easy part. The decision rules are the whole point.

It's worth being honest about the starting position. According to the Australian Bureau of Statistics, 67.3% of South Australian businesses are non-employing (ABS, Counts of Australian Businesses, June 2025 release, checked 1 September 2026). For most SA owners there is currently nobody to hand anything to. Documenting doesn't stop being useful in that case. It's what makes a first employee, a subcontractor or a bookkeeper possible later, and it's also how you stop re-deciding the same question every fortnight.

Choose the process by what interrupts you, not by what feels important

Owners usually start with the most important process in the business, which is also the most complicated one, and stall on page 3. Start somewhere duller.

The first candidate has 3 features. It happens often. It carries very little genuine judgement. And it interrupts you, meaning it lands mid-task and pulls you off whatever you were doing.

Rank your candidates on frequency multiplied by interruption, and ignore how much you dislike them. The task you hate isn't necessarily the task that costs you the most, and building a documentation habit on a small, frequent, low-stakes task is far more likely to survive than building it on the annual monster.

If you can't name which tasks those actually are, guessing is a poor substitute for a 2-week log of your own hours. Owners are consistently wrong about where their week goes, and usually wrong in the same direction.

The 4 parts a runnable process needs

Most process documents fail because they're a list of steps and nothing else. A process somebody can run without ringing you has 4 parts.

1. The trigger. What starts this, precisely. Not "when a customer wants a quote" but "when an enquiry form arrives, or a call is logged in the job book with the quote box ticked".
2. The inputs. What the person needs in front of them before they begin: the file, the login, the price list, the measurement, the previous job number.
3. The steps, with the decision rules attached. This is where the value sits. Everywhere a step says "then work out whether", write down how you work it out. "If the site is more than 40 minutes from the yard, add the travel line." "If the customer has an unpaid invoice older than 30 days, it comes to me before it goes out."
4. The definition of done. What has to be true for this to be finished, and where the output ends up. A process with no finish line gets abandoned just short of finished.

Then 2 pieces of housekeeping: a named person who owns the document, and a date it gets looked at again. A process with no owner rots quietly, and you find out when a customer does.

Capture it while you're doing it, not from memory

Writing a process from memory at 8pm produces the tidy version, not the real one. The real one includes the bit where you check something on your phone and the bit where you ring the supplier because the portal is wrong.

The fastest method is to narrate the task out loud while you do it, recording either your screen or just your voice, and say every decision as you make it. Run the whole task once at normal speed. Then write the document from the recording rather than from your head.

2 rules keep the writing honest. Write it for somebody competent who has never done this specific task, not for yourself and not for a beginner who needs everything explained. And keep the effort proportional: if documenting a 20-minute task takes 3 hours, you're writing a manual instead of a process.

Where a process touches invoicing, payroll or anything an accountant signs off on, document the operational steps only and note who owns the rest. The rules sitting behind those steps belong with your accountant or your bookkeeper, and a coach isn't the right person to be writing them.

Where the documents live, and who looks after them

A brilliant process saved to the desktop of the owner's laptop isn't documentation. It's a hostage.

Put every process in 1 shared location that the people doing the work already open during the day. A single index page listing every process and its owner beats a beautifully organised folder tree nobody browses. Name files the way the people using them would search for them, which is usually the task name, not the department.

Date the versions rather than numbering them. "Quoting process, updated 12 August" tells a reader something useful. "Quoting process v3.2" tells them nothing they can act on.

The handover test, and staying out of it

A process isn't finished when you've written it. It's finished when somebody else has run it while you sat on your hands.

Give the document to the person who'll be doing the task and ask them to work through it without asking you anything until they're genuinely stuck. Every question they do ask marks a gap, so write the questions down rather than just answering them. Then patch the document, not the person.

The hard part is not rescuing them at the first hesitation. If you step in at minute 2, you've taught both of you that the process doesn't work and that you're still the system. Let it run slightly slower than it would have in your hands, because it always does at first.

Where process documentation usually goes wrong

Documenting the exception instead of the norm. Owners write pages on the rare, interesting case and skip the ordinary path, because the rare case is the one they find worth explaining. Write the common path first, and handle exceptions with a rule about when to escalate.

Trying to do all of it at once. A quarter with 3 documented processes in it beats a shelf of unfinished ones. If you run a 90-day plan, 3 processes is a reasonable amount to put on it and a terrible amount to leave off.

Documenting a process that's broken. Writing down a bad sequence makes it permanent and gives it authority. If the process is wrong, either fix it first or write the current version down and mark plainly that it's a snapshot rather than the intended state.

Writing it and never handing it over. Documentation isn't the goal. Somebody else running the task is the goal, and that's a separate decision about what to let go of first. Plenty of owners produce a full library and carry on doing every job in it.

Expect the whole exercise to feel slower at first, and slightly humbling. Watching somebody follow your instructions and get the wrong result is a direct comment on your instructions, and the instinct is to conclude that the person is the problem.

The payoff isn't speed. It's that a task leaves your head permanently, and the business gets 1 notch less dependent on you being awake, available and in a good mood. Do that 20 times over a couple of years and you have a different business, which is the point of the whole exercise.