Vendor ROI models assume your company away
A typical vendor projection multiplies a number of users by hours saved per week by a loaded labor rate, and produces a large annual figure. Every term in that calculation is an assumption about your company. The hours saved figure comes from a customer whose process may look nothing like yours. The loaded rate is usually generous. And critically, the model assumes saved hours convert to value, which only happens if the freed time gets used for something that produces revenue.
Do not argue with the model. Rebuild it with your own numbers, including the terms the vendor left out.
Count all the costs, not the subscription
Software licensing is often the smaller share of the total. The full cost includes implementation and configuration time, integration work, data cleanup, training, the productivity dip while people adapt, ongoing administration, and the internal time spent evaluating and selecting in the first place. For a workflow automation project, internal time frequently exceeds the software cost in the first year.
Also count the cost of the option you are not choosing. Continuing as you are has a cost, and so does a competing internal project that will not get done because this one consumed the attention. A comparison against zero is not a real comparison.
Separate hours saved from money earned
Saved hours become money in three ways and it is worth being explicit about which one applies. You reduce headcount, which is rare and usually not the intent. You avoid hiring you would otherwise have done, which is measurable if the hiring plan existed. Or you redeploy the hours to revenue-producing work, such as bidding more jobs or managing more projects, which requires that the demand exists.
If none of the three applies, the hours saved are real but the financial return is not, and the honest justification is quality, risk reduction, or retention. Those are legitimate reasons to proceed. They are just different reasons, and presenting them as a financial return undermines credibility when the savings do not appear in the numbers.
Insist on a small, measured first phase
The most reliable way to produce a defensible number is to generate it yourself on a limited scope. One workflow, one or two projects, a defined period, with a baseline recorded before starting. The result is specific to your company and impossible to argue with, in either direction.
Be prepared to stop. A pilot that can only end in expansion is not a pilot, and organizations that never stop anything accumulate tools that no longer earn their cost. Decide the success threshold in advance, in writing, and hold to it when the review arrives.
Count the risk reduction honestly
Some of the strongest returns in construction automation are avoided losses rather than saved hours. A change order captured within the notice period that would otherwise have been absorbed. A certificate of insurance renewed before it lapsed. A submittal approved in time for a long-lead delivery. These are real money and they do not appear in an hours-saved calculation.
They are also harder to prove, because the loss that did not occur leaves no record. The defensible approach is to count how often the prevented condition used to happen, using your own history, and apply a conservative cost. Stating it as an estimate with the method shown is more credible than either omitting it or presenting it as certain.