ROI & Payback Period: Quantifying the Business Case

Classifying which kind of business value a system targets (efficiency, transformation, productivity, cost, or performance-SLA -- the five pillars from solution design) tells you WHICH value a decision serves. It does not tell you HOW MUCH value it delivers, or how long the system takes to pay for itself. That second, quantitative question is what an ROI and payback-period calculation answers, and it belongs in the evaluation discipline because, like every other metric in this domain, it has to be measured, not asserted.

The Four-Step Framework

1. Baseline the business-unit metric BEFORE deployment -- measure the real current-state cost or time, not an estimate
2. Predict, then measure, the post-deployment state -- once live, measure the actual post-deployment metric, not the number you hoped for
3. Subtract the running cost of the AI system -- the monthly cost of tokens, infrastructure, and any vendor fees the system itself incurs
4. Arrive at a payback period -- implementation cost divided by net monthly savings, with a sensitivity analysis on the assumptions that number depends on

A Worked Example

A document-processing team currently spends 45 minutes of loaded staff time processing each of 200 documents/week, at a loaded labor rate of $38/hour. A new AI system reduces average processing to 8 minutes of AI handling per document, but roughly 30% of documents still require human review afterward, averaging 15 minutes each -- a compliance requirement the team can't automate away. The system costs $4,200/month to run, and the one-time implementation cost was $65,000.

Sensitivity Analysis

The review-rate assumption (30% of documents) drives the whole result, so it's worth stress-testing. If the true review rate turns out to be 45% instead of 30%, post-deployment labor cost rises to about $7,473/month, net savings fall to about $11,127/month, and the payback period stretches to roughly 5.8 months. That's a modest shift for a real-world assumption error -- but it's exactly the kind of check that separates a defensible business case from a hopeful one, and it's why step 4 always includes sensitivity analysis on the assumptions, not just a single point estimate.

Common exam traps

• Using an estimated, not measured, baseline. "We think it currently takes about 45 minutes" is not a baseline -- it's a guess dressed up as one. The baseline has to come from actually measuring the current-state process before deployment; an ROI calculation built on an estimated baseline can be wrong in either direction and nobody will know until the real post-deployment numbers come in and don't match.
• Assuming 100% automation when human review is still required. The naive version of this calculation drops the 30% review line entirely and claims the full $22,800 -> near-zero swing, overstating savings substantially. Any compliance-, safety-, or quality-driven human-in-the-loop requirement reduces the actual labor savings below the naive full-automation number, and skipping that line is the single most common way an ROI case turns out to be wrong once it's actually measured in production.