Business Case

What a Business case is

A business case is the argument for investing in an AI project, set out so that a finance function can judge it. A strong one names the weakest gap, attaches a plan for closing it and ties the spend to a defined business outcome.

The site’s production article gives the reason in one sentence. A request built on competitor pressure or general enthusiasm is difficult for a finance function to evaluate on its merits, because there is no specific evidence attached to it beyond the fact that other organisations are also spending.

This page uses that meaning. It does not teach you to build a financial model. It explains what a case for AI is made of, where its evidence comes from, and why the order in which you do things changes how persuasive it is.

Why an AI Business case needs Evidence

A finance function does not need to understand AI to judge a case for it. It needs something specific to weigh: what is wrong now, what it costs, what will be done, what the outcome will be and how that will be known.

The production article puts it plainly. A request built on a scored assessment names the specific dimension that is weakest, attaches a concrete plan for closing the gap and ties the investment to a defined business outcome rather than a general aspiration. That is the basis most finance functions respond to: specific evidence and a sequenced plan, not enthusiasm framed as urgency.

The rest of this page is about where that evidence comes from.

What a Strong Business case contains

Put the pieces together and a strong case has five parts.

A named gap. Not “we should use AI” but the weakest point, which the production article ties to four dimensions: data, process, ownership and skills.

A plan for closing it, in order. The fix is sequenced so that the weakest dimension is addressed first, not whichever gap happens to be most visible.

A defined business outcome. The business outcomes page describes what an engagement is meant to leave behind. The well-scoped workflow article says to tie the work to an outcome someone already tracks, so the result can be seen in a number the business already reads.

A cost that is complete. The total cost of ownership page sets out the whole cost, not only the subscription or the build invoice.

A return set against a baseline. The return on investment page says it can only be shown against a baseline taken before the tool arrived.

Start with the Assessment, not the request

The most useful rule in the production article is about timing. It says to score an AI initiative’s readiness before writing a business case for it, not after, since the assessment tells you which gap to close first rather than guessing.

A structured assessment does three things before budget is committed. It scores where the organisation stands on data, process, ownership and skills. It names the single weakest dimension, rather than leaving preparation as a vague general concern. And it sequences the fix. That output is what turns AI investment from a decision made on enthusiasm or competitor pressure into one made on a specific, evidenced gap and a concrete plan for closing it.

The same article says an audit is where that assessment and sequencing happen. The audit method’s third step weighs each candidate on how often it repeats, what the manual version currently costs in effort, whether the data it needs exists in a usable state, and what regulatory exposure attaches to it. Each opportunity comes out ranked with the reason it sits where it sits, and candidates that are possible but not worth doing are named and set aside with the reason recorded. That ranked list is the raw material for a case.

The cost side of the case

A case that counts only the subscription will look cheaper than it is. The running cost article says the running cost of a workflow has five parts: model usage, platform and hosting, human review, maintenance and governance.

Two points from it matter most for a case. Human review is the part most often left out of the estimate, and it can cancel the saving if checking takes nearly as long as doing the work. And a workflow that is used more costs more to run, so a rising bill is a sign of success only if the value rises with it. The article’s advice is to ask for the cost per completed task, not the cost per model call, because the first is what the business actually pays.

It also says the cheapest workflow to run is the narrow one: a single process with a clear input, a clear output and a named owner. A narrow scope is therefore good for the cost side of the case as well as for the evidence.

The return side and the baseline

The return is the part of a case that most often goes missing. The return on investment page says it concentrates where a workflow is narrow and well scoped. A defined, single-purpose workflow produces a number that can be measured, while a broad, loosely defined rollout across an organisation usually does not.

To show a saving you need a baseline. The first-task article says to write it before touching the tool: how long the task takes now, how often it happens each week and what a good result looks like. Two or three lines are enough. Without them you finish the trial with a feeling that it went well and nothing to back it up.

The time-saving article explains why the whole cycle has to be timed. Time rarely disappears. It moves into checking, fixing, re-prompting and handoff, and a tool only saves time if the total across all four is smaller than before. It cites a 2025 trial in which experienced developers were 19 per cent slower with an AI tool while believing they were 20 per cent faster. The vibe coding article notes that the trial’s authors have since said that result is out of date, so treat it as a reminder that feeling faster and being faster are different things, not as a verdict on today’s tools. The productivity gain page makes the same point: a feeling of speed is not a result.

The article also says to decide in advance what the released hours are for, or they vanish into the day. A case that names what the hours will be used for is more credible than one that assumes they will turn into value on their own.

A Business case for Training

Training can have a case of its own. The training article reports that organisations investing in structured AI training see a 40 per cent improvement in measured employee productivity. That is a finding the article reports, not a measurement the site made itself.

The article’s argument is that the figure is what turns training from a cost into a business case, with a return traced to the business outcomes it was meant to move. The same logic applies as for any other case: the outcome has to be one someone already measures.

Sponsor, metric and champion

A case does not end when it is approved. The production article names three traits shared by projects that move into production: a named executive sponsor, a defined success metric tied to a real business outcome, and at least one internal champion. It adds that the owner should be recorded in your AI governance policy, since the evidence ties all three to whether a project reaches production.

The success metric is the part that links the case to its result. If the case promised a defined outcome, the metric is how anyone checks. The internal champion page adds a limit worth planning for. A champion carries a project, and a project has an end date, while owning the result is operational work with no end date. The AI governance page covers where that ownership is recorded.

What to do with a low score

A low first score is evidence, not a verdict. The production article says a below-average first assessment is not a reason to delay AI investment indefinitely. It is a reason to sequence that investment correctly: fix the weakest dimension first, reassess, and only then commit the larger budget to the initiative the assessment was originally scoped around.

For a case, that turns a weakness into a plan. Instead of arguing that the organisation is ready, you show exactly what is not yet ready and what closing it will take. Many finance functions find that easier to approve than a confident claim, because the risk has already been named.

What a Business case does not do

It does not prove the idea works. Only a test does that, and the audit method’s fourth step exists for this. The prototype is built narrow, on the organisation’s own work, to answer one question: does it behave well enough to be trusted with this work. The people who do the work judge the result, and their verdict decides whether the next step happens. A prototype that fails answers the question as usefully as one that succeeds, and it does so before anything has been rolled out.

It does not replace measurement afterwards. The time-saving article ends each review in one of four verdicts: keep, scale, switch or drop, after a re-check at 30 days. A case that includes that check is easier to trust than one that assumes success.

And it does not make the risky tasks safe. The first-task article advises leaving customer-facing and people-related tasks until you have a month of evidence about how your own team checks and corrects the output.

A worked example

An illustration, not a case study. A small business wants to use AI to draft replies to routine customer enquiries.

The case starts with a scored look at the four dimensions. It finds the process is clear but the approved answers are scattered across documents, so the weakest dimension is data. The plan is to gather and tidy the approved answers first, then trial the drafting on one narrow category of enquiry.

The baseline is written before anything is switched on: how long a reply takes now, how many arrive each week and what a good reply looks like. The cost is counted in full, including the time a person spends checking each draft, not only the subscription. The outcome is one the business already tracks, such as time to first reply.

A sponsor, a metric and a champion are named, and the owner is recorded. The trial runs for a set period. At the end, the whole cycle is timed against the baseline, and the verdict is keep, scale, switch or drop. The finance function has a gap, a plan, a cost and a number to check against.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is writing the case before the assessment, which leaves it resting on enthusiasm. The second is counting only the subscription and leaving out human review. The third is claiming a return without a baseline, so the only evidence is a feeling. The fourth is treating approval as the end, when the success metric, the champion and the owner still have to carry it.

How we use it

The production article says an audit is where the assessment and sequencing happen, and the audit methodology ranks each opportunity with the reason it sits where it sits. The case is then tied to business outcomes someone already tracks, not to a general aspiration.

If you need an evidenced case for what comes next, a discovery call is a quick way to start.

Sources

• What predicts whether an AI project reaches production: a request built on enthusiasm being hard to judge, the case that names the weakest dimension, assessing before writing the case, a low score as a sequencing problem, the four dimensions, and the three traits of projects that reach production.
• What makes AI trainings stick: the reported 40% improvement in measured employee productivity that turns a training budget into a business case.
• How much does an AI workflow actually cost to run?: the five parts of running cost, human review being left out, and cost per completed task.
• Is your AI tool actually saving time?: the baseline, the whole cycle, time moving into checking and handoff, the 30-day re-check and the four verdicts.
• Which AI tasks should a small business start with first?: writing the baseline before touching the tool, and waiting for a month of evidence on customer-facing tasks.
• How we audit: ranked opportunities with their reasons, candidates set aside, and the prototype judged by the people who do the work.
• Well-scoped AI workflow: tying the work to an outcome someone already tracks.
• Return on investment, Total cost of ownership, Productivity gain, Business outcomes, Internal champion and Prototype: the neighbouring terms this page links to.