Intercom Feature Requests: Get Them Out of the Inbox and Onto the Roadmap

A feature request that arrives in a support chat usually ends its life there, tagged and closed, and the engineer who could build it never sees it.

The story I hear from support leads is the same every time. A customer asks for CSV export in the middle of a billing question. The agent says “good idea, I’ll pass it on”, adds a feature-request tag, and closes the conversation. Three weeks later the PM asks whether anyone wants CSV export and the answer is a shrug, or a search through Intercom by tag that turns up 40 conversations nobody has read since.

Tickets are worse in one way and better in another. Worse because they get filed by the agent, so the customer’s own words are one step removed. Better because a ticket has a title, a description, a type, and internal notes, so it is often the clearest write-up of a request the team will ever get. It still lives in Intercom, and the engineer still never opens Intercom.

I want to look at how teams handle this today and what a setup that works looks like.

What do teams do with Intercom feature requests today?

Four patterns cover most of the teams I have talked to.

The tag-and-spreadsheet setup is the default because it costs nothing and takes five minutes to start. It also decays the first busy week. The agent stops retyping when the queue fills up, and the spreadsheet freezes at whatever week that was.

Intercom’s own reports can chart conversations by tag, so you can see the CSV-export tag went from 3 a month to 11. That is a useful number. It is also the whole output. The 11 conversations have no home outside Intercom, nobody can vote on them, and the engineer who would build export never sees a single one.

Zapier fixes the retyping. A tag-added trigger copies the opening message and a link into a sheet or a board. It does not know that the 11 conversations are the same request, and nothing comes back: when export ships, the sheet row still says open.

Canny puts an app inside the Intercom inbox, and Featurebase has an integration of the same shape. The agent opens it on a conversation, creates a post or links an existing one, and can vote on the customer’s behalf. This is the best of the four when the agent does it. It is still one click per conversation, by hand, on the busiest person in the loop. Canny’s AI reader that does it for you is metered per conversation on Autopilot credits (I wrote up how that works).

A founder in r/SaaS described the underlying problem better than I can, after going from spreadsheet to Notion to Linear and back:

“the problem with all of those is they capture the request but lose the context. a row that says ‘add export to CSV’ tells you nothing about who asked, why they needed it, what they were actually trying to do, or whether 5 other customers described the same need with different words.”

“the support tickets mentioning the same pain, the churn reasons that map to the same gap, the sales calls where prospects asked about it - all of that is the real picture. a spreadsheet can’t hold that.”

What does a setup that works look like?

The test I would apply: can an engineer get from a customer’s words in Intercom to a fix without a PM relaying it, and can the customer find out when it ships without the agent remembering to tell them. In the tag-and-spreadsheet version there are three steps between those two points: the agent tags, someone copies the conversation into a row, and the PM reads the rows in a weekly review. The copy step is the one that gets skipped.

1. The agent’s only job is the tag. One tag in Intercom, applied mid-conversation, and they move on. If capture takes more than that, it stops happening on a busy day.
2. Everything tagged flows to one board on its own. Conversations and tickets, with the customer’s email attached and a link back to the original thread. Nobody retypes anything.
3. It lands next to the widget and email feedback. The CSV-export chat sits in the same cluster as the three widget reports and the two emails about export, so the count is six, not one.
4. Customers can vote on it. The request is on a public board, so the next person who wants export upvotes instead of opening a fresh chat.
5. The engineer picks it up from the board. One click to a GitHub or Linear issue with the customer’s words in it, and status flows back so the board says shipped when the issue closes.

This is the direct line from user to engineer, applied to support. The agent adds a tag and the engineer reads the request, with no meeting or spreadsheet in between.

How Usero does it

I build Usero, so read this part with that in mind. The setup above is what the Intercom integration does, and here is the plumbing in the same terms.

• Connect with OAuth, read-only. It asks Intercom for three scopes: read conversations, read tags, read one user and company. No admin access, and it never writes to your workspace.
• Pick your tags. A tag allowlist in settings, matched case-insensitively. Leave it empty and every conversation imports; set it to “feature-request” and only those do.
• Hourly poll. Every hour it pulls the conversations updated since the last run, 200 per pass, and carries any overflow into the next hour. There is a Sync now button in settings for when you do not want to wait. On connect you choose whether to start from now or backfill the currently open conversations.
• Tickets come through whole. A ticket imports as one feedback item with its title, description, every custom attribute your team filled in, and the internal notes and replies, oldest first. Ticket import has its own switch and a ticket-type filter, separate from the tag allowlist, because tickets filed by an agent usually carry no tags.
• Deep link back. Each item links to the conversation or ticket in Intercom, so the engineer can read the whole thread when the summary is not enough.
• Then it is ordinary feedback. It clusters with widget, email and Slack items, appears on the public board, can be voted on, and becomes a GitHub or Linear issue with one click. If the repo is connected, Usero can also open a pull request with a first pass at the fix for the engineer to review.

Setup steps and the redirect URLs are in the Intercom docs, and the feature page has screenshots. It is on the free tier.

What it does not do yet: webhooks (an hour is the worst-case delay), writing back to Intercom when a request ships, and auto-tagging with AI. Right now the agent decides what counts as feedback, which I think is the right default for a support team that already has opinions about that.

If your support volume is 20 conversations a week, tag and spreadsheet is fine and you should keep it. If it is more than that, open Intercom, search by your feature-request tag, and count how many of those conversations made it to the roadmap. I would be curious what number you get.

Related Reading

• How Savio Pulls Feedback Out of Intercom, Zendesk, and Help ScoutRead
• How to Organize Feature Requests Without DrowningRead
• How to Sync User Feedback With Linear Issues, Both WaysRead
• Slack Feedback Tool: Capture Feedback With an Emoji, Ship the FixRead

Frequently Asked Questions