You cannot automate a process you have not written down
The hard part is almost never the technology. It is that the process lives in one person's head, comes out slightly differently each time you ask, and has never once been written in a sentence.
Umer Ejaz Chaudhry, Cadral AI ·
Ask a small business how they handle a new enquiry and you will get a confident, fluent answer of about four sentences.
Ask three people in the same business the same question and you will get three confident, fluent answers of about four sentences. They will not be the same four sentences.
None of them is lying, and none of them is wrong exactly. The process genuinely works. It is just that it has never existed anywhere except in the habits of the people doing it, and habits diverge quietly.
That is the actual obstacle to automating it, and it has nothing to do with which model you use.
What a system needs that a person does not
A person handling an enquiry brings context you never had to specify. They know that this particular customer always says urgent and never means it. They know the Tuesday delivery slot is theoretical.
They know that an enquiry mentioning a specific product line goes to a specific person, and they know it without anybody having written a rule.
A system has none of that. Every one of those judgements has to become an explicit statement before it can be encoded, and the process of making them explicit is where the project actually lives.
The disagreement nobody knew about
This is why automation work so often surfaces disagreements that predate it. Two people who have worked together for six years discover, in the scoping meeting, that they have been applying different rules to the same decision the entire time.
Both have been getting acceptable results. Neither knew the other was doing it differently.
The failure this causes, and what it looks like
A project that skips the writing down does not fail loudly. It ships something that handles the common case, and the common case is genuinely most of the volume, so initially it looks like a success.
Then it meets the exceptions. Each one gets patched in as it appears, by whoever is available, without anybody revisiting the rule underneath.
After some months the system is a pile of patches that nobody can describe, which is precisely the situation it was built to replace, except now it is in software and harder to change.
The version that works spends its first stretch on something that looks like nothing is happening: we sit with the person who does the job and get it out of their head, exceptions included, into a document they then correct.
Why the document is worth more than the automation
Here is the part we would want to hear if we were buying. That document keeps being valuable long after any particular piece of software stops being.
It is what you hand a new starter, which turns a fortnight of shadowing into an afternoon of reading and questions. It is what protects you when the person who knows is on holiday, or leaves.
It is what makes the next tool you buy possible to evaluate, because for the first time you can say precisely what it would have to do.
And it outlives us. If our arrangement ends, the automation is still yours and running, and how it works sits in your files, not with us. That is deliberate: every delivery leaves a document behind as a standing rule, not a favour on request.
The uncomfortable implication
If the writing down is most of the value, then a good deal of what gets sold as automation is really consultancy with a piece of software at the end. We think that is true and would rather say it than have it discovered.
It also means the scoping conversation sometimes ends with the finding that, once the process is written down, it is simpler than everyone believed, and a checklist plus one small change to a form would do most of the job.
That has happened. It is a worse outcome for an invoice and a better one for a client, and when that is the answer we say so.
What this does not prove
This does not prove the approach works better than any other. It is an argument from what goes wrong, not a measured result, and we would treat any supplier presenting it as a result with suspicion.
Nor does it mean documentation is always the first thing to do. Where a process is genuinely simple and already consistent, writing a specification for it is ceremony.
The claim is narrower: where the work lives in somebody’s head and varies between people, that is the constraint, and no amount of well-chosen technology will get around it.
Read something here you want running in your business? Send us the brief and we will come back with a fixed price, or book twenty minutes and talk it through.
Tell us the job. We will tell you the price.
Twenty minutes and a fixed quote in writing. You bring the brief and the brand. Everything after that is us.
Not ready to talk? Run your own numbers on fifteen free tools, no email asked.
