Most automation business cases are built backwards
The usual sequence is: someone sees an impressive demo, imagines it applied to their business, and then works backwards to a justification. The number that comes out the other end is a rationalisation, not an estimate.
The sequence that works is duller and much faster. You find the work that repeats, you count it, you price the mistakes, and only then do you ask whether software should touch it. Most of that can be done in an afternoon with a notebook, before anyone writes a line of code or quotes you a price.
Step one: count repetitions, not tasks
Automation returns nothing on work that happens once. It returns almost everything on work that happens the same way over and over. So the first question is not "what is slow?" but "what do we do again and again in the same shape?"
For each candidate process, write down three numbers:
- Frequency. How many times a month does this run? Count it for real — look at last month rather than estimating from memory, because memory over-weights the annoying and under-weights the frequent.
- Handling time. How long does one repetition take, from the moment someone picks it up to the moment it is finished? Include the switching cost of stopping other work.
- People. How many separate humans touch a single repetition? Every handoff is a queue, and queues are usually where the real delay lives.
Frequency multiplied by handling time gives you the hours. That is the number everyone reaches for, and it is the least interesting of the three.
Step two: price the delay, not just the labour
Labour hours are the visible cost. For most small and mid-sized businesses they are not the largest one.
Consider a quote request that arrives at 6pm on Friday and gets answered Monday at 11am. The labour cost of writing that quote is twenty minutes either way. The real cost is the sixty-five hours the customer spent deciding whether to wait for you — and sometimes not waiting. That cost does not appear on any payroll line, but it appears in your revenue.
The categories worth pricing separately:
- Response delay. Enquiries that go cold, quotes that arrive after the decision was made, support tickets that escalate because nobody acknowledged them.
- Collection delay. Invoices that go out late, payment follow-ups that nobody sends, cash sitting in someone else's account.
- Rework. Anything that has to be done twice because it was done wrong the first time.
- Things that never get done at all. The follow-up nobody has time for is a real loss, and it is invisible because it leaves no record.
Step three: subtract the cost of being wrong
This is the step almost everyone skips, and it is the one that changes decisions.
Automation does not simply do the work faster. It does the work differently, and it fails differently. A human doing data entry makes occasional random errors and usually notices the strange ones. Software makes systematic errors — the same error, every time, silently, on every record that matches a pattern.
We have a first-hand example. Our own invoice-extraction prototype spent nineteen days pulling the pre-tax subtotal off invoices instead of the amount actually payable, because the word "total" appears inside the word "Subtotal". It did this on every invoice with a subtotal line, and it did it while producing clean, confident, correctly formatted output. A person doing that job would not have made that mistake twenty-six times in a row.
So before you count the savings, ask:
- If this step produces a wrong result, what does the wrong result cost — and does it compound?
- How would anyone find out? If the answer is "at year-end audit", the error runs for a year.
- How quickly can it be reversed? A wrong draft is nothing. A wrong payment is a phone call. A wrong message sent to a customer cannot be unsent.
A process where errors are cheap, visible and reversible is a good automation candidate even at modest volume. A process where errors are expensive, silent and permanent needs a human check in the loop regardless of how much time automation would save — and that check is part of the cost you are estimating.
A worked example
The numbers below are illustrative — they are here to show the shape of the arithmetic, not to describe any real business. Use your own figures.
Supplier invoice entry, for a business handling 200 invoices a month:
- 200 invoices × 4 minutes each = 13.3 hours a month of direct handling
- Two people touch each one (entry, then approval), so add the queue: invoices sit an average of 3 days before payment is scheduled
- Late-payment charges on invoices that slip past terms: whatever yours actually were last quarter — look it up rather than guessing
- Cost of a wrong amount entered: the payment goes out wrong, gets caught at reconciliation weeks later, and costs perhaps an hour to unwind plus a supplier relationship cost that is real but hard to price
The 13.3 hours is the headline. But if automated extraction runs at 95% accuracy with no human check, ten invoices a month go out wrong — and unwinding ten errors can consume more time than the 13.3 hours you saved, while damaging supplier trust in a way the spreadsheet does not capture.
Which is why the sensible design here is not "automate invoice entry". It is "automate extraction, present it to a human for a five-second confirmation, and flag anything the extractor was unsure about". That keeps most of the time saving and removes almost all of the error risk. The business case for the hybrid is stronger than the business case for full automation, and it is the version that actually survives contact with production.
Step four: keep judgment where mistakes are expensive
Removing every human is not the goal, and treating it as the goal is how automation projects fail expensively.
The useful split: automate the gathering, keep the deciding. Let software read the document, pull the fields, draft the reply, prepare the record, sort the queue. Let a person approve anything that moves money, commits the business, or goes to a customer under your name.
This is not timidity. A confirmation step that takes five seconds against work that took four minutes still captures most of the value — and it is the difference between an automation you can leave running and one you have to babysit.
Step five: prototype before you estimate
Every estimate above is a guess until real data touches real software. Prototyping is not the expensive part of automation — integration is. A working prototype fed with your own documents will tell you in an hour what a month of estimating cannot:
- Which of your edge cases the naive approach mishandles
- What proportion of cases need a human anyway — the single biggest variable in the whole calculation
- Whether the data you thought was structured actually is
- Which rules nobody has ever written down, and which people apply without noticing
That last one is the most common reason automation projects overrun. The process everyone describes in the meeting is not the process people actually follow, and the difference only surfaces when software tries to follow the written version.
The short version
Count the repetitions. Price the delay as well as the hours. Subtract what being wrong costs and how long it would take you to find out. Keep humans on the expensive decisions. Then prototype with your own data before committing to anything.
If the case only works when you assume perfect accuracy and zero exceptions, it does not work.