You are trying to buy AI the same way you bought software

You are trying to buy AI the same way you bought software. That is why the numbers do not add up.

The software model you know has a clear shape. You evaluate vendors. You negotiate a price per user per month. You model adoption over twelve months. Finance runs the cost-benefit analysis. Someone signs. Someone implements. Six months later, someone measures whether it worked.

The model is slow but it is legible. The numbers are specific enough to defend in a board presentation. If it does not work, you cancel the contract and explain what you learned.

AI does not fit that model. And the mismatch between the frame and the reality is one of the main reasons so many AI conversations stall at the evaluation stage. The CEO is not being slow or cautious. The CEO is applying a rational procurement process to something the procurement process was not built to handle.

Here is what is actually happening on the pricing side.

The vendors selling AI tools charge by token. A token is a unit of computation: roughly, how much the model processed to produce a response. More complex tasks, more tokens. Longer documents, more tokens. More users asking more questions, more tokens. The vendor stacks a margin on top of the underlying model cost and gives you an estimate.

The estimate is nearly useless until you know exactly what you are going to use the system for and how much.

Which you do not, because you have not deployed it yet.

This is the circle most companies get trapped in. You cannot know what you will spend until you know how you will use it. You cannot know how you will use it until you have built something and watched real people work with it. You cannot justify building something without knowing what you will spend. Finance needs a number. The number requires a deployment that does not exist yet.

Most procurement processes stop here. The project gets labeled under evaluation and stays there.

There is another version of this problem that is less obvious. Even when the CEO is comfortable with the uncertainty on the spend side, the question of what to measure is genuinely hard.

The traditional software ROI calculation is built on substitution. This tool does what this person was doing, at this cost, so here is the net. Clean model. You can build a spreadsheet around it.

AI does not always substitute cleanly. Sometimes it compresses a task that used to take three hours into twenty minutes. The three hours do not disappear from the payroll. They become available for something else. That something else is where the value lives, but it is also where the measurement gets complicated.

What did your analyst do with the two hours and forty minutes she got back? If you cannot answer that, the ROI of the tool is real but invisible. And invisible ROI does not survive a CFO conversation.

The companies that are making this work changed the frame before starting the procurement conversation.

The question that unlocks the calculation is not what does this tool cost per user per month. It is: what is the work we are trying to move, what does that work cost today, and what becomes possible if it moves?

That sounds like a simple reframe. It requires a different kind of work upfront.

It requires actually mapping a process. Following the work from start to finish. Counting the people who touch it, the time it takes, the errors that happen, the decisions that have to escalate because no one built a system to handle them. Most companies have never done this mapping in a way that is precise enough to be useful. The process exists. It runs. But if you asked anyone to draw it from end to end, including the exceptions, the edge cases, and the informal dependencies, the map would take days to produce and still be incomplete.

That mapping work is unglamorous. It is the part that happens before any vendor conversation. It is also the part that makes every vendor conversation dramatically more useful, because you arrive knowing what you actually need rather than asking a vendor to tell you what you need based on what they sell.

Once you have the map, the pricing conversation changes.

You are not approving a software budget. You are approving a specific operational transformation with a concrete baseline. The process costs X today in time, errors, and opportunity cost. After the change, it costs Y. The difference is the value. The implementation cost needs to sit inside that margin.

That is a number finance can work with. It is also a number that holds up when the project is complete, because you can measure against the baseline rather than against a projection someone built before the work started.

The vendors who want to sell you a platform before you know what you need are not trying to mislead you. They just have a product to sell and they cannot do your mapping work for you. That is not their business model.

The companies that have made real progress on AI in the last eighteen months did not start with a vendor conversation. They started by understanding what work they wanted to move and why. They found the process that was creating the most friction, or costing the most time, or creating the most dependency on a single person or team. They built something real around that process. They measured it. Then they moved to the next one.

That approach is slower to initiate and faster to generate real results.

The alternative is the evaluation loop. The committee that studies options for six months and recommends further study. The pilot that runs in a sandbox and never touches production. The board presentation that gets revised every quarter because the numbers keep changing.

The reason the loop is so common is that the frame is wrong from the start. When you try to buy AI like software, you get stuck in a software procurement cycle applied to something that is not software. The cycle produces analysis. Not results.

The way out of the loop is to start with the operational question, not the vendor question.

What work, specifically, do you want to move? What does that work cost today? What do you do with the capacity when it moves?

Answer those first. The vendor conversation gets a lot shorter after.