Where the comparison gets interesting is the part of your ticket volume that Fin was never built to touch: resolution that requires acting somewhere Intercom doesn't own, rather than answering from an article. That is where a custom system starts to make sense, and it's worth being precise about exactly where that line sits before anyone spends a budget on either option.
Intercom Fin vs. a custom AI system, at a glance
| Category | Intercom Fin | Custom AI system |
|---|---|---|
| Best at | Resolving tickets answerable from your help centre and macros | Resolutions that require acting inside other systems, not just answering |
| Where it lives | Inside Intercom, over your existing help centre and conversation history | Wherever the work actually happens — your helpdesk, ERP, booking system, order platform, dispatch |
| How it resolves a ticket | Retrieves and adapts an answer from your documentation | Looks up the live record, decides what to do, carries out the action, and confirms it landed |
| Acting in other systems | Answers from what it can read; does not issue, rebook, or adjust a record elsewhere | Built specifically to read and write across systems, under rules you define |
| Data model | Tied to Intercom's help centre and conversation data | Reads and writes across whatever systems the workflow actually touches |
| Pricing model | Priced per resolution, inside an Intercom plan | Scoped and quoted upfront as a project, with clear pricing agreed before work starts |
| Ownership of the logic | Configuration inside Intercom's product, on Intercom's roadmap | The rules, integrations, and boundaries belong to your business |
| Audit trail | Conversation history inside Intercom | Every decision and action logged against the process it ran |
The table understates how good Fin is at the thing it's built for. It's worth spelling that out properly before getting into where it stops.
When Intercom Fin is genuinely the right choice
- Your documentation is the actual answer, most of the time. If the majority of what your support team fields is "how do I," "what's your policy on," or "where do I find" — questions a well-written help centre article already answers — Fin's job is to surface that answer inside the conversation instead of making the customer go find it. That's a real, valuable job, and it does it well.
- You already run Intercom. Fin sits inside the tool your support team already uses, over data that's already there. There's no integration project, no new system for anyone to learn, and no separate vendor relationship to manage. For a team that just wants its existing help centre to work harder, that's close to the ideal shape of purchase.
- The failure mode of a wrong answer is low. If Fin misreads a question and gives an imperfect answer, the customer rereads it, asks again, or gets handed to a person — mildly annoying, not costly. Where the downside of a miss stays contained to a slightly worse conversation, the case for building something more elaborate is weak.
- Rollout speed matters more than depth. Turning Fin on over an existing help centre is close to immediate compared with scoping and building a custom system. If the business case is "get something live this quarter," Fin is very hard to beat on that dimension alone.
- Your support volume genuinely is what it looks like. Some businesses assume their tickets need judgement and discover, once they actually categorise a month of them, that most are documentation-answerable after all. If that turns out to be true for you, the honest advice is to stop reading this page and go configure Fin properly.
None of that is a consolation prize. For a meaningful share of support operations, this is simply the correct tool, and no custom build should be pitched against it on that ground.
Where Fin hits its ceiling
Fin doesn't get worse as a ticket gets more consequential. It stays exactly as good at what it does. The ticket just moves past the kind of problem the product was designed to solve.
Resolution requires acting, not just answering. A customer wants the damaged item replaced, the appointment moved to Thursday, the wrong address corrected on an order already in transit, or a service ticket escalated to dispatch. Fin can tell the customer what the policy says. It cannot issue the replacement, rebook the appointment, adjust the order in your ERP, or check whether a technician is actually available — because those actions live in systems Intercom doesn't own, and answering from an article was never going to get the ticket resolved.
Support conversations are often operational workflows wearing a support costume. "Where's my order" looks like a question. Resolving it properly means checking live carrier status against what the order platform shows, and if the two disagree, doing something about it — not paraphrasing a shipping policy. A lot of what lands in a support queue is this shape: a process that needs to run, not a fact that needs retrieving.
Per-resolution pricing changes the arithmetic at volume. Fin's pricing model charges per ticket it resolves. That model is straightforward and fair for moderate volume. As resolution volume climbs into the range where support is a genuine cost centre, the same model that made adoption easy starts working against the economics — worth modelling deliberately rather than assuming it scales the way a flat subscription would. (See how the two pricing models actually compare once you know your own volume.)
It's tied to Intercom's data model. Fin reasons over your Intercom help centre and conversation history. If the actual answer lives in your order management system, your booking calendar, or a database that has nothing to do with your helpdesk, Fin has no route to it unless that information has already been turned into a help centre article — which most operational data never is, and shouldn't have to be.
There's no path to genuinely custom logic. Fin's behaviour is configured inside Intercom's product, inside the shape Intercom has built for it. If your business runs an approval rule that doesn't map to their configuration options — a threshold that depends on customer tier and order value together, say — there's no way to build that logic into Fin. It lives in Intercom's roadmap, not yours.
None of that is a flaw. It's the boundary of a product built to answer from documentation, correctly scoped to that job.
When a custom build wins
A custom system earns its cost exactly where those five points stop being edge cases and start being the actual shape of your ticket volume: resolutions that require acting in a system Intercom doesn't touch, support conversations that are really operational workflows, volume high enough that per-resolution pricing works against you rather than for you, and logic specific enough to your business that no helpdesk's configuration screen was built to hold it.
Custom AI agents are built around exactly that gap. Rather than answering from a help centre, an agent is given access to the real systems a resolution touches — the order platform, the booking calendar, the ERP, the dispatch queue — and rules for what it may do on its own and what needs a person to confirm first, the way our human-in-the-loop glossary entry describes in plain terms. If you're new to the general idea of what separates an agent from a chatbot that only answers, the AI agent glossary entry is a good five-minute primer before the rest of this decision. And because every engagement is scoped before build work starts, the comparison against Fin's per-resolution model is never a guess — it's a number you can hold against your own volume. If you run Zendesk rather than Intercom, the trade-off is nearly identical and our comparison against Zendesk's AI covers that version of it.
The honest hybrid: keep Fin, build the actioning layer
This usually isn't an either/or decision, and the companies that get the best outcome rarely treat it as one. The common, sensible setup keeps Fin exactly where it already earns its keep — resolving the documentation-answerable volume, fast, inside the helpdesk your team already uses — and builds a custom agent for the narrower slice of tickets that need something done in a system Fin can't reach. Fin hands off the ticket it can't finish; the custom layer picks it up already holding the order, the customer, and the context, rather than starting from zero.
That split plays to what each system is actually good at. It also means the custom build stays small and cheap relative to replacing Fin outright, because it only has to cover the actioning gap, not rebuild the documentation-answering half of the job that already works. If you're unsure which side of that line your own ticket volume falls on, our build vs. buy guide walks through the general version of that question, and we'll happily do the specific version with you on a call.