Intercom Fin Charges $0.99 a Resolution. The Definition Is the Whole Deal

Fin bills $0.99 when it resolves a support conversation and nothing when it fails. That model took the product past $100 million in annual recurring revenue and lifted net revenue retention from 112% to 146%. It also moved the entire commercial argument onto one word. A resolution is counted when a customer stops replying for 24 hours, and silence is not the same thing as a solved problem.

Written for founders and directors who are choosing a support automation vendor and have to defend the line item afterwards. That reader converts on unit economics rather than on features, and per-resolution pricing is a unit economics decision wearing a product badge.

What Fin actually charges for

Per-resolution pricing is usually described as paying only for success. That description is close but not exact, and the gap is where the money sits.

Fin bills four separate outcome types. Three of them cost the same, and one costs ten times more. None of them is a seat, and none of them is a message.

The four billable outcomes

The published outcome list is short and worth reading in full before any negotiation.

Prices are US dollar list rates published in Intercom's help centre. Committed volume agreements are negotiated and not published, so treat these as the ceiling rather than the price a large buyer pays.

Read the third row again. A disqualification bills at the same rate as a resolution, which means Fin earns $0.99 for telling you a lead is not worth your time. Intercom defends that choice openly, and I think the defence is correct. Rejecting a bad prospect is real work, and pricing it at zero would quietly push the model toward saying yes.

What Fin does not charge for

The exclusion list is the more interesting half of the contract. Fin does not bill when a customer asks for a human, when frustration triggers an escalation, when a workspace rule routes the conversation away, or when a configured procedure fails on a technical error.

It also does not bill for a greeting. If Fin answers "hello" and nothing else, no outcome is recorded. Conversations where Fin asks a clarifying question and the customer never replies close as abandoned rather than resolved.

One further protection matters more than it looks. Only one outcome is charged per conversation in a billing period, and if the customer returns to a resolved conversation asking for more help, the charge is deducted. That last rule is the vendor accepting a real refund obligation, and most outcome pricing I have reviewed does not go that far.

How a resolution is defined

Two mechanisms produce a billable resolution, and they are not equally defensible. Both are documented, which is more than most vendors in this category offer.

The first is a confirmed resolution, where the customer says something affirmative after Fin's answer. Intercom gives "Ok thanks" and "That helped" as its worked examples. Nobody disputes this case, because the customer stated the outcome and the vendor billed for it. The second mechanism is where the entire argument lives.

Assumed resolutions and the 24 hour rule

An assumed resolution happens when the customer leaves without asking for more help. The Fin help documentation sets the threshold precisely: disengagement for 24 hours after Fin's last answer records the resolution and bills it.

This is the load-bearing assumption in the whole model. It treats absence of complaint as evidence of success. In a support queue that inference is usually right, because satisfied people leave and dissatisfied people escalate.

It is not always right. A customer who reads an incorrect answer, decides the chat is useless and goes to a competitor also leaves quietly. Fin bills that conversation at exactly the same rate as the one it solved.

The growth the model produced

Whatever the definitional problems, the commercial result is not ambiguous. Intercom had recorded five consecutive quarters of declining net new annual recurring revenue before this pivot.

Fin went from $1 million to $12 million of ARR in its first year, then past $100 million, growing at roughly 350% annually. Equity research firm Sacra put total company ARR at $400 million in April 2026, up from $382 million at the end of 2025, with Fin accounting for close to all of the growth.

Sacra also estimated Fin at roughly 2 million queries a week across about 8,000 businesses, and Salesforce's acquisition release counts more than 30,000 customers on the platform overall. A quarter of company revenue arriving from one product growing at 350% is a good problem to have. It is still concentration, and any change to how a resolution is counted now moves a quarter of the revenue base.

Net revenue retention did the work

The headline number is retention rather than new logos. Intercom CFO Dan Griggs described the move from 112% to 146% net revenue retention in an interview with Mostly Metrics, and the mechanism behind it is simple.

Under per-seat pricing, a customer who automates support buys fewer seats next year. Under per-resolution pricing, that same customer buys more resolutions. The vendor stops being punished for its own product working, which is the structural problem I described in the piece on how seat compression is repricing software.

Where the definition breaks

The rules above are clear on paper. Three situations break them in practice, and only one of the three has a published answer.

Silence is not satisfaction

Your bill is partly determined by customer silence, which is among the least reliable signals available in a support system. A customer who is quietly unhappy produces the same billing event as one who is delighted.

Fin's refund rule softens this. If the customer reopens the conversation, the charge comes off. That only helps when the customer comes back, and the customer most damaged by a bad answer is precisely the one who does not.

The intervention penalty

The sharpest documented case appeared in Intercom's own community forum. A customer running photography hardware at live venues reported a 12% resolution rate and a specific complaint about how interventions were counted.

Their agents watched Fin give wrong troubleshooting steps to stressed customers and stepped in before those customers pressed the button that asks for a human. Because the escalation was not customer-triggered, the conversations billed as Fin outcomes. During a server outage, every human rescue cost them a dollar.

The incentive that creates is the problem. Waiting for a customer to become frustrated enough to escalate is cheaper than helping them early. An Intercom staff member, Paul Byrne, replied in the thread that stepping in for the customer "should be seen as good judgment, not something to be penalized" and said he would escalate it internally. No policy change has been published since.

Credit where it is due. The complaint sits on the vendor's own forum and the vendor's answer agrees with the customer, which is a healthier disclosure posture than a quiet contract clause. It is still not a resolved issue.

The resolution rate you get is not the published average

Every forecast of a Fin invoice runs through one number, and the public estimates of that number span a factor of six.

Fin publishes a 76% average and Salesforce repeated that figure in the acquisition release. Sacra's independent estimate came in at 67%. The vendor's own guidance for a new deployment is 40% to 60%, rising with tuning.

All of these can be true at once. Averages across thousands of accounts hide enormous variance, and the quality of your existing help content drives most of it. My working assumption for a first-year budget is the low end of the vendor's own new-deployment range, not the headline average.

What outcome pricing costs the vendor

Buyers focus on the invoice. The more revealing question is what this model does to the supplier, because that determines whether the price holds.

Under per-seat pricing, cost of goods is roughly fixed and revenue is contracted. Under per-resolution pricing, every failed conversation still consumes inference and returns nothing. The vendor absorbs the cost of its own errors directly.

Sacra flagged exactly this pressure, noting that external model API costs weigh on gross margins against the roughly 80% the company enjoyed before AI. That is the same squeeze covered in the piece on what inference costs do to software margins.

It also explains the strategy. Salesforce's release describes Fin's proprietary model, Apex, as outperforming leading frontier models. Owning the model is not a vanity project when your unit of revenue is a correct answer, and it is the strongest counter I have seen to the argument in the debate over what makes an AI wrapper defensible.

Fin against Zendesk and Agentforce

Three vendors, three different units of account. The unit matters more than the rate, and buyers routinely compare only the rates.

Only the Fin rate comes from a published vendor price card. Zendesk does not publish a per-resolution rate, and the figures shown are the convergent estimate across third-party pricing analyses rather than a vendor statement. Treat both non-Fin rows as directional and verify them in your own quote.

Agentforce is the instructive contrast, and it is not simply worse. Salesforce defines a conversation as a 24-hour interaction session and bills it regardless of outcome, which transfers failure risk to the buyer. In exchange the buyer gets a cost that does not rise when the agent gets better.

Salesforce has also changed that model three times in about eighteen months, moving from per-conversation at launch to Flex Credits and then to per-user add-ons. Agentforce still reached $1.2 billion of ARR by the first quarter of its 2027 fiscal year, growing 205%, so the churn in pricing has not stopped the product. Buying Fin now places a per-resolution price card inside a company whose flagship agent bills per conversation. That is a genuine tension, and I expect it to be resolved in Salesforce's favour for the reasons set out in the assessment of Salesforce in the agent era.

Where this argument is weakest

The case above leans hard on the assumed resolution problem. Here is the strongest version of the other side.

The case that assumed resolution is correct

No workable alternative exists at scale. Requiring explicit confirmation would undercount badly, because most helped customers never reply. Billing only confirmed resolutions would punish the vendor for customer politeness patterns rather than for product quality.

Intercom also published its reasoning when it built outcome pricing for its sales product. Aisling O'Reilly wrote that the company rejected revenue sharing because attribution beyond the qualified lead is contaminated by demo quality, outages and budget cuts. That is the correct instinct applied honestly, and the same instinct produced the 24 hour rule.

Set against per-conversation billing, an assumed resolution charge is still the vendor absorbing every escalation. Compared with a per-seat contract that bills whether or not anyone logs in, it is a substantial transfer of risk toward the supplier.

What this post cannot settle

Nobody outside the company can measure how often an assumed resolution was actually a failure. That would need an audit of conversations against later outcomes, and no such study is public.

The 12% case is one customer with an unusual workload, and single cases prove that something can happen, not how often it does. The 76% and 67% figures come from a vendor and an analyst respectively, and neither publishes the conversation-level methodology. Anyone quoting a precise dissatisfaction rate for assumed resolutions is guessing.

How to model the invoice before you sign

The forecast is arithmetic once you fix the resolution rate. The trap is that the sensitivity runs the wrong way from intuition, because better performance costs you more.

Two readings follow. Against per-conversation billing, per-resolution wins across the range, and the gap closes only if a vendor resolves close to everything. Against your existing human cost, the comparison depends on what a ticket costs you today, which you should calculate rather than take from a vendor benchmark page.

The discipline here is the same one I applied to enterprise AI spending generally in the review of where measurable AI return has actually appeared. Record the baseline before deployment, or the saving is unprovable afterwards.

Buyer preference is moving with the model rather than ahead of it. A Futurum survey of enterprise software decision makers in the first half of 2026 found 43% favouring consumption-based pricing and 27% favouring outcome-based structures, with fewer than one in five preferring per-user pricing. The sample size is not published, so read it as directional.

Frequently asked questions

What to negotiate first

Three asks, in the order they change your economics.

Ask for assumed and confirmed resolutions to be reported separately on the invoice. The vendor already distinguishes them internally, and the split tells you how much of your bill rests on silence rather than on stated success. A vendor who will not break that out has told you something useful.

Then run a 30 day pilot on your actual queue and use the measured rate, not the published average, in every figure of your business case. Finally, get the treatment of agent-initiated interventions in writing, because that is the one edge case the vendor's own forum shows is still unsettled.

Related reading