AI Pricing Is Product Strategy

For a long time I treated pricing the way most product people do. Build the thing, get it working, and let the pricing conversation happen somewhere near launch. Which tier, seat add-on or usage meter, what's the number. Price was the last room I decorated before the house went on the market.

The first real correction came when I stopped starting from the feature and started from the value. Before I priced the AI service desk we were building, I worked out what it was actually worth to the customer. MSPs lose somewhere between five and fifteen percent of revenue to work that never gets billed properly. Leaked time, missed entries, hours spent hunting for context instead of resolving tickets. Put a number on it and a single technician is quietly losing on the order of twenty-five thousand dollars a year. The job of the AI was to claw a chunk of that back. So my first model was simple. Estimate the value recovered, then capture a small slice of it. The math worked and the story was clean.

And I don't guess at what a buyer will actually pay. I measure it. The cleanest tool I've found for that is a Van Westendorp study, where you put four deceptively simple questions to real buyers. At what price is this so cheap you'd doubt it works. At what price is it a bargain. At what price does it start to feel expensive but still worth it. At what price is it flatly too expensive, a no. The discipline is to ask all four against a deliberately plain description of the product, worded identically for everyone, so the answers reflect the thing itself and not the story you wrapped around it. Plot the four curves and an honest acceptable price band falls out, the range real buyers will tolerate, before you've talked yourself into a number. I've run this for real on a pricing study, and it does something opinions can't. It tells you where the wall is.

So I had the value and I had the band. But the more I looked at it, the more the metric bothered me.

The default move in AI right now is to price the AI itself. Meter the usage. Charge per action, per resolution, per token burned under the hood. Outcome-based pricing gets called the holy grail and everyone is chasing it. I went the other way, and here's why. If you charge for AI usage, you tax the exact behaviour you are trying to create. The whole point is to get technicians leaning on the AI all day. Charge them more every time they do and you have built a meter that punishes adoption. The bill also swings around month to month, finance hates surprises, and the price has quietly come unhooked from whether the customer got anything out of it. Usage is easy to measure. It is just the wrong thing to measure. And outcome pricing, the supposed holy grail, is rare and flawed in practice, because you can only charge for an outcome you can measure cleanly and the customer trusts. Most teams can do neither yet.

So I asked a different question, and it turned out to be the one that mattered. What is the single number that goes up when the customer is winning with us? Not AI calls. Not tokens. For an MSP it is endpoints. The devices and clients they manage. When the AI makes a technician faster, that technician can carry more endpoints without drowning. The customer takes on more clients with the same headcount, their margins improve, and the value we created shows up as a bigger book of business. Endpoints is the number that grows when the tool is doing its job.

This only works because of where the AI sits. It is not a button bolted next to the workflow. It is in the workflow. The plan a technician acts on, the order things happen in, the context that surfaces at each step, that is the AI's output. Pull it out and you haven't removed a feature, you've removed the spine of how the work gets done. That enmeshment is what makes it impossible to rip out. It is also what makes the whole thing compound.

Here is the loop I kept drawing on the whiteboard. Enmeshed AI makes each technician more efficient. More efficiency lets the MSP run more endpoints with the same team. More endpoints means more tickets and more workflows moving through the system, which is more signal for the AI: more context, more examples of what a good resolution looks like, more to learn from. The AI gets sharper and takes on more of the work, which makes each technician more efficient still, which pulls in more endpoints. More endpoints, more workflows, more AI, better AI, more endpoints. The wheel turns on its own once it is spinning. And because the AI is baked into the per-endpoint price, every turn of that wheel is revenue, healthy revenue, tied to the customer growing rather than to the customer consuming. A usage meter would have done the opposite, sitting there as a tax the customer tries to shrink.

People assume the margin on something like this gets squeezed over time. I think the opposite, and the flywheel is why. As more workflows run through the system, the AI gets better at the same job, so the value created per endpoint keeps rising while the cost to serve it stays flat. The cost of running a given level of AI capability has also been falling fast, which helps, but I wouldn't build a pricing model on a bet about where vendor prices go. The durable reason the gap widens is that the system learns. What an endpoint is worth keeps climbing; what it costs to run does not. That spread is the part you can count on.

The hardest part was never the math. It was getting the room to stop asking "what do we charge for the AI feature" and start asking "what is the unit that grows when our customer succeeds, and how do we make AI the engine of that growth." Once the team saw AI as the thing that expands the endpoint base instead of a feature to meter, the argument was basically over. Nobody wants to ship a meter that fights their own product.

This is really just value-based pricing taken seriously. The standard advice is to design the product around the price and capture a share of the value you create, not the cost you incur. Most of the AI crowd reads that as "meter the outcome." I read it as something else. Find the unit that expands when the customer captures value, put the AI inside the workflow so it drives that expansion, and price the unit. Usage and outcomes are metrics. The growth unit is the strategy.

So here's the test I keep coming back to. Find the one number that goes up when your customer is winning, and ask whether your price is attached to it. Then ask whether your AI is wired into the work that moves that number, or just sitting beside it. If you are metering usage off to the side, you are attached to consumption, and you will spend your life explaining the bill. If the AI is in the workflow and you are priced on the thing that grows when it works, the AI sells itself, and the revenue takes care of itself.