Per-Resolution Pricing in Support: The Intercom Fin Playbook, Examined

Table of Contents

• What Per-Resolution Pricing Actually Means
• Why Intercom Chose 99 Cents
• The Definition Problem: What Counts as a Resolution
• The Economics Underneath the Sticker Price
• Where the Playbook Spread and Mutated
• Where Per-Resolution Pricing Breaks
• How to Evaluate a Per-Resolution Offer as a Buyer
• Insights Most People Overlook
• References

What Per-Resolution Pricing Actually Means

Per-resolution pricing is a specific dialect of outcome-based pricing. The vendor charges a flat fee only when the AI agent closes a customer conversation without a human stepping in. No human touch, you pay. Human touch, you don't. That's the whole pitch, and its appeal is that it lines the vendor's revenue up with the one metric a support leader actually cares about: deflection.

Compare it to the alternatives and the contrast is sharp. Per-seat pricing -- the model that built modern SaaS -- charges you for capacity whether or not you use it, which is exactly backwards for a product whose entire value proposition is reducing headcount. Per-ticket or per-conversation pricing charges you every time the agent engages, even when it fails and dumps the customer onto a human anyway. That's the model buyers hate most, because it means paying twice for a single bad outcome. Per-resolution threads the needle: you only pay for the conversations the machine actually finishes.

This sits squarely inside the broader GaaS pricing taxonomy of per-task, per-outcome, and per-seat models. What makes resolution interesting as the unit is that it's a composite metric -- it bundles "the agent engaged," "the agent answered correctly enough," and "the customer went away satisfied" into a single billable event. That bundling is the source of both its elegance and its eventual disputes.

Why Intercom Chose 99 Cents

Intercom launched Fin in 2023 on top of large language models, and the company made a deliberate, public bet: it would not charge for usage, conversations, or seats. It would charge $0.99 every time Fin resolved a query on its own. The number itself was a positioning weapon. Ninety-nine cents reads as trivially cheap next to the fully loaded cost of a human support interaction, which most benchmarks put somewhere between $5 and $15 depending on channel and complexity. Intercom's own messaging leaned hard on that gap, and you can see the framing in Intercom's Fin pricing explanation.

The strategic logic runs deeper than a cheap-looking price tag. By pricing on resolution, Intercom did three things at once. It made the buying decision feel risk-free -- a CFO can model "we'll pay only for wins." It aligned its own incentives with model improvement, because every accuracy gain converts directly into more billable resolutions. And it created a metric that was legible to a non-technical buyer in a way that token counts or API calls never could be. A head of support understands "resolved." She does not want a lecture on inference costs.

There's a quieter motive too. Resolution pricing let Intercom monetize the value of the LLM wave without exposing its margins to the volatility of underlying model costs in a way customers could see. The customer sees a clean 99 cents. What's happening behind it -- model routing, caching, retrieval -- is Intercom's problem and Intercom's margin to manage. That separation is a feature, and it's one reason the model has held up as inference prices have swung.

The Definition Problem: What Counts as a Resolution

Here's where the playbook gets genuinely hard, and where most copycats stumble. "Resolution" is not a fact. It's a definition, and whoever writes the definition controls the invoice.

Intercom resolves this with a mix of signals. A conversation counts as resolved if the customer explicitly confirms they're set, or if the conversation goes quiet after Fin's answer for a defined window with no human involvement and no reopen. If a human agent ever touches the conversation, it doesn't count -- you're not charged. That last rule is the trust anchor of the whole model: the customer's logical objection ("what if the bot 'resolves' something it actually botched?") is answered by "then a human will get involved, and you won't pay."

But the edges are messy, and they matter. What about a customer who gives up in frustration and simply leaves -- silence that looks identical to satisfaction? What about a question the bot answers confidently and wrongly, where the customer doesn't realize the answer is wrong until later? What about a conversation Fin "resolves" by telling the customer to email a different team? These aren't hypotheticals; they're the daily reality of support, and they're precisely the cases where vendor and buyer interests diverge. This is the core tension that the broader question of who defines and audits the outcome keeps running into across every outcome-priced agent.

The smart buyer move is to treat the resolution definition as the most important clause in the contract -- more important than the per-unit price. A vendor charging $0.50 with a loose, self-serving definition can easily cost more than one charging $0.99 with a tight, auditable one. Push for resolution data you can inspect: transcripts, reopen rates, CSAT tied to resolved conversations. If the vendor won't show you the conversations they billed you for, that tells you something.

The Economics Underneath the Sticker Price

Strip away the marketing and a per-resolution business is a gross-margin machine with a hidden cost curve. Every resolution costs the vendor some amount of inference -- often several model calls per conversation once you count retrieval, reasoning, and guardrail checks. Early on, with frontier models priced high, a $0.99 resolution could carry uncomfortably thin margins on long or complex conversations. The vendor's job is to keep the average cost-to-serve well below the price, and the lever for that is largely engineering: margin expansion through model routing, aggressive caching, and shrinking the number of calls per resolution.

This is why per-resolution pricing structurally favors scale and data. A vendor with millions of resolved conversations can fine-tune, route to cheaper models for easy queries, and reserve expensive reasoning for hard ones. A startup pricing the same 99 cents without that volume is running a thinner, riskier book. It's one concrete reason outcome pricing favors incumbents with data -- the unit economics reward whoever has seen the most conversations.

For the buyer, the economics flip into a budgeting question. Per-resolution spend scales directly with ticket volume, which means a viral product, a botched release, or a holiday surge translates into a support bill that moves with your worst days. Good vendors address this with caps and floors; bad ones let you discover the variance on your invoice. A solid analysis of how usage-based models reshape SaaS economics is OpenView's work on the rise of usage-based pricing, and the core lesson transfers cleanly: align the metric with value, but cap the downside.

Where the Playbook Spread and Mutated

What's remarkable about Fin is how fast the support category converged on resolution as the unit. Within roughly two years, Zendesk, Salesforce, and a wave of newer agent startups had all shipped some flavor of outcome- or resolution-based pricing for their AI support agents. Zendesk leaned into "automated resolutions" as a billable concept. Salesforce's Agentforce launched with per-conversation pricing that the market immediately compared, unfavorably or favorably, to Fin's per-resolution model. The framing battle that followed -- the "we only charge when it works" positioning war -- is downstream of Fin's original move.

The mutations are instructive. Some vendors moved to prepaid resolution pools, selling blocks of resolutions in advance, which smooths the vendor's revenue and gives the buyer a budget ceiling. Others adopted hybrid structures: a platform subscription plus per-resolution usage, which is closer to how hybrid pricing with base plus usage actually performs in enterprise deals where procurement wants a predictable floor. The fact that nobody settled on a single shape tells you the model is still being figured out in public.

Where Per-Resolution Pricing Breaks

The model has real failure modes, and pretending otherwise does buyers a disservice.

The first is the perverse incentive on quality. If a vendor is paid per resolution, it has a subtle incentive to mark borderline conversations as resolved. The human-touch exemption blunts this, but it doesn't eliminate it -- a customer who gives up silently looks exactly like a happy one. The honest vendors instrument against this with reopen tracking and CSAT; the rest hope you don't ask.

The second is the punishment of improvement. As your own knowledge base and product get better, easy questions get deflected by self-serve before they ever reach the agent. What's left for the AI is the hard residue -- the genuinely tricky cases the bot resolves least often. So your resolution rate can fall even as your support operation improves, which is a confusing story to tell your CFO. This is a specific instance of how metered pricing can punish the wrong behavior.

The third is volume coupling. Because you pay per resolution, your bill is mechanically tied to your inbound volume. A great vendor relationship can still produce an ugly invoice during a bad month, and the buyer who didn't negotiate a cap learns this the hard way. The mitigations -- usage caps that protect both sides and floor-and-ceiling structures -- exist, but they're opt-in, and the default contract rarely includes them unless you ask.

How to Evaluate a Per-Resolution Offer as a Buyer

Treat the resolution definition as the contract, not the headline price. Read exactly which signals mark a conversation resolved, what the silence window is, and whether reopens claw back the charge. A tight definition at a higher price usually beats a loose one at a lower price.

Demand auditability. You should be able to pull every conversation you were billed for and inspect it. Tie resolved conversations to CSAT so you can see whether "resolved" correlates with "happy." If the vendor resists transparency on token counts or resolution evidence, weigh that against the broader debate on whether vendors should show token counts -- you don't necessarily need tokens, but you do need to verify outcomes.

Negotiate the downside before you sign. Ask for a monthly cap, a volume-tiered rate, or a prepaid pool so a traffic spike can't blow up your budget. And model your own trajectory honestly: if your self-serve is improving, your resolution mix will get harder over time, so price the contract against next year's residue, not this year's easy wins.

Finally, separate the agent's price from the platform's. A 99-cent resolution sitting on top of a platform you also pay for is a different deal than a standalone agent, and conflating the two is how buyers misjudge total cost.

Insights Most People Overlook

The 99-cent price was a moat, not just a price. By anchoring the category on a round, cheap, outcome-tied number, Intercom forced every competitor to argue against "resolved" as the unit -- a debate they mostly lost. Setting the metric is more durable than setting the price, because once the market thinks in resolutions, you compete on resolution rate, which favors whoever has the most data. The pricing model was a strategic choice about what the category would measure, and that's a more powerful lever than the dollar figure.

The human-touch exemption is doing more work than the resolution definition. Buyers obsess over what counts as resolved. But the clause that actually protects them is the inverse: you don't pay when a human gets involved. That single rule converts the buyer's biggest fear (paying for bad bot answers) into the vendor's problem, and it's the real reason the model earns trust. Copycats that price per resolution but get fuzzy on the exemption inherit the elegance without the trust.

Per-resolution pricing quietly transfers model-cost risk to the vendor -- and that's a selling point buyers underrate. When inference prices swing, the per-resolution buyer's price doesn't move. The vendor eats the volatility. In a market where token costs are genuinely unpredictable, fixed-outcome pricing is a form of insurance the buyer gets for free, and few buyers credit it when comparing against cheaper metered models that pass cost volatility straight through.

Improving customer support can raise your per-resolution cost per ticket. Because better self-serve skims off the easy questions, the agent is left with harder ones it resolves less often -- so your effective cost per resolved conversation can climb even as your overall operation gets cheaper and better. Almost nobody models this, and it produces a genuinely counterintuitive line on the support budget.

The model only works in categories with a clean, legible outcome. Support resolution is unusually well-suited to outcome pricing because "the customer's problem went away" is observable and roughly binary. Most agentic work isn't. The reason Fin's playbook hasn't cleanly transplanted to, say, agentic sales or research agents is that those domains lack a resolution-shaped event to bill against. Fin's success is partly a story about support being the easy case, not about per-resolution being universally right.

References

• Fin AI Agent Pricing -- Intercom Help Center
• The Rise of Usage-Based Pricing -- OpenView Partners