How to Document a Process So Someone Else Can Run It

To document a process so someone else can run it, write down two things: the steps, in the order they happen, and the reason each step exists. The steps let someone run the process. The reasons let them change it without breaking it. Most handover documents contain only the first, which is why so many of them are quietly ignored within a month of being written.

This post is mostly about the second half — where those reasons come from, why you can only write them down if you have looked at the whole process rather than your part of it, and what it looked like when we did it for a client.

Why a process leaves when the person does

Small organisations run on individuals. One person knows how referrals get allocated. One volunteer knows which of the three spreadsheets is the real one. One trustee knows why the second approval step was added, and it was for a good reason that nobody else was in the room for.

That works, right up until it doesn't. Someone moves house, changes job, has a baby, or simply runs out of the time they used to have. And what leaves with them is not the task list — the tasks are usually visible enough. What leaves is the understanding of why the process is shaped the way it is.

It is worth saying that people rarely leave because something went wrong. NCVO's Time Well Spent survey found the most common reason volunteers stop is changing circumstances and having less time — 37% of those who said they were unlikely to continue. Not a falling-out, not dissatisfaction. Just life, arriving on its own schedule. Which means this isn't a problem you can prevent by keeping people happy. It's one you plan for.

You can only document a process you have traced end to end

Here is the part that connects the two halves of this post. If you only understand your own section of a process, you can still write down your steps perfectly well. What you cannot write down is why they are shaped that way — because the reasons live in the parts you never looked at. The step exists because of something that happens upstream, or something that would go wrong downstream, and from the middle you cannot see either.

So the end-to-end look is not a separate exercise you do before documenting. It is the thing that generates the content. Trace one real case from the moment it arrives to the moment it is finished — the actual route, including the workarounds and the "we always just ring Sue" bits — and you end up holding the reasons as well as the steps.

There is a practical version of this argument too. Fix a step you do not understand in context and you rarely remove a delay. You move it. The queue reappears further down the chain in someone else's week, where it is harder to notice because nobody is looking there. The only reliable way to find the step that is genuinely holding everything up is to look at the whole chain, and the loudest complaint is often not it.

Two things worth writing down

Almost every handover document is the top row only. That is not laziness — the steps are the part you can see yourself doing, and the reasons feel obvious to the person who already knows them. They are obvious right up until the person holding them is gone.

What happens to someone who only gets the steps

Picture the new volunteer arriving to a list of instructions with no reasoning attached. They have two options, and both are bad.

They can follow it exactly. That works until something happens the list did not anticipate — an unusual request, a step that fails, a person who is on holiday — and then they are stuck, because they have no basis for judging what matters and what doesn't. A process nobody understands is brittle in exactly the situations you most need it to hold.

Or they can look at it, decide it is nonsense, and redesign it. This is the more common outcome, and it is not arrogance. From the outside, a well-designed process often looks like an over-complicated one, because all the mess it is quietly absorbing is invisible. So they simplify it, and six weeks later the problem you removed two years ago is back, and nobody connects the two events.

Neither person is being difficult. They just were not told. One line of reasoning attached to a step settles it: requests go straight to the regional volunteer rather than through a coordinator, because the coordinator step was pure relay and added a day. Nobody argues with that. And it does something else that matters — if the reason ever stops being true, the next person now knows they are allowed to change it. Reasons do not freeze a process. They are what makes it safe to touch.

What this looked like in practice

We rebuilt a request-handling process for a small charity a while back. The new version was genuinely simpler than the old one — requests arriving through a form, allocated automatically, tracked in one place instead of relayed by hand. But simpler is not the same as self-explanatory, and the people running it are volunteers who join and move on.

So the handover was built in two forms.

• A video walkthrough covering what the system does, why it was set up this way, and the process being run from start to finish.
• A written procedure setting out the steps in order, as a reference for someone who already knows the process and needs to check a detail.

The split was deliberate. Written steps are good for reference and poor for onboarding, because someone reading a document they have never seen before has to decode it before they can use it — and the moment they hit a phrase like "filter the requests view by region", they are guessing. A video does the opposite. Someone watches it once, sees the thing happening on screen, and then follows along. Reading that instruction is work; watching someone do it takes four seconds.

The video also carried the part a step list structurally cannot: what the organisation is there to do, what the process is protecting, and what to watch out for. Someone who has watched it understands not just which button to press, but why the whole thing is arranged as it is — which is the difference between a volunteer who can cover a shift and one who can be trusted to handle something the document never mentioned.

How to do this without it becoming a project

This should take an afternoon, not a quarter. If it is taking longer than that, the scope has grown.

1. Trace one process end to end, with the people who actually do it. Follow one real case from where it arrives to where it finishes. Write down every step, including the workarounds.
2. Write the steps plainly, in order, naming who does each one. Aim for under a page. Long documents do not get read, and they certainly do not get updated.
3. Add a reason to the steps that are not obvious. Not all of them — usually three or four. The test is whether someone new would look at it and ask "why is it done like that?"
4. Once the document is agreed, record the process being run end to end. One video, start to finish — that is how someone watches it. A phone or a free screen recorder is fine; nobody needs production values, they need to see the screen.
5. Give it to someone who does not do the job and ask them to follow it without help. Every question they ask is a gap in the document. This is the whole test, and it takes half an hour.

The order of those last two matters, and it is where people waste the most effort. Video is harder to maintain than text: change the process and a written step takes a minute to edit, while a video has to be recorded again from scratch. So do not film anything until the written steps are settled and someone has signed them off. Film a process that is still moving and you will be re-recording it three times before the month is out — which is how documentation ends up out of date, and how everyone learns to ignore it.

Do you need help with this?

For a process that lives inside one team, usually not. Write the steps, add the reasons, record the screen, and hand it to someone to test. The tools are free and the skill is mostly patience.

Where it gets harder is a process that crosses several people who each only see their own part. Nobody in that chain can write the reasons down, because nobody holds the whole picture — and each person's honest account of the process is slightly different from the next person's. Untangling that, then designing something simpler and writing it up so it survives the people who built it, is the work NorthGate Collective does with charities, community organisations and small businesses around Reading and Berkshire. If a single afternoon and a screen recorder is all you actually need, we will tell you that.

Common questions

What should a handover document include?

The steps in order, naming who does each one, plus the reason behind any step that is not self-explanatory. The steps let someone run the process; the reasons let them change it safely later.

Should I use video or written instructions?

Both, for different jobs. Written steps are for reference when you already know the process. A video is better for someone learning it, because they can watch it happen rather than decode a document — one recording, running end to end, is what people actually watch. Write the steps first and only film once they are signed off, because a video is far more work to redo.

How long should a process document be?

Under a page for the steps, plus a short reason on the three or four that need one. If a process genuinely needs ten pages, that is usually a sign the process is too complicated, not the document too short.

How do I know if my documentation is any good?

Give it to someone who does not do the job and ask them to follow it without help. Every question they ask is a gap. It is a better test than any amount of rewriting on your own.