Automation Readiness: You Cannot Automate a Process You Cannot Describe

Automation readiness is the state of being able to describe a process precisely enough that something which cannot ask you questions could run it from start to finish. That is the whole test. Not budget, not whether the tools integrate, not whether your team is keen. Whether you can say what happens, in what order, and what happens when it goes wrong.

Most teams fail that test on the first process they pick. They find out after the invoice.

What automation readiness actually means

Automation readiness gets sold as a checklist about data quality and API access. Those things matter, but they sit downstream of something much duller. A machine has no context. It cannot infer that the invoice goes to Priya on Tuesdays because Marcus is part time. It cannot notice that the approval step gets skipped whenever the amount is under two hundred pounds, because nobody ever wrote that down and the person doing it does not think of it as a rule.

So the real prerequisite is a description. Not a diagram someone drew on a whiteboard in a workshop. A description that survives contact with the person who actually does the work.

Here is the test. Take the process you want to automate and write it as a numbered list. For every step, name the trigger that starts it, the person or system that does it, the thing it produces, and where that thing goes next. Then take the list to whoever runs the process and ask them to find the lies in it.

They will find some. That is the point of asking.

The three questions that break most descriptions

Ask what happens when the input is wrong. In a described process there is an answer: it goes back to whoever sent it, with a note. In an undescribed one the answer is that Sam notices and fixes it quietly, and Sam has been doing that for four years without ever mentioning it.

Ask how often the exception path runs. People will say rarely. Count it for a fortnight instead of accepting the estimate. On most processes the exception is not an exception at all, it is a second process running alongside the first at a meaningful share of the volume, and it has never been named or resourced.

Ask who decides. Automation handles a decision fine when the rule behind it can be stated. It handles judgement badly. If the honest answer is that the person doing it uses their experience, you have just found the part that stays human, and knowing exactly where that boundary falls is worth more than the automation you were planning.

What happens when you automate an undescribed process

You get one of three outcomes, and none of them is the one on the vendor's website.

The first is that the automation handles the happy path and dumps everything else into a queue nobody owns. Volume through that queue climbs quietly. Six weeks later somebody works out that half the work is still being done by hand, only now it is done by hand after a delay.

The second is that you automate the workaround. What you described was not the designed process, it was the accumulated set of patches around a system that stopped fitting three years ago. Encode that and you have made the patches permanent, load bearing and expensive to unpick.

The third one costs the most. The automation runs, it looks fine, and it is wrong in a way that only surfaces in the numbers a quarter later. Nobody can debug it, because there is no description to compare the behaviour against. You cannot tell a broken automation from a working one without knowing what it was supposed to do.

Describing it is cheaper than you think

The instinct here is to launch a documentation project, and documentation projects are where enthusiasm goes to die. You do not need one.

Pick a single process. Sit with the person who runs it for forty minutes and ask them to talk you through the last three times they did it. Real instances, not the general shape. Specific cases surface the exceptions, general questions produce the official version, and the difference between those two things is most of what you are looking for. Write down what they say. Show it back to them the next day and let them correct it. Then do the same with the person upstream and the person downstream, because the interesting failures live in the handoffs rather than in the steps.

That is a morning per process. Twelve processes is a fortnight, and a fortnight of that work will change what you decide to buy.

If you want somewhere for it to live, abi. Clone builds a free working model of how your business actually runs: departments, roles, systems and the work moving between them, built by hand in minutes with no card and no expiry. The tool matters less than the fact that the description sits in one place, so the second person to ask the question does not have to start over.

Why this is not only an efficiency argument

Here is where the case usually stops, and it should not. A description of the work is not just what makes automation safe. It is what makes any claim about the business checkable.

Take a growth decision. You are about to spend on demand, whether that is outbound, content or a paid channel. The real question underneath is whether the plan is working, and answering it means holding what your revenue data says against what you expected to happen. That comparison only means something if you can also say how the work behind the numbers runs. A pipeline converting badly might be a marketing problem, or it might be that quotes take nine days because one person signs all of them. A dashboard cannot tell you which. It does not know the process is there.

That is the connection between the two halves of this. abi. reads your live pipeline, revenue and marketing data and tells you weekly whether the plan is actually working, and it gets more useful the more it knows about how the work runs, because a number with no process behind it is a symptom with no cause. Describing the work is the shared prerequisite for both. It is why the efficiency exercise pays for itself twice.

When to ignore all of this

Three cases, honestly.

If a process runs four times a year, describing it properly costs more than doing it by hand forever will. Leave it. Write two lines for whoever inherits it and move on.

If the process is obviously wrong, do not describe it. Delete it. A good deal of what any mapping exercise turns up is work that only exists because a client left in 2023 and nobody stopped the weekly report going out.

And the strongest objection to the whole argument: modern AI tools tolerate vagueness far better than the rules engines this thinking grew up around. You can hand a language model a messy instruction and get something broadly workable out of it. That is real, and it means a cheap prototype is sometimes the fastest route to the description. Build the small thing, watch where it fails, let the failures tell you what you did not know. What has not changed is that you still need the description in the end. You have only moved when you get it, and you get it by breaking something small rather than by asking someone.

Which leaves a rule narrower than the title. You can automate a process you cannot describe. You cannot trust it, fix it, or tell whether it helped.