Buying and budgeting
Write the AI business case your finance team can question
A one-page proposal that separates observed costs, capacity benefits, uncertain upside, and the next funding decision.
Published · Collection dates are retrospective editorial dates.
A useful business case makes it easy to disagree with an assumption. It gives the finance team a way to change an input, inspect the evidence, and see whether the proposal still makes sense.
A weak case does the opposite. It combines time saved, hypothetical revenue, and broad industry research into one attractive return figure. Nobody can tell which benefits will actually reach the bank account or what operating work the proposal adds.
For a customer-facing AI project, build the case around one workflow and one funding decision. You do not need to prove that AI will transform the organization. You need to show why the next bounded investment is worth making.
Put the decision at the top
Use a concrete request: approve a supervised pilot for a defined task, with a spending ceiling, a named owner, and a review date. If you are requesting a full deployment, explain what evidence already supports that larger step.
State the current problem in observable terms. “Staff spend time clarifying incomplete callback requests” can be measured. “We are falling behind on AI” is not an operating problem.
Specify the affected work and exclusions. A proposal for after-hours intake should not claim benefits from all inbound calls. A drafting assistant should not claim savings from autonomous actions it will not perform.
Separate four kinds of benefit
| Benefit type | Example | Evidence needed |
|---|---|---|
| Cash reduction | A specific external expense ends | Current bill, replacement cost, and termination terms |
| Capacity | Staff have more time for other work | Comparable handling-time evidence and a plan for using the capacity |
| Service quality | More complete requests reach the right owner | Defined quality review and baseline |
| Uncertain upside | Additional eligible enquiries become customers | Local conversion evidence and explicit assumptions |
Capacity can be valuable without reducing payroll. Say what the team will do with it: clear an existing backlog, cover a predictable peak, or handle another task. If there is no plan to use the capacity, the benefit is less concrete than a cash saving.
Keep uncertain upside out of the base case unless the evidence is strong enough to support it. Present it as a separate scenario. This prevents a speculative revenue estimate from hiding a certain operating cost.
Use research to frame the question
Brynjolfsson, Li, and Raymond's revised 2024 paper, Generative AI at work, studies a particular customer-support assistance setting and reports differences across workers. That is a reason to examine your own task and team, not to copy an average result into a receptionist business case.
External research can help identify mechanisms worth testing: finding information, drafting, learning, or reducing repeated effort. It cannot tell you the volume, exception mix, integration cost, or review burden of your own workflow.
Label each input as observed, quoted, estimated, or not yet known. A vendor quote is evidence of a proposed price. It is not evidence that the workflow will succeed. A measured baseline is evidence about the current process. It is not proof of what the new process will deliver.
A one-page proposal you can actually review
Attach detailed calculations rather than crowding every cell onto the page. The page should tell a reviewer where the numbers come from and what decision they support.
Show a calculation without pretending it is a forecast
Suppose a fictional team handles 800 eligible requests a month. For illustration only, it assumes the proposed workflow could release two minutes of staff time per request. The estimated capacity is 1,600 minutes, or about 26.7 hours a month.
That is an assumption, not an observed saving. If review and cleanup take ten hours, the net capacity estimate becomes about 16.7 hours. It is still not a payroll reduction unless the business changes a cash expense as a result.
The example exposes two pilot questions: how much initial effort is actually released, and how much new work appears? Use the pilot to replace the assumptions with comparable observations. Include the requests the system escalates or fails, rather than measuring only the clean completions.
Give uncertainty a consequence
For each important unknown, state what changes if the assumption is wrong. Low eligible volume may make setup hard to justify. High exception effort may erase the capacity benefit. An unsupported integration may require a different scope.
This is more useful than a generic risk paragraph. It connects the uncertainty to the funding decision and shows what evidence would change your recommendation.
Ask finance to challenge the most favorable assumption first. If the proposal works only when every input is optimistic, narrow the project or gather more evidence before asking for full rollout.
The business case should survive a conversation with a skeptical colleague. A clear proposal can be approved, revised, or rejected for a reason everyone understands. That is a stronger foundation than a return figure nobody feels comfortable questioning.
Keep reading
