AI
What AI automation actually replaces
Most automation projects fail for the same reason: someone picked the process before understanding which parts of it were actually decisions.
Rule-shaped work is the target
The work worth automating first has a particular shape. It happens often, it follows rules a person could write down, and the cost of getting it slightly wrong is low and recoverable. Invoice data entry fits. Routing a support ticket to the right department fits. Deciding whether to extend a client's credit terms does not — not because a model could not produce an answer, but because being wrong is expensive and someone needs to own the call.
When we scope automation work, the first session is usually spent separating these two categories on a whiteboard. Teams are often surprised by how much of a process is genuinely mechanical, and equally surprised by which one step turns out to carry all the judgement.
The bottleneck is rarely the model
Off-the-shelf models are good enough for most business tasks now. What stops projects is everything around them: the data lives in six formats, nobody agrees what a "completed order" means, and the process as documented is not the process as practised.
Expect the majority of the effort to go into collecting reliable inputs and defining terms precisely. That work is unglamorous and it is the project.
Design for being wrong
Any automated step will produce a wrong answer eventually. The question is what happens next. Systems that survive contact with reality tend to share three properties:
- A confidence threshold below which the item goes to a human queue rather than through.
- A visible log of what the system decided and why, readable by someone who is not an engineer.
- An obvious way for a person to override the decision without filing a ticket.
Automation that cannot be overridden gets worked around, and a workaround is worse than the manual process it replaced because now nobody trusts the numbers.
Start narrow
The most reliable pattern we have found is to automate one high-volume step end to end rather than one stage of everything. A narrow slice gives you a real measurement of time saved, a real error rate, and a team that has seen the thing work. That is a far better foundation for the second phase than a broad pilot that half-works everywhere.
If you are weighing up where to start, we are happy to talk it through — get in touch.