How to Implement Fin from Intercom
Learn how to scope, prepare, test, roll out, measure, and improve Intercom Fin without creating more support work.
Implementing Fin well is a fairly simple task consisting of a handful of decisions and a couple clicks (thank you Intercom for making it simple). To boil it down into a few sentences: You decide what kind of questions Fin may answer, prepare the content it refers to, define rules for when it hands off, test it with batch questions, roll it out to a few customers and measure the outcomes then improve from there.
Simple? Yes, but skipping a few steps and executing poorly gets you an agent that is more trouble than help. Following this guide helps you set up a support channel that can handle (boring) repeat questions while your team focuses on the important things.
Okay but what (or who?) is Fin?
Fin is Intercom's AI support agent, and it answers customer questions from the content sources you've connected (help articles, snippets, external pages) while handing conversations to your team when it can't answer or when it hits an excluded topic.
Intercom currently charges $0.99 per Fin outcome. This is worth flagging because a weak implementation can cost you twice: the usage fee when an outcome is counted, and the cleanup you have to do after that. It is better to prepare first. It is cheaper than both.
Before you start: is your system ready?
Fin amplifies whatever content it inherits, and stale content plus an undefined handoff equals wrong answers. Now imagine that at scale with hundreds or thousands of customers. You will be so neck deep in support questions, you'll wish you didn't start your company.
So run a cheap check first: pull ten recent conversations and ask whether each contact was preventable, whether an approved answer existed, and whether it reached the right person the first time. Fix Your Support System Before Adding AI walks through it.
Mostly "no" answers mean fix first, and mostly "yes" answers mean continue.
The implementation sequence
| Phase | Goal | Done when |
|---|---|---|
| 1. Scope | Pick what Fin answers | Written lists of eligible and excluded topics |
| 2. Content | Prepare knowledge pack | Every eligible topic has a current, approved answer |
| 3. Handoff | Define rules for handoff | Handoff conditions and receiving context are written |
| 4. Test | Verify answers before your customers do | Test set passes, unsafe answers fixed |
| 5. Rollout | Go live small | Controlled slice live, owner watching daily |
| 6. Measure | Measure outcomes | Baselines set, weekly review running |
| 7. Improve | Fix knowledge from failures | Failed answers become content fixes each week |
Phase 1: Scope
Start narrow, with one of your channels, one language, one customer group, and your lowest-risk topics. Write two lists: eligible for repeatable questions with approved answers, and excluded for anything involving judgment, money, legal exposure, or account decisions. Billing disputes, deletions, anything where a wrong answer is expensive, all of that goes on the excluded list.
You can widen the scope later, but you can't unsend a wrong answer.
Phase 2: Content
Fin answers from sources, so the sources are the product, and every topic on your eligible list needs one current article written to a standard, with no duplicates or conflicts. How to Prepare a Knowledge Base for AI Customer Support is the full standard.
Two rules matter most here: delete any duplicate answers before you connect sources, and put all your conditions in writing eg. plan differences, regions, dates.
Phase 3: Handoff
Make sure to define in writing when Fin must hand off: your excluded topics, requests for a human, uncertainty, and customer frustration. Then define what your team receives when it does, which is the conversation history, what the customer already tried, and the requested action. A handoff without context just moves the loop to another person.
Phase 4: Test
Build a test set before launch, with 20 to 30 real questions from your actual inbox in four categories:
- Normal questions, the common cases
- Edge cases, the conditions and exceptions your articles describe
- Conflict traps, questions where your sources might disagree
- Human requests, customers who ask for a person
Write the correct answer for each question first, then check Fin's answer against it. Don't worry about how fast Fin replied (speed can come later) and check whether the answer was correct, complete, and within scope, plus what happens when it wasn't: did the handoff catch the problem before the customer noticed?
Phase 5: Rollout
Go live to a small slice of customers first, because Intercom provides audience controls for a staged rollout (how convenient, thanks again Intercom!). Pick a slice you can watch daily, assign someone to monitor, and their job in your first weeks is reading conversations, catching wrong answers, and fixing content.
Phase 6: Measure
Make sure to set a few basic targets before you launch. Record a base target for each one, else you'd be shooting in the dark without anything to base on.
Watch how often Fin's answer is actually correct on a weekly sample of conversations, how often and how well it hands off, whether customers come back about the same thing after a Fin answer, and what they say about the experience. Track the wrong answers (important!) you catch too, sorted by how much each one cost you.
Something to take note of: Fin reports outcome counts, and that number will look great in a dashboard but it's just volume. It says nothing about whether customers got the right result, and it can happily go up while your actual support quality goes down. Make sure to pair it with the quality sample or it's just a metric that looks good on paper.
Phase 7: Improve
This is the part most teams skip, because they set it and forget.
Once a week, you need to pull a sample of Fin conversations and grade them. For every failed conversation, find the content behind it: maybe the answer didn't exist, maybe it was outdated, or perhaps two sources disagreed. Fix the source, retest, so that it doesn't happen again in the future.
Once you do that, you can widen. Add more topics, maybe another channel, or even another language. But only when a few weekly samples come back clean, because scope grows on the back of a working loop. Every failure you skip today compounds and becomes another bad customer experience.
Some common mistakes to avoid
- Full rollout on day one. Skipping test questions, no named owner, no numbers recorded beforehand. Fin might succeed at answering a few questions well, but the failures will be visible to all of your customers.
- Connecting sources before polishing them up. Two pages that disagree, an article from 2024, a PDF that no one has opened since your last engineer hire. Fin reads all of it and answers from the worst of it.
- No one owns it. The product changes, but the help center doesn't, and the first people to notice are your customers.
- Watching only the outcome count. Volume climbs, but quality stays a mystery, and every wrong answer can create another handoff on top of the Fin usage fee.
None of these are problems with Fin or any AI customer support agent. They are simple content and ownership problems, which means they are all fixable before launch.
Where to start?
Write your eligible and excluded lists today, because that action trickles down to every decision and phases later on: content, testing, handoff, rollout. Then work the phases in order, don't skip steps! You got this.
If you want an experienced pair of hands on the scoping, testing, and rollout decisions, book a call with Deskruby.