Can Intercom Merge Tickets Started From Different Channels?
Mostly, but phone is where it gets complicated. Intercom lets you merge an email conversation into a Messenger conversation and back again, and it lets you merge a plain conversation into a Customer ticket. Phone calls are the exception, and not a clean one. Intercom's own documentation disagrees with itself about which direction is blocked. The capability table marks phone-to-email and email-to-phone both as unsupported. The prose on the same help page says a phone conversation can be merged in as the secondary into a primary email conversation, contradicting the table outright, while agreeing with the table on the reverse: an email conversation can't be merged into a primary phone conversation, and there's no setting that changes that part.
That's messier than a yes-or-no answer, and it's worth knowing exactly where Intercom's own documentation splits before you build a workaround on top of it.
“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 Intercom's merge actually supports
Intercom documents a specific capability matrix for merging conversations and tickets, and outside of phone it's more permissive than you'd guess:
- Messenger and email merge in either direction. A user who messages you in-app and later emails about the same thing can be combined into one conversation, whichever one you designate as primary.
- A conversation can merge into a Customer ticket, but not the reverse. Once something is a Customer ticket, a plain conversation can't be merged into it as the surviving record going the other way.
- Customer tickets can merge into other Customer tickets. Back-office and Tracker tickets are excluded from merging entirely.
- Phone and email conflict in Intercom's own docs. The capability table lists phone-to-email and email-to-phone as both unsupported. The article's prose says the opposite for one of those directions, that a phone conversation can merge in as the secondary under a primary email conversation. Both sources agree that an email conversation can't be merged into a primary phone conversation.
- WhatsApp, Facebook, and Instagram conversations only merge within the same channel and the same user. Slack conversations and tickets only merge with other Slack items from the same Slack channel.
Merging also isn't a message-history combine. The secondary conversation is closed, marked read-only, and linked to the primary with a summary note. Both keep their own conversation IDs; nothing gets deleted or rewritten, it's a redirect with a note attached, not a true merge of the transcripts.
Why the phone gap keeps showing up as a request
Phone's status isn't just contested by outside observers, it's contested by Intercom's own help article. A support lead raised this exact friction on Intercom's community forum, describing tickets that "originated via email or messenger" as impossible to merge "with tickets created from a phone call," and calling the resulting duplication "unnecessarily cumbersome and error-prone." Intercom's reply pointed to the product wishlist for voting rather than a fix or a clarification of which direction is actually blocked, which is the standard response when something is a known gap rather than a bug. As of this writing it's still open, and the merge article's own table-versus-text conflict hasn't been corrected either.
The likely reason phone sits apart from email and Messenger at all is that a call conversation in Intercom is built around a recording and a transcript, not a thread of back-and-forth messages the way email and Messenger are. Merging assumes two things that can plausibly share one timeline; a call's shape doesn't match that model as cleanly as two text threads do, which may be exactly why Intercom's own documentation can't settle on a consistent answer for it.
A support lead who ran into it directly
A facilities manager at one of Redline Metering's utility customers called the support line on a Tuesday about a reading that hadn't synced in three days. The rep took the call, collected the meter ID, and logged it as a phone conversation.
Four days later, with no update, the same person emailed instead, describing the identical missing-reading issue in different words. Whoever picked up the email checked the ticket queue, saw nothing filed under that customer's name, and started triage from scratch.
Both records surfaced within an hour of each other at Redline Metering, a utilities-focused usage-metering vendor, when Carla Bianchi went digging into why one account had two open threads and noticed the overlap. She has run its support queue since the team was half its current size. She tried to merge the email into the phone conversation, the record the original triage notes actually lived on.
Intercom wouldn't let her. An email conversation can't be merged into a primary phone conversation, the one direction where the capability table and the help article's own prose agree with each other.
Carla, after the second ticket closed: "We solved this customer's problem twice. Once on the call nobody closed, and once on an email that didn't know the call existed."
Tagging both with the same customer's account number was the only connection she could make by hand, and that only worked because she happened to remember the call had come in earlier that week.
Where the matrix stops covering you
- Phone is only half-blocked, and Intercom's own docs don't agree on the other half. Merging an email conversation into a primary phone conversation is confirmed blocked, by both the table and the text, and there's no setting that changes it. Merging a phone conversation into a primary email is where the table says no and the article's prose says yes, so testing it against your own account is the only way to know which one your workspace actually does.
- Merging is a manual action, and Intercom doesn't flag the duplicate for you. There's no suggested-match prompt across conversation types. Someone has to notice two records describe the same request before either can be pointed at the other, so the two threads need to be noticed by the same person, close enough together to still connect them.
- A merge only links two records, and the secondary one goes read-only. If the same issue shows up a third time in a different channel weeks later, that's a third manual merge onto a thread that's already closed to further edits, assuming anyone remembers to look for it.
The volume where this breaks isn't high. A handful of overlapping requests a week is enough for the noticing part to fail before the channel restrictions ever get tested, because watching two inboxes for the same account to show up twice isn't anyone's actual job. Modem exists to be the thing doing that watching. We built Modem to ingest Intercom conversations in real time, match Intercom contacts to Modem people profiles by email address, and group everything tied to that person and their company into one topic alongside Slack, Discord, and GitHub activity. An email thread and a Messenger conversation about the same issue land on the same topic even when Intercom's own merge rules would keep them apart, because Modem is building its own record on top of Intercom rather than merging Intercom's records for it. It doesn't ingest phone calls today, so the phone-specific gap in this guide is still yours to solve by hand. Details on the Intercom integration are here.
If you're not there yet, the cheap version of the same idea is a shared identifier: put the account or customer ID into every ticket's title or a custom field regardless of channel, so a search on that field finds the phone conversation even when the merge button won't combine it with the email one. It's slower than an automatic match, but it beats relying on memory. For the related question of why Intercom keeps conversations and tickets as separate objects in the first place, see why Intercom splits tickets and conversations, and for getting ahead of the underlying feature requests before they fragment across channels, see how to track feature requests in Intercom.
The one habit worth adopting either way
Before closing any conversation or ticket, search the customer's email or account ID across both the conversation inbox and the ticket list, not just the thread in front of you. It won't catch a phone call you don't already know happened, but it catches the email-and-Messenger case the matrix already supports, and it's the exact check Redline's team was missing when the same reading issue got solved twice.
