Senthil Info

automating business processes, honestly

Reading a Vendor ROI Model

A vendor ROI model is not dishonest. It is a calculation built from assumptions, and the assumptions were chosen by someone whose engagement depends on the answer.

Six of them do most of the work. Checking them takes half an hour and changes the number more than any negotiation on licence cost. A product-side example of how workforce software approaches this topic is available in further reading.

Reviewed August 9, 2026. Vendor-published payback figures in this field commonly run 6–9 months with first-year ROI of 100–200%; treat those as the marketing baseline rather than as findings. For broader background and an independent point of comparison, see SAP.

The six assumptions

One. The exception rate. Usually absent, occasionally stated as an optimistic figure. It determines what proportion of the volume the automation actually handles, and the saving applies to that proportion only. Ask for it explicitly; if the model does not contain one, the model assumes zero.

Two. The hourly rate applied to saved time. Often a fully loaded cost including overhead. Defensible for headcount reduction, misleading for time redistributed within an existing team — saved time is not saved money unless something changed.

Three. Maintenance. Frequently absent from year one and material from year two. Systems change, rules change, and someone maintains the automation. A model with no maintenance line is a model of the first eight months.

Four. The implementation duration. Optimistic by default, and the benefit clock starts at go-live. Two months of slip removes two months of benefit from the payback calculation while adding two months of cost.

Five. Adoption. The model assumes the automation is used for 100% of eligible volume from day one. Real adoption ramps, and some volume routes around it permanently.

Six. The counterfactual. The model compares automation against today. The honest comparison is against the cheapest alternative that achieves the same thing, which is sometimes fixing the upstream system or eliminating the process.

Notice the direction. Five of the six push the number the same way. That is not conspiracy — it is what happens when the person building the model is paid on the outcome.

Rebuilding it in twenty minutes

You do not need a finance function.

Take their hours-saved figure and multiply by your measured straight-through rate. If they said 500 hours and your exception rate is 20%, start from 400.

Apply a rate you would actually stop paying. If nobody leaves and nobody stops working overtime, the cash rate is close to zero and the benefit is capacity, which is real and belongs in a different line.

Add maintenance at some fraction of build cost per year. Anything from a tenth to a third depending on how often the underlying systems change. Pick one, state it, and let the vendor argue.

Push go-live back by a third of the quoted duration.

And run the same model against doing nothing, and against the cheapest fix.

If the case survives all five adjustments, it is a good case. Most do not survive, and the ones that do are usually smaller and more specific than the original. Better still, build your own from measured figures.

What to ask the vendor

Four questions, and the answers are more informative than the numbers.

What exception rate does this model assume?

What happens to the payback if implementation takes 50% longer?

What did maintenance cost your last three clients in year two?

And which of your clients turned this off? Nobody publishes the failures, and a vendor who can answer this candidly is a better sign than one with a perfect record.

What a good model looks like

Being fair — some are honest, and they share features.

A stated exception rate, with a source.

A benefit split into cash and capacity, not blended.

Maintenance from year one.

A sensitivity table showing what happens if the assumptions move.

And a smaller number than the marketing material. A vendor whose specific model comes in below their published case studies is showing you something real.

The short version