Pay Per Resolution
Definition
Pay Per Resolution
Pay per resolution charges a fixed amount for each issue closed, regardless of how many contacts, channels or handoffs it took to get there. The provider is paid for the ending, not the effort, and that single change reshapes how agents work.
It is the cleanest answer to a familiar complaint — that per-contact pricing rewards a supplier for handling the same problem three times. Here the third touch earns nothing extra.
The mechanism only works when resolution can be observed. That means a definition, a reopen window and a system of record both sides can read without arguing about it.
Get those wrong and the model inverts — premature closure becomes the rational strategy, and the customer pays for it.
Key takeaways
- Payment attaches to a closed issue, not to contacts, minutes or handoffs.
- A reopen inside the agreed window must void or refund the original payment.
- Complexity banding is required, because issues are not interchangeable units.
- The model needs a trustworthy ticketing system before it needs a price.
How it works
Four things must be agreed before a price means anything: what resolution is, who confirms it, how long the reopen window runs, and how issues of very different difficulty are banded. Skipping the fourth is the most common mistake.
Resolution is normally defined as the customer confirming the issue is fixed, or a defined system state being reached. Auto-closure after silence is the weakest definition available and the one suppliers push hardest for.
The reopen window is the control that makes the model honest. If the same issue returns within, say, ten days, the original payment is voided rather than a second one earned.
Complexity banding stops the arithmetic collapsing. A password reset and a failed integration cannot carry the same price without one of the parties being systematically wrong.
| Band | Typical content | Price relationship |
|---|---|---|
| Tier 0 | Self-service deflection | Usually unpaid or nominal |
| Tier 1 | Known issue, scripted fix | Base rate |
| Tier 2 | Investigation, no known fix | Two to four times base |
| Tier 3 | Engineering escalation | Priced separately or excluded |
Public procurement has been writing requirements this way for years. Federal rules direct buyers to describe work “in terms of the required results rather than either ‘how’ the work is to be accomplished or the number of hours to be provided”.
The behavioural warning comes from the same tradition. UK guidance asks that contracts be designed “to minimise perverse or unintended incentives” — and premature closure is exactly the incentive this model creates.
Examples
Resolution pricing rewards genuine problem-solving and punishes weak definitions, so the same contract can look excellent or absurd depending on one clause. These four cases show both outcomes and one deliberate fix.
A SaaS company pays per resolved support case with a fourteen-day reopen void. Repeat contacts fall sharply in the first quarter, because closing something twice earns the provider nothing.
A telecoms operator pays per resolution with no reopen clause. Closure rates look excellent for two months until customer satisfaction collapses and the pattern becomes obvious.
A hospital system bands clinical-system issues into three tiers with different prices. Providers stop cherry-picking the easy queue, because the hard queue is now worth taking.
A retailer pays per resolution but keeps its own quality sampling on closed cases. Any case closed without a genuine fix is clawed back, which costs almost nothing to administer.
Related terms
Resolution is measured in several ways and priced in one, so the surrounding terms are easy to mix up. The entries below separate the price from the measurements that sit around it.
- Cost per resolution: the internal metric you calculate, not the price a supplier quotes.
- First call resolution: resolving on the first contact, which this model rewards indirectly.
- Resolution rate: the share of contacts that reach a close.
- Ticket resolution rate: the same measure expressed in a ticketing system.
- Average resolution time: the speed dimension this price deliberately ignores.
- Service level agreement (SLA): where reopen windows and quality gates are usually written.
- Outcome based pricing: pays for a business result, where this pays for a closed issue.
FAQ
What counts as a resolution?
Whatever the contract says, which is why the definition matters more than the price. Customer confirmation is the strongest test; automatic closure after silence is the weakest.
How long should the reopen window be?
Long enough to catch a bad fix and short enough to close the books. Ten to fourteen days is common, and the window should match the natural recurrence pattern of the issue.
Does the model discourage quality?
Only without a reopen clause. With one, a premature closure costs the provider the payment it already earned, which is a stronger control than a quality score.
Should tier 0 deflection be paid?
Usually not per unit, because paying for deflection and paying for resolution pull against each other. Most contracts handle deflection with a separate improvement target.
Is this suitable for technical support?
Yes, provided issues are banded by complexity. Without banding the provider is paid the same for a password reset and a three-day investigation.
How is it different from per-ticket pricing?
Per-ticket pays on arrival; this pays on closure. A ticket that bounces between teams for a week earns one payment here and several under per-ticket.
Understand how support pricing is structured across the sector at Outsource Accelerator.
Independent
