AI automation that pays for itself, and the kind that does not
Most AI pilots fail because they automate the interesting work instead of the expensive work. How to pick the process that actually returns the investment.
- Published
- 18 Jun 2026
- Reading time
- 6 minutes
- Category
- AI automation
- Topics
- AI, Document automation, Process
The AI projects that fail are rarely technical failures. They are usually a correct implementation of the wrong process — something visible and interesting rather than something repetitive and costly.
Three questions before writing any code
- How many times a day does this happen? Under ten, automation rarely returns the build cost.
- Is the input structured enough to be checked? If nobody can say whether the output is right, you have built a machine for generating unverifiable work.
- What happens when it is wrong? If the answer is 'we would not notice', stop — that is a liability, not an efficiency gain.
Why document processing is usually the right first target
Invoices and delivery challans hit all three. They arrive constantly, they have a correct answer that can be validated against a purchase order, and a mismatch is caught by the validation rather than discovered at audit.
The shape that works is not 'AI reads the invoice and posts it'. It is: extract, validate against something authoritative, post automatically when it reconciles, and route only genuine exceptions to a person. The human review does not disappear — it moves from every document to the few that are actually ambiguous.
Design for the exception path first. A pipeline with no good way to escalate is a pipeline that silently makes bad decisions at scale.
The chatbot trap
A chatbot answering from your real catalogue, pricing and stock is genuinely useful. A chatbot answering from a general model is a liability with your logo on it, because it will confidently invent a delivery date. The difference is entirely in whether it is grounded in your data and constrained to say 'I do not know'.
Measure hours, not accuracy
Model accuracy is an engineering metric. The business metric is how many hours came back and whether error rates went down. If a team still checks every output by hand, the accuracy number does not matter — nothing was saved.