The AI ROI Framework: How to Calculate Real Business Value Before You Build

Most AI projects are justified with a feeling. It will save time. It will make us more efficient. It will keep us competitive. Those are not reasons, they are hopes. Before you write a single line of code you should be able to put a number on the outcome, and the good news is that the maths is simpler than people make it.

Here is the framework we use to size the value of an AI project before building it.

Start with one task and one unit

Do not try to value "AI for the business." Value one task, and pick the unit it is measured in. A unit might be one support ticket, one invoice processed, one lead qualified, one report drafted. Everything else hangs off that single unit, so choose a task you do often and can count.

Work out the current cost per unit

For one unit, what does it cost you today. Usually that is time multiplied by a loaded hourly rate, but do not stop there. Add the cost of the mistakes that happen at the current quality level, and the cost of the things you cannot do because this work is eating the hours. If a person spends twelve minutes per invoice and you process a few thousand a month, you already have a real number worth caring about.

Be honest about the cost after AI

This is where business cases go wrong. The cost after AI is not zero. There is the running cost of the system, the time a human still spends reviewing output, and the exceptions the model cannot handle that get kicked back to a person. A realistic estimate might be that AI handles eighty percent of cases cleanly, a human reviews everything briefly, and twenty percent still need real attention. Model that, not a fantasy of full automation.

Do the multiplication

Now it is arithmetic. Saving per unit, which is the old cost minus the new cost, multiplied by your volume, gives the gross saving. Subtract the one-off cost to build and the ongoing cost to run. What remains is the real value, and dividing the build cost by the monthly saving gives you a payback period. A project that pays for itself in three months is a very different decision from one that takes two years.

The point is the decision, not the spreadsheet

You will not get these numbers exactly right, and that is fine. The purpose of the exercise is not a precise forecast. It is to turn a vague hope into a decision you can defend, and to give the build a target to aim at. If the honest maths does not work you have just saved yourself a failed project. If it works comfortably even on conservative assumptions, you can move with confidence.

Three things that quietly break the maths

First, time saved that you cannot redeploy. If a tool saves each person twenty minutes a day but that time just evaporates, you have not saved money, you have added slack. Saving only counts if you can do something with it.

Second, ignoring the exception tail. The last twenty percent of hard cases often costs more than the easy eighty percent. Cost it properly.

Third, mixing one-off and recurring. A build cost is paid once. A saving recurs every month. Keep them in separate columns or the numbers will mislead you.

Run this before you build, not after. It takes an afternoon, it costs nothing, and it is the difference between an AI project that earns its place and one that just looked impressive in a meeting.

If you want a second set of eyes on the numbers before you commit, that is a good use of a first call. Book a strategy call and bring the task you have in mind.