The AI ROI question nobody's asking before they buy.
Most AI purchases get justified by a demo, not a number. Here's the math worth doing first — the same discipline that's driven every real result on this site, applied to a tool decision instead of a process one.
"It's impressive" is not the same as "it pays for itself"
Most AI purchasing decisions happen backwards. Someone sees a capable demo, gets excited about what the tool can technically do, and the budget conversation starts from there — with the ROI case built after the fact to justify a decision that's already emotionally made. That's not a criticism of the people making the call; it's just how impressive technology tends to get bought, and it's exactly the pattern that made the automation wave and the ERP wave expensive for the companies that got it wrong.
The fix isn't skepticism for its own sake. It's asking the ROI question in the right order — before the contract, not as a retroactive justification for one already signed.
Three numbers, not one gut feeling
What does this actually cost, fully loaded?
Not just the subscription price. Implementation time, the internal hours spent configuring and training the tool, the cost of the process work that has to happen first if the underlying workflow isn't ready for it yet. A tool that looks cheap on the price sheet is often expensive once the real adoption cost is counted.
What is the specific thing it's replacing or accelerating worth?
Not "saves time" in the abstract — an actual number. Hours saved multiplied by a real cost per hour, or a measurable increase in output, or a specific error rate it reduces and what that error currently costs. If this number can't be estimated with reasonable confidence, that's itself useful information: it usually means the use case hasn't been defined precisely enough yet to know if the tool is solving a real, sized problem.
How long until the first number is paid back by the second?
A tool that pays for itself in two months and a tool that pays for itself in two years are not the same decision, even if they end up with the same eventual ROI on paper. Payback period tells you how much risk you're actually carrying while you wait to find out if the estimate in step two was right.
This is the same discipline behind real numbers, not a new one
This three-number framework isn't abstract — it's the same logic behind the For-Profit Education case study, where the fix wasn't a bigger media budget, it was modeling the actual lifetime value of each degree program and letting the acquisition cost follow the real number instead of a blended guess. That discipline supported 4x the media spend specifically because the value side of the equation was calculated honestly first, not assumed.
The same logic applies to an AI purchase. If you can't say with reasonable confidence what a tool is actually worth to a specific, sized use case, the responsible move isn't to buy it and hope the value shows up — it's to define the use case precisely enough that the number becomes calculable.
- Can you name the specific task or decision this tool is replacing, not just the general capability it offers?
- Do you have a real cost-per-hour or cost-per-error number to multiply against the time or accuracy it claims to save?
- Have you accounted for the implementation and training cost, not just the subscription price?
- Is the process underneath this use case actually consistent enough for the tool to improve it, or does it need fixing first?
Not sure if the math works yet?
Six questions, two minutes — or send us the specific use case and we'll help you find the real number before you commit to the tool.
Take the readiness check Talk to us