How to Set Up Intercom's Fin AI Agent Without Losing Control of What It Resolves

Fin, Intercom's AI Agent, is billed separately from seat costs on a per-resolved-outcome basis, roughly a dollar per resolution with no volume discount noted, which means the setup work done before it ever answers a real customer determines both how well it performs and how predictable the resulting bill is. Turning it on with default settings and broad knowledge access is the fastest way to a large invoice attached to a mediocre resolution rate. Here's the setup that avoids that.

For background on what Intercom is, its full pricing structure including Fin's per-outcome fees, and how it compares to Drift, see our full Intercom profile.

The billing structure itself is worth understanding before touching any settings: since there's no volume discount noted on Fin's per-outcome fee, cost scales linearly with resolution count rather than tapering off as usage grows, which means the setup discipline below isn't just about answer quality, it's the actual cost-control mechanism, since there's no pricing tier that softens the bill once volume climbs.

Step 1: Audit Your Knowledge Sources Before Connecting Anything

Fin answers by retrieving relevant material from whatever knowledge sources you connect and generating a response grounded in that material. That makes the quality of what you connect the single biggest factor in whether Fin gives accurate answers or confidently wrong ones. Before enabling Fin, audit your help center articles, macros, and any other content slated for connection: outdated pricing references, deprecated features still documented, contradictory answers to the same question living in two different articles. Connecting a messy knowledge base doesn't just risk bad answers, it risks confidently wrong answers delivered with the same tone as a correct one, which is harder for a customer to catch than an obviously unhelpful response would be.

Step 2: Enable Fin and Connect Sources in Workspace Settings

With clean content ready, confirm your plan includes AI access, enable Fin in workspace settings, and connect your knowledge sources deliberately rather than selecting everything available by default. Scope the initial connection to your most reliable, most frequently referenced content, expanding it over time as you confirm accuracy, rather than connecting your entire content library on day one and discovering gaps only after Fin has already answered customers from thin or contradictory material.

Step 3: Configure Actions and Guidance Boundaries Explicitly

Beyond answering questions from connected content, Fin can take actions through connectors and integrations, looking up an order status, checking an account, triggering a workflow. Configure explicitly which actions Fin is permitted to take on its own and which require guidance or a boundary around them, rather than leaving this to default settings. A support team's comfort with Fin autonomously issuing a refund, for instance, is very different from its comfort with Fin looking up a shipping status, and the platform expects this distinction to be configured deliberately rather than assumed.

Step 4: Set Handoff Rules Beyond the Automatic Safety Triggers

Fin automatically hands off to a human when it detects certain high-risk situations, self-harm content, jailbreak attempts, high-risk medical, legal, or financial advice, but those built-in triggers cover safety, not business judgment. Add explicit handoff rules for the situations specific to your business that warrant a human regardless of whether Fin technically has an answer: billing disputes, refund requests above a defined amount, an angry or escalating tone, or any topic your team has decided shouldn't be resolved autonomously regardless of how confident the retrieval looks. Treat the automatic safety handoffs as a floor, not the complete list of situations where a human should take over.

Step 5: Roll Out to a Traffic Subset Before Going Fully Live

Test Fin in preview mode against real historical conversations before it touches live traffic, then roll it out to a limited subset of incoming conversations rather than switching it on for everything at once. This staged approach catches knowledge gaps, incorrect actions, and handoff rules that need adjusting while the exposure, and the billing impact, is still limited to a fraction of total volume, rather than discovering a systemic problem after it's already been generating resolutions, and charges, across the full conversation volume.

Step 6: Use Workflows to Route Ticket-Only Cases Separately From Conversational Resolution

Intercom's Workflows builder (which replaced the older Custom Bots) supports distinct workflow types, including ticket-only flows separate from conversational, real-time chat handling. Route structured requests that don't need a back-and forth conversation, a status check, a simple form-based request, through a ticket-only workflow rather than funneling everything through Fin's conversational resolution path. This keeps Fin's usage, and its billing, concentrated on the conversations that actually benefit from its conversational and retrieval capabilities, rather than paying a per-resolution fee for requests a simpler, unbilled workflow could have handled just as well.

Step 7: Audit a Sample of Billed Resolutions for Whether They Were Actually Solved

This is the step most rollouts skip, and it's the one that catches the gap between "the conversation closed without escalation" and "the customer's actual problem got solved." Periodically pull a sample of conversations Fin billed as resolved and read them directly: did the customer's issue genuinely get addressed, or did the conversation simply end, closed by a timeout or an ambiguous customer reply that didn't explicitly flag remaining frustration. A resolution rate that looks strong on a billing dashboard can still be masking a meaningful share of conversations that closed without actually helping anyone, and manual spot-checking is the only way to catch that gap before it shows up later as a customer satisfaction or churn problem.

A Few Mistakes That Undo This Setup

A handful of habits reliably turn a well-configured Fin rollout into an expensive, low-quality one. Connecting the entire help center on day one because it's faster than curating a scoped starting set means any outdated or contradictory article is now a live risk across full traffic immediately, rather than caught during a smaller rollout. Treating the automatic safety handoffs as the complete handoff policy, rather than adding the business-specific triggers your team actually needs, means Fin will confidently resolve conversations, like refund requests or angry customers, that most support leaders would want a human reviewing regardless of whether Fin technically had a correct answer. And skipping the manual audit in Step 7 because the billing dashboard already shows a healthy resolution rate is exactly how a gap between "billed as resolved" and "actually solved" goes unnoticed until it shows up as a wave of reopened tickets or a customer satisfaction dip nobody can immediately explain.

What This Setup Actually Produces

Done this way, Fin becomes a genuinely useful resolution layer with a cost that scales predictably with real value delivered, clean knowledge sources producing accurate answers, explicit handoff boundaries keeping autonomous action within a comfort zone your team actually chose, and a regular audit catching drift between "billed as resolved" and "actually solved" before it compounds. That's a meaningfully more controlled outcome than enabling Fin with default settings and finding out three months later, via an unexpectedly large invoice and a spike in reopened tickets, what its actual resolution quality looked like all along.

None of this requires the largest possible knowledge base or the most aggressive autonomy settings to get right. The discipline, curating what Fin can draw on, being explicit about what it's allowed to decide on its own, and checking its work periodically against what actually happened in the conversation, matters more than how much of the support surface area gets handed to it on day one. A narrower rollout done carefully will consistently produce a better cost-to-value ratio than a broad one turned on with default settings and left unaudited indefinitely.

If you're still weighing whether Intercom's Fin pricing model fits your support volume, our Intercom tool profile covers the full seat and per-outcome cost breakdown in more detail.