Where AI Automation Actually Pays Off (And Where It Doesn't)
The successful automation projects we have delivered have one thing in common: they started by measuring a process, not by choosing a model.
There is a version of an AI project that begins with a model and looks for something to point it at. It produces a demo that impresses a board, then quietly stalls. There is another version that begins with a stopwatch and a process map. That one tends to survive contact with production.
The qualities of a good first candidate
Not every repetitive task is worth automating. The processes that reward the effort share a recognisable profile:
- High volume — it happens dozens or hundreds of times a week, not twice a month
- Low variance — the same shape of input, most of the time
- Language- or document-shaped — classification, extraction, drafting or summarisation rather than genuine judgement
- Tolerant of review — a wrong answer can be caught before it causes harm
- Currently measurable — you can state how long it takes today
That last point is the one most often skipped, and it is the one that determines whether anybody will be able to tell if the project worked.
Where it tends to disappoint
- Processes where the hard part is a decision requiring accountability, not the paperwork around it
- Anything with a genuinely zero error tolerance and no practical review step
- Low-volume work where the integration cost will never be recovered
- Processes that are broken rather than slow — automating those just produces bad outcomes faster
Human in the loop is a design decision
The most useful pattern we deploy is unglamorous: the system does the extraction or classification, attaches a confidence score, and routes anything below a threshold to a person. Volume drops dramatically, error rate does not rise, and the review queue doubles as a source of training signal for improving the thresholds later.
Automate the typing. Keep the deciding. Log everything either way.
Run it in shadow mode first
Before an automation takes over a process, run it alongside the manual one for a full cycle and compare the outputs. This is the cheapest possible way to discover the edge cases nobody mentioned during discovery, and it gives you a defensible before-and-after rather than an anecdote.
If the comparison is unflattering, you have learned something valuable for the price of a pilot. That is a considerably better outcome than discovering it after cutover.
The Cherbix Team
Engineering & editorial
Written and reviewed by the Cherbix engineers who do this work day to day — the same people who build the software, run the migrations and wire up the automation described here.