How to Write an AI Business Case That Survives Scrutiny

AI business cases get rejected for predictable reasons: an assumed baseline, a missing mechanism, and costs that stop at the build. This playbook covers writing one that survives scrutiny, drawing on FISTA Solutions' AI enablement work.

When is this worth doing?

Before any significant AI investment, and particularly before a programme rather than a project. Small experiments funded out of existing budget may not need one.

The test is whether anyone will ask afterwards what it delivered. If they will, the case is worth writing now while the claims are still honest.

What does the sequence look like?

Step	Purpose
1. Measure the baseline	What it costs today, actually
2. State the mechanism	The chain from system to benefit
3. Size the benefit	Conservatively, with a range
4. Cost it fully	Build plus operation plus review
5. Name the risks	Including what would disprove it
6. Define the decision points	When to continue or stop

Step 1 — Measure the baseline

Find out what the workflow costs today: time per case, volume, error rate, rework, and the downstream consequences of getting it wrong.

This is the step most cases skip and the one that determines whether the rest is credible. A measured baseline also gives you the comparison for afterwards, without which nobody can say whether the investment worked.

Measuring takes days rather than weeks: sample the work, time it, count the volume. The result is frequently surprising, and occasionally it kills the case, which is a cheap outcome at this stage.

Step 2 — State the mechanism explicitly

Write the chain: this task takes this long, occurs this often, the system handles this proportion at this quality, which saves this much time, which produces this business result.

Every link is challengeable, which is the point. A case built this way can be argued with specifically, improved, and eventually believed. A case asserting an outcome cannot.

Be honest about the proportion the system handles. Claiming it handles everything invites the obvious objection, and claiming a realistic share makes the whole case more credible.

Step 3 — Size the benefit conservatively

Give a range with a stated basis rather than a single number, and use the lower end for the decision.

Optimistic sizing wins approval and loses credibility later, which affects the next case. Conservative sizing that is then exceeded builds the standing to fund larger work.

Where the benefit is quality rather than cost — fewer errors, better decisions, faster response — say so and quantify the consequence rather than converting it to a spurious financial figure.

Step 4 — Cost it fully

Build cost, model usage at projected volume, evaluation, monitoring, maintenance, human review capacity, and the internal time the project consumes.

Operation is the cost that surprises organisations. A system costing a modest amount to build can cost considerably more to run over three years, and cases that stop at the build are describing a fraction of the commitment.

Include the review capacity explicitly. Systems that raise output volume without review capacity produce a bottleneck that the case did not fund. See AI total cost of ownership.

Step 5 — Name the risks and the disproof

List what could make this fail: data that turns out to be inadequate, a quality ceiling below what is needed, adoption resistance, or a dependency that does not hold.

Then state what result would prove the case wrong. That single sentence does more for credibility than any amount of confidence, and it gives the organisation a way to stop without anyone losing face.

Reviewers who see honest risks trust the benefits more. Cases with no risks listed are read as either naive or evasive.

Step 6 — Define the decision points

Structure the investment in stages with a decision at each: prove the mechanism, prove it works at small scale, then scale.

Staged funding is easier to approve and easier to stop. A case asking for the whole amount up front invites a longer argument and produces a project nobody can cancel without declaring failure.

State what evidence each stage produces and what would justify continuing. That converts the case from a forecast into a plan.

What if the benefit is hard to quantify?

Say so, and quantify the proxy. Faster response, fewer escalations, and shorter resolution times are measurable even when their financial value is not.

Inventing a financial figure for an unquantifiable benefit is the most common way business cases lose credibility, because the assumption behind the conversion is always the weakest part and reviewers find it.

A case that says honestly what it cannot value is stronger than one that values everything.

How do you handle the headcount question?

Directly. If the benefit depends on reducing roles, say so; if it depends on redeploying capacity to work that is not getting done, say that instead and name the work.

Cases that imply savings without stating the mechanism produce two problems: finance expects a reduction that nobody committed to, and staff correctly infer that something is being avoided. Both damage the programme more than an honest statement would.

Who needs to be involved?

Someone who knows the operational detail, someone who can build the cost model, and the sponsor who will own the outcome.

Cases written entirely by technologists tend to under-cost operation and over-claim adoption. Cases written entirely by finance tend to miss why the mechanism might not work.

How long does it take?

One to three weeks, dominated by measuring the baseline. Cases produced in a day are describing assumptions.

What are the common failure modes?

Assumed baselines. Outcomes without mechanisms. Build cost only. No stated risks. Single-point benefit estimates. And avoiding the headcount question.

How do you know it worked?

Approval without a challenge to the numbers, a measured baseline available afterwards for comparison, and stage decisions that get made on evidence.

What does it cost?

Mostly people's time rather than tooling. The expensive version is the one that stalls halfway and leaves the organisation with neither the old state nor the new one, which is why a narrow first pass beats a comprehensive plan nobody finishes.

Budget the work as an operated change rather than a project with an end date, because most of these need a maintenance tail. See AI total cost of ownership.

What should you do first?

Measure the baseline for the workflow you want to improve. Everything else in the case depends on it, and it is the part you cannot borrow from someone else's analysis.

How FISTA Solutions helps

FISTA Solutions runs this work alongside client teams rather than around them: baselines measured before benefits are claimed, costs modelled across build and operation rather than build alone, evidence produced as the work proceeds, and handover that leaves your people able to continue without us. Delivery runs through AI agents, AI enablement, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries, with 47% average efficiency gains where measured.

To run this with support, message FISTA on WhatsApp, or read how to get AI budget approved.