Automation projects get stuck at the approval stage more often because nobody built a clear business case than because the automation itself wasn't valuable. Here's a framework that holds up in front of a CFO.
Step 1: Measure the actual time cost
Don't estimate — track it for a week if you can. For each manual process, capture:
- How many times it happens per week (invoices processed, reports built, approvals handled)
- How long each instance takes, including interruptions and context-switching
- Who does it (their approximate hourly cost, loaded for on-costs, not just salary)
A process that "only takes 10 minutes" run 200 times a week is over 33 hours — often more than a full-time role's worth of admin hidden inside other people's jobs.
Step 2: Add the cost of errors, not just time
Manual data entry has a measurable error rate — industry estimates typically put it between 1% and 4% per field entered. For a business processing 200 invoices a week, even a 2% error rate is 4 mistakes weekly, each costing time to identify and fix, and occasionally costing real money (duplicate payments, missed early-payment discounts, compliance issues).
Step 3: Calculate the automation cost properly
A realistic build for a single well-defined process (invoice processing, an approval workflow, a recurring report) typically runs 1-4 weeks of development time, depending on complexity and exception handling required. Get a fixed-scope estimate rather than an open-ended one — it's the only way to compare against the time saved.
Step 4: Run the actual numbers
Here's a worked example based on a real pattern we see often:
| Before | After | |
|---|---|---|
| Hours per week | 15 hours (manual invoice processing) | 3 hours (exception review only) |
| Error rate | ~3% of invoices | Under 1% |
| Weekly cost (loaded hourly rate $45) | $675 | $135 |
| Annual cost | ~$35,100 | ~$7,020 |
Annual saving: roughly $28,000, against a one-off build cost that's typically a fraction of that. Most invoice or approval automations pay for themselves within 2-4 months, and the saving compounds every year after.
A note on what not to automate first
The biggest process isn't always the right first project. Pick the process that's high-volume, well-defined (few exceptions), and painful enough that people already complain about it — that combination gets the fastest, most visible win, which makes the case for automating the next process much easier.
If you want help putting real numbers against your own processes rather than working from industry averages, a free automation assessment covers exactly this — no obligation, just a clear picture of what's worth building first.