Independent AI intelligenceSource-backed analysis · Static by default · Agent-ready pipeline
Agent-native workLensUp analysis1 source

Your Support Bot Just Got a Sales Quota. Here's What Breaks.

People hear "outcome-based pricing" for AI support agents and picture something clean. Support stops being a cost center and becomes a profit center. The...

/5 min read/Pipeline-assisted editorial

People hear "outcome-based pricing" for AI support agents and picture something clean. Support stops being a cost center and becomes a profit center. The bot answers a question, nudges a purchase, takes 5%. Everyone wins.

That's a nice story. Let me ask the dumb question that breaks it: paid on what, exactly?

Because "a sale" is not a thing a computer can bill on. A sale is fuzzy. It gets returned. It gets charged back. It happens three days later in a different browser. Before anyone can pay on an outcome, someone has to write down, in a contract, the precise event that triggers payment. This is the shape of the deal companies like Sierra describe publicly: the fee fires when a customer-defined success outcome is met — a resolved ticket, a completed purchase — not when the agent "earns a commission" in any human sense. That much comes from how they talk about their own model. And the moment you write that trigger event down, the clean 5% picture falls apart.

I don't have anyone's private contracts, and you don't need them. You just need to think about what any contract like this has to contain to survive contact with reality. So think of what follows as contract-design patterns — the clauses a competent buyer's lawyer would demand and a competent vendor would expect. The billable event isn't "a sale." It's a resolution or conversion event with carve-outs bolted on. There are three obvious ones.

First, a clawback window, typically a couple of weeks to a month. The payment is provisional. If the order gets refunded or reversed inside the window, the fee unwinds. This clause isn't paranoia. Apparel return rates are notoriously high — often cited in the tens of percent. Without a clawback, the vendor bills you on revenue you never keep.

Second, a self-serve suppression rule. No credit if the customer was already sitting in an active checkout the agent didn't create. In plain terms: if they were about to buy anyway, the bot doesn't get paid.

Third, a materiality threshold. The agent had to take a logged, causal action — recommend the SKU, resolve the objection, complete the payment step — not just be present in the session.

Now follow those last two clauses one step past where the sales deck wants to stop. They exist because of a single ugly fact about attribution.

These systems bill on last-touch or session-window attribution. The customer talks to the bot right before they buy, so the bot gets 100% of the credit. Fine. Except: who contacts support? People who are already trying to buy. Someone who opens a chat has, as a rule, higher intent than cold traffic — because reaching out is a high-intent signal. They self-selected into buying.

So a naive last-touch model charges the vendor's fee for conversions that were going to happen with or without the agent. The bot is standing next to a purchase, taking credit for the purchase. That's not causation. That's correlation wearing a name tag.

There's exactly one honest way to measure whether the agent caused anything: a holdout. Route some fixed percentage of eligible conversations to a no-agent control, and pay only on the measured lift between the two groups. That's the real number.

Vendors rarely offer that, and now you know why. The measured lift is usually well below the total attributed conversions — sometimes far below. That gap is the non-incremental volume, the "would've bought anyway" traffic, and it's exactly the volume the vendor bills you for. A holdout would make that number visible. So the contract leans on the suppression rule instead — a crude heuristic that strips the most obvious cases without ever running the experiment that would show the truth.

Now the second thing the deck won't tell you: the floor.

A single support conversation on a modern agent can fire many model calls per turn, and if it's voice with heavy tool use, it runs long. Every one of those calls costs money whether or not the customer buys. So think about "free until outcome" honestly. The vendor eats the full inference cost of every long, tool-heavy conversation that doesn't convert. Do that at scale and you're underwater.

Which means no vendor prices it that way. They set the per-outcome fee at a healthy multiple of the marginal inference-and-tool cost, or they attach a minimum platform fee, usually both. Here's the step most people miss: that means outcome pricing does not move all the risk onto the vendor. The vendor takes the inference risk, prices it, and hands it right back to you inside the fee. When you think you've offloaded your risk, you've actually bought an inference-risk premium you can't see, because it's baked into a percentage that looks like it's about sales.

Then Monday comes and the invoice lands.

The vendor's event ledger and your order-management system are two different systems of record, and they disagree. They disagree on timing — did the conversion happen in-session or three days later. They disagree on returns — their log shows a sale, your system shows a chargeback. They disagree on fraud reversals. In practice, a meaningful slice of billed outcomes gets contested every single month. Without audit rights and a shared source-of-truth ledger written into the contract, every invoice becomes a reconciliation fight. The profit-center narrative dies quietly in the finance queue.

And here's the part that isn't about billing at all — the part worth worrying about most.

The moment you pay a support agent on sales outcomes, you change what it's trying to do. A deflection-optimized agent wants to resolve the ticket and close the conversation fast. A revenue-optimized agent wants to keep the conversation open, upsell, steer toward the paid path. Those are opposite objective functions. Reward the second one and you get longer handle times and lower CSAT — the exact things you bought support to improve — plus a bot quietly eating the human sales team's quota. You paid to change the agent's incentive, and the incentive changed the agent.

So here's the handle to carry away: phantom commission. It's the slice of any outcome-based invoice that pays for conversions the agent didn't cause — non-incremental volume dressed as caused revenue. Every outcome-based contract without a holdout has phantom commission in it. The only question is how much, and whether the contract lets you find out.

Three things to do tonight if anyone is selling you outcome-based pricing.

One, open the draft MSA and find the exact definition of the billable event. If it says "sale" or "conversion" without a clawback window, a self-serve suppression rule, and a logged causation criterion, that's not a contract, it's a wish. Redline it.

Two, ask one question in the next call: "Will you run a randomized holdout and bill only on measured lift?" Write down the answer. If it's no, ask them to name the incrementality rate they'll accept as an estimate — and watch whether they'll put a number on paper at all.

Three, ask for audit rights and a shared reconciliation ledger before you sign, not after the first disputed invoice. The month you're arguing about a fifth of a bill is the wrong month to discover you never negotiated the right to check.

One honest question for anyone who's been on either side of one of these contracts: when the vendor's log and your order system disagreed, who won — and what was written down that made them win?

ENDEnd of analysis
Related analysisAgent-native work