Most ROI calculations fail at the same spot: there is no before value. Someone automates a workflow, finds it faster afterwards, and writes down a benefit that was never measured. That is not a calculation, it is a feeling with a sign in front of it.

Measure the current workflow before you touch it. How often does the process run each week? How long does an average case take, and how long the difficult ones? How many come back because something was wrong? This baseline costs a few days of sampling and is the only fixed point you can later check the benefit against.

An ROI you never measured is an opinion with decimal places.

Without a baseline the calculation drifts quietly in your favour, because you compare the new state against a memory, and memories are generous.

The second mistake is the expensive one: people count the rollout and forget the operation. An automation is not a purchase, it is a lease. It keeps costing as long as it runs, and it costs extra when the process around it changes and the automation does not follow.

An honest calculation holds four cost blocks. The rollout with setup, integration and testing is the visible part. Operation with licences, hosting and monitoring runs on quietly afterwards. Maintenance appears the moment forms, systems or rules shift. And exception handling is the silent line that eats the benefit: every case the automation does not handle cleanly becomes manual rework and counts against the saving.

Set only the rollout against a rough time saving and you get a number that looks good in month one and tips over in month four.

Benefit is the other side, and discipline pays here too. Three sources hold up if you set them conservatively. Saved time is only a benefit if the freed hours are genuinely needed elsewhere, otherwise it is a number on paper. Fewer errors often outweighs pure time, because an avoided error saves the correction, the follow-up query and the whole annoyance path behind it. Shorter cycle time pays off where speed carries real value, such as quotes or approvals.

Set every source too low rather than too high. An ROI that stays positive under cautious assumptions survives contact with reality. One that only works at best-case values is a bet.

For the ongoing work it helps to tie the benefit to the process rather than to an annual sum. What does a single case save in minutes and errors, and how often does it run? You scale up cleanly from that unit, instead of setting a big number from the top and reasoning backwards.

Now it is visible why the scope decides the payback. A bounded process has a small rollout, a clear benefit and little operation, so it returns quickly. A platform project spreads the benefit across many workflows while integration, governance and operation land immediately and in full. The cost is early, the benefit is late and dispersed.

This is not an argument against big efforts. It is an argument for earning the first ROI on a small case and building the platform only once a few of those cases have proven the calculation holds.

Five steps, in this order. If you get stuck on one, you have found a real unknown, and it is cheaper to clear it now than in month four.

• Measure the baseline before anything changes: frequency, duration and error rate in the current state.
• Count every cost type: rollout once, operation, maintenance and exception handling ongoing.
• Set the benefit conservatively: saved time only if used, plus errors and cycle time.
• Separate one-off from ongoing: otherwise a cheap rollout looks better than the real operation.
• Work out the payback: when does the running benefit cover the running cost and the rollout.

Core sentence: an honest ROI is not a big number but one that stays positive under cautious assumptions and has already counted the operation in.

The saving from the demo is the ROI.

A demo shows the normal case under ideal conditions. The ROI arises in real operation with exceptions, maintenance and the hours your team spends on rollout and monitoring.

Operating cost barely matters.

It is the reason many calculations tip over after a few months. Operation, maintenance and exception handling keep running long after the one-off rollout effect has been booked.

Saved hours are automatically money.

Only if the freed time is needed and used elsewhere. Otherwise the saving is really measured but not really realised, and that belongs honestly in the assumption.

AI ROI, Total cost of ownership, Baseline, Exception handling.

When is it worth calculating at all?

Once a workflow runs often enough that measurement gives a stable picture. For a rare special case the baseline is too thin to carry a defensible number. A frequent, regular process delivers reliable values quickly.

How do I treat saved time nobody uses elsewhere?

Honestly: then it does not count fully as benefit. Either you plan concretely what the freed time is for, or you set it lower in the ROI. An hour nobody else needs lowers no cost.

What is a good payback period?

For a bounded process, weeks is a realistic target. If the payback stretches over many months, the case is either scoped too large or the benefit too thin. Then a smaller first step is worth more than a bigger effort.

No external market figures, percentages or unapproved client results are asserted as verified.