A client came to us last year with a clear request: automate our invoice approval process. It was slow, people kept chasing each other for signatures, and they were losing track of which invoices had been paid. The solution seemed obvious. Build a tool, remove the friction.
We spent the first week not building anything. We mapped the process as it actually worked - not as it was supposed to work, but as it actually happened on the ground. What we found: four redundant steps that existed because of a reorg three years ago, two approval gates that had been added after an audit and never served a real purpose since, and a compliance check that happened after the payment had already been sent. The check was theater.
They didn't need automation. They needed to fix the process first. Automating what they had would have made a slow, broken process into a fast, broken process.
What Automation Actually Does
Automation removes the human from a loop. That's the point - fewer manual steps, less waiting, lower cost per transaction. But when the human is removed from a loop, everything that human was doing disappears too.
Sometimes that's the goal. But sometimes, that person was catching errors. Noticing when something looked off. Using judgment to decide whether to flag an exception. Making a phone call before approving something questionable. Those aren't inefficiencies - they're controls. When you automate the loop, you automate away the controls too, and you often don't realise what you've lost until something goes wrong.
Automation makes a process run faster and at higher volume. That's a benefit when the process is sound. When the process is flawed, it is a liability.
The Speed Problem
A broken manual process might produce ten bad outcomes in a month. Maybe a supplier gets paid twice, or an invoice gets lost, or the wrong approval comes from the wrong person. Bad, but manageable. Recoverable.
An automated broken process can produce ten thousand bad outcomes in a month. And the scale of failure is often invisible - precisely because there's no human in the loop to notice that something is wrong. By the time the problem surfaces, the damage has compounded. Finance discovers at quarter-end that the exception logic has been routing a category of invoices incorrectly for eleven weeks. The manual work required to fix eleven weeks of automated errors is far greater than the time the automation saved.
Speed is not always a benefit. When the process is wrong, speed is the enemy.
Automating Before Understanding
Most automation failures come not from bad engineering but from a failure at the design stage. The typical path looks like this: the operations team has a process that feels painful. Someone proposes automation. A tool gets built that digitises the existing process. The tool ships. And six months later, the company is more dependent than ever on a process that was never quite right.
This happens because automating what exists is easier than designing what should exist. The existing process comes with years of accumulated workarounds, patches, undocumented exceptions, and institutional habits. When you automate all of that, you don't just preserve the dysfunction - you lock it in. It becomes far harder to change because now there is a system built around it.
The tool becomes the reason the process cannot change. That is backwards.
The Right Order
There is a correct sequence, and most teams skip the middle step.
First, map the process as it actually is. Not the official version from the procedure document - the version that actually runs. Who does what, in what order, and why. Where do exceptions go. What gets escalated. How long does each step take. What are people doing to work around the system.
Second, redesign the process from scratch as it should be. Not tweaking the edges - questioning the whole thing. Does this step need to exist. Does this approval gate add real control or just delay. Is there a simpler way to get to the same outcome. This step is uncomfortable because it requires making decisions, not just building. But skipping it is the most common and most expensive mistake in process automation.
Third, build the automation on top of the redesigned process. Not the original.
Most teams go from step one to step three. The system they build enshrines everything that was wrong.
Signs Your Process Needs Fixing Before Automating
Watch for these:
- There are lots of exceptions and special cases. If the process generates more exceptions than standard outcomes, it is not a process - it is a collection of workarounds.
- People regularly override the system. When your team consistently finds ways around the official flow, the official flow does not match the work.
- Different people do the same step differently. Inconsistency at this level means the process was never clearly defined in the first place.
- There is "that one person who knows how it works." If the process lives in someone's head rather than in clear documentation, it is not ready to be automated. When that person is out, the process stops.
- The process has not been reviewed since it was designed. Most processes were designed for conditions that no longer exist. Automating them means automating the old conditions.
Before We Build Anything
We audit the process. Every time. Not because we want to delay the work, but because building on top of a broken foundation guarantees that the build fails. The clients who push back on this step are usually the ones who come back six months later with a system they cannot use.
If you want to automate a process - or if you suspect you have a process that needs fixing before you even think about automation - get in touch. We will start by understanding what you actually have before we discuss what to build.