An AI use case will not pay back when there is no credible path from the model output to a measurable change in the business. Capability is not value. Before estimating upside, a sponsor should look for seven rejection signs in the workflow, data, operating cost, exceptions, and user behavior. Any sign can justify stopping the idea or reshaping it into a smaller test.
Why attractive demos hide value leakage
A summarization tool can produce clean text and still make the process worse. If an employee must reread the source, verify every claim, reformat the draft, and then enter it into another system, the tool has created a review queue rather than removed work. The demo proves generation. It does not prove demand, adoption, or financial return.
Begin with the current baseline: what event creates the task, how often it occurs, who performs it, what an acceptable result looks like, where exceptions go, and which business metric could change. Unknown effort must stay visible. Setting missing costs to zero makes almost any idea appear attractive.
Physical dependencies can also erase expected economics. The infrastructure bottleneck analysis contributes a reminder to count capacity, power, cooling, utilization, maintenance, and recovery when a use case depends on owned compute. A software estimate that ignores the system underneath it is not a payback case.
The seven signs
- No baseline. The team cannot describe current time, cost, delay, error handling, or outcome. Without a before state, any later improvement is a story rather than a comparison.
- Weak or irregular demand. The task is rare, optional, or concentrated in unusual cases. Even an effective system may sit idle while setup and maintenance continue.
- The output does not change a decision. People may read the answer, but no action, cycle time, cost, revenue event, or risk control changes because of it.
- Verification duplicates the original work. A reviewer must reconstruct the source task to trust the output. The proposed saving disappears into checking and correction.
- Exceptions dominate. The easy cases are automated while difficult cases create routing, escalation, and cleanup that the estimate did not include.
- Adoption depends on forced behavior. Users have no reason to change, the output arrives outside their normal tools, or nobody owns the revised procedure.
- Costs and authority are treated as assumptions. Data preparation, integration, monitoring, security, reviewer capacity, and rollback are missing, while the system is allowed to act beyond what anyone approved.
A cheap capability test can expose several signs early. The local AI experiment contributes a way to test whether a task is technically feasible without beginning with a large subscription. Its limit is equally useful: low setup cost cannot repair weak demand, duplicated review, or missing ownership.
Choose stop, reshape, or test
Stop when there is no baseline, no owner, no lawful data path, or no business action connected to the output. These are not small implementation gaps. They mean the current proposal is not an investable use case.
Reshape when value is plausible but leaks through review or exceptions. Narrow the input, change the output from final answer to draft, route only familiar cases, or bring the result into the tool people already use. State which sign the redesign is meant to remove. Then observe whether the revised workflow creates less work than it consumes.
Test when demand is real, the baseline is observable, the owner is accountable, and the authority boundary is reversible. Collect accepted outputs, corrections, exception effort, and user behavior. Do not turn an early test into an ROI claim. It supplies evidence for an estimate; it is not the estimate itself.
The payback-period framework contributes the financial sequence once a credible workflow survives: name the job, metric, cost of inaction, accountable people, and acceptable window. Use observed internal values and list unresolved costs instead of manufacturing a favorable answer.
Frequently Asked Questions
Yes. They cover the baseline, demand, connection to a decision, duplicated verification, exceptions, adoption, and missing cost or authority boundaries.
Not always. Missing ownership or lawful access can require a stop, while review duplication or poor routing may justify reshaping the workflow and testing again.
A baseline shows the current work, cost, delay, and exception burden. Without it, later improvement cannot be distinguished from a persuasive demonstration.
The decision record should show which of the seven signs appeared, what evidence supports each finding, and why the sponsor chose stop, reshape, or test. If you need an independent screen before committing budget, request an AI Opportunity Report.