Intercom Fin

Fin is a retrieval-grounded support agent, and nearly everything about its performance follows from that. Answers are drawn from your help center, prior resolved conversations, and connected sources, which constrains the model to documented policy instead of plausible invention. The mechanism is the same retrieval-augmented generation pattern used across enterprise assistants, tuned for a support corpus.

Deploying it is a documentation project

The consequence teams underestimate is that gaps, contradictions, and out-of-date articles that a human agent silently works around become visible immediately as bad answers.

Experienced support staff carry an enormous amount of undocumented knowledge: which article is wrong, what the policy actually is now, which exception applies to enterprise customers. They compensate for the knowledge base without anyone noticing it needs compensating for. Fin cannot, and the first week of a deployment is largely a report on how bad your documentation is.

Most of the implementation effort therefore lands on content, not configuration. Teams that plan for a two-week technical rollout and discover a three-month documentation backlog are the common failure story, and the useful reframe is that the documentation work was owed anyway — the agent just sent the invoice.

Escalation design decides whether it works

The measure worth tracking is resolved-without-follow-up, not raw deflection rate. Deflection counts conversations the agent ended; resolution counts problems that went away. A tool optimised for the first can look excellent while making customers miserable.

That makes escalation the critical design surface. When should the agent hand off — on explicit request, on low retrieval confidence, on detected frustration, on topic? What does the human receive: the transcript, the sources the agent used, the confidence it had? A handoff that arrives as a cold conversation with no context is worse than no agent at all, because the customer has now explained the problem twice.

Getting this right is more consequential than any model choice, and it is where implementations most often skimp.

The pricing model and what it implies

Fin is priced per resolution on top of an Intercom plan, with volume and enterprise agreements available.

Per-resolution pricing aligns incentives better than per-seat and creates its own dynamic worth understanding: the vendor is paid when the agent resolves, so the definition of a resolution matters commercially as well as operationally. Read that definition carefully, and instrument your own measure of whether customers came back within a week rather than relying solely on the platform’s count.

It also means costs scale with volume, which is the right shape for support but makes the business case sensitive to your ticket mix. High-volume repetitive queries are cheap to resolve and are where the economics work; complex low-volume queries are expensive and mostly escalate anyway.

Where it fits

High-volume first-line support with repetitive questions and a maintained knowledge base, on teams already using Intercom. Organisations willing to treat documentation as infrastructure.

Teams not on Intercom face a platform migration that usually outweighs the agent, and should evaluate the equivalent capability in their existing helpdesk first. Teams with thin or contradictory documentation should fix that before buying anything, because no support agent recovers from a bad corpus.

See AI automation for business for where support agents sit in the wider automation picture.