Why AI Cannot Fix A Process Nobody Has Written Down

A business decides to automate its order handling. Three months and a budget later, the system is in and nobody uses it, because it does not match how orders are actually handled. It matches how one person described them in one meeting.

This is the most common failure pattern in automation, and it has nothing to do with the technology.

The hidden variation

Ask three people who handle orders to describe what they do and you will get three different processes. Not because anyone is wrong, but because each has absorbed different exceptions over time.

One always calls the customer to confirm quantities because of an incident two years ago. One skips the confirmation for regular customers but not new ones. One does it only above a certain value.

None of this is written anywhere. It works, more or less, because the people doing it are competent and adjust as they go. It only becomes visible when you try to encode it, at which point you discover you do not have one process, you have three.

Software cannot resolve this. It will simply implement whichever version was described to the developer, and the other two people will find it wrong.

Why writing it down is the actual project

Documenting the process before automating it does three things, and only one of them is about the software.

It surfaces the disagreements while they are still cheap to resolve. The conversation where three people discover they have been doing it differently is uncomfortable and enormously valuable. It should happen in a meeting room, not in a support ticket after go-live.

It forces decisions about exceptions. Every real process has them. Written down, each becomes an explicit choice: is this a rule we keep, or a habit we drop. Undocumented, they arrive as surprises during testing.

It frequently removes the need for the software. A surprising proportion of processes, once written out, turn out to have redundant steps, duplicate approvals, or a form that three people fill in and nobody reads. Deleting those is free and immediate.

That last outcome is worth taking seriously. The best result of an automation project is sometimes discovering you needed a decision rather than a system.

How to do it without it becoming a project of its own

Do not commission a formal process manual. It will take months and nobody will read it.

Sit with the person who actually does the work and watch them do it. Write down each step in plain language as it happens. When they do something not on the list, ask why, and write the reason down too. The reasons matter more than the steps.

Then do the same with the second person who does the same job. The differences between the two documents are the real output.

A page or two per process is enough. If it runs to ten pages you are describing too much at once -- split it.

What "good enough to automate" looks like

You are ready when you can answer these without hedging:

What starts this process, and what ends it. Who does each step. What information is needed at each point, and where it comes from. What the exceptions are, and what should happen in each. What happens when something fails halfway through.

That last one is the most commonly missed. Real processes are interrupted constantly -- the customer changes the order, the item is out of stock, the payment does not clear. A process description that only covers the happy path will produce a system that only handles the happy path, and the exceptions are most of the work.

Then, and only then, decide what to automate

With the process written down, the automation decision becomes obvious rather than speculative. You can see which steps are pure mechanical assembly, which need judgement, and which exist only because they always have.

Automate the mechanical ones. Leave the judgement with people. Delete the third category.

You may also find, having done this, that the sensible next step is not software at all but a checklist, a shared document, or one clear decision about who owns what. Those are legitimate outcomes and they cost nothing.

The uncomfortable version

If you cannot write down how your business handles its core processes, you do not have a technology problem. You have a business that runs on the memory of a few specific people, and the risk that carries is much larger than the inefficiency you were trying to automate away.

Writing it down addresses that risk directly, whether or not you ever buy the software.