The hardest processes to document are the ones that work. Nobody has ever had to explain them, so nobody knows what is actually in them.
Ask a person how they do their job and you get a summary that skips 80 percent of the decisions. Not because they are hiding anything — because those decisions are automatic and therefore invisible to them.
Here is how to get the real thing out.
Do not interview. Observe.
The single biggest improvement over "tell me how you do this" is "do it while I watch."
Sit with them, or screen-share, while they perform the task on a real case. Record it. Ask questions in the moment, not afterward.
The difference is enormous. In an interview they describe the idealised version. In observation you see the actual version, including the workaround they forgot they invented.
Ask why, constantly
The steps are the easy part. The value is in the reasoning.
Every time they do something, ask why. Especially when it looks arbitrary.
"Why that customer and not the other one?" "Why do you check that first?" "Why do you send it to Sarah?" "Why is this one different?"
You will get one of three answers, and all of them are useful:
- A real reason. Capture it. That is a rule, and rules are what let someone else make the same decision.
- A historical reason that no longer applies. You just found waste.
- "I do not know, that is just how we do it." Flag it. Either there is a reason nobody remembers, or the step can go.
Catch the exceptions
The main path is straightforward. The exceptions are where the knowledge lives and where a new person fails.
Ask directly: What goes wrong with this? What is the annoying case? When do you have to ask someone? What did you get wrong when you were learning?
Then ask for a recent example of each, and watch them handle one if you can.
Undocumented exception handling is the number one reason a person follows the SOP and still produces the wrong result.
Find the trigger and the end
Two things that get left out of almost every attempt at documentation.
What starts this? A form submission, a phone call, a Tuesday, a customer complaint, another process finishing. If the trigger is not written down, the process silently depends on someone noticing.
How do you know it is done, and done right? Not "when you finish the steps." What is the observable outcome? What would tell you it went wrong?
Write it, then test it
Turn the recording into steps. Keep it plain. Include the decision rules and the exceptions.
Then run the test that matters: give it to someone who has never done the task and have them do it, with the original person watching and not helping.
Every question they ask is a gap. Every place they hesitate is ambiguity. Every mistake is a missing rule.
Fix those, and you have something real. Skip this test and you have a document that reads well and does not work.
Do it in small pieces
The mistake is trying to document a whole role. Nobody finishes that.
Document one process. Test it. Move on. Four solid procedures covering your most frequent work changes the business. A comprehensive manual you abandoned at 30 percent changes nothing.
Our note on writing your first SOP covers the format and what to leave out.
The reason this is worth doing
Two payoffs, and the second is bigger.
The obvious one: someone else can now do it, so it is not a single point of failure.
The one people miss: a process explicit enough for a new person to follow is usually explicit enough to automate the repetitive half of. You cannot automate something you cannot describe. Documentation is not busywork before the real project. It is the first half of the real project.
Every automation I have ever built started with someone explaining, out loud, what they actually do all day.