Why Your AI Business Case Dies in the Second Meeting

A CFO and a CISO can read the same AI proposal and reach opposite conclusions without either of them being wrong. One is reading a payback horizon. The other is reading what the software can reach once it has write access to a production system. Both are correct inside their own frame, and neither frame is the one the proposal was written in.

Call it the four-sheet problem. Four executives now score the same AI workflow, each on a different sheet, and the sponsor usually writes to one of them.

That is where AI purchases stall. Not at the demo, which usually lands. Not at the champion, who is often the most enthusiastic person in the building. It stalls two meetings later, when the people who were not in the room start asking questions the sponsor cannot answer, and the deal stops moving without anyone ever saying no.

This is a map of the four sheets, and of how to write one business case that survives all four reads.

AI stopped being a departmental purchase

The committee did not grow because procurement got stricter. It grew because of what AI now touches.

Start with the baseline the sales world already knew. Gartner research, cited by Bullseye (2026), puts the average enterprise buying committee at six to ten people, with deals under $25K involving two to four stakeholders and enterprise deals regularly running past ten once security, legal, and procurement join. Roughly 83% of B2B purchases now involve a formal committee. AI did not create that structure. It activates all of it at once, in a single decision, on a shorter timeline than most companies have a process for.

What changed is reach. Deloitte's 2026 State of AI report found that worker access to AI rose by 50% during 2025, and that the number of companies with at least 40% of their AI projects in production is expected to double within six months. Deloitte (2026) also found that just 34% of organizations are truly reimagining the business, while the rest are redesigning individual processes or still using AI at surface level. That combination is the interesting part. Broad access plus shallow redesign is the condition that produces a purchase nobody has scoped properly.

OpenAI's enterprise research points the same direction from a usage angle. Structured workflows such as Projects and Custom GPTs grew 19 times year to date, and average reasoning token consumption per organization rose roughly 320 times in twelve months, according to OpenAI (2025). Those are not the numbers of a tool people query occasionally. They are the numbers of software that has been wired into repeatable processes.

Once software is wired into a repeatable process, it stops being a licence and starts being infrastructure. That draws budget scrutiny, because the spend recurs and scales. It draws architecture scrutiny, because it touches production data. Operations gets involved, because someone's day changes. And security gets involved, because an agent that can act has a blast radius that a chatbot does not.

Four kinds of scrutiny, four sheets, one meeting. Here is what is written on each of them.

The four seats and what each one actually scores

Most guidance on this topic says "align your stakeholders" and then stops. That is the gap. Stakeholders are not a single audience with a shared metric. They are four people with four accountabilities, and the same slide reads differently to each.

The CFO: return, timing, and what happens if it does not work

The CFO is accountable for capital allocation. The question out loud is "what is the return and when does it land." The question underneath is "what does this displace, and what is my exposure if the projection is wrong."

What satisfies a CFO is a defensible number rather than a big one: a measured baseline from before the purchase , a value model with a conservative, expected, and upside case, a stated payback horizon, and an honest line on what happens in the downside scenario. A number with a range and a method beats a number with a bigger headline every time.

What kills it is a saving with no baseline. "Saves 20 hours a week" invites the obvious follow-up. Twenty hours compared to what, measured how, over what period. If the sponsor cannot answer that in one sentence, the CFO has learned that nobody measured the current state, and the whole case becomes a guess wearing a spreadsheet.

The CTO: architecture, data, and dependency risk

The CTO is accountable for what the estate looks like in three years. The question out loud is "what does this touch." The question underneath is "what am I locked into, and what breaks if this vendor changes direction or disappears."

What satisfies a CTO is specificity: where data flows, which systems are read from and written to, which integrations exist today versus which are on a roadmap, and what the exit path looks like. IBM's 2026 study of technology leaders found that organizations which designed for adaptability early, keeping workloads portable and models replaceable rather than locked into hard dependencies, reported a 10% higher return on AI investment in 2025. Portability shows up as a return line, which puts it on the CFO's sheet as well as the CTO's.

What kills it is "it integrates with everything." That sentence tells a CTO that either nobody has checked, or the integration is a generic API that will need six weeks of internal work nobody has budgeted.

The COO: throughput, staffing, and who does the work differently

The COO is accountable for the work getting done. The question out loud is "who does what differently." The question underneath is "what breaks in my process during the transition, and who absorbs it."

What satisfies a COO is a before-and-after view of the workflow with named owners, a realistic view of the transition period, and clarity on what happens to the time that gets freed. Deloitte (2026) found that just 34% of organizations are truly reimagining the business rather than layering AI onto existing work, which is precisely the gap a COO is trying to avoid falling into.

What kills it is saved hours that nobody redeploys. Twenty hours saved across ten people is two hours each, spread thin, and it shows up in no operational metric at all. A COO has seen that film before. The version that convinces is "this removes a step that currently takes 40 minutes and is owned by one team, and here is what that team does instead."

The CISO: access scope, auditability, and blast radius

The CISO is accountable for what happens when something goes wrong. The question out loud is "what can it reach and who can see it." The question underneath is "when this misfires at 2am, how fast do we know, and how fast can we stop it."

This is the seat that has changed most, and the numbers say why. IBM (2026) reported that only 11% of surveyed technology leaders say they are completely prepared for the scale of AI agent deployment, and that 59% of tech CxOs cite security and compliance concerns as the top barrier to scaling agents. Of the AI agent incidents reported, 17% were high severity and took more than four hours to contain, with 37% resulting in data exposure or a security breach and 33% causing cascading system failures.

What satisfies a CISO is a control plan drafted before deployment: explicit access scope, the specific points where a human reviews or approves , an audit trail that survives an incident review, and a kill switch someone is authorised to pull. IBM's data gives this an economic argument too, since organizations that embed control directly into their AI systems experienced 25% fewer incidents than those relying on manual governance.

What kills it is write access discovered late. A security review that starts after the contract is drafted is a renegotiation.

Read the last column downward. Those four failures are usually the same sentence, read four times.

Why one ROI number fails four ways

Take the most common sentence in AI proposals: "this saves the team 20 hours a week."

The CFO rejects it because there is no baseline and no counterfactual. Twenty hours against what measured starting point, and what would those hours have cost if the team had simply hired a contractor or improved the template instead?

The CTO rejects it because the saving assumes an integration that does not exist yet. The 20 hours only materialize if the tool reads from the system of record automatically. Today it does not, so the real first-year number includes an integration project.

The COO rejects it because saved hours are not redeployed hours. Unless the freed capacity is pointed at something specific, it disperses into the working day and never appears in a cycle-time metric.

The CISO rejects it because the calculation quietly assumes the tool has access to a dataset that has not been approved for it. The saving is real only under a permission model nobody has signed off.

The same claim rewritten to survive all four looks like this: "In the last quarter, this workflow took 340 hours across four people, measured from the ticket log. With the integration built, the modelled range is 180 to 240 hours, and the freed capacity is committed to reducing the backlog in the same queue. It reads from two systems and writes to one, with human approval before any write. Payback lands somewhere between month seven and month eleven depending on the scenario."

Longer, yes. It is also the version that survives a second meeting, because each seat finds its own answer inside it without needing a separate document. Which raises the obvious question: how do you write one document that does that on purpose?

Building one business case instead of four documents

The instinct when four people want different things is to write four things. That is the trap. Four documents drift, contradict each other, and signal that nobody owns the decision.

One document, structured in seven parts, does the job:

1. The workflow, described as a workflow. Inputs, steps, current owner, current cycle time. Not the product, not the vendor, not the category. If the first page describes software rather than work, every seat starts from the wrong frame.
2. The baseline, measured before anything is bought. Whatever number the case rests on has to have been observed. A week of honest measurement is worth more than a month of modelling.
3. The value model with three scenarios. Conservative, expected, upside, with a stated payback horizon and the assumption behind each. The range is the credibility, not a weakness in the case.
4. The architecture note. Where data goes, what it reads, what it writes, which integrations are real today, and what happens if the vendor is acquired or changes its pricing model. Portability belongs here.
5. The operating change. Who does what differently, what training or role change it implies, and what the transition period looks like for the team absorbing it.
6. The control plan. Access scope, the specific human-in-the-loop checkpoints, the audit trail, and the kill switch. Written before deployment, not requested after.
7. The decision ask. One page naming exactly what is wanted from each seat, so nobody has to infer their own role in the approval.

Parts 4, 5, and 6 are the ones most AI business-case templates skip entirely, and they are the ones that stop deals. A case with a beautiful financial model and no control plan gets sent back, and the delay usually costs more than writing those three sections would have.

If the structuring work is the part that feels hardest, that is normal, and it is worth doing properly rather than fast. A focused AI Transformation Discovery sprint exists for exactly this: producing the baseline, the architecture note, and the control plan as real artifacts rather than assertions.

A worked example: one workflow, four scorecards

The following is an illustrative model, not a client result. The numbers are constructed to show the shape of the argument, not to report an outcome.

The workflow is first-pass contract summarization in a mid-market company. Legal reviews inbound vendor contracts. Someone reads each one, extracts the commercial terms, and produces a summary for the business owner. The proposal is an agent that produces the first-pass summary and routes it for review. One workflow, four readers.

The CFO read. Baseline: the ticket log shows 62 contracts last quarter, averaging 95 minutes each, so roughly 98 hours per quarter across two people. Conservative scenario assumes 40% of that time is removed. Expected assumes 60%. Upside assumes 70% plus a reduction in the review backlog. Against the licence and integration cost, payback lands between month eight and month fourteen. Downside case: if adoption stalls at the conservative end, the project is roughly cost-neutral in year one and positive in year two.

The CTO read. The agent reads from the contract repository and the CRM. It writes to one place, the summary field on the contract record. The repository integration exists today. The CRM write is a two-week internal build that has to be in the plan, not assumed. Models sit behind an abstraction layer so the underlying provider can be swapped, which is what makes the 10% adaptability return line from IBM (2026) relevant rather than decorative.

The COO read. Two paralegals currently own this step. After the change, they review and correct rather than draft, which is a different task with a different skill emphasis, and it needs two weeks of overlap while both processes run. The freed capacity is committed to the contract renewal backlog, a named queue with a named owner rather than a general productivity claim.

The CISO read. The agent has read access to the contract repository, which contains commercially sensitive terms and some personal data in signatory blocks. It has write access to exactly one field. Every summary is reviewed by a named human before it reaches the business owner. All actions are logged with the source document id. Access can be revoked by the legal ops lead without a vendor ticket.

Four reads, one document. The disagreements that remain are about numbers and sequencing rather than about whether anyone understands what is being bought, and that is the whole difference between a decision and a stall.

Where AI business cases stall, and the tell for each

Four failure modes account for most stalled AI purchases . Each has a tell that shows up before the deal goes quiet, which means each is catchable while there is still time to fix it.

Stuck in pilot. McKinsey's global survey, cited by Alice Labs (2025), found roughly 65% of organizations still in an experimentation or piloting phase . The tell is that nobody has written down what "done" means. A pilot without a written exit condition does not conclude. It gets renewed until the sponsor changes jobs.

The control gap. IBM (2026) found that most surveyed technology leaders are accountable for AI systems they do not fully control, and that 84% have not fully operationalized AI financial management while 85% lack full visibility into real-time AI spend. The tell is that the security conversation has not happened yet and everyone assumes it will be fine. It will not be fine. It will be a six-week delay at the worst possible moment.

Use-case selection failure. MIT Sloan's work on generative AI use-case selection makes the point that the technology gets simple things wrong and struggles with basic logic, which means the use case has to tolerate that failure mode. The tell is a pitch that says the tool can do anything. A use case that only works when the model is never wrong is a hope with a budget line attached.

The champion-only deal. Bullseye (2026) reports roughly twice the win rate on deals multi-threaded across four or more contacts, and notes that around 27% of buying time is spent researching independently, away from any seller. The tell is one email thread and one name. If the only relationship is with the champion, the deal is one reorganization away from dead.

The order to approach them in, and why finance goes last

Sequencing is where most sellers and sponsors lose weeks they did not need to lose.

The instinct is to build the financial case first, win the CFO, and use that momentum to carry the rest. It is the wrong order, for one structural reason. The CFO's number depends on inputs only the other three can supply. The integration cost is a CTO answer. The transition period is a COO answer. The control requirements can add real cost and are a CISO answer. A financial model built before those three have spoken will be revised, and a revised number reads as an unreliable number even when the revision is upward.

A workable order:

1. Start with the COO or the process owner. They hold the baseline. Without a measured current state there is no case to make, only a claim.
2. Bring the CTO in early, while the architecture is still a question rather than a commitment. Early technical involvement converts a veto holder into a co-author. Late involvement guarantees a reopened evaluation.
3. Bring the CISO in at the same time, not after. This is the change most organizations have not made. Security cannot be won in a single meeting at the end, because the answers a CISO needs, such as access scope and audit trail, are design decisions rather than documentation. Design them in and the review is a confirmation. Bolt them on and the review is a rebuild.
4. Take the CFO the assembled case. By this point the number has real inputs, the risks are named, and the ask is specific. That meeting is short when the other three have already happened.

The whole sequence takes longer than a sponsor wants and less time than a stalled deal costs.

What good looks like

A healthy AI evaluation is recognisable from the outside. It has these properties:

• A named owner per seat. Not "finance" but a person, and that person has read the document.
• A baseline measured before purchase. Observed rather than estimated, even if the observation window is short.
• A scoped pilot with a written exit condition. Everyone knows in advance what result would mean go, and what result would mean stop. Stop is a real option.
• A control plan that predates deployment. Access scope, review points, audit trail, and kill switch, agreed before the agent touches a production system.
• One document every seat has read. Not four decks. One, with the parts each seat needs findable inside it.
• An honest downside case. The version of the case that includes what happens if it does not work is the version that gets believed.

None of that is free. It costs a sponsor two or three weeks of unglamorous work before anyone gets to talk about the software, and plenty of teams look at that and decide it is not worth it. The ones that skip it usually spend those weeks later anyway, in a reopened evaluation, with less goodwill in the room.

Where the constraint is capacity rather than clarity, that is a different problem with a different answer. Companies that lack the internal bench to produce the architecture note and the control plan often do not need a permanent hire to get through the evaluation. An embedded fractional agentic team can carry that work through the decision and into the build without a headcount commitment made before the business case is even approved.

Key takeaways

• An AI purchase now clears four accountabilities rather than one, because AI touches budget, architecture, staffing, and access control simultaneously.
• The CFO scores baseline and payback, the CTO scores what the system touches and what it locks you into, the COO scores who does the work differently, and the CISO scores access scope and blast radius.
• A single ROI figure fails all four seats for four different reasons, and rewriting it to name the baseline, the integration, the redeployed capacity, and the permission model is what makes it survive.
• The three sections most AI business-case templates omit, the architecture note, the operating change, and the control plan, are the three that stop deals when they are missing.
• Approach the process owner, the CTO, and the CISO before the CFO, because the financial model depends on inputs only those three can supply.

If the four-sheet problem is where your AI initiative keeps stalling, the fastest way to find out which seat is actually blocking it is to have someone look at the workflow with you. Book a free 30-min readiness call and get an AI Readiness Snapshot: a short, practical read on where AI would pay off in your process and what each of your four stakeholders would need to see before signing.