Author
TL;DR Pricing per resolution moves the charge from the attempt to the success, which changes the licensing model before it changes the price. Every rate card fixes the resolution rate; the vendor’s roadmap exists to move it, and as it rises the per-resolution bill climbs toward the per-attempt bill. The price has to be designed for that trajectory, for the attempts that never bill, and for a counter that reads absences.
The SERP for pricing per resolution is a wall of rate cards. Published figures, per-unit comparisons at stated volumes, break-even tables. Every page-one entry fixes two variables and solves for a third.
None of them treat the success rate as a variable. That omission is the argument this article makes.
- Per Resolution Changes the Licensing Model Before It Changes the Price
- The Dated Record: How the Per-Resolution Unit Shipped
- The Convergence Problem the Comparison Math Cannot See
- What the Resolution Counter Counts
- Who Pays for the Attempts That Never Resolve
- The Questions to Settle Before You Move the Meter
- FAQs
Per Resolution Changes the Licensing Model Before It Changes the Price
What Changes When the Meter Moves from Attempt to Success
Moving the charge from the attempt to the success changes what the meter counts. That is a licensing-model decision. The pricing model wraps it afterward.
Consumption meters attempts. Resolution meters successes. The distance between the two is execution risk the vendor agreed to carry.
Resolution-based pricing is the operational-outcome sub-family inside outcome-based pricing. Trade press uses the two terms interchangeably. Resolution sits at the operational end of the family, where the measurable event is a workflow closure inside the vendor’s own system rather than a revenue event at the customer’s.
What Is the Difference Between Per-Resolution and Per-Conversation Pricing?
Per-conversation attaches a charge to every interaction, regardless of outcome. Per-resolution attaches a charge only to interactions the system closes on its own. One bills attempts. The other bills successes.
The operational difference is who absorbs the cost of the failures. Under per-conversation, the customer pays for every attempt. Under per-resolution, the customer pays only for the ones that close. The vendor absorbs the rest. That asymmetry is the structural fact that rate comparisons at a fixed volume cannot capture, because the failure volume is not fixed.
Atlassian’s credits and HubSpot’s resolutions are the two opposite bets on the licensing axis, side by side in the market; AI software pricing covers the architecture beneath both.
Why Pricing Per Resolution Is Not a Pricing Model Change
The pricing model is the rulebook that turns a measured quantity into a net price: unit list price, volume breaks, discount rules, renewal mechanics. Flat fee, usage-based and hybrid are names for how the metric is licensed, and they belong one layer up, in the licensing model.
The metric is the quantity. The licensing model is where the metric lives.
Per-resolution moved the value metric from an attempt count to a success count. The pricing model that wraps it can be any number of shapes: a flat fee per resolved case, a rate per resolution against a committed volume, a hybrid with a platform fee.
In our corpus the swap surfaces at an upgrade, never at a plain renewal. The unit of measure is written into the license agreement, so nobody arrives at a renewal to find resolutions where seats used to be.
The surprise comes when the customer takes the new model on an upgrade. The price lands well above what the old unit produced, because the new metric usually carries stronger growth dynamics than the one it replaced. The buyer had priced it as a rate change when it was a licensing change.
The Dated Record: How the Per-Resolution Unit Shipped
The per-resolution unit has a documented arc, and the sequence carries more information than any single rate. A rate is a number on a date. The sequence is a record of what the market learned about the unit’s edges.
Rates and dates render in the table above, re-verified on a rolling basis. Source: SPP Pricing Observatory.
The arc in the table follows a recognizable shape. A clean, countable unit ships first. Competing definitions follow once the event boundary proves messier than it looked, and a verification layer lands on top to manage disputes at that boundary. Then the unit widens, or a flat fee per case replaces the per-unit rate. In at least one case, the vendor’s own pricing page argues against the unit it is charging.
When a vendor’s pricing page steers buyers toward a different model than the one on its rate card, the vendor has revealed where the unit’s edges cause problems. The rows beside that case show the same edge worked from both sides: one vendor widening the unit from resolution to outcome, another narrowing which resolutions count to the ones a second model confirms. Published rate ranges across vendors are a spread across different definitions of the same word.
Is Your Per-Resolution Rate a Bet You’ve Actually Examined?
The sequence behind a per-resolution unit reveals whether your licensing, packaging, and pricing decisions were deliberate or inherited. Find out which decisions in that sequence need to be revisited first.
The Convergence Problem the Comparison Math Cannot See
Why Product Improvement Raises the Customer’s Bill
Every rate comparison on page one fixes the success rate and varies the unit price. The success rate is the one input that does not hold still, because improving it is the product roadmap.
As the share of work the system closes end to end rises, the per-success bill climbs toward the per-attempt bill for the same volume. The customer’s spend rises without their volume rising. The vendor either moves the unit price down as the rate moves up, or renegotiates that point every renewal.
Every multi-year projection of per-resolution revenue rests on an assumed success-rate curve, and the projections in circulation leave that curve unstated. Read the curve before the revenue line, because the revenue line is the curve in a different unit.
What a Per-Resolution Price Is a Bet On
Per resolution is the one common metric where the vendor’s own product success raises the customer’s bill unless the price moves with it.
The vendor bets that improving its resolution rate will produce enough customer value to justify a renegotiated price. The customer bets that the rate holds or that the renewal conversation will go well.
What Moves When the Resolution Rate Moves
The per-attempt bill and the per-resolution bill converge as the success rate rises. At a high resolution rate the customer pays the same total they would have paid per attempt, while the vendor’s cost per success has fallen because the system is more accurate. That is the renewal-moment asymmetry, and it does not appear in any comparison that fixes the rate.
The renewal shape we see most often is a mix argument. As resolution counts grow, every customer has resolved a blend of high-value and low-value cases. Once the bill rises, the customer argues that the low-value resolutions should carry a lower rate, or none.
Volume discounting carries more of the design than it does under most metrics, because it is the instrument that handles that mix. A per-resolution price with no volume breaks charges the same for the resolution that saved a contract and the one that closed a password reset, and the customer notices the second kind first.
The failure shape we see is cleaving. The customer routes the low-value resolutions to another tool or a manual workflow and keeps the high-value ones on the meter. The vendor’s volume falls while its cost per success rises. Volume breaks that step down as resolution counts climb keep the low-value work on the meter at a rate the customer will tolerate. The mix stays whole, and the argument at renewal is about the schedule rather than about which resolutions count.
What the Resolution Counter Counts
What the Counter Can See
A resolution is typically defined by an absence. No human touched it. No escalation fired. No negative rating landed. The counter records that none of those events happened.
That is measurable, and it is also a proxy. The resolution counter records the vendor’s non-intervention. The buyer’s underlying question was answered, or it was not, and the counter does not know; it knows that no one escalated.
The absence definition holds across the vendors in the ledger; the vendor-specific read belongs to Agentforce pricing.
Where the Escalation Boundary Sits
The escalation carve-out is standard: no charge when a human finishes the work. A resolution is an AI closure, so a human closure does not trigger the meter.
The boundary is where the disputes concentrate. An interaction that required three human touches before the system closed it, or one the system closed after a human clarified the question, sits at an edge the contract language has to reach. The absence definition does not resolve these cases. It records that the final state had no open escalation.
Outcome-contingent contracts improve supplier reliability and introduce a distortion in the process: the supplier optimizes the measured quantity. A meter that counts closures without escalation pays for closures without escalation. The resolution counter makes the event easier to measure; it does not verify the underlying outcome.
Peer-reviewed work on expert-service markets, where the buyer cannot verify quality on their own, finds that tying the seller’s charge to the result changes seller behavior substantially. The research measures the size of that change. What we observe is where it lands: on whatever definition the meter can read, which is rarely the buyer’s underlying goal. The definitional edge is where the pressure sits.
The counter has two blind spots of its own. A satisfied customer and a deflected-but-frustrated one bill the same, because the metric cannot tell containment from resolution. And a session holding three problems closed as one resolution understates the value delivered, while one problem reopened three times overstates the cost; the metric has no denominator for issue complexity.
Who Pays for the Attempts That Never Resolve
Every attempt consumes inference. Only the successes bill.
The vendor absorbs the cost of the failures. Revenue is bounded by the customer’s outcome volume. Cost is bounded by the customer’s attempt volume. Those two boundaries are not the same, and the gap between them is where the vendor’s margin on the unit lives.
The per-resolution rate the customer sees is the bill for the successes; it says nothing about the inference cost of the failures. The rate is a bet on a margin target that depends on a success rate the vendor is simultaneously trying to improve.
When the agent is wrong covers who absorbs the cost of a failed run in operational terms, with the pass-through-or-recast decision on supplier cost underneath it. Both apply before a per-resolution negotiation, because the failure cost does not disappear: it transfers.
Absorbing failed attempts predates AI. An optimization run that came back without an answer still consumed the run. What a per-resolution unit monetizes is the distribution of usage across the customer base, and that is a portfolio play. Each customer has its own distribution of success and failure, and the portfolio in aggregate has one too.
The misreading we see in software companies is that the failures have to be eaten. The dollars are collected elsewhere, in other components of the pricing approach, and the design question is which components carry them.
Two distributions move under this design at once. The mix of customers changes as the base grows and churns. The mix of successes and failures inside each customer changes as the model improves and the use cases shift. A price set once, against one snapshot of both, drifts from the day it ships. That is the case for continuous monetization in its plainest form: the components that carry the failures need re-reading on a cadence, because the thing they were sized against keeps moving.
The Questions to Settle Before You Move the Meter
Four questions your rate has to answer before it ships. Your counter carries an answer to each one whether you wrote it down or not.
The counterfactual question. Would your counter have fired if the result had arrived without the software? A meter that bills on outcomes the customer would have reached anyway is a billing error, and it surfaces at renewal as a dispute about the definition. Your rate holds only for the work the system caused.
The absence question. Is your resolution defined by an event that happened or by events that failed to happen? A counter built on absence records that no human touched the case and no escalation fired, and your customer reads that record differently from you when the issue recurs. Both of you are reading the same contract correctly. Where the definition lands is a design decision, and your rate has to survive it.
The escalation-boundary question. Where does your counter stop once a human touches the case? An interaction closed after three human touches, or after a human clarified the question, sits at an edge the absence definition cannot read. Your contract language has to reach that edge before the first invoice does, because the disputes concentrate there.
The complexity-denominator question. Can your counter tell a session holding three problems from a session holding one? A counter with no denominator for issue complexity understates the value in the first and overstates the cost of a problem reopened three times. Your rate is a bet that the mix averages out across the base, and your customer reads the bill one account at a time.
These are the questions a rate card cannot answer. Designing outcome-based pricing covers the design decisions underneath each of them.
If you are designing a per-resolution unit and want a structural read on how your rate holds as the resolution rate moves, pressure-test it with a pricing expert.
