Most automation projects fail their business case in the spreadsheet, not the codebase. If you cannot baseline the process, you cannot defend the investment.
We have reviewed roughly ninety automation business cases in the last four years. The technology worked in most of them. The business case survived in fewer than half. The difference was almost never model quality — it was whether anyone had measured the process before changing it.
A baseline is not a guess about how long something takes. It is an instrumented number, collected over enough cycles to include the bad weeks, attributed to named steps in a real workflow.
What a defensible baseline contains
Volume per period, including seasonality. Time per unit, separated by happy path and exception. Fully loaded cost per hour for the people involved. Error rate and the cost of each error class. Rework volume, which is almost always underestimated.
The last one matters most. Teams measure the time to do the work and forget the time spent doing it a second time. In our engagements, rework accounts for a median 19% of total process hours.
The exception tax
The happy path is cheap to automate and cheap to measure. Exceptions consume the majority of human time and the majority of build effort. If your business case assumes the exception rate you see in the documentation rather than the one in the data, it will be wrong by a factor rather than a margin.
Design for exceptions from the start: route them to people with full context, and count them as a first-class outcome rather than a failure.
Instrument the new system with the old metrics
The most common reporting mistake is measuring the new system with new metrics. Automation rate and token cost are operational metrics, not business metrics. Keep reporting hours, cost per unit, cycle time, and error rate — the same four numbers you baselined — and the argument for the next project writes itself.