Every comparison of these two lines up seat prices and feature checkmarks, and that made sense for about a decade. It does not any more, because neither company sells you only seats now.
Both platforms bill you for outcomes their AI produces. Both describe that the same reassuring way, as paying only for work that actually got done. And then they define the work differently, in a place that turns out to matter enormously: what happens when the bot gives up and passes the customer to a person.
On one platform that conversation is explicitly excluded from the bill. On the other it can be one of the billable outcome types, and whether it is depends on how you configured the routing. Same customer, same question, same eventual human reply, opposite invoices.
So this page starts there rather than with the feature grid. We build and maintain custom HubSpot integrations for a living, so the disclosure goes up front: we do not sell either of these, we are not affiliated with either, and for most teams one of the two is genuinely the right answer. The part where we have something useful to add is narrow. It is that the conversations your integration creates, and the routing your integration configures, are what decide how many billable outcomes exist.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
The Short Answer
Zendesk is the more predictable bill and the more restrictive platform to build against. Intercom is the more capable platform to build against and the one whose costs move around more.
If you run a conventional support desk with a stable headcount, mostly email and web form volume, and you want to know in January what you will spend in December, Zendesk's model is easier to forecast. Seats are seats, the AI allowance is published per agent per month, and you can cap it.
If your support motion is conversational, in-product, and tied to what people are doing in your app, Intercom is built for that shape and its API will not fight you. What you give up is the ability to predict the AI line, because it moves with your conversation volume rather than your headcount, and because some of your escalation paths become billable in a way that is not obvious when you configure them.
The case for reading further is if any of three things are true: you plan to route conversations programmatically, you plan to open conversations or tickets from another system, or something in your stack is going to answer questions on your behalf. Each of those interacts with the outcome meter, and none of them appear on a comparison table.
Both Vendors Bill for Outcomes Now, and That Is the Real Comparison
Here are both models in the vendors' own words, because they are rarely put side by side.
Zendesk states that AI agents are included in every Suite and Support plan, with pricing based on the successful outcomes they deliver. The unit is the automated resolution, which Zendesk defines as "the unit of measurement used for calculating and billing your account for AI agent usage and legacy AI agent usage." The framing is that "paying per automated resolution means that you pay only for customer requests that were successfully resolved by the AI agent, without any escalation to a human agent."
Intercom prices Fin at $0.99 per outcome, and describes a resolution as Fin answering the customer's question where "they confirm it helped, or leave without asking for more help." Intercom publishes several outcome types rather than one, and you are charged at most once per conversation regardless of how many questions were asked.
Read those two definitions carefully and they are not describing the same product boundary. Zendesk's is a negative condition: the resolution counts because a human never touched it. Intercom's is a positive one: the outcome counts because Fin did the thing you asked it to do, and one of the things you can ask it to do is hand the conversation over.
That is not a gotcha on Intercom's part. It is a coherent position, and arguably the more honest one, because configuring a bot to collect context and route a conversation correctly is real work that produces a real outcome. But it inverts the intuition almost everyone brings to this comparison, which is that you pay the AI when it saves you from a human.
The Handoff Is Where the Two Meters Point Opposite Ways
This is the part worth slowing down for, because it is the only place the two pricing models actively contradict each other.
Intercom publishes its billable outcome types. A Resolution is counted when no further help is requested after the last AI answer. A Procedure Handoff is counted when, in Intercom's wording, "Fin successfully executes a Procedure that you've configured to end in a handoff to a human or a workflow." There are also Qualification and Disqualification outcomes for sales use.
Critically, not every escalation is billable. Intercom is clear that escalations arising from workspace-level rules, from default frustration detection, or from a customer simply asking to speak to a person are not charged. Neither are failed procedures, spam routing, abandoned conversations, or conversations where Fin's last message was a clarifying question rather than an answer.
Zendesk's definition has no equivalent, because escalation is the disqualifying event rather than a billable one. Zendesk also excludes resolutions generated by testing through Admin Center and resolutions in a sandbox environment, along with several legacy surfaces.
The same event, a bot passing a conversation to a person, is the thing Zendesk will not charge for and one of the things Intercom will.
Neither company is hiding this. Both publish it plainly. But no feature comparison puts the two definitions on one page, and the definitions are what you are actually buying once your volume is real.
Silence Is a Billing Event, and the Clocks Run at Different Speeds
Both platforms have to decide when a customer who stopped replying counts as a customer who was helped. Both made a reasonable decision. They made different ones.
Zendesk counts an automated resolution on email 72 hours after the last message, on messaging after a 2 hour default window of inactivity which can be configured up to 72 hours, and on voice immediately upon hangup. The resolution is verified by an LLM as satisfactory and without human intervention.
Intercom treats a customer who exits without requesting further assistance as an assumed resolution, and its help centre states customers have at least 24 hours to respond to the last AI answer before they are considered to have exited.
So a customer who asks one question, gets a plausible answer, and never comes back becomes a billable outcome after roughly a day on Intercom and after three days on Zendesk email. On Zendesk messaging, with the default left alone, it takes two hours.
For a support desk answering humans who are sitting at their keyboards, this is a detail. For anyone whose conversations are created by software, it is the whole ball game, which is the next section.
Why Automated Conversations Are the Expensive Ones
Here is the part that connects the pricing model to the integration, and it is the reason this page exists rather than being another feature table.
A conversation opened by a person is watched by that person. They asked something, they are waiting, they will reply or they will close the tab, and either way the platform learns something real about whether they were helped.
A conversation opened by an integration has nobody on the other end. A form submission that becomes a ticket, an order event that opens a conversation, a failed payment that triggers an outreach, a system alert routed into the support queue: none of these have a customer sitting there. Silence is their default state, not a signal.
Both platforms convert silence into a resolved outcome. So automated traffic is, structurally, the traffic most likely to produce billable outcomes that nobody actually benefited from. And it looks identical in the dashboard to a genuinely satisfied customer, because from the platform's point of view it is identical: an AI answered, and nobody asked for more help.
The practical consequence is a design rule. Decide deliberately which automated conversations should reach an AI agent at all. A ticket opened by a sync so that a record exists does not need a bot to answer it, and routing it away from the AI agent costs nothing and prevents an outcome charge on both platforms. That is a fifteen minute decision at design time and it is close to impossible to unpick once a year of traffic has run through it.
What the Seats Cost Before the Meter Starts
Seats are still most of a small team's bill, and the tiers are not comparable one to one.
| Intercom | Zendesk | |
|---|---|---|
| Entry tier | Essential, $29 per seat/mo | Suite Team, $55 per agent/mo |
| Middle tier | Advanced, $85 per seat/mo | Suite Professional, $115 per agent/mo |
| Top published tier | Expert, $132 per seat/mo | Suite Enterprise + Copilot, quoted |
| AI pricing | $0.99 per outcome | Per automated resolution, with an included allowance |
| Included AI allowance | None published | 5 per agent/mo on Team, 10 on Professional and Growth, 15 on Enterprise |
| Annual ceiling | None published | Maximum 10,000 allocated automated resolutions per year |
Zendesk's prices are per agent per month billed annually. Two things in that table do more work than the headline numbers.
The first is the included allowance, which is genuinely valuable for a small desk. A five-agent Zendesk Professional account carries 50 automated resolutions a month before anything is charged. The same volume on Intercom is roughly $49.50. That is not a large number either way, but it means a small team experimenting with an AI agent starts free on one platform and metered from the first conversation on the other.
The second is the 10,000 per year ceiling on allocated automated resolutions across all Zendesk plans. Above that you are into purchased resolutions or overage. It is a number worth checking your projected volume against before you assume the allowance model scales with you, because a busy desk passes 10,000 resolutions a year without being especially busy.
Zendesk also lets you configure the account to pause AI agent features when you reach your resolution limit. That is the only hard cost cap either platform publishes, and if predictability is why you are here, it is the single most important setting in this comparison.
What Each One Sends Back to HubSpot
Both have a free HubSpot App Marketplace listing. Both are narrower than the phrase "HubSpot integration" suggests, in different ways.
Zendesk's app is built by Zendesk. It brings support ticket activity onto the HubSpot contact timeline and will create a HubSpot contact from a ticket requester who does not already have one. It is a visibility integration: the rep opening a contact record can see that support activity exists.
Intercom's HubSpot app is explicit about its direction. It states that it "only sends data one-way from Intercom to HubSpot" and that "this app cannot sync data from HubSpot to Intercom." It carries two rules that catch people out repeatedly. The first is that "we sync every end-user reply in real time, while your teammates' replies are only synced once the conversation is closed," so an open conversation appears in HubSpot as a one-sided transcript. The second is that "only conversations that were started after you connected the HubSpot app to Intercom, and that have an end user reply, will be sent to HubSpot," so there is no backfill and a conversation the customer never replied to never arrives at all.
We have written up the Intercom side of this in detail, including the identity problem and the separate Data Sync app that points the other way, in our HubSpot Intercom integration guide, so we will not restate it here.
What matters for this comparison is that neither app moves support state into the CRM in a way you can build on. Ticket status, resolution, SLA breach, reopen count, the things a renewal risk score or a service report would actually need, are not what either listing is delivering. If those need to drive anything in HubSpot, that is a build on both sides, and the platform choice changes how hard the build is rather than whether you need one.
What Each One Publishes to Whoever Builds the Integration
This is where the two platforms are least alike, and where Intercom wins clearly.
Intercom documents 10,000 API calls per minute per app and 25,000 API calls per minute per workspace, for both private and public apps, with no endpoint-specific variations. It returns X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset, and a 429 Too Many Requests when you exceed it.
Zendesk sets limits by plan: 200 requests per minute on Team, 400 on Growth and Professional, 700 on Enterprise, and 2500 on Enterprise Plus. The High Volume add-on raises a qualifying plan to 2500 requests per minute against the Support and Help Center APIs. It returns an X-Rate-Limit header, and a 429 carrying Retry-After telling you how many seconds to wait.
What Intercom gives a build
- 10,000 calls per minute per app, and 25,000 per workspace
- One limit across all endpoints, so there is nothing endpoint-specific to discover in production
- Full X-RateLimit header set with remaining and reset
- The same limits for private and public apps, so a prototype behaves like the real thing
What Zendesk gives a build
- 200 requests per minute on Suite Team, which is the tier most small teams buy
- Per-endpoint limits well below the plan limit, several of them on the endpoints a sync needs
- Incremental exports capped at 10 requests per minute, 30 with the High Volume add-on
- Ticket updates capped at 30 per 10 minutes per user per ticket, and 100 per minute per account
That last pair of Zendesk numbers deserves more attention than the headline plan limit ever gets.
Incremental exports are how a scheduled sync reads changes out of Zendesk. It is the endpoint a nightly or five-minutely job is built on. It is capped at 10 requests per minute, rising to 30 with the High Volume add-on. Your 700 per minute Enterprise limit does not help, because the job is not going to use any other endpoint in bulk.
Ticket updates are capped twice over, at 30 updates per 10 minutes per user per ticket and 100 requests per minute per account, rising to 300 with the add-on. Any integration that writes back to tickets at volume, which is most of the interesting ones, is designing against 100 per minute rather than against the plan number on the pricing page.
A plan's headline rate limit tells you almost nothing. The limit that decides your architecture is whichever one sits on the endpoint your job cannot avoid.
Neither of these makes Zendesk unbuildable. They make it a platform where the sync design has to be batched, incremental and patient by default, rather than one where you can be casual and fix it later. That is a real cost, it lands on the build rather than on the subscription, and it does not appear anywhere in a pricing comparison.
Intercom vs Zendesk, Line by Line
| Intercom | Zendesk | |
|---|---|---|
| Billing unit for AI | Outcome, at $0.99, once per conversation | Automated resolution, against a per-agent allowance |
| Handoff to a human | Billable when it came from a Procedure you configured | Excluded, resolution requires no escalation to a human |
| Unconfigured escalation | Not billable (workspace rules, frustration, customer request) | Excluded, same as any escalation |
| Silence window | At least 24 hours before an assumed resolution | 72 hours on email, 2 hour default on messaging, immediate on voice hangup |
| Verification | Resolution counted only when Fin gave an actual answer | LLM verifies the resolution was satisfactory |
| Testing for free | During the trial period | Admin Center testing and sandbox both excluded, permanently |
| Hard cost cap | None published | Pause AI agent features at the resolution limit |
| API limit | 10,000/min per app, 25,000/min per workspace | 200 to 2500/min by plan |
| Sync-critical endpoint | No endpoint-specific limits | Incremental exports at 10/min |
| HubSpot app direction | One-way, Intercom to HubSpot only | Ticket activity onto the contact timeline |
What Neither Price Covers
Three costs sit outside both pricing pages, and they land on whoever builds the integration.
Deciding which automated conversations meet an AI agent. Covered above, and the cheapest decision on this list by a distance. It is a routing rule, it takes an afternoon to specify, and it is the difference between your automated traffic being free and being metered.
Getting support state into the CRM in a usable form. Neither marketplace app delivers ticket status, resolution time, reopen count or SLA state as properties you can build a workflow or a report on. Both deliver activity onto a timeline, which is useful for a human reading a record and useless for anything automated. If a renewal risk signal, a churn score or a QBR report needs support data, that gap is the build.
Keeping identity consistent between the two systems. Every support platform keys on an email address and every CRM eventually has two records with the same person behind them. This is not specific to either vendor and we have covered the general shape of it in our customer 360 guide, but it is worth saying plainly that a support integration is an identity integration wearing a different hat, and the deduplication work is not optional.
Which One to Pick
A stable headcount, mostly email and form volume, and a finance team that wants the number in advance. The per-agent allowance covers a small desk's AI usage outright, and pausing AI agent features at the resolution limit is the only published hard cap in this comparison. Accept that the build against it will be slower and more batched.
Conversational, in-app, tied to what the user is doing. The API will not fight your integration, the outcome model matches a motion where Fin genuinely closes things end to end, and the platform is built for the shape of work you actually have. Budget the AI line as a variable cost rather than a fixed one.
If most of what would land in the queue is generated by your own systems rather than by people, the first question is not which platform. It is which of those conversations needs a support tool at all. Route the record-keeping traffic somewhere that does not meter outcomes, and choose a platform for the human volume that remains.
Three questions settle it faster than any feature table.
How many of your conversations will be opened by software? If the answer is most of them, the outcome meter is your main cost driver and it is controlled by your integration, not by your support team. Design the routing before you sign either contract.
Do you need the bill to be predictable, or the platform to be capable? Both are legitimate answers and this comparison mostly reduces to that choice. Zendesk gives you a ceiling you can set. Intercom gives you an API you will not spend a year working around.
What has to reach the CRM, and who is building that? Neither marketplace app carries support state into HubSpot as data you can act on. Whichever way you go, that is a build, and its cost is roughly the same on both sides.
The Bottom Line
Intercom and Zendesk have converged on the same business model and diverged on its most important definition. Both charge for seats and then charge again for outcomes their AI produces. One of them refuses to bill you when a human gets involved. The other bills you for the handoff when the handoff was something you designed.
That single difference reorganises the whole comparison. It means the better your routing, the more Intercom costs and the less Zendesk does, for identical customer journeys. It means silence is revenue on both platforms, on clocks that run at 24 hours and 72. And it means the conversations your integration opens, which are the ones no human is ever going to reply to, are the most expensive traffic you can send either platform.
None of that is hidden. All of it is on the vendors' own documentation pages, and neither company is behaving badly. It is simply that the decision has moved. It used to be a comparison of two support tools. It is now a comparison of two meters, and the thing feeding the meters is your integration.
So before you compare the seat prices again, answer one question in writing: which conversations in your business should an AI agent be allowed to answer, and which ones exist only so that a record exists. That is a design decision, it costs nothing to make, and on both platforms it is worth more than the tier you pick.
