How to Document a Process That Only Exists in One Person's Head

Ask most business owners how a particular process actually works and they will start explaining it fluently, in detail, without notes. Ask them to write it down and the fluency disappears. This is the gap between knowing how to do something and being able to hand that knowledge to someone else, and it is one of the biggest obstacles standing between a small business and either automation or a team that can operate without the owner in the room.

This is one of the foundational moves inside operations and systems work, and it matters whether or not automation is the end goal.

Why the knowledge never gets written down

The process usually lives in one person's head for reasons that have nothing to do with secrecy or carelessness.

The first reason is time. Documenting a process takes longer than doing it, and the person who knows it best is usually also the person with the least spare time on the calendar. Writing down how a refund request gets handled competes with actually handling refund requests, and the refund requests win every time.

The second reason is that the steps feel obvious to the person doing them. Anything repeated hundreds of times stops registering as a decision. The judgement calls, the small checks, the habits that start with "I always look at this before I do that", have become automatic. When someone this familiar with a task is asked to describe it from memory, they tend to describe the two or three steps that feel notable and skip the ten that feel too basic to mention.

The third reason is that nobody has set aside dedicated time for it. Documentation gets treated as something to get to when things are quieter, and things are rarely quieter. It sits below every task with a deadline attached, indefinitely.

None of this is a character flaw in the business owner or the staff member holding the knowledge. It is what happens by default in a growing business, and it is fixable with a method rather than good intentions.

Shadow the person doing the work

The extraction method that works is not an interview. Asking someone to sit in a meeting room and describe their job from memory produces the same gaps as asking them to write it down: the obvious parts get left out and the exceptions get forgotten.

What works is watching the process happen in real time, ideally for a full working day, or a full cycle of the task if it does not run daily. Sit next to the person, or watch over video if the work happens on a screen, and let them do the job exactly as they normally would. Do not direct them. Do not ask them to slow down for your benefit until the observation pass is finished.

The point of shadowing first is to see what actually happens, including the parts the person would never have thought to mention. You will notice the tab they always have open in the background, the spreadsheet they check before replying to a certain type of email, the second look they give an order before approving it. These are the steps that live in muscle memory and disappear from any description given from memory alone.

Record them narrating the task as they go

Once you have watched a full pass, go through it again and ask the person to narrate out loud what they are doing and why, step by step, while you record it. This is different from shadowing silently. Narrating forces the person to surface the reasoning behind each action, not just the action itself: "I check this field because if it's blank the order usually means the client forgot to confirm a delivery address, so I follow up before I process it."

That kind of detail rarely survives a written summary produced after the fact, because by the time someone sits down to write documentation, the reasoning has already collapsed back into instinct. Recorded narration catches it while it is still conscious.

Keep the recording. It becomes the raw material for the written documentation, and it is also useful later if a training video or a walkthrough for a new hire is ever needed.

Capture the exceptions, not just the happy path

A written process that only covers the version where everything goes right is not documentation, it is a summary. The version that matters is the one that covers what happens when the client does not respond, when a stock figure does not match, when a payment fails, when a supplier sends the wrong item.

Ask directly, for every step in the process and not just the ones that seem risky: what do you do when this does not go as expected? Push for specifics. "I sort it out" is not an answer. "I check the order history for that client, and if it's their first order I escalate to the manager instead of processing it myself" is an answer.

Most processes have three or four recurring exceptions that account for the bulk of the judgement calls a person makes in a day. Finding those exceptions is usually more valuable than documenting the happy path, because the happy path is often self-evident from the software itself. The exceptions are where the real expertise sits, and where automation or a new team member is most likely to get it wrong without guidance.

Turn the raw material into something usable

Shadowing and narrated recordings produce raw material, not documentation. The next step is turning it into a structured written process: numbered steps, a note on the decision points, and a separate section for exceptions with what to do for each one. Keep the language plain and specific. A step written as "review the request" is not documentation. A step written as "open the request in the portal, check the delivery date against the calendar, and flag anything inside 48 hours" is.

Once it is written, test it. Hand it to someone who does not already know the process and watch them try to follow it without help. Every place they hesitate or ask a question is a gap in the documentation, not a failure on their part. This validation step is what separates documentation that looks complete from documentation that actually works when the original person is unavailable.

Why this step comes before automation, not after

Businesses sometimes try to skip straight to automating a process that has never been written down, on the assumption that the software will force clarity on its own. It does not. An automated workflow built on top of an undocumented process usually encodes the happy path and quietly drops every exception the original person handled by instinct. The result is a system that works until the first edge case arrives, at which point nobody, including the software, knows what to do.

This is the reasoning behind the Assess stage of the Claro Build Framework: understanding and documenting the current process properly, before any design or build work starts, so the automation is built on how the work actually happens rather than a tidy version of it. You can read more about how the four stages fit together on the frameworks page, and see the pattern show up across different industries in our case studies.

Why it reduces risk even without automation

Documenting a one-person process is worth doing even if there is no automation project on the horizon. A business where one person holds the only working knowledge of a critical task has a single point of failure built into its operations. That person cannot take proper leave, cannot be promoted into a different role without a gap opening up behind them, and cannot be replaced without a period where the task does not get done to the same standard.

Writing the process down changes that. It means the task survives the person's absence, illness, or departure. It also makes it possible to delegate the task properly rather than in name only, because delegation without documentation usually means the new person is set up to fail quietly. This is one of the more overlooked parts of building a team that can operate independently, which we cover in more detail in team and people.

If you are weighing up whether a particular process is a candidate for automation once it is documented, our guide on how to automate this walks through how to tell the difference between a process worth automating and one that only needs to be written down and left alone.

Extracting knowledge like this from a busy person, whether that person is a member of staff or the business owner, is rarely something that happens by deciding to do it one weekend. It needs a structured process and someone asking the right follow-up questions. If you want help working through this for a specific process in your business, book a discovery call with Claro Builds and we will look at where the knowledge gaps sit and what to document first.