Sizing an AI investment before you commit to it

A business case that begins with a technology is difficult to defend, because the number at the end was chosen to justify a decision already made. A business case that begins with a measured baseline is harder to argue with, including by the people who would prefer a different answer.

The method below is unremarkable. It is also skipped often enough that skipping it is the single most common reason an AI initiative cannot get funded.

Measure the current path first

Pick the workflow. Then measure what it costs today: elapsed time from arrival to resolution, the number of human touches, the rework rate, and how much of the elapsed time is waiting rather than working.

That last split matters more than it gets credit for. A process taking four hours of which twenty minutes is work has a queueing problem, and automating the twenty minutes will change the four hours very little. Plenty of automation business cases quietly assume otherwise.

Value the change, not the technology

Once the baseline exists, the value of a change is expressible without reference to what delivers it: hours returned to a role and what that role does with them, error rate reduction and what an error costs, throughput increase and whether demand exists for it.

The discipline here is being honest about what happens to the freed capacity. Time returned to a team that then does higher-value work is a real gain. Time returned to a team that absorbs it is a real but smaller gain. Time returned with an assumption of headcount reduction is a different conversation, and it should be had explicitly rather than implied in a spreadsheet.

The hardest number in an automation business case is not the saving. It is what happens to the time.

Cost the whole thing, including the parts nobody quotes

• Build cost, which is the part suppliers quote.
• Integration cost, which depends on what your systems expose and is routinely underestimated.
• Data preparation, which is frequently the largest line and the least anticipated.
• Change and training, because a system people route around has no return at all.
• Ongoing running cost, including model or licence costs that scale with usage.
• Maintenance, because interfaces change and models are replaced.

A case built on build cost alone will look excellent and will not survive its first year.

Decide whether you can size it yourself

Sometimes the picture is clear enough to go straight to a scoped build: one workflow, one system, a well-understood problem and an internal team who can estimate it.

Sometimes it genuinely is not: several systems, an unproven integration, disagreement inside the business about where the cost actually sits, or internal estimates that differ by a factor which makes a decision impossible.

That second situation is what a paid assessment is for. Its value is a decision you can defend, not a document. If an assessment cannot conclude "do not build this", it is a proposal wearing a lab coat and it is worth asking the supplier directly whether that conclusion is available.

Insist the case can fail

A business case that cannot produce a negative result is not an analysis. Before commissioning either an assessment or a build, agree what evidence would mean not proceeding.

That single question changes the quality of what follows, because it forces the measurement to be real. It also makes the eventual approval considerably easier to defend when someone asks how the number was arrived at.

General guidance on sizing technology investment. It is not financial advice, and figures used in any specific engagement are established with the client rather than assumed.