There is a particular kind of pitch that always sounds irresistible. You have a slow, painful, manual process, and someone offers to automate it. No more retyping, no more chasing, no more human delay. Push a button and the whole thing runs itself. It is an easy yes, and it is often the wrong one, because automation does not do what people assume it does. It does not fix a process. It runs the process you already have, faster, at scale, and with fewer people watching. If that process is broken, you have not solved anything. You have just industrialised the mistake.
This is the trap underneath a great deal of wasted automation spend. Automation is an amplifier. Point it at a good process and it makes that good process faster and cheaper. Point it at a bad one and it makes the mess faster and cheaper too, and now the mess is buried inside a system nobody wants to reopen. The speed hides the problem rather than removing it.
What "broken process, now faster" looks like
Imagine an approval workflow that, on paper, routes a request through three people. In reality, the first approver rubber-stamps everything without looking, the second is a bottleneck who sits on requests for days, and the third only exists because someone important asked to be included years ago and never asked to be removed. Everybody who does the work knows this. They route the urgent ones around the second approver entirely.
Now automate it exactly as written. The rubber-stamp becomes an instant automatic approval, so the one checkpoint that occasionally caught something is gone. The bottleneck is now enforced by the system, so the human workaround that kept urgent work moving is no longer possible. And the pointless third step is now permanent, coded in, and awkward to remove. You have taken a flawed but flexible process and turned it into a fast, rigid, flawed one. The manual version was bad. The automated version is bad and immovable.
The same pattern shows up everywhere. Automated data entry that faithfully copies dirty data into more systems. A generated report that arrives every morning based on a calculation nobody trusts. A customer email sequence that fires perfectly on time and says the wrong thing to the wrong segment. In each case the automation works exactly as designed. The design was the problem, and now it runs a thousand times a day.
Automation removes the very visibility you needed
There is a second, quieter cost. A manual process is visible. People touch it, complain about it, and know where it hurts. That friction is information. It is your early warning system, telling you which step is painful and why. When you automate a broken process, you remove the friction without removing the fault, and with it you lose the signal. The problem does not go away. It just stops being obvious, until it surfaces somewhere further downstream as an error you cannot easily trace back.
That is why automating first so often makes things harder to fix later. You have spent money, you have a system to defend, and the evidence of what was wrong is now hidden inside it. Nobody wants to reopen a project that was just delivered. So the flawed process calcifies, and the organisation quietly reorganises itself around the automation instead of the other way round.
The order that actually works
The fix is not to avoid automation. It is to do it in the right order. Before you automate anything, watch the work as it is really done, not as the process document claims. Map the actual path a request takes, including the workarounds, because the workarounds are usually where the truth lives. Then question every step. Does it add value, or does it exist out of habit? Who owns it? What happens when it goes wrong? Strip out the steps that survive only because no one ever removed them, clarify the handoffs, and settle the exceptions.
What you are left with is a lean process that the people doing the work actually agree on. That is the thing worth automating. And here is the quiet bonus: by the time you have simplified it, there is usually far less to automate, which makes the automation cheaper, faster to build, and easier to maintain. Fixing the process first does not delay the automation. It shrinks it.
A worked example
A company came to us wanting to automate their order-processing workflow, which took, they said, far too long. The obvious brief was to build automation around the existing eleven steps. Instead we spent two days watching orders actually flow through the business. Four of the eleven steps turned out to be duplicated checks that existed because two departments did not trust each other's data. Two more were manual re-keying between systems that could simply be connected. One was a signature nobody could explain.
We did not automate eleven steps. We removed the duplication by fixing the trust problem at its source, connected the two systems so the re-keying disappeared, and cut the process to four genuine steps. Only then did we automate, and the automation was small, because there was very little left to automate. The workflow went from days to hours, and most of that gain came before a single line of automation was written. Had we automated the original eleven steps as briefed, we would have delivered a fast, expensive version of a process that should never have existed in that shape.
Fix it, then scale it
Automation is one of the highest-return moves a business can make, but only when it is pointed at the right thing. The value comes from scaling something that works, not from hiding something that does not. So before you automate a process, earn the right to. Watch it, question it, and simplify it until you would be happy to run it a thousand times a day. Then automate the version that survives.
If you are looking at a slow, manual process and reaching for automation, the highest-value move is often to fix the process first, and that is exactly the work our workflow optimisation engagements are built around: finding what to remove before deciding what to automate. Book a discovery call and we will help you point the automation at the right thing.
Frequently asked questions
Should I fix my process before automating it?
Almost always, yes. Automation does not improve a process, it executes it faster and at scale. If the process has unnecessary steps, unclear ownership, or hidden workarounds, automating it hardwires those flaws in and makes them harder to see and change. The right order is to observe how the work is actually done, strip out the steps that add no value, agree who owns each part, and only then automate what remains. Automating first usually means paying to industrialise a mistake.
How do I know if a process is ready to automate?
A process is ready when it is stable, well understood, and genuinely worth keeping. That means the people who do the work agree on the steps, the exceptions are known rather than surprising, no one is quietly working around the official version, and you can explain why each step exists. If you cannot describe the process without saying it depends on who is doing it, it is not ready. Stabilise and simplify first, then automate the version you would be happy to run a thousand times.
Does this mean automation is not worth it?
Not at all. Automation is one of the highest-return moves a business can make, but only when it is pointed at the right thing. The value comes from removing repetitive manual effort on a process that is already sound, not from papering over a broken one. Done in the right order, fix the process, then automate it, the returns compound because you are scaling something that works. Done in the wrong order, you scale the problem and lose the visibility you would have needed to fix it.
What does fixing the process first actually involve?
It starts with watching the work as it is really done, not as the manual describes it, and mapping the actual path a request takes. Then you question every step: does it add value, who owns it, what happens when it goes wrong. You remove the steps that exist only out of habit, clarify the handoffs, and settle the exceptions. What is left is a lean, agreed process. That is the thing worth automating, and by then automation is usually simpler and cheaper because there is less to automate.