AI ROI: why one point of win rate beats every hour you save

Ask a company where AI should start and you usually get the same answer. Find the most tedious job in the building and automate it. It sounds responsible. It is also how AI programmes end up with a healthy adoption rate and a business case nobody believes.

We start that conversation with a value model, before any process mapping. It is simple arithmetic on a whiteboard, and it keeps producing the same uncomfortable result. The task that is easiest to automate is rarely the task worth automating first. Put the two cases below side by side and one percentage point of win rate beats automating the most obvious manual job by an order of magnitude.

Both of them went up on the whiteboard in a workshop in September 2026. The numbers below are from that session. Both cases are anonymized, and nothing here says they sit in the same company.

The first is a clerk who retypes around 1,600 numbers a day from paper into the ERP. The work is dull, it is error prone, and everybody in the room can picture it. A model reads the paper, writes to the ERP, done. This is the automation people reach for first.

The second is the inquiry queue at a manufacturing company. An incoming inquiry waits around two weeks for an answer today, and only part of the queue gets one at all. With agents reading, classifying and drafting the response, the answer comes in minutes, and the whole queue gets handled.

Both are real. Only one of them changes the shape of a business.

Score the first one honestly. The clerk's day is worth a clerk's day. Automate all of it and you free up part of a job. You can count it, you can defend it in a budget meeting, and the number will be small.

Now score the second one. That company's inquiry win rate sits under 5 %. Lift it to 6 %. That single percentage point is worth tens of millions of crowns.

That is an order of magnitude more than every hour the retyping automation frees. Not twice as much. An order of magnitude.

Nothing about the second project is harder in a technical sense. Reading an inquiry, classifying it and drafting a quote is well inside what agents do today. It is harder in an organisational sense, because it touches sales, pricing and the people who own the customer relationship. That is the whole reason it gets skipped.

Hours saved is an easy number to produce. You can measure it before you build anything, you can attribute it to one department, and nobody has to agree to change how they work.

Win rate is the opposite. It is a number several teams share, it moves for reasons other than your project, and improving it means somebody's process changes. So the business case that gets written is the one that is easy to write, not the one that is worth the most.

There is a second effect, and it is the expensive one. Once the first AI project is a back office efficiency project, the next one is judged against it. The programme gets filed under cost reduction. Budget follows the file.

The hours framing also sets up a comparison the programme cannot win. Freed capacity only becomes money if somebody redeploys the people, and that decision sits with a manager who did not ask for the automation. So the saving stays theoretical, the finance team discounts it, and the next business case starts from a worse position than the first one did. A rate that moves does not have this problem. Nobody has to act on it afterwards for the money to appear.

We wrote about the reasons AI fails to stick in organisations that did everything else right. Picking the wrong first process is upstream of most of them.

The split we use on the whiteboard is blunt on purpose.

A minus activity costs the company money and produces nothing a customer would pay for. Retyping numbers is a minus activity. So is reconciling two systems that should have been one system. Automating a minus activity takes a cost to zero. The ceiling is the cost itself.

A plus activity earns money. Answering an inquiry well and fast earns money. Keeping a customer earns money. Automating a plus activity does not have a ceiling in the same way, because you are not removing a cost, you are moving a rate.

| | Minus activity | Plus activity | |---|---|---| | Example | A clerk retypes ~1,600 numbers a day into the ERP | An inquiry gets a quoted answer in minutes instead of ~2 weeks | | What AI changes | The cost of doing it | The rate at which the business wins | | Upper bound of the value | The salary cost you remove | No fixed ceiling; it scales with volume and margin | | Why it gets picked | Easy to measure, nobody else has to change | Harder to attribute, crosses team boundaries |

Most AI roadmaps we see are a list of minus activities. That is not a technology problem. It is a sequencing problem, and it is fixable in an afternoon with the right people in the room.

It does not mean the retyping should stay. It means it is not the project you fund first, and it is not the project you build the business case on.

It also does not mean you should promise a point of win rate. We have not delivered a measured plus one point to anyone. This is a model, worked out on a whiteboard in a workshop. The numbers get real after process mapping, not before.

What it does mean is that the first question in an AI business case is not "what is slow here". It is "which process, if it got meaningfully better, would show up in the result".

You need three things, and none of them is a tool.

First, the list of processes that touch revenue. Not the list of processes that annoy people. They overlap less than you would expect.

Second, the current rate on each of them, however rough. Inquiry win rate, churn, time to quote, order accuracy. If nobody knows the number, that is itself the finding.

Third, an honest estimate of what a better rate is worth at your volume and margin. One percentage point, no heroics. If that number is smaller than the salary cost of the nearest minus activity, automate the minus activity and feel good about it. In the inquiry case above, it was not even close.

The usual objection at this point is that the rate cannot be measured cleanly. It moves with the market, with pricing, with who happens to be on the sales team that quarter. That is true, and it is not a reason to go back to counting hours. Pick a narrow slice where the attribution is defensible, a single product line or a single channel, and run the comparison there. A rough number on the metric that matters beats a precise number on the metric that does not.

Then sequence the work so the first delivery proves the model on a plus activity, even a narrow one. Measuring that properly is its own discipline, and we have written about how we measure AI developer impact when the output is code rather than quotes. The principle transfers: pick the metric the business already cares about, baseline it before you start, and accept the number you get.

The same logic is why the ROI of developer experience reads the way it does. Faster developers are not the point. What the faster developers ship is the point.

Our AI platform work starts with exactly this conversation. The AI adoption across product, HR, marketing and back office case study shows the other end of it, where non-technical teams pick up the tools themselves.

Pick the process that earns money. The hours will still be there next quarter.