A problem without a price is an opinion

Every AI build I get called into has a business case attached, and most of them fall apart in the first ten minutes. Not because the technology is wrong. Because somebody wrote a number down that nobody can source, and the whole case is standing on it.

There is one test that sorts this out, and it takes about four seconds to apply. Can you point at the invoice, the contract, or the payroll line? If yes, it is a hard cost, and finance will accept it without argument. If no, it is modelled. It might still be real. It might even be the biggest number on the page. But it is modelled, and the moment you pretend otherwise you have lost the room.

I have watched teams fail this test in the most understandable way. Somebody calculates that the company leaks four hundred thousand dollars a year through pricing errors, or missed terms, or rework. It is a good number, honestly derived from a real report. And then it goes into the hard-cost column, because it feels solid, and because putting it there makes the payback look twice as good. That is not fraud. It is optimism with a spreadsheet. But the CFO will find it, and when they do, every other number on the page becomes suspect, including the ones that were right.

So we split the page in two, and we gather the cash column first. Software and licences this build would replace or duplicate. Contractors, agencies, temps, outsourced processing. Overtime paid to get through month-end. Error cost that actually left the building as credits, refunds, write-offs, penalties, expedite fees. Whatever the last audit remediation cost. Infrastructure and data. Six categories, each traceable to a document with a date on it. That column is usually smaller than people expect, and it is the floor the entire argument stands on.

The second column is the modelled one, and it is honest as long as it is labelled. Labour time, which is one line of arithmetic done out loud: how many, how often, how long each, at what fully loaded hourly rate. Foregone margin or revenue, from whichever report shows the leak today. What one day of delay costs. What it costs when somebody acts on a stale number. Risk exposure, stated as probability times impact rather than a single confident figure. Every one of those is real. Not one of them is cash, and the document says so on the page where it appears.

Two things go wrong in that second column almost every time, and they go wrong in opposite directions.

The first is that everybody describes the version of their job where things go right. Ask how long a task takes and you get the happy path. The exception path, the rework, the chasing, the one in five that comes back, is typically a fifth to a third of the real workload and it never volunteers itself. So you ask for it separately, as its own question, after the normal volume is settled. It is the single largest correction most teams make to their own baseline, and I have never run a session where it did not move the number.

The second is the opposite failure: modelling something that should have been left out. Deals lost to slow turnaround is the classic. Sales believes it is happening. It probably is. Nobody can source it, and if you model it, it becomes the largest line on the page and the entire return now depends on the figure least able to survive a challenge. So write it down as an open item, with a name and a date against it, state in writing that it is excluded from the business case, and move on. Excluding it makes the payback longer. It also makes the argument nearly impossible to attack, and I will take that trade every time.

That is the part most people find counterintuitive. A weaker-looking number, honestly sourced, beats a stronger one that cannot be defended. When the case rests on lines a CFO can verify, the conversation moves from whether to believe you to whether to fund it. That is a completely different meeting.

There is a discipline underneath all of this that has nothing to do with AI. Before you can improve a process, somebody has to be able to say what it costs today, in a form another person can check. Most organisations cannot. The work happens, the money goes out, and no one line item anywhere says what this particular piece of it costs. That is not an accounting failure. It is a systems failure, and it is why the same argument gets relitigated every budget cycle with different numbers.

The baseline is worth building for its own sake, before anyone approves anything. It ends the argument about whether the problem is real. It gives you the denominator for every claim that follows. And when the build ships, it is the only thing that lets you prove the return arrived, because you can go back to the same lines and measure them again.

Build it once and build it honestly. If the baseline is soft, everything downstream is soft, and no amount of technology fixes that. Define it. Measure it. Own it. A problem without a price is an opinion, and opinions do not get funded twice.