Why Does Intercom Push Feature Requests to a Separate Product Wishlist Instead of Tracking Them Natively?
Feature requests in Intercom go one of two places, and neither is inside the conversation where the customer typed them. If a teammate happens to notice a pattern, they can manually copy the request into Intercom's Community Product Wishlist, a public voting board at community.intercom.com/ideas. If nobody does that, the request lives nowhere at all, just plain text in a closed conversation. Neither path happens automatically, because Intercom's data model has no object called "feature request" for the platform to route the message into.
Intercom's own support staff tell customers to do exactly this, so the answer to "why does it end up over there" isn't a mystery. On a public thread asking Intercom to support a specific feature, an Intercom team member replied telling the requester to check the wishlist to see if the idea already exists, and to add it themselves and gather votes if it doesn't (source). The request the customer already typed into a conversation gets manually re-typed, by the customer or the support team, into a completely separate site.
Intercom's three ticket types
Intercom's inbox splits into two kinds of objects. Conversations are the raw back-and-forth; Tickets give a request a lifecycle. Tickets come in three default types, and the help center covers each one. A Customer ticket handles one person's issue with visible status. A Back-office ticket covers internal work nobody outside sees. A Tracker ticket groups many conversations under one internal issue, and cascades the update to everyone linked once you confirm it.
None of those three is a feature request. A Tracker ticket comes closest, since it can hold "N customer reports" against one internal problem, but Intercom built it for known bugs and incidents, not open-ended asks for something that doesn't exist yet. There's no fourth type, no dropdown option, no field anywhere in the conversation or ticket UI that says "this is a feature request" and routes it somewhere a product team can rank it. A support rep who wants to preserve a request has exactly two native options. Tag the conversation, which keeps it in Intercom, searchable but uncounted against anything. Or manually post it to the public wishlist, which counts it, but outside Intercom entirely.
“export is broken for us”
“any update on SSO?”
“we hit the rate limit again”
Read + clusteredInside the Community Product Wishlist
The Community Product Wishlist is not a feature of the Intercom product a support team logs into. It's a public site, community.intercom.com/ideas, built for anyone (customers, prospects, competitors' employees, nobody in particular) to post and upvote ideas. Submitting one means clicking "Share an idea," writing it up from scratch, and picking a product category. Intercom's help article on it is direct about how voting connects to the roadmap, calling the top 20 most-voted community ideas "inputs to the product roadmap," alongside "other factors... like complexity, impact, reach, and alignment with Intercom's strategic product roadmap." Ideas move through visible statuses, Submitted, Planned, In Beta, Released, or Similar functionality, and voting on one auto-subscribes you to its updates.
That mechanism is a genuinely reasonable way to run a public roadmap, in the same category as boards from Canny or Featurebase, not a broken feature. What it lacks is any described connection back to the conversation, ticket, or customer record that produced the request. Intercom's own documentation doesn't mention a link between a wishlist post and the support thread it came from. The wishlist runs its own login, with SSO available as a convenience rather than a requirement, and a customer's Intercom account inside your workspace and their community profile stay two separate records that happen to share an email address if you're lucky.
What that costs at Faircrest
Faircrest builds time-tracking software for creative agencies, and Liesel Alvear runs its three-person support team out of Intercom. A designer at one of Faircrest's agency customers asked, in an open conversation, whether timers could round to the nearest quarter hour instead of the nearest minute, since her agency billed clients in fifteen-minute blocks and every invoice needed manual rounding before it went out.
Customer (via Intercom): Is there any setting to round tracked time to 15-minute increments? We bill in quarter-hours and I'm hand-adjusting every invoice right now.
Liesel: Not currently, it always tracks to the exact minute. I'll flag this as a request on our end.
Liesel tagged the conversation feature-request, and because it was the third time she'd heard some version of this ask that month, she took the extra step and posted it to the wishlist herself, writing "Round tracked time to configurable increments (5/10/15 min) for invoicing." She wrote it from memory, in her own words, three weeks after the original conversation, because that's when she got around to checking the wishlist for duplicates.
The post picked up eleven votes over two months, all from people who found the idea on the public board and none of whom Faircrest could identify as paying customers versus visitors browsing the roadmap. Meanwhile, the original conversation, plus two more Liesel never got around to re-typing, sat tagged inside Intercom with the actual account names, plan tiers, and exact wording attached, invisible to anyone looking at the wishlist's eleven votes. When product eventually asked "who specifically wants this," the answer required Liesel to go searching Intercom by tag again, because the wishlist post she'd written carried none of that.
The manual bridge breaks down at scale
The re-typing step is fine at Faircrest's volume, three people, a few dozen tagged requests a month. It breaks down for structural reasons that get worse with size, not habit:
- Someone has to notice, then choose to act twice. Recognizing a request is worth a wishlist post is a judgment call, and writing it up on a separate site is a second piece of work most reps do only when they remember to.
- Whoever re-types it decides the wording, not the customer. A request phrased three different ways by three different customers becomes, at best, three separate wishlist posts under three headlines nobody thought to search for first.
- Votes and identity never meet. Eleven upvotes from anonymous community accounts carries less weight in a roadmap argument than "three enterprise accounts asked for this by name," and Intercom's wishlist can't produce the second number.
- The two systems drift permanently. A wishlist status of "Planned" doesn't update the original conversation, and a conversation getting tagged again doesn't touch the wishlist post's vote count. Nothing keeps them in sync because nothing links them in the first place.
For a team fielding a handful of well-known asks, tagging conversations (and opening the occasional Tracker ticket for the ones that turn into real bugs) is a reasonable place to stay; the tag is doing the actual tracking there, not the ticket type. Our guide on tracking feature requests in Intercom with tags covers that setup directly. Past a few dozen requests a month, the re-typing step becomes the actual bottleneck.
How Modem removes the re-typing step
We build Modem, so read this as a disclosed pitch rather than neutral advice. Modem's Intercom integration reads conversations as they happen and classifies feature requests directly from what was said, without anyone re-typing a summary onto a separate board. The quarter-hour rounding request above becomes a topic the moment Liesel's customer typed it, with her account, her company, and the exact wording attached, and the second and third mentions of the same ask land on that same topic instead of never getting written up at all. That topic sits inside a context graph linking the request to the person and company behind it, so when product asks "who wants this," the answer is already attached instead of requiring a second search through tags. Modem doesn't replace a public roadmap board if you want customers voting in the open; it replaces the manual step of deciding what's worth writing up there in the first place, and it keeps counting the ones that never make the cut.
One habit that narrows the gap without a tool
If a wishlist post is worth writing, write it the same day, in the customer's own words, and drop a link to it as an internal note back on the original conversation. That one-line habit doesn't fix the identity gap, a vote is still anonymous, but it stops the drift between "what the customer said" and "what the roadmap post says" from starting on day one instead of three weeks later.
