Most ROI models for automation projects get built after the decision has been made, which makes them justifications rather than models. A model is only useful if it is capable of telling you not to proceed.
The good news: a workable first estimate needs four numbers, and you can gather all four in an afternoon.
The four numbers
- How many people touch this workflow in a normal week
- How many hours each, measured rather than guessed
- Loaded hourly cost: salary plus employment costs, not the headline wage
- What share is realistically automatable, which is the number everyone gets wrong
Multiply the first three and you have what the workflow costs per week. Multiply by working weeks (we use forty-eight, which allows for leave and holidays) and you have the annual figure. Apply the fourth number to get the recoverable portion.
Measure the hours, don't estimate them
People are consistently bad at estimating how long recurring tasks take. Short, frequent tasks get underestimated the most, because the switching cost is invisible. A five-minute job done eleven times a day is not fifty-five minutes. Each interruption costs attention on either side of it.
Ask people to track it for a week. The number that comes back is usually higher than the estimate, sometimes by a factor of two, and it is the only version worth building on.
Be honest about the automatable share
This is where models go wrong. It is tempting to assume a workflow is ninety percent automatable because the happy path is straightforward. The happy path is never the whole job.
A realistic share accounts for the exceptions that still need a person, the review step you will want to keep for the first few months, and the cases nobody mentioned in interviews because they are rare enough to feel unimportant but frequent enough to matter. For most workflows we look at, the honest number lands between forty and seventy percent. Not ninety.
Model the conservative figure. If the project only makes sense at the optimistic one, it does not make sense.
Count the costs on the other side
A saving is not a saving until you have subtracted:
- Build cost, including the integration work that always runs long
- Running cost (model or API usage, hosting, monitoring), which is ongoing rather than one-off
- Your team's time during Build and Adopt, which is real cost even though it never appears on an invoice
- Maintenance as your own systems and processes change around it
What the number is for
The point of the model is not precision. Your inputs are approximate and the output inherits that. The point is comparison and disqualification: which of five candidate workflows is worth doing first, and is the best of them worth doing at all?
If the leading candidate pays back comfortably inside a year on conservative assumptions, you have a strong case. If it only works on optimistic assumptions, you have a project that will disappoint. And if nothing on the list clears the bar, the correct output of the model is to do nothing yet. For the cost of an afternoon, that is a valuable result.