Outcome Pricing as a Process Question

What Counts as Resolved?

On 25 June, a major platform vendor announced a prebuilt service agent billed on a new principle: per resolution. You pay only when the agent actually resolves an issue — not per conversation, not per action, not per license. After years of debate over unpredictable AI costs, this sounds like the long-awaited commercial simplification: no paying for idle capacity, a price tied to the outcome, a budget you can finally plan.

The promise is real. But it carries a precondition that appears on no invoice.

The question the model asks — and that no one has prepared for

If you pay per resolved case, you have to define beforehand what “resolved” even means. That sounds trivial. In the B2B service operation of an industrial company, it is not.

Some cases are cleanly binary: Where is my delivery? Which spare part fits this machine number? When is the appointment? Here there is a clear, verifiable answer — the case is resolved or it isn’t. For these processes, the model fits without friction.

The larger share of industrial after-sales looks different. A technical fault diagnosis runs across several stages. A configuration question depends on conditions that only surface mid-conversation. A complaint is often settled only after several open points have been clarified. What does “resolved” mean when the agent delivers a partial answer and then hands off to a human? When the question is answered but the problem isn’t fixed? When the customer hangs up satisfied while the ticket remains technically open?

These are not billing details. They are process decisions — and many service organizations have never made them explicitly, because they never had to. A human employee knows the grey zones from experience. A billing-relevant “resolved” demands a definition that is fixed in advance, consistent, and verifiable in case of dispute.

The pricing model forces a clarity the process never needed before

This is where the real effect of the announcement lies — and it is bigger than the price question. Outcome-based pricing turns the resolution definition into a hard design criterion. You can run a service process loosely as long as people carry it. The moment billing hangs on the outcome, the looseness becomes visible — and either costly or contested.

For B2B industrial companies, this means the introduction of such an agent is not a procurement exercise that ends in purchasing. It begins on the business side with a process question that precedes any licensing decision. Which of our service processes have a clear, verifiable “resolved” definition — and which live on human judgment? Where does the model create fair value, and where does it pre-program systematic disputes over billing?

And one point easily lost in the commercial enthusiasm: whoever sells the outcome shapes the definition of the outcome. This is not an accusation against any single vendor but a structural property of every outcome-based model — what counts as “resolved,” which time or session limits apply, how things are counted, rests with whoever sets the model. The right response is not mistrust but definitional ownership. A company that defines its own resolution logic out of its process negotiates from a different position than one that adopts the tool’s default definition.

What decision-makers should do now

Outcome-based pricing is a welcome development. It ties cost to value — commercially cleaner than any model before it. But it is only as good as the process clarity behind it. The value does not come from the pricing model. It comes from the precision with which a company understands its own service processes.

Before the first invoice arrives, an uncomfortable inventory is worth the effort: do we really know what “resolved” means in our service — process by process? Answer that question before go-live, and you use the model. Answer it afterward, and you pay tuition.

The technology is ready. The real work, as so often, lies in the process beforehand.