Most automation projects fail at selection, not at engineering. The process chosen was rare, or the rules were never written down, or an error cost more than the labour saved. Choosing correctly is most of the work, and it takes an afternoon.
Score every candidate on three factors
List the repetitive work in your business, then score each item one to five on three axes. The scores predict payback better than any vendor demonstration.
| Factor | Score 1 | Score 5 |
|---|---|---|
| Frequency — how often it runs | Monthly or less | Many times a day |
| Rule clarity — can you write the rules down? | It depends on judgement | A checklist already exists |
| Error tolerance — what a mistake costs | A customer is lost or a regulator is involved | Somebody corrects it in a minute |
Multiply the three. Anything scoring above 60 is a strong first candidate. Below 20, leave it alone — not permanently, just until you have a success behind you.
Note that the third axis is counter-intuitive: you want to start where errors are cheap. Every automation is wrong occasionally, and the first one has to survive being wrong in public.
What scores well in practice
- Invoice and document data entry. Runs constantly, the fields are fixed, and a misread number is caught at approval. This is the most reliable first project we see.
- Lead capture and routing. Enquiries arrive across WhatsApp, email, phone and a form; routing them by territory or product into a CRM is pure rules. High frequency, obvious benefit, cheap failure.
- Appointment and payment reminders. Trivially rule-based, runs daily, and the measurable outcome — fewer no-shows, faster collection — shows up within a month.
- Recurring reports. Someone rebuilds the same spreadsheet every Monday. The rules are already in their head and can be written down in an hour.
- First-line support triage. Classifying and routing incoming questions is rule-based even when answering them is not.
What scores badly, and why
- Anything annual. A process that runs twelve times a year cannot repay a build, however tedious it is each time.
- Work where the rules are contested. If two experienced people would handle the same case differently, you do not have a process to automate — you have a decision to settle first. Automating it freezes one person's judgement and calls it policy.
- High-consequence approvals. Credit decisions, clinical steps, anything with a regulator — and note that automated decisions on personal data carry obligations of their own. Automate the paperwork around them, not the judgement inside them.
- Processes about to change. Automating a workflow you are mid-way through redesigning is paying twice.
The written-rules test. Before committing, ask the person who does the work to write the rules as if training a new hire. If they can, you have an automation candidate. If the instructions keep arriving as "it depends", you have discovered the real problem, and it is not a software problem.
Working the arithmetic honestly
Take a real example. A firm processes 400 supplier invoices a month. Each takes about four minutes to key in and check — roughly 27 hours a month. At a loaded cost of ₹400 an hour, that is about ₹10,800 a month, or ₹1.3 lakh a year.
An extraction workflow that handles the standard cases and routes exceptions to a person might cost ₹2,00,000 to build and ₹3,000 a month to run. If it handles 80 per cent of invoices without intervention:
- Time saved: roughly 21 hours a month, about ₹8,600
- Running cost: ₹3,000
- Net: about ₹5,600 a month
- Payback: roughly 36 months
Three years is a poor return, and the honest conclusion is not to build it at that volume. Double the invoices to 800 a month and payback falls under 18 months. Reach 2,000 and it is under seven. The same automation is a bad idea and a good one depending entirely on volume — which is why frequency is the first factor scored.
Run this arithmetic before you build, with your real numbers. A vendor will not do it for you honestly, because the answer is sometimes no.
Where the AI part actually belongs
A great deal of what is sold as AI automation is ordinary rule-based automation, and that is fine — rules are cheaper, faster and easier to debug than models. Reach for a model only where the input is genuinely unstructured:
- Reading documents whose layout varies — invoices from forty suppliers in forty formats
- Classifying free text — routing an email by what it is actually about
- Drafting text a person will review before it is sent
- Extracting fields from images or scans
If the input arrives in a fixed structure, use rules. A model introduces a failure mode — confident wrongness — that a rule does not have, and you should only accept that trade where the rule genuinely cannot do the job.
Where you do use a model, ground it in your own data and check its output against a known answer set before trusting it in production. A system that is right 95 per cent of the time and cannot tell you which 5 per cent is wrong is not ready for work that matters.
Keep a person in the loop, deliberately
The durable pattern is not full automation. It is: the system does the work, a person approves the exceptions, and the exception rate is monitored. That gives you the throughput without the unsupervised failure mode, and the exception log tells you exactly where to improve next.
Design the human step in from the start. Retrofitting oversight onto an automation that was sold as hands-off is how organisations end up quietly turning it off.
Working out where to start? Send us the three most repetitive things your team does and we will score them and tell you which is worth automating first — including when the answer is none of them yet. Get in touch, or see how we approach AI and business automation.
