Resolution-based pricing

What is resolution-based pricing?

Resolution-based pricing is a commercial model in which a customer support vendor charges for each issue its system resolves, and in its pure form charges nothing for the attempts that fail. The billable unit is a completed outcome: a customer question answered or a task finished without a human picking it up.

The model spread as AI support agents began closing tickets end to end. A seat license prices capacity, and capacity stopped being the constraint once software could handle thousands of concurrent conversations. Contracts that once counted logins now count closures.

How resolution-based pricing works

A workable resolution-based contract has five parts: a definition, a detection method, an attribution window, an exclusion list, and a reconciliation process. Read in that order, they explain most invoice disputes.

The definition states what a resolution is, usually a conversation the AI agent carried to closure with no human transfer and no reopen inside an agreed window. Detection is the instrumentation that proves it happened, drawn from ticket status changes, transfer events, and reopen flags in the help desk. Aggregated over a month, those same events supply the numerator of the resolution rate operations teams already report, though that rate also needs a total-inquiry denominator the billing meter never sees.

The attribution window decides the edge cases: a ticket reopened inside it is credited back, and one reopened after it stands. Because a billable event requires that the issue stay closed, the counting logic sits closer to first contact resolution than to ticket volume, while average resolution time remains a quality signal that never touches the invoice.

What counts as a resolution, and what does not

• Contained conversations: The agent answered the question or completed the task, the conversation closed with no human transfer, and the issue did not return inside the attribution window. Silence alone is not evidence of a resolution, which is why stronger contracts pair this test with a survey or a sampled review.

• Actioned requests: The agent changed something in a system of record, such as issuing a refund or updating an address, usually billable even with a short reply.

• Escalated handoffs: A conversation transferred to a human, whether by customer request or by a confidence threshold, which almost always sits outside the meter.

• Reopened tickets: A closed issue that returns inside the attribution window, credited back on the next invoice when the contract is written honestly.

• Non-issues: Spam, duplicate submissions, internal test traffic, and abandoned sessions, all of which a standing exclusion rule should remove before billing.

Resolution-based pricing vs per-seat vs per-conversation pricing

Buyers compare these models on unit price, which hides the fact that each one bills a different event. Per-seat pricing charges for licensed capacity, whether or not that capacity is used. Per-conversation pricing charges for every session opened, including the ones that end in frustration. Deflection-based pricing charges for contacts that never reached a human, including the ones where the customer simply gave up. Resolution-based pricing charges only when the issue is closed and stays closed, which moves delivery risk onto the vendor and makes the contract's definition of "closed" the most valuable sentence in the document.

If you can instrument closures and reopens in your own help desk, and you want the vendor carrying delivery risk, the resolution meter is the right one. If volume is flat and contact reasons are stable, a fixed fee is easier to forecast and cheaper to administer.

Why resolution-based pricing matters for customer experience

Pricing shapes behavior on both sides of a contract. When a vendor is paid per conversation, nothing in the commercial model punishes an agent that answers vaguely and lets the customer try again, because the second attempt is revenue. Paying per resolution moves that cost onto the vendor.

The contrast with capacity pricing is what buyers notice. A seat count says nothing about how many customers left satisfied, so leaders on seat contracts prove value from numbers their contract does not measure. A human contact carries queue time, handling time, and after-call work, so a contact genuinely resolved without one carries real savings, while a contact merely avoided may only be deferred, which is why the gap between deflection and resolution rates gets argued over so hard.

The tradeoff is direct: a vendor paid for closures has an incentive to close, and an agent that ends ambiguous conversations early books revenue while quietly damaging satisfaction.

How is resolution-based pricing measured?

No standards body sets a price per resolution a buyer is expected to hit, and no neutral registry defines what a resolution is, so any figure offered as an industry average needs its definition and its denominator attached before it means anything.

What you can measure is the meter itself, in three passes. Count first: pull closure, transfer, and reopen events from your own help desk and reconcile them against the vendor's billed list every cycle. Sample second: draw a random set of billed conversations each month and have a reviewer judge whether the customer's problem was genuinely solved. Rate consistently third, because judgment work needs a written protocol, a fixed scale, and more than one independent reviewer. Raw agreement between reviewers overstates reliability when they can guess alike, which is why chance-corrected measures of interrater agreement exist.

The output is a billable-accuracy figure of your own: the share of billed resolutions your reviewers agree were resolutions, reported with the agreement level behind it. That figure belongs in the dispute clause.

How AI agents change resolution-based pricing

What changes is the evidence. When a human closes a ticket, the proof that the issue was solved is a status field someone set by hand. When an AI agent closes one, the transcript, the tool calls, the record it updated, and the reopen history all exist as machine-readable events, and an outcome that can be observed independently is an outcome that can be billed for.

That changes the shape of a vendor roadmap. A vendor paid per resolution has reason to expand into the intents it currently escalates, because every unbilled ticket type is unearned revenue, and the same meter argues for confidence thresholds, since a case damaged by an over-eager agent is a reopen nobody gets paid for. Buyers who understand the incentive negotiate coverage targets contact reason by contact reason. The economics of per-resolution versus per-seat pricing shift again once the agent takes actions inside other systems, since each action is another observable outcome.

What to look for in a resolution-based pricing agreement

Coverage comes first: which contact reasons the vendor commits to handling, and what happens to the ones it declines. Integration surface decides whether both parties see the same events, so require that closure, transfer, and reopen data flow to your systems as well. Governance is the clause buyers skip: who may change the resolution definition mid-term, how long the dispute window runs, and whether you receive a line-item export of every billed conversation.

Security is the gate for regulated teams, where SOC 2 Type II, ISO 27001, ISO 42001, HIPAA with a signed BAA, and GDPR obligations all apply to the transcripts the meter is built on. The operational constraint is forecasting, since a variable meter makes budgets move with demand.

Resolution-based pricing and support quality programs

A billing meter built on outcomes only works if someone inspects the outcomes. That is the job of customer service quality assurance, whose scorecards can be pointed at billed AI conversations exactly as they are pointed at human ones, which turns a sampling program into a billing control.

The second connection is contractual. A service level agreement committing to response and resolution times sits naturally beside a resolution meter, because the same closure events that trigger a service credit also determine what the vendor may invoice that month.

What does resolution-based pricing mean in plain terms?

Think of it as paying a plumber when the leak stops, not for the hours the van sat outside. The company selling the software carries the risk that it works, and in exchange it gets a say in what counts as a stopped leak.

Under a seat-based deal, you buy ten licenses in January and justify all ten in December. Under this model, a quiet month produces a small bill, and a month where the software struggles produces a small bill too, so spending tracks results.

The tradeoff is that everything hangs on one word. If the seller decides what "resolved" means, and that definition quietly includes conversations where the customer shrugged and walked away, you are buying outcomes on paper and activity in practice. Agreeing the definition in writing, with a reopen window and an audit right, is where the negotiation should concentrate.

Common resolution-based pricing mistakes

The most common mistake is signing before defining. The definition of a resolution is the price, so a contract that defers to whatever the vendor's dashboard reports has no agreed price. Definition drift then arrives through a product release that reclassifies escalations as containments.

The second is comparing headline unit rates. Two quotes with an identical rate per resolution mean different things when one counts abandoned chats and the other excludes them, because the denominators differ. Normalize the definitions, then compare.

The third is trusting a single meter. When only the vendor can count, monthly reconciliation becomes a negotiation over their export. Pull your own closure and reopen events and reconcile them yourself.

The fourth is ignoring the quality incentive. A model that pays for closures rewards closing, so pair the meter with reopen windows and sampled quality review, or the billed number will improve while customer experience degrades.