A common request from finance is simple: when will this AI project pay for itself? The honest answer is "it depends", which is not much use in a budget meeting. A better answer is a short plan that says what you expect to see after three, six and twelve months, what you will do if the results are weaker, and which signs show early that the project is going the wrong way.
This article gives a way to build that plan. It does not promise any particular return. Every number below is a worked example with invented figures, there to show the arithmetic, not to predict your results. For the broader discussion of what benefits to expect, see our article on realistic AI ROI expectations; here we focus on timing, scenarios and warning signs.
Why one number on one date misleads
An AI project has costs from the first week: setup, integration, testing and the time of the people who explain the process to the team building it. Benefits come later, because the system has to be trusted before it takes over real work, and trust is built in stages. A pilot that runs in parallel with the old process saves nothing by design, since people still do the work and also check the machine.
If the business case shows a single payback date, two things tend to happen. Either the date passes with the project still in its learning phase and people conclude it failed, or the team pushes the system into production too early to hit the date, and errors cost more than the savings. Describing the path in three steps avoids both.
What to expect at 3, 6 and 12 months
The timing below is a typical shape, not a rule. A narrow process with clean data can move faster; one that touches several systems moves slower.
Month 3: proof that it works on real cases. You should have a working pilot, a baseline measured before the start, and first data on how often the system finishes a task correctly without help. Financial return is usually negative or close to zero here. If you are asked for savings at this point, be careful: they are almost always estimates. What you can show is quality and effort, for example how many runs needed correction and how long each correction took.
Month 6: first controlled savings. The system handles a defined share of real work, people review a sample rather than everything, and you can compare against the baseline. This is the first point where a cost comparison means something. Expect the review cost to be still visible; it falls as the rules and the instructions improve.
Month 12: stable operation and a decision about scale. By now you have a full year of costs, including usage fees, maintenance, and the changes needed when a connected system or a policy changed. You can say whether the saving is real and repeatable, and whether to extend the system to a second process. Our article on the monthly review of an AI agent describes the routine that gets you there.
Three scenarios
Write all three down before the project starts. They keep the discussion honest, because the weak scenario is on paper from the beginning and nobody has to introduce it later as bad news.
| Cautious | Expected | Weak | |
|---|---|---|---|
| Month 3 | Pilot works on a narrow set of cases; most outputs still checked | Pilot works on the main cases; review of every output continues | Pilot misses the agreed quality; the process needs redesign |
| Month 6 | Small share of work handled; savings smaller than running cost | A clear share of runs finished without help; savings begin to offset cost | No stable improvement; review time is as long as the original work |
| Month 12 | Break-even is close; decision is to continue a little longer | Savings exceed running cost; plan to extend | Stop, or restart with a smaller scope |
Notice that the table says nothing about money in absolute terms. That comes from your own baseline, which is where the arithmetic starts.
A worked example (invented figures)
Suppose a team handles 400 incoming requests a month, and each takes 12 minutes of staff time. At a loaded cost of 30 per hour, the process costs 400 × 12 / 60 × 30 = 2,400 per month. These are example figures only.
Now take the expected scenario. At month 6 the system finishes 50 percent of the requests without help. Each of the other half still takes the full 12 minutes, and a person spends 2 minutes checking a sample of the automatic ones, say all of them for simplicity. Staff time is then 200 × 12 / 60 × 30 = 1,200 for the manual half, plus 200 × 2 / 60 × 30 = 200 for checking, a total of 1,400. The saving is 1,000 per month. If the running cost of the system (usage fees and maintenance) is 600 per month, the net monthly saving is 400.
Now the weak scenario. The system finishes only 20 percent of the requests without help, and the checking takes 5 minutes because outputs are unreliable. Manual staff time is 320 × 12 / 60 × 30 = 1,920, and checking is 80 × 5 / 60 × 30 = 200, a total of 2,120. The gross saving is 280, which does not cover the 600 running cost. The project loses money every month, and no amount of waiting changes that unless the share of automatic runs rises.
The point is not the figures. It is that two quantities decide the result: the share of runs finished without help, and the time spent checking and correcting. Both can be measured from month one.
Early warning signs
Choose a few indicators that move before the money does. These are the ones we would watch first:
- The share of runs finished without help is flat. If it does not rise over two or three months despite improvements to instructions and data, the process may be too varied for this approach.
- Rework per run is not falling. Corrections that stay constant mean that the same mistakes repeat and nobody is feeding them back.
- Checking time is close to doing time. If reviewing the output takes nearly as long as the original task, you have added a step instead of removing one.
- Cost per run is rising. Longer prompts, more tool calls or more retries can raise usage fees faster than volume grows.
- The scope keeps growing. Every month a new case is added to the pilot to make the numbers look better. This hides the lack of progress on the original goal.
- Nobody owns the process. When the team that does the work does not use the output, the saving stays on paper.
- The baseline was never measured. Without it you cannot show any change. If this applies to you, a week of tallies can be set up quickly, even in the middle of a project.
One or two of these signs in a single month are a reason to look closer. Three or more across two months are a reason to talk about stopping.
Agree the decision rules in advance
For each checkpoint, write one sentence about the decision it supports. For example: at month 3, if fewer runs than the agreed minimum finish without help, narrow the scope or stop; at month 6, if net savings are not positive in the expected scenario, adjust the process before adding anything new; at month 12, if net savings are positive and stable for a quarter, extend to the next process. Our article on how to review, expand, adjust or retire a pilot goes through these choices in more detail.
Stopping is a legitimate result. A project that is stopped at month 3 because the indicators were bad has cost three months of effort; one that continues without checks can cost a year. For a wider view of how to measure, how to measure the return on AI investments is a good companion.
What to bring to the next budget meeting
A single page is enough: the baseline cost of the process, the three scenarios with the expected picture at 3, 6 and 12 months, the two or three indicators you will review each month, and the decision rule for each checkpoint. Add a line saying which figures are measured and which are estimates. A CFO who sees that the weak scenario and the stopping rule are already written down will usually trust the plan more than one that shows a single optimistic date.