Most automation projects fail at the choosing, not the building. A business picks the process that annoys the loudest person, spends three months on it, saves four hours a month, and quietly concludes that automation is overrated.
The building is rarely the hard part now. Choosing well is, and it is arithmetic rather than judgement.
The formula
Score every candidate process on three numbers you already know, or can find out in an afternoon:
Frequency. How many times a month does this happen? Weekly is fine. Daily is better. Once a quarter is almost never worth it, however painful it is when it comes round.
Error cost. What does one mistake cost you — in money, in rework, in a customer relationship? A process where errors are embarrassing but cheap ranks below one where a single slip costs a client.
Hours. How long does one pass take, including the interruptions and the chasing? Count the chasing. It is usually most of it.
Multiply the three. Rank. The top of that list is where to start, and it is very often not what anyone would have guessed.
The three that usually win
Moving data between two systems nobody connected. Someone exports from one thing and types it into another. It happens constantly, errors are invisible until they compound, and the hours are real. This is the most common highest-scoring process in any business under a few hundred people, and it is also the cheapest to fix.
Reconciliation. Anything where two records should agree and a human checks that they do — invoices against payments, stock against orders, hours against billing. High frequency, high error cost, and genuinely tedious. Automation here also produces something valuable as a by-product: a record that the check happened.
Chasing. The follow-ups that only occur when someone remembers. Overdue invoices, unreturned documents, expiring approvals. Low hours per instance but very high frequency, and the error cost is invisible because you never find out what the forgotten follow-up would have been worth.
Where the framework says stop
Some processes score well and should still be left alone.
If the process changes shape every time it runs, automating it means encoding a rule that will be wrong next month. If it exists because two people disagree about who owns something, automation will formalise the disagreement rather than resolve it. And if it runs four times a year, the payback arrives after the business has changed.
The honest test: could you write down exactly what happens, step by step, without using the word "usually"? If not, the process is not ready — and fixing the process is the cheaper project.
A worked example
Illustrative, not a client result. A business rekeys order details from an email inbox into a stock system. It happens 40 times a week, takes six minutes each, and roughly one in fifty goes in wrong — costing a corrected delivery and a phone call.
That is four hours a week of typing plus the correction cost of about four errors a month. Automating the transfer removes almost all of both. Whatever you pay for that build, the arithmetic is not close — and it was never about the technology.
Where to start
Write down your top five processes, score them on the three numbers, and look at what comes out on top. If the answer is obvious, you have your project. If two are close, pick the one with the higher error cost, because saved hours are recoverable and lost customers are not.
If the list is longer than five and they all feel urgent, that is the more common problem, and it is what the Reality Check is for: a week, a fixed fee, and a ranked answer with the numbers attached.
This is the part we do — the crossing from a demo to a system that survives production.