Outcome-Based AI Pricing: Who Counts the Outcomes?

Fin bills an AI outcome when the customer goes quiet after an answer. Zendesk refuses to. Same month, a 2.9x invoice spread. What to demand before you sign.

Your AI vendor is about to offer you outcome-based pricing, and it will sound like they're taking on your risk. They're not. They're handing you an accounting job you don't have the records to do.

I build governed agents into other people's CRMs. The pattern I keep hitting isn't that outcome pricing is a scam. It's that the word in the middle of the contract, the one the whole invoice hangs on, means different things to different vendors, and nobody makes the buyer read it.

The short version

• Fin (formerly Intercom) bills an outcome when a customer goes quiet after an answer (Fin docs, 2026). Zendesk calls that same silence a contained resolution and refuses to charge (Zendesk, 2026).
• One 400-ticket month, three plausible definitions: 318, 246 or 108 billable. A 2.9x spread on identical work.
• You can't fail over from a definition. The fix isn't a second model provider. It's a workflow written down somewhere you can read it.

Why won't your next AI contract have seats in it?

Because your vendor's margins broke. In a survey fielded in mid-2025, seven in ten software companies building AI features said delivery costs are eroding their margins, and 52% said they were planning new pricing models to mitigate cloud spend (Revenera, Monetization Monitor 2026 Outlook, October 2025, n=501 product leaders). They aren't moving off seats to be generous.

The logic is genuinely good. If an agent lets four people do the work of ten, a per-seat contract punishes you for the savings. Paying for results instead of headcount is the honest fix. But it moves something onto your desk, and almost nobody has noticed what.

What does outcome pricing actually move onto you?

Outcome pricing doesn't transfer risk to the vendor. It transfers accounting to you. Under a seat licence you count people, in a system you already trust: payroll. Under outcome pricing you count events inside a workflow, and the events are generated by software the vendor controls.

Verifying an invoice now takes four capabilities. Define the billable event, in writing, before the first one fires. Count them independently. Find the ones that shouldn't have counted, because a false positive looks exactly like a success until you check. And keep a record good enough to win a dispute. Most teams signing these contracts have none of them. The vendor has all four, because the vendor built the instrumentation. Its number wins, not because anyone is being dishonest, but because it's the only number that exists.

Two vendors, one word, opposite invoices

Fin charges $0.99 per outcome. Its documentation defines a resolution as an outcome where "the customer confirms Fin resolved the issue or does not request more help after Fin answers" (Fin pricing docs, retrieved October 2026). Read the second half again. A customer who leaves without asking for more is counted as an "Assumed Resolution" once 24 hours pass. But a customer leaving isn't a customer being helped.

Credit where it's due: Fin doesn't bill escalations, explicit requests for a human or detected frustration, and deducts the charge if the customer comes back for more help. The gap is narrower than the headline suggests. It is still a gap, and it sits exactly where silence lives.

Zendesk names the same event and refuses to bill it

Zendesk goes the other way, and it moved first: it announced outcome-based pricing for its AI agents in August 2024. Its automated resolution tiers charge only for requests "successfully resolved by an AI agent, without any escalation to a human agent," verified through a conversation window of up to 72 hours (72 on email, two by default on messaging) and an LLM evaluation of whether the answer actually landed. The silence case gets its own name, a contained resolution, and Zendesk does not charge for it.

Salesforce publishes $2 per conversation for Agentforce and, as of October 2026, no definition of a conversation on its pricing page. The page carries a footnote saying it "is subject to change."

HubSpot moved Breeze Customer Agent from $1.00 per conversation to $0.50 per resolved conversation in April 2026 (HubSpot). Per unit, that's a cut. But its own documentation also counts a conversation as resolved when a lead is marked qualified, partially qualified, or not qualified, so a lead your agent rules out is still a billable resolution.

Nobody's customers voted on any of those windows. The resolution rates you're quoted are the vendor's too: Fin cites an average of 76% of support volume resolved end-to-end (Salesforce, June 2026), a figure no independent party has audited. You're billed against the vendor's figure, and there's no neutral referee.

The vendor that changed its own definition

On 12 March 2026 Fin renamed its billing unit. "Resolution" became "outcome," because, in Fin's words, it "now handles more complex, multi-step support queries" where a resolution isn't always the result, so procedure handoffs became billable too. Read that as a buyer. A vendor changed the definition of the thing you were paying for, mid-contract. That's not a scandal. It's evidence the unit isn't stable enough to price against without your own records.

Can you prove the resolution happened?

Not from the vendor's dashboard alone. Take four hundred tickets in a month. One coding agent front-lining the queue, humans behind it, one line in the contract reading €1.00 per resolution, a round number chosen for clean arithmetic. Now bill that month three times.

Same month. Same tickets. Same agent. Three invoices, and the widest is 2.9 times the narrowest. D1 is close to what most vendor dashboards report. D2 is what most buyers think they're buying. D3 is the only one where the customer's problem actually went away.

What each gate removes

From the 318 tickets the agent touched and closed, the gates strip 72 where a human replied after the agent, 70 auto-closed on timeout, 41 reopened within seven days, and 27 where the same contact opened a new ticket. Three roughly equal causes: 72, 70, and 68 (41 reopened plus 27 new tickets from the same contact). You can't patch this with one clause.

The euro numbers are small on purpose. The ratio is what scales. At 10,000 tickets a month the same three definitions bill €7,950, €6,150 and €2,700. That's €5,250 a month of pure definitional drift, €63,000 a year, on one workflow, decided by a word nobody argued about at signing.

Which definition is right?

D3, the durable one. Pay for durable resolutions, or don't pay per resolution. A ticket that reopens on Thursday wasn't resolved on Tuesday, and a reply your own team wrote is payroll, not vendor value. Zendesk already sells something close to D3, with a 72-hour window instead of my seven days.

The baseline is the whole negotiation

Take the baseline before anything gets built, because it's the only number in the argument that belongs to you. Time the workflow by observation, not by survey: how long the dreaded task takes today, measured with a timer, over one or two weeks, on data you own. It's your only independent denominator when the vendor reports a rate, and the only version of the number that survives a procurement challenge, because you can show your method.

What has to be in the audit record?

Six fields, all held on your side rather than in the vendor's dashboard. A durable resolution isn't harder to write into a contract than a touched one. It's harder to prove, and that's the real reason vendors don't lead with it.

1. What the agent proposed to do, and the payload it sent.
2. Who replied last, and whether they were a person or the agent.
3. Why it closed. Resolved, or aged out.
4. An idempotency key: a unique stamp on each action, so that if the agent retries after a timeout you can prove the same reply went out once rather than twice.
5. Reopen events, with timestamps.
6. Contact-level linkage, so a follow-up ticket points back at the original.

The first four are the approval record we design before a skill goes live. We put the gate inside the tool rather than bolting an approval button onto an opaque workflow, which is what makes the record replayable. Fields five and six are already sitting in your CRM and almost nobody queries them.

If you can't produce those six fields, you aren't auditing an invoice. You're approving one.

What happens when your AI leans on a single provider?

Everything so far assumes the vendor stays the vendor and you can read the workflow it bills. Neither is guaranteed.

You probably didn't choose a model provider. Your AI arrived pre-installed in the tools you already ran: the CRM, the help desk, the sequencer. For operators, single-vendor AI risk isn't downtime; it's inspectability. An outage is loud, rare, and somebody else's engineering problem. A workflow nobody can read is silent and permanent, and it's yours. Ranked by how likely each is to be the thing that gets you:

1. 01
   The person who built it. One head, one login, no artifact. High risk.
2. 02
   The workflow, never written down. It lives inside a vendor's builder. High risk.
3. 03
   The SaaS vendor's AI feature. Repriced or redefined without your consent. High risk.
4. 04
   The automation layer. Fails silently by default. Medium risk.
5. 05
   The model version. Deprecated, or quietly swapped. Medium risk.
6. 06
   The seat, API key, or OAuth grant. Leaves with the builder. Medium risk.
7. 07
   The model vendor itself. OpenAI or Anthropic goes down. Low risk.

The one everybody writes about is seventh.

The vendor itself can change. On 15 June 2026, Salesforce signed a definitive agreement to acquire Fin, formerly Intercom, for approximately $3.6 billion, pitching Fin's models as a complement to Agentforce (Salesforce, June 2026). The deal closed on 10 September 2026. Teams that picked Intercom precisely because it wasn't Salesforce now have Salesforce, on a timeline they didn't control.

The automation layer fails quietly. Zapier's default alert is an email to whoever built the Zap, and it sends none at all when an error handler catches the failure (Zapier). n8n alerts nobody unless someone has built an error workflow for it (n8n docs). A pager wakes someone up. A silent stop just accumulates until somebody notices, three weeks later, that the enrichment stopped. It's the same argument we made about why eval datasets matter more than model choice.

And you already have multi-provider AI: Fin runs Apex, a support model it built in-house, so your vendor routes across models you never picked. The usual prescription is an AI gateway with automatic failover. I used to recommend building one. For most people reading this, that was the wrong advice. A gateway makes the model swappable. It does nothing to make the workflow swappable, because your workflow isn't in code. It's in a vendor's visual builder, a Slack thread, and somebody's head.

The fix is a governed skill: a markdown file in Git. You can read it, diff it, and hand it to a new hire, a different model, or an auditor. Repricing becomes a question of which model you call, and the builder leaving becomes a pull request.

Five questions check your exposure, one per layer. Who could explain step four if the builder left tomorrow? Can you export the workflow as something a person can read? Do you know how your vendor defines its billable unit? How long did the last silent failure go unnoticed? Who approves before an automation writes to your CRM? Two or more "I don't know" answers mean the problem isn't which model you're on.

Does outcome pricing change your AI Act position?

Yes. Article 50 transparency duties have been live since 2 August 2026, and the same date gave the EU AI Office power to enforce against general-purpose AI providers. Break those duties and the fine runs to €15 million or 3% of global turnover, whichever is higher, under Article 99(4)(g). High-risk obligations for stand-alone Annex III systems are a different story: the Digital Omnibus, Regulation (EU) 2026/1744, in force since 27 July 2026, deferred them to 2 December 2027.

There's a timing detail most people miss. Was your AI system live before 2 August 2026? Then you have until 2 December 2026 to add machine-readable marking to generated content (Cooley, August 2026). Deploy anything new from August onward and you get no window at all.

Enforcement is expected to open with technical compliance dialogues rather than fines (Wilson Sonsini, EU AI Act Enforcement Phase Begins, August 2026). A dialogue means producing documentation: what the system does, which actions it takes, who reviewed them. That's the same evidence you'd need to audit a per-resolution invoice. One record, two jobs, and your vendor's billing dashboard does neither. Anyone evaluating EU AI implementation partners should ask who owns that record before asking about price.

Which six questions belong in the contract?

Put these in the RFP, in writing, before the pricing conversation.

Question six is the one that decides the other five. Every definition above is unenforceable without the log. If a vendor won't give you the log, treat it as a pricing signal, not a technical limitation, and negotiate a flat fee or a capped commitment instead.

Where this argument still leaks

The weakest part of this piece is the dataset. I chose the gate proportions myself. The mechanism holds at any proportions, but the specific 2.9x is mine, not a measurement of your queue. Strict definitions have a cost too: push every vendor to durable-only and some will go back to seats. And seven days is arbitrary. Whatever number you choose, choose it before you sign, not after the first invoice you want to dispute.

One I don't have a clean answer for yet: how you review something an agent did when the agent also writes the record of what it did. That problem shows up in billing and in approvals, and I suspect they're the same problem.

What to do before the next vendor call

Do one thing this week: open your current AI vendor's pricing documentation and find the sentence that defines the billable unit. If you can't find one, that's your answer. Then, in order:

1. Time your target workflow for two weeks. Observation, not survey. You own the data.
2. Pull the six fields above out of your CRM for last month and compute your own D3. Most of them are already there.
3. Send the six questions before you discuss price, not after.

The word is the price

Outcome pricing is the right idea. The contracts aren't ready. And support is just where the definitions are published: anywhere a vendor bills per completed thing, from qualified leads to matched invoices, the definition of "completed" carries the price.

The fix is small and boring. Vendors write the unit into the contract and hand over the log. Buyers time the workflow before they buy it, and keep their own record of what the agent did. This is a paperwork problem. It just doesn't look like one when it arrives as a price.