Share product ideas and upvotes with our product team
We’d like to have individual agent Slack notifications for when a conversation is assigned. This would help cut down on noise in our Slack channel, and allow our team to meet critical SLAs.
Currently, navigating between different Intercom ticket types (chat, phone, email) is confusing and unintuitive. We’re hoping to see UI changes that leverage more intuitive visual design principles. One possible low-lift suggestion could be as simple as implementing different color-coding for each unique channel (ex: Green border on Intercom window for chat contacts, orange for emails, etc).
It would be an enhancement in user experience if it would be possible to set background colors to the different ticket types. We have teams that process both customer tickets and back-office tickets and it is now sometimes confusing for them, because there is only a slight difference in what they see. If we could put a background color for example to back-office tickets, that would help them make the distinction between the different types.
Currently, when we edit article titles in the help center, the URL automatically updates to match the new title. This breaks all existing links to that article across our ecosystem, including:Article cross-references External website academy links to our articles in helpcenter Email automation sequences directing to articles in helpcenter Any other systems linking to our help centerRequested Solution:URL Persistence: Keep article URLs stable when titles are edited, similar to how website platforms handle page URLs Manual URL Control: Allow manual editing of article URLs when needed Redirect System: Automatically redirect old URLs to new ones when URLs are manually changedBusiness Impact:For organizations with extensive linking systems (cross-references, external websites, email automations), title changes create significant maintenance overhead. We make regular title updates for clarifications, spelling corrections, and content improvements as our platform evolves, making this a frequent pain point.Current Workaround:None available - we must manually track and update all links across multiple systems whenever we edit article titles.
Currently, “Snooze to tomorrow” is a fixed option to 9:00.I would like to suggest making this a custom field, meaning that as a company we can decide that “Snooze to tomorrow” will be set to 10:00 for example.(Same for other fixed snooze times)This will really speed up our process of having to use the “Custom” button every time.
Previously, when a new conversation opened, I could press Tab to quickly insert a greeting like “Hello!” and start replying faster. This shortcut is no longer appearing in my Inbox.I’d like this behavior restored so teammates can quickly send a greeting using the Tab key when a new conversation opens.You can paste that directly into the Share an idea form on the wishlist. Once posted, others can upvote it and you’ll get updates if the status changes.
Hello Fin team,It's easy to go a little blind on resolution rates, since what really matters is what the customer believes is the truth. Fin will calculate an assumed resolution if a customer stops replying to the thread and leaves. Although this is quite common in the SaaS industry, it is also not a very safe indicator that the issue was in fact resolved. Even for confirmed resolutions, it may be that the customer thought it was perfect and confirmed, but later found that this was actually not the resolution anyway. To get a better picture of this, please consider this feature request for reporting:Any lead or user who does not only reopen a previous conversation (this can already be done in reporting), but opens a new conversation within X time (a variable that we should be able to select), is considered a recontact. The combination of AI resolution together with low recontact rate is dynamite, and far stronger than just showing off with a high AI resolution alone. Thanks,Christian Osmundsen, Deliverect
In our setup we use five Intercom workspaces and one Slack workspace, so it’s critical to be able to add the same Slack workspace to multiple Intercom Workspaces in this setup.
Currently we can set assignment limits to our team members based on the Inbox, but we cannot do it by Channel. Ideally, we would like an additional control option to set capacity limits by channel. Also worth noting that currently, if you’re on a call you will not be assigned a Chat, but if you’re assigned Chat’s you can be assigned a phone call. As an example, if we have someone working on multiple Chat interactions, we do not want them to then be assigned a Phone Call. In this same instance we could want the ability to set a larger number of email assignments to a team member and would want to limit the number of Chat conversations they are assigned simultaneously. Doing this could help us prevent live channel interactions that step over each other like in the case of a chat being assigned while the team member is on a phone call.
Here are some failure points.Network error A race condition currently happens in my app where a logout runs while a login is in-flight If SDK is stuck in failed registration and I try to log in a user Generic errorGeneric errors are errors that might have different reasons that I don't know about yet.All of these give me "[HTTP - 1] Something went wrong" on android and "Error in <METHOD_NAME>" on iOSThis is problematic since I can't segregate the errors and I can't find out why each one happens except for checking each user session and find out why this was thrown manually.I would rather having error codes for different failures, and the failures I mean here are not the ones I said only, the engineers will know best what are all the failure points and create an error code for each.
Currently on the mobile SDK whenever we call `loginUnidentifiedUser` it creates an unidentified user in the Intercom dashboard.This makes it so annoying to actually handle filtering between unidentified and identified users (we use “Is Mobile Unidentified” flag), it causes a problem in merging contacts when they become identified so they lose their other conversations, and the proposed solution by the team results in a ton a of orphan unidentified users…Here's a question another user asked about
Hey there, I would really like to be able to merge conversations. is that on the roadmap yet?
The problem in one line: Audience targeting and article cross-linking are both core Help Center features — but they break each other, and in the Messenger the result is that customers are pushed to a sign-in wall and end up contacting support, which is the exact opposite of what a Help Center is for.How our Help Center is set up:We plan to use audience targeting to serve different versions of the same content to different customer types. For example, we will have two articles:• "Customer Center - SIM" — shown only to our SIM audience• "Customer Center - TM" — shown to all other customersThese are separate articles with different IDs — Intercom has no way to know they're two versions of the same topic. This won't be a one-off: we plan to have other audience-split article pairs across the knowledge base, and the number will grow every time we tailor content for a new audience.The blocker we hit:In testing this setup, we found that cross-linking breaks it. A third article, shown to everyone, links to "Customer Center - TM." That single link works for most customers but is broken for the entire SIM audience — the SIM customer can't see the TM article, and there's no way to point them to the SIM version instead. We can only link to one fixed article ID.Why it's especially bad in the Messenger (where most of our customers read):• Normally, clicking an article link in the Messenger opens that article inline, right inside the conversation — smooth and in-context.• A customer who IS in the linked article's audience gets exactly that.• A customer who is NOT in that audience gets kicked OUT of the Messenger to a web page telling them they're not part of the audience and must sign in to view the article.So a customer using our Help Center exactly as intended — reading an article, clicking a relevant link — is suddenly bounced to what looks like an access-denied / login wall, for content they were never supposed to see, when a perfectly good version written specifically for them already exists. The customer did nothing wrong. The audience targeting created the problem.The consequence (this is the part that matters most):The customer's only path forward from that sign-in wall is to contact support. So audience targeting ends up generating support conversations — the precise outcome a self-service Help Center exists to prevent. Every audience-split article we link to becomes a potential support ticket for everyone outside that audience. The more we invest in tailoring content by audience, the more support volume we create. The feature works against its own purpose.This is also why we can't move forward with audience targeting the way we'd planned: adopting it more widely would mean knowingly creating these dead-ends across the knowledge base. The gap is effectively capping how much we can use a feature we want to use more.A question for Intercom: does this also affect Fin and other surfaces? If audience-restricted articles behave this way when linked, the same wall could likely appear anywhere Intercom surfaces that article — Fin citing it in an answer, suggested articles, or search results — for a user outside the audience. We haven't fully tested this, but if so, the impact is far wider than manual cross-links and would directly undercut Fin's resolution rate. Worth investigating on your side.The request: Audience-aware article links — a single link that resolves to the correct article for the reader's audience and opens inline in the Messenger like any other article link. Possible approaches:1. Article groups / variants — designate "Customer Center - SIM" and "Customer Center - TM" as audience variants of one logical article, then link to the group; Intercom serves and opens whichever variant matches the reader.2. Audience-conditional links — map a link per audience when inserting it (SIM → SIM article, everyone else → TM article).3. At absolute minimum — stop ejecting Messenger users to a sign-in wall. If a linked article isn't available to the reader, fail gracefully inside the Messenger (hide the link, or route to the parent collection) rather than throwing an access/sign-in page that dead-ends into a support contact.Why it matters: This isn't a cosmetic gap. It turns two of the Help Center's core features into a source of customer confusion and avoidable support volume — and it's currently blocking us from adopting audience targeting the way it's meant to be used. Thanks for considering!
Currently, website source re-sync requires a full crawl of the entire website, even when only a single new page or a small number of URLs have been added or updated.For organizations with large knowledge bases, this can be inefficient and time-consuming. In our case, we have thousands of indexed articles, and triggering a full re-sync just to make one new page available to Fin is not practical.It would be valuable to support one or more of the following capabilities:• Sync a specific URL or a set of URLs on demand• Incremental sync that only processes new or modified pages since the last crawl• Ability to submit a URL or a set of URLs for immediate indexing without triggering a full website re-syncBenefits:• Faster availability of new content in Fin• Reduced crawl time and resource consumption• Better experience for teams managing large documentation sites• Improved agility for time-sensitive content updatesThis would significantly improve knowledge management workflows for customers with large and frequently updated websites.
QA Metrics typically track how long a call was on hold for - we like to train our agents to stay under a certain threshold. Our previous phone provider had a timer that counted how long the the call had been on hold once the hold button was pressed. This helps the agents stay accountable when tracking how long they’ve left customer’s on hold. We would love to see this feature land on the roadmap soon.
We currently use Fin Service for our e-commerce site, and it handles our 2,000+ SKU catalog well. That said, Fin for E-Commerce looks far more capable than Service when it comes to actually selling products. The catch is that we run on Magento, not Shopify, so E-Commerce isn't available to us. I'd love to see E-Commerce support extended to platforms beyond Shopify.
Already have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
OKSorry, our virus scanner detected that this file isn't safe to download.
OK