How to turn an Intercom conversation into a GitHub issue without losing who asked
Intercom already has a built-in way to do this: hover over a comment or note in a conversation, choose "New GitHub issue," and Intercom files it in your connected repo with the conversation text, any images, a link back, and the customer's details attached automatically. When that issue closes, Intercom posts a note in the original conversation and reopens it if it had gone quiet, so the customer is right there for you to reply to. That's the mechanism, and for a single customer reporting a single bug, it's genuinely complete.
The part that takes more than the built-in app is what happens when more than one customer reports the same thing. Two separate conversations become two separate GitHub issues, and closing one doesn't touch the other, which is exactly where "which customers does this affect" quietly turns into "whichever one conversation happened to be linked to the issue that shipped."
What the GitHub app actually does
Intercom's GitHub app covers three things, and it's worth knowing the exact shape of each one before you build a habit around it:
- Creating an issue from a conversation. Hover over any comment or internal note, select "New GitHub issue," and the issue is created with the conversation text, screenshots, a link back to the conversation, and the customer's name and details already in the body. Nothing gets retyped.
- Linking to an issue that already exists. If the bug already has an issue open, paste the conversation's URL into that GitHub issue or a comment on it, or add the GitHub issue's URL as a note on the Intercom side. Either direction creates the link, and Intercom won't leave a new note in a conversation that's already linked to the same issue.
- Reopening on close. When the linked GitHub issue closes, Intercom leaves a note on the conversation and reopens it if it had been snoozed or closed, which is the mechanism that answers "how do I follow up when it ships." You don't have to remember to check GitHub; the conversation comes back to you.
The setup has one real constraint: you pick a single "main" repo that conversations create issues into directly, and each teammate can only add repos they personally have GitHub access to. Other repos still work, but only through the manual link step, not the one-click create.
Same bug, two conversationsWhere Corda Field Service hit the gap
Corda Field Service builds scheduling and job-status software for HVAC and plumbing contractors, and support runs entirely through Intercom while engineering ships out of GitHub, with the native app connected on the main repo.
Priya Larkin, Redwood Mechanical (conversation #1187): "Our job tickets have been stuck on 'in progress' for two days even after the technician marks it complete in the field app. Dispatch is manually double-checking everything now."
Marcus Diallo, who runs support at Corda, hovers the message and creates the issue directly. It comes in as #412: Job status doesn't update after technician marks complete, with Priya's name, Redwood Mechanical's account, and the conversation link already in the body. Two weeks later, a second contractor hits the same bug independently.
Theo Kessler, BrightPath Plumbing (conversation #1204): "Completed jobs aren't clearing from the active board. We're having to manually mark them done on our end."
A different teammate handles this one, doesn't recognize the pattern from the wording, and creates a second issue, #418. When an engineer picks up #412 a few days later, he searches and finds #418, confirms it's the same rounding bug in the completion-sync webhook, and comments "Duplicate of #412" before closing #418.
Here's the part that surprises people: closing #418 does what the app promises, it posts a note on conversation #1204 and reopens it. But the note just says the issue closed. It doesn't say the fix is the same one that shipped for Redwood Mechanical, because GitHub's own duplicate-marking feature only adds a comment and a timeline event linking the two issues for a human reader. It doesn't move comments, doesn't merge conversations, and doesn't touch anything either issue is linked to in Intercom. Marcus had to open both conversations himself and write the same confirmation twice, because nothing connected Theo's ticket to the fix that had already shipped for Priya.
Where the native link stops covering you
The gap isn't the create step or the reopen step. Both work exactly as documented, for the one conversation that's linked to the one issue that closes. What it doesn't do:
- Duplicates don't inherit each other's customers. Marking an issue a duplicate is a GitHub-side comment, not a merge. Whatever's linked to the duplicate stays linked to the duplicate, not to the surviving issue.
- Renamed issues are fine, reassigned repos are the risky part. The link tracks the issue itself, so a title change or a new assignee doesn't break it. Moving the fix to a different repo than the one the conversation's issue lives in is where you'd have to relink by hand.
- Nobody's counting how many conversations point at the same underlying bug until an engineer happens to search for it, the way this one did by luck.
Below a few duplicate reports a month, that's a "search before you file" habit, not a system problem. Past that, it's the same shape of gap covered in linking GitHub issues to the customers who reported them: the connection exists in exactly one place, and a person has to notice when a second copy of it shows up.
What Modem does differently here
This is squarely the category we build Modem for, so weigh the recommendation accordingly. Modem reads Intercom conversations as they arrive, using the Intercom integration to pull in the conversation, the customer, and their company, and groups Priya's and Theo's reports into one topic before either one becomes a GitHub issue. It doesn't need the wording to match to do that: Modem reads what each conversation is actually describing rather than searching for shared keywords, which is how it catches a connection that neither teammate spotted from the words alone. One topic files one issue, with both accounts attached from the start. On the GitHub side, when the PR that fixes it merges, Modem matches the merge back to the topic and surfaces both Priya and Theo as people to follow up with, whether or not anyone remembered to mark a duplicate or relink a conversation. The attribution lives in Modem's own record of the topic, not in whichever single GitHub issue happens to still be open, so a rename, a duplicate marker, or a reassignment doesn't disconnect it. If your volume is a handful of overlapping reports a year, the native app above is the right amount of tooling; this is for the point where duplicates start slipping past the person filing them.
The cheapest fix, no new tool required
Turn on Intercom's GitHub app on your main repo if it isn't already, and add one habit: before filing a new issue, skim the open and recently closed issues in the feature area the report touches, not just a keyword search on the customer's own words. Theo's report didn't share Priya's wording at all, "active board" versus "in progress," so a literal text search would have missed the connection just like the second teammate did. But both reports trace back to the same completion-sync code path, and a few minutes spent looking at what's recently shipped or reopened there would have surfaced #412 before #418 ever needed a duplicate marker. It takes longer than a keyword search, but it doesn't depend on guessing the other customer's exact phrasing. For the customer-support side of catching these before they fragment, see how to track feature requests in Intercom.
