An AI project's business case is credible only when its return has a denominator — a measured base the return is expressed as a share of, rather than a bare number floating free of context. "This saves 2,000 hours a year" is not a business case; it is a claim nobody can check, because 2,000 hours is impressive against a base of 3,000 and trivial against a base of 300,000. The version finance can actually evaluate reads: this process consumes X hours today, the system removes Y percent of them, and here is what building and running it costs against that. The denominator is what turns a number into an argument.
This matters because most AI proposals fail review not on the technology but on the arithmetic. They quote a benefit with no base, count the build cost but not the running cost, and present a single confident figure where a range and its assumptions would have been more honest and more persuasive. A weak case does not just lose funding; it funds the wrong projects, because a well-told story about a small gain beats a badly-told story about a large one.
Why does the return need a denominator?
Because an absolute number carries no scale, and scale is the whole question. A return stated as a ratio — hours saved as a percentage of hours spent, errors caught as a share of errors made, cost avoided against the fully loaded cost of running the process today — tells a reviewer immediately whether the improvement is marginal or material. An absolute number tells them nothing until they go and find the denominator themselves, and most will not bother; they will simply distrust the figure.
The discipline also protects you from your own optimism. When you are forced to write "we remove 40 percent of the manual keying in this workflow," you have to know what 100 percent of that keying actually is — which means you have to measure the base before you can claim the gain. Cases that skip the denominator usually skipped the measurement, and it shows. The work of quantifying leakage before pricing the fix is what gives the numerator something honest to sit on.
A practical test: if your benefit cannot be written as "Y percent of a base we measured," you have a slogan, not a case.
What belongs on the cost side?
More than the build. The most common error in an AI business case is comparing a one-time build cost against a recurring benefit, which flatters the ratio and sometimes reverses the true answer. A defensible cost side has three layers.
- Build. The one-time cost to design, integrate, and deploy — including the unglamorous work of connecting to source systems, which is usually where budgets overrun.
- Run. The recurring cost of keeping it working: model or API fees, the human review layer that any judgment-bearing system needs, monitoring, and error handling. This line is ongoing and is the one most often left off.
- Maintain. The cost of change. Source systems get upgraded, document formats drift, a portal changes its layout, and the pipeline needs attention. AI systems are not "build once"; they decay quietly against a moving environment.
Sum these over at least two years, not one. A project that looks transformative on a twelve-month build-only view can look ordinary once a second year of running and maintenance is counted — and it is better to know that before you commit than after.
How do you handle savings you cannot prove yet?
You name them as ranges and label the assumptions, rather than burying uncertainty inside a single decisive-looking number. Every honest AI case has soft numbers in it: how much rework the system prevents, how much faster a decision gets made, how much a slow quote or approval was quietly costing in lost deals. The failure is not having soft numbers — it is disguising them as hard ones.
State the base, the expected improvement, and the two or three things that must be true for it to hold. For example: "The team spends roughly 30 hours a week reconciling entries across systems; we expect to remove 50 to 65 percent of that, assuming the source data stays in its current formats and the exceptions we did not automate stay below one in ten." That sentence is more persuasive than "saves 18 hours a week," because it shows its working and tells the reviewer exactly what to challenge.
This is also where much of the hidden cost hides on the benefit side — the compounding cost of manual data entry across disconnected systems is real but hard to pin to a single figure, so it belongs in the case as a named, bounded estimate rather than either an invented precise number or a silent omission.
What the business case does NOT tell you
It does not tell you the project will work. A business case is a hypothesis about value with the costs made honest — it sizes the prize and prices the ticket, but it cannot prove the return will materialize, because that depends on execution, adoption, and whether the process actually behaves the way your measurement assumed. Treating the case as a forecast rather than a bet is how organizations end up defending bad projects long after the evidence has turned.
It also does not settle how to close the gap. Whether to build the system, buy a product, or bring in a partner is a separate question the ROI number informs but does not answer — a strong return can still be the wrong thing to build in-house, which is why the build, buy, or partner decision sits alongside the business case rather than inside it.
And it does not measure itself. The case is written before the work; the harder discipline is checking afterward whether the denominator you assumed held and the benefit you promised arrived, which is the difference between a pilot that shows ROI and one that merely claimed it. A business case with no plan to measure the outcome is a case designed never to be graded.
Where to start
Measure the base before you write a word of justification. Pick the single process the project targets and put a defensible number on what it costs to run today — hours, error rates, delay, fully loaded cost — because that number is the denominator every later claim will be divided by. Regulated and procurement-heavy environments in India and the Gulf make this easier than it sounds: portals, ERPs, and workflow tools leave timestamps and volumes you can count rather than guess.
Then write the case in three columns — the base you measured, the return as a share of it, and the two-year cost of build, run, and maintain — and mark every soft number as an assumption in plain sight. A firm like SynthXel that sizes the leakage before proposing the fix is following the same order deliberately: the denominator first, the technology second. A case built that way may still be declined, but it will be declined for the right reason, and it will not quietly fund the wrong thing.