A foundation-model project dies in one of two ways. It never gets funded because no one could quantify the upside beyond "AI is important." Or it gets funded on hype, runs up a surprising bill, produces fuzzy results, and gets quietly killed in the next budget cycle. Both failures come from the same gap: a missing, defensible business case.
Building that case is not hard, but it requires resisting two temptations — inflating the benefits to win approval, and ignoring the costs that show up after launch. A business case that survives contact with a skeptical CFO is specific about where value comes from, honest about what it costs to capture, and clear about how you will know if it is working. Here is how to build one.
Start With the Outcome, Not the Technology
The fastest way to lose a budget conversation is to lead with the model. Decision-makers do not care that you are using a foundation model; they care that a process gets faster, cheaper, or better. So the business case starts by naming a specific outcome tied to a number the business already tracks.
Good outcome statements are concrete: reduce average handle time on support tickets by 30%, cut the cost of first-draft contract review by half, increase qualified-lead throughput without adding headcount. Each names a metric, a direction, and a magnitude you can defend. Vague outcomes — "improve productivity," "enhance customer experience" — cannot be measured and therefore cannot be funded. The metrics discipline behind this is the same one covered in measuring foundation models: if you cannot instrument it, you cannot claim it.
Quantify the Benefit Side Honestly
Benefits come from three places, and the credible business case is explicit about which ones it is claiming.
Labor Acceleration or Displacement
The most common source of value is making expensive human time go further. If a foundation model drafts something a person then reviews, the value is the time saved per task multiplied by the volume of tasks multiplied by the loaded cost of that person's time, adjusted for the review overhead.
Be honest about the adjustment. The model does not eliminate the human; it changes what the human does. A realistic claim is "this task drops from 40 minutes to 12 minutes including review," not "this task is now free." Inflated labor savings are the fastest way to lose credibility when the actuals come in.
Quality and Risk Reduction
Some value shows up as fewer errors, not faster work — a missed clause caught, a misrouted ticket avoided, a compliance gap closed before it became a fine. This value is real but harder to quantify, so anchor it to the cost of the failure it prevents and a conservative estimate of how often it occurs.
Throughput and Revenue Expansion
The most strategically interesting value is doing more than was previously possible — responding to every inbound lead instead of the top 20%, reviewing every document instead of a sample, offering a service that was too labor-intensive to be viable. This is harder to model but often the largest prize, because it is growth rather than savings.
Account for the Full Cost, Not Just the API Bill
The per-token price is the visible cost and usually the smallest one. A business case that only counts the API bill will be wrong by a wide margin. The full cost stack includes:
- Inference cost, measured per outcome rather than per token — the same task may need retries, larger prompts, or escalation to a more expensive model. This is why the trade-off analysis belongs inside the ROI model, not beside it.
- Engineering and integration to build, test, and connect the system to your existing tools.
- Evaluation and monitoring, the ongoing work of measuring quality and catching drift.
- Human-in-the-loop overhead, the review and correction time that does not disappear.
- Governance and compliance, the review, documentation, and controls a responsible deployment requires.
The cost that surprises teams most is not inference — it is the engineering and ongoing operations. Budget for the system around the model, not just the model.
Build the Payback Model
With benefits and costs named, the payback model is straightforward. Estimate the monthly benefit, subtract the monthly run cost, and compare the result against the one-time build cost to get a payback period. A use case that pays back its build cost in a few months and runs profitably after is an easy approval. One that takes two years is a harder sell and probably needs rescoping to a narrower, higher-value slice.
Run the model with conservative, central, and optimistic cases. The conservative case is what protects you — if the project still makes sense when you assume modest adoption and higher costs, you have a robust case. If it only works in the optimistic case, you are one bad month from cancellation.
Present It So a Decision-Maker Can Act
The strongest business case fits on one page: the outcome and its metric, the conservative benefit estimate, the full cost, the payback period, and the single biggest risk with your plan to manage it. Lead with the number that matters to the person approving it, not the technology underneath.
Include how you will measure success from day one. A decision-maker is far more comfortable funding a project that says "here is the metric, here is the baseline, here is the checkpoint at 90 days" than one that asks for faith. The willingness to be measured is itself a signal that you believe the numbers.
Frequently Asked Questions
How do I estimate ROI before I have built anything?
Run a small, time-boxed pilot on real data to get actuals for the key variables — time saved per task, quality rate, and cost per outcome — then extrapolate to full volume. A two-week pilot that measures these on a few hundred real cases produces a far more defensible model than any amount of upfront estimation.
What is the most common mistake in a foundation-model business case?
Counting only the API bill and inflating labor savings. The API cost is usually the smallest line item, while engineering, evaluation, and human review dominate the real cost. Pair that with a claim that the model makes a task "free," and the actuals will undercut your credibility fast.
Should I measure cost per token or per outcome?
Per outcome, always. Per-token price is an input that ignores retries, prompt size, and escalation. The number that determines whether the project improves your margin is the fully loaded cost to produce one finished result, which is the figure to put in the payback model.
How long should payback take to justify the project?
A few months of payback is an easy approval; under a year is generally defensible; multiple years usually means the use case is too broad and should be rescoped to a narrower, higher-value slice. Always test whether the project survives the conservative case, not just the optimistic one.
How do I defend the case against a skeptical CFO?
Be specific, conservative, and measurable. Tie every benefit to a metric the business already tracks, count the full cost stack rather than just inference, present a conservative payback case, and commit to a 90-day checkpoint with a baseline. A case that invites measurement is far more persuasive than one that asks for belief.
Key Takeaways
- Lead with a specific, measurable business outcome, not the technology.
- Quantify benefits honestly across labor acceleration, risk reduction, and throughput expansion — and adjust for review overhead.
- Count the full cost stack; inference is usually the smallest line, while engineering and operations dominate.
- Build a payback model with conservative, central, and optimistic cases, and make sure it survives the conservative one.
- Present a one-page case that leads with the decision-maker's metric and commits to measurement from day one.