Direct answer
An automation business case is four measured quantities combined in a simple way: the cost of running the process today, the cost of the errors and delays it causes, the one-off cost of building the automation, and its ongoing cost to run. The case holds if the difference between today's cost and the new running cost repays the build within a period you are willing to wait. Every input must come from your own process. Any figure taken from someone else's project is a guess about your business.
This page is a worksheet, so it deliberately contains no percentages, savings or benchmarks. For the AI-specific version, see how to measure AI automation ROI. For what drives the build cost side, see workflow automation cost. To find a good first process to put through this worksheet, the automation opportunity finder helps you shortlist candidates.
Choose one process
Do the worksheet for one process at a time. Pick a process that repeats, has a clear start and end, and is done by people following mostly the same steps. A business case for automation in general cannot be measured; a case for one named process can. Write down its trigger, what counts as finished, who does it today and which systems it touches.
If you cannot describe the process in a paragraph, it is not ready to price. Mapping it comes first, and the map often reveals that a simpler change to the process is worth doing before automating anything.
Measure time and volume
Two numbers carry most of the case: how often the process runs, and how much human time each run takes. Measure both by observation, not from memory. Time a sample of real runs across different days and different people, and take note of the spread. Count volume from a system record, such as a mailbox, a queue or a log, over a period long enough to include the busy and quiet stretches.
The basic arithmetic is: runs per week x minutes per run = person-minutes per week. Then multiply by the cost of that person's time, using whatever internal rate your finance team accepts. Label each input as measured, estimated or unknown, and keep those labels visible in the final calculation.
- Runs per period, counted from a record.
- Handling time per run, timed on a sample and noted with its spread.
- Who performs it and the internal cost rate finance agrees to use.
- Seasonal or irregular peaks written down separately.
Error and delay costs
Human handling time is only part of the cost. Add what mistakes and waiting cost you. For errors, count how often a run needs correcting, how long the correction takes, and what a mistake that reaches a client or supplier costs you, even if only in credits, rework or lost time from a senior person. For delay, ask what happens when the process is slow: late invoices that delay cash, leads that go cold, orders that miss a cut-off.
Some of these are hard to price. Do not invent a number for them. List them as unpriced benefits and keep them out of the arithmetic, so the case stands on what you can measure and the rest is visible but not relied on.
Build and run cost
The cost side has more than the build. Include the initial design and build, the time your own people spend on requirements and testing, any subscriptions or usage charges the automation needs, hosting, and the time to maintain it as connected systems change. Ask any vendor for one written scope with what is and is not included, so you compare like with like.
Then add the cost of running the automation's exceptions. Some runs will still need a person, and that residual human time belongs in the after-automation column. A common error is to assume the automation removes the entire process, when it usually removes the routine part and leaves the awkward part.
Break-even logic
Break-even is the point at which cumulative benefit equals cumulative cost. In symbols: let A be the cost per period of the process today, B the cost per period after automation, and C the one-off build cost. The benefit per period is A minus B. Break-even in periods is C divided by (A minus B). These letters are placeholders for your own measured values; the formula is the useful part.
If B is close to A, the case is weak whatever the build cost. If A minus B is small compared with C, the payback period is long and other uses of the same money may be better. Decide in advance the longest payback you would accept, so the answer is compared with a threshold you chose before seeing it.
What to exclude
Leave out anything you cannot defend in a meeting. That includes hours saved that will not be redeployed into anything, since a person's time is only a saving if it changes a budget or lets you avoid a hire or overtime. It includes benefits you would like to be true, such as staff being happier, unless you can point to a cost that changes. It also includes costs you would have anyway, such as a system upgrade planned regardless.
Exclude one-off effects from recurring benefits, and do not count the same benefit twice, for instance as both time saved and error reduction when the errors were mostly time spent redoing work. When in doubt, leave it out and list it as an upside.
Sensitivity
Your inputs are uncertain, so test the result against that. Recompute the break-even with each input at a pessimistic value, one at a time: volume lower, handling time shorter, build cost higher, run cost higher. See which input moves the answer most. That input deserves more measurement before you decide.
Then try a combination of pessimistic values. If the case still clears your payback threshold, it is robust. If it only works when everything goes right, treat it as a gamble and consider a smaller first scope. A narrow first workflow gives you real measurements to replace the estimates.
Decision
Write the decision on one page: the process, the measured inputs with their labels, the formula, the pessimistic case, the unpriced benefits and the threshold you set. Decide to proceed, to measure more, to shrink the scope or to stop. All four are legitimate outcomes.
If you proceed, agree the measures you will check after launch so the estimate can be compared with reality. If you would like a second pair of eyes on the worksheet, the workflow automation and systems integration page explains how we scope one workflow in writing before any work starts, and we will say plainly if automation is not the right answer for the process.
Questions
Why does this page not give typical savings?+
Because any typical number would be a guess about your process. The worksheet shows which quantities to measure and how to combine them so the figures come from your own data.
Which input matters most?+
Usually volume and handling time per run, together with how much of the process remains manual after automation. The sensitivity check will show which one your case depends on.
Should I count time saved as money saved?+
Only if the time is redeployed into something with a cost effect, such as avoiding a hire or overtime. Otherwise show it as capacity gained, not as savings.
What if I cannot measure a benefit?+
List it as an unpriced upside and keep it out of the arithmetic. A case that stands on measured inputs alone is stronger than one that leans on estimates.
Can a small automation still have a business case?+
Yes, the worksheet applies at any size. A narrow first workflow is often the best way to replace estimates with measured data before committing to more.