Documenting a Process Nobody Has Ever Written Down

How to document a process nobody has ever written down: follow one real instance of it from trigger to finish, sitting with the person who actually does it, and record what happens rather than what is supposed to happen.

That distinction is the entire job. Everything after it is formatting.

Most companies of any size have a folder of process documents. Some were written during an ISO push. Some were written by a departing employee in their last week, out of guilt. A few were written properly, three years ago, for a version of the business that no longer exists. And then there is the other set, the ones that were never written at all, which are usually the processes that matter most: how a refund actually gets approved, what happens between a signed contract and a live account, who chases the supplier when the delivery is late.

Those live in one or two people's heads. They work fine right up until the moment they do not.

Why it never got written down

The person who knows the process is the person with the least spare time to describe it. That is not a coincidence. They know it because they run it, and they run it because nobody else can, and nobody else can because it has never been written down. The loop is tidy and it holds.

There is also a quieter reason, and it is worth saying out loud rather than pretending it does not exist. Being the only person who can do something is a form of security. If you are the one person who understands the claims process, you are difficult to make redundant and impossible to interrupt on holiday. Nobody says this. Plenty of people feel it.

So if you walk in and announce a documentation project, expect the enthusiasm to be uneven. The way through is not a pep talk. It is being visibly clear about what the document is for, and honest that it is not a performance review.

Start at the trigger, not at step one

The first question is not "what do you do first". It is "what makes this start".

Processes do not begin with a step. They begin with an event. An email lands. A contract comes back signed. A date arrives in a calendar. Somebody messages a channel with a question that turns out to be a request. Until you have named the trigger you do not have a process, you have a list of activities that might belong to three different processes.

Then jump straight to the other end and ask how you know it is finished. This one catches people out. A surprising number of processes have no defined finish at all. They simply stop being anybody's problem, which means nobody can tell you whether they are working, because nobody agreed what working looks like.

Trigger and finish first. The middle is easier once both ends are pinned.

Follow one real run

Do not ask anyone to describe the process. Ask them to do the next real one while you watch.

A description is a summary. It has been averaged across the last twenty times, tidied up, and stripped of everything the person no longer notices doing. It will be accurate about intent and wrong about reality. You will get a clean six-step flow, and the real thing has nineteen steps, four of which involve a spreadsheet nobody has mentioned.

Watching one live instance takes twenty minutes of screen share and produces more than an hour of interviewing. Keep quiet while it happens. Note the moments the person hesitates, alt-tabs, opens a second window, or says "hang on, I always forget this bit". Those are the steps that were going to be missing from the document.

If you cannot watch a live one, watch a recent one being reconstructed. Have them open the actual emails and the actual records from the last time, in order, and narrate. Second best, but far better than memory.

The four questions that get the truth out

Once you have seen a run, four questions fill in nearly everything you missed.

What did you have to wait for? Waits are invisible in every document ever written, because they are not work, and they are usually where most of the elapsed time goes.

What happens when it goes wrong? The exception path is not an edge case. In a lot of processes it is a third of the volume and most of the effort, and it is almost never documented because it does not feel like the process.

Who do you ask when you are not sure? That names your real approval structure, which is frequently not the one on the org chart.

And the useful one: is there a quicker way you use when you are busy? Ask it warmly and mean it. The answer is the workaround, and the workaround is the actual process. The official route is what people do when someone is watching.

If you would rather not run this as a document exercise at all, abi. Clone builds a free working model of how your business actually runs, with the processes drawn against the real roles and systems they pass through. Free on any account, no card, and a first pass takes minutes. A picture of a handoff tends to survive longer than a paragraph describing one.

Write it in the present tense, using their words

Two rules make process documents readable and their absence makes them useless.

Every step gets an owner, named as a role rather than a person. "The account manager sends the welcome email", not "a welcome email is sent". Passive voice is how accountability disappears from a document without anyone deciding to remove it.

And keep the team's own vocabulary. If everyone calls it the Friday sheet, write the Friday sheet. Renaming it to "the weekly reconciliation workbook" makes the document more professional and less true, and the first person to read it will have to translate every line back into the language they already use.

What to leave out

Screenshots of software. They look helpful and they are out of date by the next release, and a document with three wrong screenshots gets distrusted entirely.

Policy. Why the rule exists belongs somewhere else. Mixing the two doubles the length and means the document has to be rewritten whenever either half changes.

Anything you cannot check. If nobody can tell you what happens after a request goes to finance, write down that nobody knows. An honest gap is useful. A guess dressed as a fact is the thing that makes the whole document unreliable eighteen months later.

The part that argues against doing this

Most processes do not deserve a document.

The test is frequency multiplied by handoffs. A process that runs weekly and passes between three people is worth writing down. A once-a-year task that one person does alone is worth a note in a calendar entry, and the hours you would spend documenting it properly are better spent almost anywhere else.

Documents also rot, faster than anyone plans for. A process document that is two years stale is worse than no document, because people follow it. If nobody owns it and nobody has a reason to open it, you have built a small liability and called it an asset.

So here is the honest minimum. A five-minute screen recording with someone narrating what they are doing beats a twelve-page document that no one maintains. It takes one attempt, it captures the workarounds automatically, and it never claims to be more current than it is. If you do nothing else this quarter, record the three processes that only one person can run.

The first one is the expensive one

Documenting a process for the first time takes about half a day, including the watching, the questions and the writing. That number surprises people, usually downward.

The second one takes less, because you stop asking whether the format is right. By the fourth you have a house pattern and it is closer to an hour.

Start with the one that would hurt most if the person who runs it left on Friday. You already know which one that is. Everybody does.