If You Cannot Write the Process Down, You Cannot Automate It

An unwritten process is not ready to be automated

The first thing I ask for before an automation project is a written version of the process, and most of the time it does not exist. That is not a paperwork problem. A process that cannot be written down has not been decided, and a machine cannot execute a decision nobody has made.

If a process cannot be written down, it cannot be automated — and the writing down is not overhead, it is the deliverable that makes every later step possible.

I have watched this play out the same way five times. The tool is chosen, the pilot is built against the happy path, and somewhere in week three an engineer asks what happens when an invoice arrives without a purchase order, or when a customer qualifies for the discount but not the payment terms. Everyone in the room knows the answer. Nobody has written it, and two people's answers do not match.

Why does missing documentation stop a capable model?

The objection I hear most often is that this is old advice from the pre-LLM era, and that a language model can absorb a fuzzy process the way a new hire does. It can absorb the language. It cannot resolve the disagreement.

Take a single step and ask two experienced people to decide thirty historical cases independently. Where the rule is written, they agree. Where it is tacit, they diverge — not on the easy cases, on the ones that matter: the exception going to a named customer, the amount just over a threshold, the supplier who is late but reliable. An AI system trained or prompted on the team's behaviour will make a reasonable decision on those cases. It will not reliably make your decision, because nobody has told it what that is.

The second failure is worse than the first. Without a written rule there is no definition of correct, and without a definition of correct you cannot build an evaluation set. You are then left judging the system by watching it work, which is exactly how organisations end up unable to say whether an AI workflow is accurate or merely fluent. Fluency and correctness look identical in a demo.

What does "written down" actually mean?

It does not mean a sixty-page process map. It means one page per step with eight fields filled in, and a table of exceptions with a frequency estimate beside each one.

Field	What it prevents later
Trigger	Two definitions of when the clock starts, and a queue nobody owns
Input and its source of truth	The system of record being decided by whoever writes the integration
Decision rule	A model reproducing general good judgement instead of your rule
Thresholds and limits	Silent drift on the cases closest to the boundary
Exception handling	The one case in six that becomes an unplanned branch in week five
Who may authorise an exception	An approval path nobody can audit six months from now
Output, destination and format	Rework after go-live because the downstream consumer needs different fields
Volume, timing and failure mode	Sizing the build against an average that does not exist

The rule I apply: if a step's decision rule cannot be written in three sentences that two different people read the same way, that step is not ready for a build. It is ready for a conversation with whoever holds the judgement, and that conversation is the first week of work rather than a discovery during testing.

The written process is what makes an evaluation set possible

This is the part that changes how people spend money, and it is the reason I insist on the documentation before anything is built.

To test an AI workflow you need historical cases with the correct outcome attached. The correct outcome is defined by the rule. Once the rule is written, someone can sit down with last quarter's cases and label thirty of them per decision point, deliberately including those the team remembers as awkward. Without the rule, the labelling exercise collapses into two reviewers disagreeing with each other, and the disagreement is the finding.

When two experienced reviewers label the same thirty cases separately and agree on twenty-one of them, you have learned something a pilot would have taken three months to reveal: the process has no stable answer, so no automation can be measured against one. That result costs a few days and no software. It also tells you which exception types to write down next.

Where the hidden work sits

A documentation pass takes longer than the process owner expects, and the reason is not bureaucracy. The exceptions are the content. The happy path is usually already known; what has never been written is the list of detours, the phone call to a named person, the spreadsheet that exists because the system report is wrong. That material is the undocumented exceptions that turn out to be more than half the process, and it is the difference between a build that covers the process and one that covers the diagram of it.

In my own passes the surprise is rarely that an exception exists. It is that five or six exception types recur at a volume nobody had counted, because each one is somebody's normal Tuesday and nobody has ever added them up.

What does the pass cost, and who should do it?

The numbers below are mine, from projects in Shenzhen, and you should replace the rates with your own payroll figures rather than repeat mine.

The process owner's time, in three or four sessions of ninety minutes plus review: 35 to 50 hours for a process of ten to fourteen steps.
An analyst pulling historical cases and writing them up: 15 to 25 hours.
Two reviewers labelling thirty cases per decision point: about 8 hours between them.

At a loaded RMB 40,000 a month for an operations manager and RMB 30,000 for an analyst — roughly RMB 230 and RMB 170 an hour at 174 working hours a month — that lands near RMB 14,000 before any software is discussed. Against a six-week build with two engineers, the documentation is under a tenth of the project cost and it changes what the remaining nine tenths contain.

There is a failure mode on both sides. Spend three months documenting and you have produced a document nobody builds from. Spend three days and you have written the happy path, which is the part nobody needed help with. The sessions should be scheduled tightly, with the build start date already agreed, so that the document has a consumer waiting for it.

How much documentation is enough?

Not every step deserves the full pass. The decision is about where variance is a defect and where judgement is the value.

Process shape	What to write	Why
High-volume and rule-driven: invoice matching, claims triage, order validation	The full rule, including thresholds and who owns each exception	The rule is the product, and variance is the defect
Judgement-heavy: credit, pricing exceptions, hiring screens	The interface only — inputs, constraints, and the escalation path	Automating the preparation is useful; flattening the verdict is not
Work split across several teams	The handoff contract: what each team must receive and return	Most delay sits at boundaries, and the inside of a team's work is theirs
Regulated or externally audited	The rule plus the record of who decided, with dates	The missing record, not the model, is what a regulator objects to
Low volume, no existing rules, nobody asking for speed	Nothing yet	A document with no reader is a cost, not an asset

Where this line of argument has limits

Documentation also changes the process while you write it. People tidy their own work when someone writes it down, and in two of my projects the cycle time improved measurably before any software ran, which makes attribution of the later gain genuinely murky. I have run this pass five times and the direction is consistent; the split between what the writing fixed and what the automation fixed, I cannot give you.

A written process also decays. Without a named owner and a review date it will describe a process that no longer exists within a quarter, and a stale document is more dangerous than none, because a build team will trust it. And some processes should stay undocumented in full: where the value is a senior person's judgement on a handful of cases a month, the honest answer is to automate the preparation and leave the verdict alone.

What to do on Monday

Pick the process with the highest volume and the lowest tolerance for variance, book two ninety-minute sessions with the person who actually does the work, and write the decision rule for each step in three sentences. Then label thirty historical cases per decision point with two people working separately, and count how often they agree. If they agree on nearly all thirty, you have a specification, an evaluation set and a defensible reason to build; if they disagree on a third of them, you have found the real project, and it was never technical. Treat that written artifact as the first deliverable of the automation project with a date attached rather than as preparation for it, and when someone calls it overhead, ask them which decision the machine is supposed to make.