Outcome pricing: 76% are open, about 5% have signed — what actually closes the deal

Your buyer will ask you to price on outcomes. Then, most likely, they will not sign it.

According to HFS Research, 76% of enterprise CX buyers are open to outcome-based pricing. As of July 2026, about 5% were actually contracted on it (HFS Research, as reported by CX Foundation on 21 August 2026). That is roughly a 15× gap between what the market says it wants and what it has put its name to.

Our read: the question is not a request for a discount. It is a test. The buyer is checking whether you know what you are promising precisely enough to count it.

The published prices, so the unit is not theoretical

Two vendors have put a unit and a number side by side in public (The Pricing Conundrum). HubSpot moved its AI agents to $0.50 per resolved conversation and $1 per recommended lead, effective 14 April 2026. Zendesk bills roughly $2 per automated resolution pay-as-you-go, and about $1.50 under committed volume.

Look at what the unit is doing in each. "Resolved conversation" and "automated resolution" are not the same object, and "recommended lead" is a different category again: one is a closed thread, the other is a row handed to a salesperson. In our view the price is the easy half. The definition is the half that gets argued about in month four.

The four clauses your buyer arrives with

Buyer-side guides now teach four things to negotiate before signing (Lusivision, 2026):

1. Independent measurement. The buyer, or a system the buyer controls, counts the outcomes, with raw logs and audit rights. Not the vendor's dashboard.
2. A conservative attribution window. Exactly how much time, and how much prior human involvement, still lets the agent claim credit.
3. False-positive handling. What happens when a billed outcome turns out to be wrong: credited back, inside what window.
4. A hard monthly cap on outcome-linked fees.

Attached to that list is a warning, paraphrased: if the vendor cannot state the unit in a sentence the buyer would defend to their own finance team, this is usage-based pricing under a nicer label.

We think all four are correct, and that the vendor should bring them to the table unprompted. Our position: arriving with the buyer's own checklist already answered is a stronger opening than any capabilities deck.

Write the unit before you write the price

A unit is not a noun. It is a noun plus its exclusions. Here is the shape we use, with example thresholds: one sentence at the top, then the edges, because the edges are where the invoice gets disputed.

UNIT: one support conversation resolved without a human.

Counts only when all of:
  - the thread was opened by a customer, not by us
  - no human agent posted in the thread
  - no customer reply for 72 h after our last message
  - no new thread on the same order id within 7 d

Never counts:
  - a thread routed to a human at any point, even at the last step
  - a thread closed on timeout with no answer sent
  - a second thread on an order id already billed this month
  - anything in a locale we have not shipped review coverage for

Rule for anything not on this list: it does not count.

That last line matters most. Every ambiguous case resolves against us, by default, in writing. It is also what makes the first sentence defensible to someone else's finance team.

Hand over the count

Clause one says the buyer counts. Our view is that the strongest version of this is not audit rights over our numbers. It is keeping our numbers out of the loop entirely. We ship the query, it runs on their tables on their schedule, and the invoice reads their result.

-- runs nightly in the buyer's warehouse, on tables the buyer owns
-- we ship this file; they read it, run it, and can change it
select count(*) as billable_units
from conversations c
where c.opened_by   = 'customer'
  and c.closed_month = :month
  and not exists (
        select 1 from messages m
        where m.conversation_id = c.id
          and m.author_type = 'human_agent')
  and c.last_outbound_at < c.closed_at - interval '72 hours'
  and not exists (
        select 1 from conversations d
        where d.order_id = c.order_id
          and d.opened_at between c.closed_at
                              and c.closed_at + interval '7 days');

-- reconciliation: if our number and theirs disagree, theirs is the invoice.

The reconciliation line is a commitment, and it is cheap to make when the definition is tight. If the two counts drift, the definition is wrong, and we want to know that in the same month rather than at renewal.

Name the false-positive rule yourself

Here is the case we design for: the agent marks a ticket solved, the unit is billed, and the customer comes straight back. The buyer has now paid for a problem that was never solved. Our answer is that detection must be automatic. A credit the buyer has to notice and claim is not a credit.

FALSE POSITIVE
  trigger  a billed unit gets a customer reply on the same order id within 7 d
  action   credit on the next invoice, automatic
  window   90 d from the invoice date
  found by the same nightly query, in the buyer's warehouse
  nobody files a claim; the credit line appears on its own

MONTHLY CAP
  ceiling  agreed at signature, per month
  above it units are counted and reported, not billed
  reason   if a spike week triples ticket volume, revenue does not
           triple in the same month to pay for it

What we give up

Three costs, and we think all three are worth paying.

Ambiguity resolves against us, so a thread we half-handled earns nothing. The cap hands the upside back in the good month; that is the point of a cap. And if the buyer's pipeline breaks, our revenue waits on their data engineering, not ours.

That third one is the real cost. We would still rather have a client who can audit us than a client who suspects us.

The other number in the room

A second set of guides teaches a price floor. 2026 partner-selection guides tell founders to disqualify a quote well below €50,000: it reads as inexperience, under-delivery, or costs added later (Brixwave, 2026). We read them as evidence of what your buyer has been told, not as market rates.

Our point stands either way. A low price does not protect you. A price with no named unit protects you less.

What would change our mind

If the contracted share moves well off 5%, say a third of enterprise CX deals signed on outcomes within a year, this stops being a test of definition and becomes underwriting. The edge would then belong to whoever can absorb variance on their balance sheet, not to whoever writes the clearest clause, and we would be wrong about where it sits. We will say so here if that happens.

FAQ

Should we agree to outcome pricing when the buyer asks for it? If your unit survives the four clauses, it can work. But in our reading of the numbers above, agreeing is rarely what closes: about 5% had signed as of July 2026. Our advice is to bring the unit definition, the count and the false-positive rule to any pricing conversation, including a fixed fee. In our view, that is what the question is really probing.

What if the buyer cannot run the count in their own system? Then the attribution window and the credit rule carry the weight, and the contract should say the raw logs are theirs and exportable.

Who owns the outcome when a human was involved earlier? That is clause two. The only version we will sign names a maximum elapsed time and treats any prior human touch inside it as disqualifying.

Does this apply outside support tickets? The published units come from support and sales, so that is where the numbers can be checked. The method (define, exclude, count in their system, credit automatically, cap) does not depend on the domain, but that generalization is ours, not something the research measured.

A related case

This is the same discipline we build with. In RE Intelligence, our Dubai property intelligence product, the architecture line is "Postgres owns the truth. AI owns the story.": every number comes from a deterministic query, and the model narrates only what the data already proved. Forecasts are archived and graded against what actually happened, and the accuracy is shown to the user rather than hidden. A billable unit is the same contract in a different setting: a number the other side can recount, and a public record of the times it was wrong.

The case is at iloblique.com/re-intelligence, and the product is at reint.ae.

If you have something worth building, we'd like to hear about it.