Why Does Intercom Split Tickets and Conversations Into Separate Objects?
A Conversation in Intercom is the chat thread itself: whatever a customer types, whatever a teammate replies, in one running back-and-forth with its own open, snoozed, or closed state. A Ticket is a different object entirely, with its own ID, its own status field, and its own type (Customer, Back-office, or Tracker). Intercom's API treats them as separate resources with separate endpoints, and moving between them takes a deliberate action, like converting a conversation into a ticket or linking a conversation to one that already exists.
That split matters the moment a request needs to survive past the conversation that raised it. A Conversation is built to represent one thread of messages. A Ticket is built to represent a piece of work with a lifecycle, something that can be Submitted, In Progress, and Resolved independent of whatever anyone is currently typing. Reporting, SLAs, and mass status updates all read off the ticket, not the conversation, so a request that never gets converted is invisible to anything that queries tickets, no matter how many times a customer mentioned it in chat.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionWhat a conversation is built to hold
A conversation is Intercom's default unit: a customer sends a message, it opens a thread, a teammate replies inside it, and the whole exchange lives together with a simple state (open, snoozed, closed). Most support ever needs happens here. There's no separate lifecycle to manage, no type to pick, nothing to configure. The tradeoff is that a conversation's state describes the thread, not the underlying issue. Closing a conversation means the chat is done, not that whatever the customer asked about is resolved. If the same bug shows up in five conversations, Intercom has five closed threads and nothing that says they were the same problem.
What a ticket adds on top
A ticket exists to give a request permanence past its originating conversation. Intercom's ticket model defines three types: a Customer ticket, for one person's issue with visible status updates; a Back-office ticket, for internal work with no customer facing it directly; and a Tracker ticket, which represents one known issue that many conversations can link to, so the whole group gets a mass status update when it resolves. Tracker tickets are internal-only, and notes posted on them never reach the customer directly; only the linked conversations do, when the tracker's state changes.
Creating a ticket is a decision, not something Intercom does automatically. A teammate converts a conversation, or opens a ticket directly, or links an existing conversation into a Tracker ticket someone else already started. Each of those actions requires a human to recognize "this is a thing," which is exactly the judgment call that gets skipped when the queue is long and the wording is unfamiliar.
What it looks like when the same request shows up twice
A three-person support team running Intercom for a reporting-dashboard product hit a version of this last quarter. A customer replied in an open conversation that the CSV export "just spins forever on anything over 5,000 rows." The rep confirmed the bug, noted it internally, and closed the conversation once the customer accepted a smaller date range as a workaround.
Nine days later, a different customer filed what was functionally the same complaint, but through the help center's ticket form, which Intercom converts into a Customer ticket automatically. The ticket got its own ID and its own Submitted status, with no link back to the earlier conversation, because nothing on either side prompted anyone to connect them. When the team ran its monthly pass on "what are people actually asking for," the tally read as two separate, low-volume issues instead of one problem two customers had hit independently, and neither cleared the bar for escalating to engineering that month.
That's the failure mode the split invites: a Conversation carries no signal that a matching Ticket exists somewhere else, and a Ticket carries no signal that someone said the same thing in plain chat last week. Intercom's own counts are accurate for each object; they just can't tell you two objects are describing the same request.
Why three people can absorb this and thirty can't
At this size, a team can compensate by paying close attention. That stops scaling as request volume grows, for reasons that are structural rather than a training gap:
- Conversion is a per-teammate judgment call. Whether a given message becomes a ticket depends on whether the rep handling it recognizes it as ticket-worthy, right then. Ten reps make that call ten different ways.
- Status describes the object, not the request, in both directions. Intercom's own support confirms a Resolved ticket does not reopen when the customer replies in the same thread (source), and a Closed ticket can reopen months later with no customer message at all, when a new portal submission gets matched against it (source). Neither direction shows up in the ticket list; someone has to happen to notice.
- Counting happens per object, not per request. The CSV-export complaint above, logged as two unrelated tickets, is the common case once a team is fielding more than a handful of requests a week, not the exception.
- The seam has no owner. Nothing in Intercom flags "this conversation should probably be a ticket" or "this ticket matches one that's already open." Catching it is always someone remembering to look.
Where Modem picks it up
Modem is the product we build, so what follows is our pitch for it, not neutral advice. Modem's Intercom integration reads conversations in real time, whether they stayed plain chat threads or got escalated into a Customer or Tracker ticket along the way, and groups them into topics by what was actually said, not by which Intercom object happened to carry it. The CSV-export complaint above is exactly the case it's built for: a request that arrives as a reply in one conversation and again as a ticket from a different customer still counts as one topic with both people attached, because the classification runs on content, not on ticket status. That's also where the context survives a status change: when a theme gets filed as a tracker issue, the requesters and their original wording travel with it, so a ticket sitting at Resolved doesn't mean the underlying request dropped out of view. For the mechanics of getting requests out of Intercom in the first place, see our guide on tracking feature requests in Intercom with tags, and for the narrower question of whether Tracker tickets alone are enough, see Intercom Tracker tickets vs. dedicated feedback tools. If your ticket and conversation counts already agree with each other, you don't need anything more than what's built in.
The one habit worth adopting either way
If you're not ready to add a tool, adopt one rule: before you close out a monthly count, search the ticket list and the conversation inbox for matching language, not just matching tags. It's the manual version of what Modem automates, and it's the exact gap that split the CSV-export complaint into two counts instead of one.
