Intercom chatbot: what Fin costs and when it is the wrong tool

The short version

• Intercom's chatbot is called Fin, and Intercom's published list price is $0.99 per outcome plus seats from $19 per seat per month.
• Every resolution rate Intercom publishes is its own telemetry, with no published definition of 'resolution', sample size or time window.
• A bot resolves only what your content already answers, so the content audit is the project and the configuration is an afternoon.
• Intercom moved Fin from resolution-based to outcome-based pricing in March 2026, so cost comparisons written before that are counting a different unit.
• If most of your volume is account-specific questions, a bot that only reads articles will deflect almost nothing.

What is the Intercom chatbot?

It is Fin, the AI agent built into Intercom. It sits in the Messenger widget your customers already use, reads the content you point it at, answers inside the conversation, and passes the conversation to a human in the Intercom inbox when it cannot answer. People search for it as the Intercom chat bot, the Intercom bot, the Intercom AI agent and the Fin AI chatbot. Those are all the same product.

Underneath, it is a retrieval system with a model on top. It finds passages in your content that look relevant to the question and writes an answer from them. Nothing in that loop knows your refund window unless your refund window is written down somewhere the bot can read. That one sentence predicts most of what happens after you switch it on, and it is worth understanding before you form a view on whether Fin will work for you.

Intercom changes what Fin can do often enough that any feature list in a blog post ages badly within a quarter. The only Intercom figures in this post are its published prices and its own resolution telemetry. Everything else here is mechanism, which ages better.

What does the Intercom chatbot cost?

Intercom lists Fin at $0.99 per outcome, and seats start at $19 per seat per month. So an Intercom chatbot pricing model has two parts: the humans who still work the queue, charged per seat, and a usage charge that moves with how much work the bot does.

The second part changed recently. Intercom's CTO announced on 12 March 2026 that Fin was moving from resolution-based pricing to outcome-based pricing. That matters for a practical reason: any cost comparison written before that date is describing a different meter. If you are working from a spreadsheet somebody built last year, check what it is counting before you trust the total.

Usage pricing has one honest property and one awkward one. The honest property is that a bot which does nothing costs you almost nothing, which is a fairer deal than a flat platform fee. The awkward one is that your bill becomes a function of your deflection rate, and your deflection rate is the number you are least able to predict before you start. So model both ends. Take your monthly conversation volume, apply the low end of Intercom's own published figures, then the high end, and look at both bills. If the high-end bill is uncomfortable, the price per outcome is not really your problem. Your volume is, and the question becomes what is generating it.

How should you read Intercom's published resolution rates?

As a ceiling somebody else reached, not a forecast for your queue. Intercom publishes a 76% average resolution rate across its Fin customer base, and says on its small business page that most small teams see Fin resolving 52% of conversations in their first month, with many reaching 76% or higher over time. Both numbers are Intercom's own telemetry about its own product.

What is not published next to them is a sample size, a time window, or a definition of 'resolution'. The last one matters most. A conversation where the customer read an answer and left gets counted differently by different teams, and the gap between 'the bot answered' and 'the customer got what they needed' is where most disappointment with support bots lives. Intercom's stronger claim, 85% or higher, is attached to 'many teams' with no number behind it at all.

None of that makes the figures worthless. Vendor telemetry is real data, and at that scale it is the only data anyone has. It is simply measured across a population that chose Intercom, configured Fin, and kept it running, which is a filtered group by definition. Your number will be set by your question mix, and your question mix is not theirs.

What decides whether you land nearer 52% or 76%?

Three things, in this order: your content, your question mix, and your handover. The model is the same model for everyone paying the same price, so it is not the variable.

Content first, because the bot cannot resolve a question nobody wrote an answer to. Teams routinely discover that the article covering their most common question was last edited two years ago, or that the real answer lives in a Slack thread and a senior agent's head. A bot does not fix that. It exposes it, loudly, in front of customers. If your help centre is thin, the honest order of work is to write the articles first and switch on the bot second.

Question mix next. 'How do I reset my password' is answerable from an article. 'Where is my order' and 'why was I charged twice' are not, because the answer is in your order system and your billing system, specific to one customer, and changes by the hour. If that is most of your volume, this is an integration project wearing a chatbot costume, and the per-outcome price is not the decision you should be agonising over.

Handover last, and it is the part most often skipped. A bot that says it cannot help, explains what it tried, and puts the customer in a queue with the context attached is better than a bot with a higher resolution rate and a dead end. A bot that loops, apologises twice and asks the customer to rephrase makes your support look worse than having no bot at all.

How can you test the fit before you commit?

1. Export your last 500 conversations and tag each one by whether a published article answers it in full, today, without edits.
2. Count how many need a live lookup into another system. That share tells you whether this is a content project or an integration project.
3. Read the ten worst conversations in the set. If the honest answer to each is 'it depends on the account', no bot resolves them from articles.
4. Multiply the article-answerable share by your monthly volume and by the per-outcome price. That is your optimistic bill, not your expected one.
5. Decide in advance what the bot says when it does not know, and who receives the conversation next. Write that down before you turn anything on.

Which questions can a bot actually close?

Is there independent evidence that support bots work?

Some, and it does not measure the thing you want measured. The most cited field study is 'Generative AI at Work', which used data from 5,179 customer support agents at a software firm during a staggered rollout in 2020 and 2021, later published in the Quarterly Journal of Economics. It studied an assistant that helped human agents do their work, not a bot answering customers instead of them.

So it is good evidence about AI inside a support organisation and no evidence at all about your deflection rate. Anyone citing it to argue that a customer-facing Intercom bot will close most of your tickets is citing the wrong paper. The two setups share a technology and almost nothing else.

The wider picture is that this is still early. Eurostat's 2025 survey, covering 157,000 enterprises out of the 1.53 million in the EU with ten or more employees, found just under 20% of enterprises using AI at all. Most teams switching on a support bot this year have no internal baseline to compare against, which is precisely why vendor averages get quoted so often and so uncritically.

When is Intercom's bot the right choice, and when is it not?

If you already run Intercom and most of your volume is questions your help centre answers, turn Fin on and stop shopping. Building a custom replacement for help centre deflection is usually a waste of money. The retrieval is commodity, the channel is already there, your agents already live in the inbox, and the per-outcome meter means a quiet month is a cheap month. We will say that plainly even though it is not the answer an engineering company is supposed to give.

It is the wrong tool when the work is not answering. If resolving a ticket means reading an order, issuing a credit, changing a subscription or checking an entitlement, the bot is a thin front end on an integration problem, and the integration is where the cost and the risk sit. Same verdict when the knowledge cannot be published as articles, when each answer depends on who is asking and what they are allowed to see, or when a wrong answer carries regulatory weight rather than an apology.

The useful middle path is not either or. Keep Fin on the front for the questions articles answer, and put the hard work behind an action the bot can call, built and tested on your side with its own permission checks and its own failure behaviour. That way the deflection you already get stays cheap, and the engineering effort goes to the conversations that were never going to be solved by better writing.