A vendor quote is not a business case. The licence or platform fee is the number everyone sees, so it is the number proposals lead with, and it is often less than half of what the initiative will really cost. When Gartner predicted in mid-2024 that at least 30% of generative AI projects would be abandoned after proof of concept, escalating costs were one of its four reasons. Most of those costs were foreseeable; they simply weren't in the original case.

Every AI business case should cost five categories. Licences and usage: the platform or subscription fee, plus any usage-based charges, since many generative AI services bill by volume of text processed and costs rise with adoption. Integration: connecting the tool to your document stores, identity systems and workflows, and rolling it out, including training. Data preparation: finding, cleaning, labelling and permissioning the data the tool will draw on; "we have the documents" is not the same as "the documents are ready". Governance: the risk assessment, policies, human review process, testing and audit trail you need before the tool touches client work. Maintenance: updates, monitoring, vendor management and support once it is live.

Then separate one-off costs from recurring ones. Integration and data preparation are mostly one-off. Licences and maintenance recur. Governance is the one leaders most often get wrong: the set-up is one-off, but monitoring, periodic testing and audit carry on for as long as the system runs. A case that costs governance once is understating every year after the first.

The test of a cost model is simple: could your finance team find a cost in year two that isn't on your page? If so, it isn't finished.

For the exercise, use this proposal. A function head asks for £60,000 for a contract-summarisation tool: a £50,000 annual licence and £10,000 for integration. Nothing else is costed. The tool will summarise client contracts held in three separate systems, and the summaries will go to clients.

A CFO will not fund "saves lots of time". You need to turn the operational improvement into a pound figure, and show every step so that each one can be challenged.

Start with the baseline cost: what the process costs today. For a time-based use case, that is the number of people doing the work, the hours each spends on it, and what an hour of their time is worth. Then build the benefit chain: people × hours saved per week × working weeks per year × hourly rate. Use realistic working weeks (around 46 to 50 once holidays and absence are allowed for) and say which rate you're using: a cost rate if the benefit is cost avoided, a charge-out rate only if the freed hours will be billed.

That distinction is where most benefit cases fall apart. Freed time is recovered capacity, not cash. It becomes money only if something changes: the hours are redeployed to billable or revenue-generating work, the team absorbs growth without hiring, or overtime and contractor spend falls. Write down which of these will happen and who is accountable for it. A CFO who sees "recovered capacity, redeployed to client work, tracked through utilisation" will engage. One who sees hours multiplied by a rate and called a saving will discount the lot.

Next, apply a realisation rate. Not everyone adopts a new tool at once, and not every task speeds up as much as the pilot suggested. Stating that you expect, say, 70% of the theoretical benefit in year one is not weakness; it is the assumption that makes the rest of your case credible.

Finally, classify each benefit. Hard benefits, such as reduced external spend, show up in the accounts. Soft benefits, such as faster turnaround or better quality, are real but harder to verify. Map each to one of the four value drivers from Module 2: cost reduction, revenue growth, risk reduction or new capability. Lead with the hard benefits and describe the soft ones without inflating them.

Boards use three numbers to judge an investment. Net benefit is total benefit minus total cost over a stated period. ROI is net benefit divided by total cost, times 100. Payback period is how long it takes cumulative benefits to cover the cost. None needs a finance degree, but each needs a stated horizon. Your finance team may also want discounted measures; for a leader's case, these three carry the decision.

Show year one and a three-year view. Year one tells the board how quickly the money comes back. Three years shows the recurring costs from year two onwards, so nobody is surprised when the licence renews. For Meridian's legal research assistant, the three-year view is £235K of cost (£105K in year one, then £65K a year) against £2,025K of benefit, a net benefit of £1,790K.

Then test the assumptions. Implementation lag, the delay between going live and benefits arriving, is the one most cases ignore. If benefits start three months late, Meridian's payback moves from 1.9 months to 4.9: the three lost months plus the same 1.9. Halve the realisation rate instead and payback becomes 3.7 months. The assumption with the biggest leverage is the one to evidence most carefully, and to monitor once the system is live.

Treat very high returns as a warning, not a selling point. Year-one 543% ROI invites the question "what have you left out?" The answer should be visible on the page: the costs you included, the realisation rate you assumed and what happens if you're wrong.

Three errors sink most AI business cases. First, missing costs: the headline licence and nothing else, or governance costed once. Second, capacity counted as cash at full adoption from day one: hours multiplied by a rate, with no realisation rate and no plan for what the freed time will do. Third, a single-point estimate: one ROI figure with no lag and no sensitivity, so the first delay destroys the case's credibility. Each fix is cheap: cost five categories, state the realisation rate, and show a cautious scenario alongside the expected one.

The AI ROI Calculator calculates all three metrics, with implementation lag and realisation rate as inputs you can change.

Once the numbers work, the question becomes how to source the capability. There are three routes, and they are genuinely different. Build means developing the solution in-house with your own engineers and data scientists, usually on top of a foundation model or open-source components. Buy means licensing a commercial product and configuring it rather than coding it. Partner means working with a vendor or specialist firm to co-develop or integrate a solution: they bring engineering and platform capability, you bring the data, the domain knowledge and the process change.

Four tests decide between them. Strategic differentiation: is this capability something you compete on, where owning it matters, or something every firm in your sector needs? Internal capability: do you have the engineering, data and product skills to build and run it, now, not after a hiring plan? Speed to value: how quickly do you need results, and how much does delay cost? Cost and control over time: what will each route cost across three years, how dependent will you be on one supplier, and how easily could you switch?

A mature vendor market tips the balance towards buying. When several established products already do the job, building your own rarely beats them on cost or speed. Partnering fits when the problem is specific to your data or processes and no product does it well, but you lack the people to build alone. Building fits when the capability differentiates you and you have, or will commit to, the team to sustain it.

Two mistakes recur. Always buying leaves you with a scatter of tools that do the same for your competitors, and no capability that is yours. Always building wastes time and money reproducing what vendors already sell, and leaves you maintaining software you didn't need to own. The evidence leans against reflexive building: MIT's Project NANDA reported in 2025 that purchased tools and partnerships succeeded about twice as often as in-house builds. It is an observational study, so read it as a caution rather than a rule.

Whichever route you choose, plan the exit. Ask who owns the data and outputs, how you would move to another supplier, and what happens if the vendor's pricing changes.