Intercom Fin vs Custom AI Agent: Cost, Control, Voice, and Ownership

The first Intercom invoice that surprises a support leader is rarely the seat line. It is the resolution line. You spent two quarters improving your help center, tightening your macros, and cleaning your product docs, and Fin's deflection rate climbed from 34% to 58%. Support headcount stayed flat. The bill went up by $14,000.

That is not a bug in Intercom's pricing. It is the pricing working exactly as designed. Fin bills $0.99 per resolution, so every improvement you make to the knowledge your agent draws from converts directly into vendor revenue. The question is not whether that is fair. It is whether it is the right structure for your volume curve, your channel mix, and your five-year plan.

Most "Fin vs custom" comparisons are written by companies selling one of the two. This one gives you the arithmetic and the decision rule, including the case where you should sign with Intercom and stop reading.

The pricing unit is the entire argument

Every other difference between a platform agent and a custom one is downstream of how you get charged.

Fin's model is outcome-priced. You pay when the agent works. Intercom's seat pricing sits underneath that, starting around $29 per seat per month and climbing toward $132 per seat on higher tiers, with additional charges layered on for add-ons and usage. Voice resolutions are priced on their own line. The structure is not unique to Intercom - Salesforce prices Agentforce on conversations and flex credits, and most of the category has converged on some version of pay-per-outcome.

A custom agent inverts this. You pay a large amount once (design, integration, evaluation harness, rollout), then a small amount forever. The marginal cost of a resolution is model inference plus retrieval plus logging. At current API rates, a well-scoped support answer with retrieved context runs somewhere between $0.03 and $0.15 depending on model tier and how much context you stuff into it. Published token pricing makes this easy to model within about 20% accuracy before you build anything.

So the comparison is fixed cost versus variable cost. That is a finance question with a clean answer, and I will do the arithmetic in a moment. But it is worth saying plainly: outcome pricing is a genuinely good deal at low and moderate volume. Anyone telling you otherwise is selling a build.

The nine dimensions that actually differ

Pricing dominates the conversation, but eight other dimensions decide whether the cheaper option is even viable for you.

Two rows on that table decide more deals than the price row.

Actions and writeback. A support agent that can only answer questions caps out fast. The value curve bends when the agent can issue a refund, reschedule a delivery, apply a credit, update a subscription, or open a warranty claim - and do it across systems that were never designed to talk to each other. Platforms support this through a curated set of actions. If your refund logic lives in a homegrown billing service with rules that took four years to accumulate, you are going to spend real engineering time either way. The difference is whether that engineering lives inside a vendor's action framework or inside your own codebase. We wrote more about the failure modes in AI agent writeback patterns.

Evaluation. Vendor-reported resolution rates are a billing metric first and a quality metric second. If Fin marks a conversation resolved because the customer did not escalate within the window, that is a reasonable proxy, but it is not the same as a correct answer. Eugene Yan's patterns for building LLM systems makes the case that the eval set is the real asset, not the prompt. On a platform, you can build your own eval layer on top of exported transcripts. With a custom build, the eval harness is part of the deliverable and you can gate deploys on it. That matters more in regulated categories than in ecommerce.

The break-even math, done honestly

Take a mid-market SaaS company. 8,000 inbound support conversations per month, 50% handled by AI, so 4,000 AI resolutions. Twenty support seats.

Fin, year one:

• Resolutions: 4,000 × $0.99 × 12 = $47,520
• Seats: 20 × $85 × 12 = $20,400
• Total: about $68,000

Now grow volume 30% per year, which is what happens when the business is working.

• Year 1: $68,000
• Year 2: about $82,000
• Year 3: about $100,000
• Three-year total: roughly $250,000

Custom, same three years:

• Build: $90,000 for a scoped production agent with retrieval, three system integrations, an eval harness, and human handoff
• Inference and infrastructure: 4,000 resolutions at roughly $0.10, plus hosting and observability, call it $1,500 per month or $18,000 per year
• Maintenance: 0.25 FTE of engineering attention, roughly $45,000 per year fully loaded
• Three-year total: $90,000 + 3 × $63,000 = roughly $280,000

Custom loses. At this volume, on cost alone, it loses by about $30,000 and it loses with far more execution risk.

That result surprises people who assume building is always cheaper. It is not. Generalize it into a rule:

Custom becomes cheaper when annual AI resolutions exceed roughly (annual fixed cost of the custom build) ÷ (platform price per resolution minus your marginal cost per resolution).

With $80,000 in annual fixed cost and a delta of about $0.85 per resolution, that is roughly 94,000 resolutions per year, or about 8,000 per month. Double your volume from the example above and the three-year picture flips hard: Fin climbs past $450,000 while custom moves by less than $30,000, because the only thing that grew was token spend.

This is the single most useful number in the comparison. Compute yours before you talk to anyone. We broke the structural argument down further in per-resolution vs flat-fee support AI pricing, and the line-item detail lives in the Intercom Fin pricing reality.

The reasons to build that have nothing to do with cost

Volume is the clean trigger. These are the messy ones, and they show up well below break-even.

Voice with a real latency budget. Voice is not chat with a microphone. It needs streaming speech recognition, barge-in handling so the customer can interrupt, and a total turn latency under about 800 milliseconds before the conversation starts feeling wrong. Platform voice gets you there on a vendor-chosen stack with vendor-chosen tradeoffs. If voice is your primary channel rather than a secondary one, owning the ASR and TTS choices is worth real money, because that is where the quality lives.

Data residency and model constraints. If you are operating under GDPR with strict residency requirements, or preparing for EU AI Act transparency obligations on customer-facing systems, "the vendor handles it" is a contract term, not an architecture. Custom deployment inside your own cloud account changes the compliance conversation from negotiation to configuration.

Model version control. Platforms upgrade models on their schedule. That is usually good and occasionally terrible, because a model swap can change tone, verbosity, and refusal behavior across every conversation you handle without warning. If you have spent six months tuning an agent's escalation behavior for a regulated product, an unannounced upgrade is a genuine operational event.

Domain depth. Klarna's assistant handled two-thirds of customer service chats within a month of launch, doing the work of roughly 700 agents. That result came from deep integration into Klarna's own systems and data, not from generic knowledge base retrieval. When your resolutions depend on your proprietary logic more than on your documentation, the ceiling on a configured platform agent is lower than the ceiling on a built one.

Multi-system reality. A platform priced around one helpdesk works best when your support world is one helpdesk. If your reality is Zendesk for support, Salesforce for accounts, a custom billing service, and a warehouse system reachable only through an internal API, you are integrating regardless. Zendesk's own pricing plus Fin plus connectors starts to look like a stack you are assembling anyway, without owning any of it.

Exit cost is the line item nobody prices

Ask any vendor this question before signing: on the day we leave, what exactly do we get, in what format?

The honest answer is usually raw transcripts and contact records. What does not travel:

• The tuned retrieval corpus and chunking decisions
• Resolution labeling logic (what the platform counted as resolved and why)
• Eval sets and quality baselines built inside vendor tooling
• Action and workflow configuration
• Escalation rules and confidence thresholds

That is 18 months of institutional learning that stays behind. It is not malice, it is just that these artifacts are the product. But it means the switching cost at renewal is much higher than the migration cost of your data, and vendors know it when they price the renewal.

The same question applied to a custom build has a boring answer: it is in your repository, your database, and your cloud account. That boring answer is the entire value proposition of building, and it is worth roughly one renewal negotiation per year. Our broader take on this tradeoff is in AI agent platforms vs custom built.

Platform ownership can also change under you. Consolidation in the support AI category has been steady, and a vendor's roadmap, pricing, and integration priorities are set by whoever owns them at the time, not by the contract you signed two years earlier. Price that risk at zero if you like, but do not pretend it is zero.

A decision rule you can apply this week

Run these four checks in order and stop at the first one that answers cleanly.

1. Volume check. Compute your break-even resolution count using the formula above with your own numbers. Above it by 40% or more, and growing? Build. Below it? Keep going.
2. Channel check. Is voice a primary channel, or will it be within 18 months? If yes, model the voice add-on cost separately and compare against owning the stack. Voice economics diverge from chat economics faster than anything else.
3. Action check. List the ten highest-volume resolutions you want automated. How many require writing to a system outside your helpdesk? If it is more than four, you are doing custom integration work regardless, and the platform's abstraction may cost you more than it saves.
4. Constraint check. Any hard requirement on data residency, model version pinning, or audit trails that a vendor contract cannot satisfy architecturally? That is a build trigger at any volume.

If all four come back clean in the platform's favor, sign with Intercom. Fin is a well-built product, the pilot takes days rather than months, and you will get value in week one. Come back to this arithmetic when your volume doubles.

If two or more come back in favor of building, do not build the whole thing. Scope one workflow with clear escalation, instrument it, and prove the marginal cost model on real traffic before committing to the full migration.

How OpenNash CX Can Help

We build production support agents for teams that have already outgrown the per-resolution model or have hit a constraint a platform cannot clear.

The engagement follows the same four stages every time. Audit: we pull your last 90 days of conversation data, classify actual resolution types, and compute your real break-even against current platform spend. That number decides whether we should be working together at all, and we have told plenty of teams to stay on their platform. Design: we define escalation thresholds, human approval points, and failure handling before writing agent code, because those decisions determine whether the thing is trustworthy in production. Build: the deliverable includes the retrieval layer, system integrations, an eval set built from your own historical conversations, and traces you can audit. Deploy: production release in your cloud account with CI/CD, documentation, and full ownership handoff.

The measurable outcome is a fixed monthly run cost that stops tracking your success and a set of artifacts that transfer if you ever replace us.

Book a call and bring your last three months of support volume plus your current Intercom invoice. We will run the three-year projection with you in the meeting and tell you which side of the line you are on.