Finance leaders and product owners are often asked to approve an AI project on the strength of a demo and a large promise. A long business case rarely helps, because most of its numbers are guesses. A single page with honest ranges helps more. It shows what you are assuming, which assumption matters most, and whether it is wise to start now.
This article gives that page. For realistic expectations about returns in general, see what to expect from AI ROI. The model below turns those expectations into numbers you can argue about.
What goes on the page
Three blocks are enough.
One-off costs. Everything you pay before the benefit starts: building or configuring the solution, connecting it to your systems, preparing data, testing, and training the people who will use it.
Monthly costs. What you pay every month once it runs: usage fees or hosting, support and maintenance, and the time people spend checking and correcting what the AI produces. That last item is the one most often left out. If you want help with the usage part, estimating the monthly API cost of an AI feature shows how to do it before building.
Monthly benefits. Usually hours saved, multiplied by what an hour costs your company. Add other benefits, such as fewer errors or faster replies, only if you can put a figure on them. If you cannot, list them separately and do not count them. To find the current cost of a manual process, see measuring the cost of a manual process in a week.
The payback period is then simple:
payback in months = one-off costs / (monthly benefits - monthly costs)
If the monthly benefits are not larger than the monthly costs, there is no payback, and no amount of waiting fixes that.
An illustrative example
The numbers below are invented to show the method. They are not from a real project and are not a promise of what an AI project will return.
A team spends 300 hours a month on a document-handling task, and an hour costs the company 35. That is 10,500 a month. The proposal is an AI tool that handles part of the work.
| Item | Amount |
|---|---|
| One-off: build and integration | 30,000 |
| One-off: data preparation, testing, training | 6,000 |
| One-off total | 36,000 |
| Monthly: usage and hosting | 900 |
| Monthly: review of AI output (about 17 hours) | 600 |
| Monthly cost total | 1,500 |
| Monthly benefit: 40% of the 10,500 handled by AI | 4,200 |
| Net monthly benefit | 2,700 |
Payback is 36,000 / 2,700, which is about 13 months. That is a base case. On its own it says little, because it rests on a single guess for how much of the work the AI handles.
Test two assumptions, not twenty
Pick the two numbers that move the result most and give each a low and a high value. In most projects they are the share of work the AI really handles and the monthly running cost.
Assumption 1: share of work handled. If the AI handles 25% instead of 40%, the monthly benefit is 2,625 and the net is 1,125. Payback becomes 32 months. If it handles 55%, the benefit is 5,775 and the net is 4,275, so payback is about 8 months.
Assumption 2: monthly running cost. If usage and support cost twice as much, 1,800 instead of 900, the net monthly benefit is 1,800 and payback is 20 months. If they cost half, the net is 3,150 and payback is about 11 months.
| Case | Payback |
|---|---|
| Base case | about 13 months |
| Share handled 25% | about 32 months |
| Share handled 55% | about 8 months |
| Running cost doubled | 20 months |
| Running cost halved | about 11 months |
The range is wide: from 8 to 32 months. That is the real finding. The project is not bad, but its result depends heavily on how much work the AI can really take over. That is exactly what a small pilot can measure.
How to read the result
Decide in advance what payback you accept. Many companies use 12 to 24 months for process improvements, but this is your policy, not a rule. Then look at the cases:
- Even the low case pays back in time. Go ahead, and still measure the first months.
- Only the high case pays back. Do not commit the full budget. Run a pilot on a slice of the work to find the real share handled.
- The base case does not pay back. Look for a cheaper scope, or wait. Prices and tools change, so a project that fails today can pass in a year.
- Net monthly benefit is zero or negative. Stop, or change the idea, not the numbers.
When waiting is the right answer
Waiting is not a failure. It is the right choice when the process is about to change anyway, when the data is not ready, when nobody will own the result, or when a cheaper alternative, such as a better existing feature, is close. Write the reason on the page and a date to look again.
Check the model against real numbers
A model is only useful if someone checks it. For the first three months, record the actual hours saved, the actual running cost and the time spent on review. Compare them with the two assumptions. If the real share handled is far below your low case, stop early rather than hoping. If you are still deciding where AI helps at all, an AI audit is a good first step.
Mistakes to avoid
- Counting the vendor's saving as your saving. Use your own hours and your own hourly cost.
- Leaving out review time. AI output still needs a person, at least at the start.
- Adding benefits you cannot measure. List them, but keep them out of the payback.
- Testing too many assumptions. Two are enough to see whether the result is fragile.
What to do this week
Write the page for one candidate project. Fill in the three blocks, calculate the base case, and test the share handled and the running cost with a low and a high value. Decide what payback you accept, and what you would measure in a pilot before spending the full budget.
