Automation · 6 min
A credible automation case counts recovered hours honestly, includes build and maintenance cost, and states what happens to the time saved. Cases that fail review usually claim savings nobody can point to afterwards.
How it works
Frequency, time per occurrence, and who does it, observed rather than recalled, because estimates of one's own repetitive work are consistently wrong in both directions. A week of observation makes the whole case defensible.
If automation removes four minutes from a task done twice a day, that is the saving; the rest of the process is unaffected. Cases claiming the whole task disappears are the ones finance rejects.
An automation covering 80% of cases leaves 20% needing a person, and the case has to account for that rather than assuming full coverage.
'Saves 200 hours a year' is not a saving unless someone can say whether that becomes reduced headcount, absorbed growth, or work moved to something else. Finance will ask, and 'efficiency' is not an answer.
Rekeying data has an error rate; errors have a cost in rework and occasionally in customer trust. Where that can be estimated it frequently exceeds the hours saved.
Usually because the savings cannot be pointed at afterwards. Naming what happens to the recovered time (absorbed growth, reduced overtime, reallocated work) is what makes the case reviewable.
Always. Automations break when systems change and credentials rotate. A case that funds the build and not the upkeep produces something that quietly stops working within a year.
A credible automation case counts recovered hours honestly, includes build and maintenance cost, and states what happens to the time saved. Cases that fail review usually claim savings nobody can point to afterwards.
You have read what we think. If you want to know what it means for your case specifically, describe it and we will tell you which parts of building the business case for automation actually apply — and which do not.
