A prioritized roadmap gets you to “yes.” An investment-grade business case gets you funded, staffed, and held accountable. It is the translation layer between discovery artifacts and the organization’s capital allocation process: finance needs numbers it can reconcile, risk needs controls it can trust, technology needs an implementation path it can deliver, and business owners need a plan they can run in operations.
13.1 Business case structure and required evidence
A business case is a story with math. If the story is weak, the math will be questioned. If the math is weak, the story will be dismissed. The right structure makes it easy for reviewers to answer four questions quickly: what are we doing, why does it matter, what will it cost, and how do we know it is safe and likely to work?
Decision request: state what you are asking leaders to approve now, and what you are explicitly not asking for yet. In AI, staged approvals are often the most rational choice. A request framed as “fund the work to reach the next evidence gate” is usually stronger than a request framed as “fund full scale now,” because it aligns investment with learning and reduces pressure to overpromise.
Use case definition: describe the decision or workflow moment, the user role, the system-of-work where the capability will appear, and the first operational release. Keep this tight. Leaders can approve what they can visualize. A vague definition (“AI for underwriting”) creates scope creep and makes measurement ambiguous. A precise definition (“underwriter sees a ranked list of missing evidence and recommended follow-up requests inside the workbench before approval”) is fundable.
Current-state baseline: provide a short, evidence-based picture of today. This should include the eligible population, the current KPI level for that segment, and the specific mechanism that the use case targets (time spent searching, rework loops, escalation rates, error rates, losses). Baselines do not need perfect precision at concept stage, but they must be traceable to a source and consistent with how finance and operations define performance.
Value logic: show how the workflow change turns into measurable impact and then into value. Keep the model driver-based and readable. Explicitly name the value pool and the conversion mechanism: volume, impact per unit, adoption, ramp, and capture. Present a range (conservative, most likely, optimistic) and explain what drives the range. Always show Net value: gross value minus recurring run costs and any incremental review or control costs. Net value is what can be compared across initiatives.
Cost and investment: list the one-time build effort and the ongoing operating costs required to keep the system safe and effective. AI initiatives are frequently underfunded for “run” activities—monitoring, evaluation, incident handling, and configuration management—because those costs feel like overhead. In reality, they are the cost of reliability. If the case cannot explain how the system will be operated, the case is not investment-grade.
Unit economics: AI systems have variable costs per interaction. If a use case runs millions of times per month, small differences in prompt length, retrieval calls, or model choice can swing annual run cost at scale. An investment-grade case includes a unit-cost view—cost per transaction, expected volume, and cost controls—so leaders can see how net value behaves as adoption grows.
Risk and controls: identify the dominant risk scenarios and the control design that makes the first release safe. This section should read like engineered safety, not like policy slogans. It should explain what the system is allowed to do, what it is prohibited from doing, what happens when it is uncertain, and what evidence will be gathered to prove controls behave as designed.
Implementation and stage plan: lay out the path from concept to MVP to pilot to scale. The plan should describe the first release, the scope of the pilot, and the criteria for scaling. It should name dependencies that affect timing—data access approvals, integration release windows, or the build-out of shared foundations—so the timeline is credible.
Ownership and operating model: name who owns benefits, who owns delivery, and who owns ongoing operation. This includes the cadence where performance is reviewed and how issues will be handled. If ownership is vague, reviewers will assume adoption and benefit capture will be weak, and they will be right more often than not.
Once structure is defined, the next step is evidence. Evidence should match the decision. A concept-stage decision needs less proof than a scale-stage decision, but it still needs substance. The simplest discipline is to define an evidence ladder and use it consistently.
Evidence ladder: at concept stage, require a credible baseline, a coherent driver model, a plausible data and integration path, and a confirmed risk tier with minimum controls. For MVP funding, require confirmed data access and a build plan that places the capability in the system-of-work with logging and measurement. For pilot approval, require MVP evidence that the mechanism metric can move, that users will engage in the workflow without harmful workarounds, and that controls behave correctly on realistic edge cases. For scale approval, require pilot evidence of KPI impact within agreed bounds, stable guardrails, acceptable net run cost at scale, and clear operating ownership.
Investment-grade cases typically rely on a small set of evidence types. These are not documents for their own sake; they are answers to predictable questions.
- Baseline evidence: scoped operational extracts that show current performance for the eligible segment, including variance by case type or channel.
- Workflow evidence: short observations, queue analysis, or time studies that validate where work gets stuck and where errors or losses occur.
- Data evidence: a quick feasibility check confirming required fields or content exist, are accessible under policy, and meet minimum quality and latency needs.
- User evidence: feedback from representative users on a first-release experience, focusing on usefulness, trust, friction, and exception handling.
- Architecture evidence: a lightweight confirmation that the integration pattern is feasible and aligns with security requirements.
- Cost evidence: realistic estimates of build effort and run costs based on expected volumes, including evaluation and review overhead.
Be explicit about what you do not know. The strongest cases include a short list of the two or three assumptions that drive the value range, then explain how MVP and pilot will validate them. This makes the case stronger, not weaker, because it signals disciplined learning instead of marketing certainty.
Finally, include alternatives. Alternatives considered: describe what else could solve the same problem—process simplification, rules-based automation, policy change, training, or a different analytics approach—and explain why AI is the best lever for this workflow moment. This prevents the business case from being perceived as “AI for AI’s sake” and forces clarity on the real problem you are solving.
13.2 Pilot design: hypotheses, metrics, and evaluation approach
A pilot is where a use case earns the right to scale. It is an experiment in real operations, designed to produce evidence a steering committee can accept. A pilot should answer three questions with data: does the intervention move the mechanism metric, does that translate into KPI impact, and do controls hold under real-world conditions?
Pilot hypotheses: explicit, testable statements about what will change and why. Write hypotheses at three levels. Mechanism hypothesis: the operational lever will move (for example, handling time decreases, routing improves, rework falls). Outcome hypothesis: the primary KPI improves as a downstream result (for example, cost-to-serve declines, losses reduce, retention improves). Adoption hypothesis: users will use the capability in the system-of-work at a level sufficient to realize benefits, and usage will be sustained beyond novelty.
Hypotheses should include boundaries. A careful pilot does not claim universal impact. It states where impact is expected and where it is not, based on workflow realities. For example, you might expect strong impact on high-frequency, low-complexity cases and limited impact on rare edge cases. These boundaries are valuable because they guide segmentation and prevent overgeneralizing results.
Metrics: choose a small set that captures outcomes, mechanisms, adoption, and safety. At minimum, include a primary KPI, one or two mechanism metrics, and guardrails. Add adoption measures that reflect real behavior, not just logins. For example, track how often recommendations are accepted, edited, or overridden, and whether overrides cluster in certain case types. In higher-risk use cases, guardrails should include safety and compliance indicators, not only experience metrics.
Measurement is a design decision. If you do not instrument usage, overrides, and exception handling, you will not be able to explain results or improve responsibly. For GenAI systems, it is especially important to capture grounding behavior and failure handling. Useful signals include whether the system used approved sources, whether it refused when out of scope, and what kinds of edits humans made before final actions were taken. For predictive models, capture score distributions, thresholds, override rates, and downstream outcomes so you can distinguish model limitations from workflow or policy limitations.
Evaluation approach: define how you will attribute observed changes to the intervention. Randomized A/B tests are the cleanest, but not always feasible. Phased rollout can work well when rollout order is planned and comparison groups are similar. Matched cohort designs can work when stable segmentation exists. Before/after comparisons can be acceptable if seasonality and mix shift are handled and if the baseline window is chosen deliberately. The most important step is agreement in advance: finance, analytics, and business owners must agree what counts as credible evidence and what thresholds will trigger the next decision.
Design pilot scope to balance speed and credibility. If scope is too small, you get noisy results and endless debate. If scope is too large, you create operational disruption and slow learning. A good pilot scope is large enough to move mechanism metrics visibly and to surface real failure modes, but constrained enough to manage change and risk. Consider including more than one team or site when practical to test generalizability; if that is not feasible, be explicit about what additional validation will be required as you expand.
Controls must be tested, not assumed. This is where many pilots fail to produce scale-ready evidence. For higher-risk use cases, include deliberate testing of failure conditions: missing context, contradictory inputs, out-of-scope requests, and attempts to cross permission boundaries. If the system can execute actions, test action gating, audit logs, and safe rollback. The point is not to show the system never fails; the point is to show failures are contained, visible, and recoverable.
Success criteria: define the thresholds that justify moving toward scale. These should include impact ranges for the primary KPI, stability of guardrails, minimum adoption levels, and evidence that net run cost is acceptable at the expected scale. Stop criteria: define conditions that trigger pause or redesign, such as repeated policy violations, unacceptable error patterns, material guardrail harm, or operational disruption that outweighs benefits. Stop criteria protect trust and prevent the organization from “sleepwalking” into production with a risky or ineffective system.
Finally, operate the pilot like a product, not like a science project. Define who supports users, how issues are triaged, and how configuration changes are managed during the evaluation window. Frequent changes can contaminate measurement, but refusing all changes can create avoidable friction. A practical approach is to batch changes on a schedule, document what changed, and interpret results accordingly. A pilot with a clear cadence produces clear evidence, and clear evidence enables decisive roadmapping.
13.3 Budgeting and funding models (product funding, OpEx/CapEx)
AI initiatives often struggle in finance review not because the value is wrong, but because the cost structure and funding approach are unclear. The most common mismatch is approving a build budget without approving the recurring operating costs, then discovering later that the solution is expensive to run or cannot be sustained. Another mismatch is claiming productivity savings as OPEX reduction without an explicit mechanism to remove spend. An investment-grade business case anticipates these realities and proposes a funding model that matches the lifecycle of the solution.
Product funding: a model where a persistent team is funded to deliver and operate a product over time, with a roadmap of increments and a benefits narrative. Product funding fits AI well because AI solutions require continuous improvement, monitoring, and adaptation. It also supports reuse: a product team can deliver multiple use cases and shared components inside the same domain or system-of-work.
Project funding: a model where a time-bound effort is funded to deliver defined scope, often with a handoff after delivery. Project funding can work for narrow use cases with stable requirements, but it can be fragile for AI because ongoing monitoring and updates are required. If you use project funding, explicitly fund post-launch operations; otherwise value decays and risk rises.
Many organizations use a hybrid: product funding for platforms and reusable components, and time-boxed increments for individual use cases delivered by product teams. The important point is clarity: who owns the system after launch, and where do operating costs live?
Even when accounting treatment varies, the business case should make cost structure explicit. AI costs almost always include both one-time and recurring components. One-time includes design, build, integration, data engineering, safety and control design, and change enablement. Recurring includes hosting and compute, model inference, retrieval infrastructure, monitoring and evaluation, human review where required, incident response, and ongoing updates to prompts, retrieval sources, or models.
Run costs: the recurring costs required to keep the system safe, effective, and available at expected volume. Run costs are often underestimated because teams focus on building and overlook evaluation, logging, and support. Treat run costs as first-class because they determine net value and can materially affect which technical approach is optimal.
For GenAI, run costs can be highly volume-sensitive. Small differences in usage patterns can change cost materially. It is therefore prudent to estimate run costs under conservative and high-usage scenarios and to define cost controls, such as limiting expensive actions to high-value cases, caching frequent retrieval, and using smaller models for low-stakes tasks.
Funding should align with stage gates. A staged funding approach—fund to reach the next evidence point, then decide again—reduces pressure to inflate benefits and encourages learning discipline. It also makes big bets safer: leaders can fund a pilot to validate impact and control effectiveness without committing to full-scale spend before evidence exists.
Finally, define how benefits will be recognized. For productivity, clarify whether value is treated as cost reduction, capacity release, or service improvement. If cost reduction is intended, identify the operational decision that removes spend (contractor reduction, overtime reduction, delayed hiring). If reinvestment is intended, define the metric that proves reinvestment matters (backlog reduction, faster resolution, improved quality coverage). Finance does not need certainty at the concept stage, but it does need a coherent recognition path.
13.4 Approval pack template and stakeholder FAQs
The approval pack is the business case in a format leaders can decide on in one meeting. The goal is not length; the goal is completeness in the right places. The pack should make the decision request unmistakable and should answer predictable questions without forcing stakeholders to infer what is missing.
Approval pack structure: a concise narrative that moves from why to what to how to ask. Keep the structure consistent across initiatives so executives can compare decisions quickly.
- Context and problem: the current-state pain, the impacted segment, and why it matters now.
- Proposed use case: the workflow moment, user roles, system-of-work placement, and first operational release.
- Value summary: value pool, baseline, mechanism, net value range, and the assumptions that drive the range.
- Cost summary: one-time build and recurring run costs, including evaluation and control overhead.
- Risk and controls: dominant risks, minimum controls, and what will be proven in MVP and pilot.
- Plan and timeline: stage gates, dependencies, and what decisions will be required at each gate.
- Ownership: benefits owner, delivery owner, operating owner, and performance management cadence.
- Decision request: what is being approved now, what is conditional on evidence, and what is out of scope.
Stakeholder FAQs are predictable, and preparing for them strengthens the case before the meeting. Finance typically asks: what is the value pool, how is value captured, what is net value after run costs, and how is double counting avoided? Business owners ask: what changes day to day, how exceptions are handled, and what training and reinforcement are required. Technology asks: what is the integration pattern, what foundations are reused, and what operating model supports updates and incidents. Security, risk, and legal ask: what data is processed where, how permissions are enforced, what failure modes exist, and what evidence proves controls work.
When you cannot answer a question today, label it as an open issue with a planned validation step before the next gate. The worst answer is vague reassurance, because it invites late surprises that undermine trust. A disciplined pack makes choices visible: proceed as planned, proceed with narrower scope to reduce risk, invest in a prerequisite foundation first, or defer until prerequisites are met.
When done well, the investment-grade business case becomes a contract: what will be built, what will be proven, what will be measured, what it will cost to run, and who will own it. That contract is the bridge from a promising use case to a funded initiative that delivers real outcomes.
