Share product ideas and upvotes with our product team
Just how phone calls have a different tune when they come in, I think it would be super helpful if live chat had a different ringtone as well! Or even being able to set a different ringer for differnet inboxes would be nice to recognize different inboxes that may have shorter first response times, closing times, etc.
Currently, Intercom does not provide a native export capability that allows teams to export all Knowledge content into a spreadsheet format such as Excel. Adding the ability to export published content, along with key metadata, would significantly improve content governance and operational efficiency.This functionality would support activities such as content audits, inventory management, reporting, and maintaining change logs outside of Intercom. Having a centralized export of all published Knowledge content would make it easier for teams to review content at scale, identify gaps or outdated information, and manage documentation processes across systems.Request: Feature request that enable administrators to export all Knowledge content and associated metadata to a downloadable Excel or CSV file. This export should all content types (i.e internal, public, snippets) and include both published and archived content. As well as relevant article details (e.g., title, status, author, last updated date, category, and URL).
Currently, callbacks are automatically assigned to a specific user rather than being left open for someone to pick up. This is disruptive to our workflow — we'd prefer to choose ourselves when we take a callback, similar to how tickets work today (where they sit available until someone claims them).Why this matters: Rejecting an assigned callback is time-consuming, and we're trying to work as efficiently as possible. Having callbacks behave like tickets — available for pickup rather than pre-assigned — would remove that friction.Suggested change: Make callback claiming behave like ticket claiming, i.e. queue-based/self-select rather than auto-assign.
Hello, I would like to request adding Azerbaijani language as supported language on help center, because we are having a lot of clients requesting support in AZ. Thank you!Eyeball Support
Currently, sending a bulk outbound email to a specific list of people requires: uploading a CSV via "Filter audience from CSV," having those contacts already exist in Intercom (the CSV only filters/tags existing users and leads — it doesn't create new ones), tagging them, then building an audience rule around that tag. If any of the target emails aren't already in Contacts, the CSV filter simply won't find or tag them, so they're silently excluded from the send. In practice this means before sending to a list, we first have to import those emails as contacts, then run the CSV filter to tag them, then build the message around the tag - and clean up duplicate contacts created in the process. For a simple "send this email to this list of people" task, that's a lot of manual setup and prone to errors (duplicates, silently dropped recipients). We'd like a simpler option: either paste a list of email addresses directly into the outbound message audience, or upload a CSV of emails, and have Intercom send to exactly those addresses - regardless of whether they already exist as contacts. This would remove the need to pre-populate Contacts just to do a one-off bulk send.
Our team treats chats and tickets differently once closed, but both the Email and Messenger settings currently apply one shared rule to both types, so we can't configure them to match our actual workflow.For chats, once closed we want them to stay closed - any reply, whether via Messenger or email, should route through our automation that converts it into a new ticket rather than reopening the original chat. This keeps chat volume clean and ensures the conversation gets proper ticket-level tracking, prioritization, and SLA handling instead of being buried as a reopened chat.For tickets, the opposite is true: once a ticket is closed, we generally want customers to be able to reply and reopen it directly, since the underlying issue may still need follow-up work by the same team, and creating a brand-new ticket would fragment the history and context of that case.Right now, because the setting doesn't distinguish between the two, we can't apply "prevent reopen, convert to new ticket" logic to chats without also affecting tickets in the same way (and vice versa). This forces us to either accept the wrong behavior for one type or manually catch and fix misrouted conversations - which is exactly the manual work we're trying to eliminate with our reopened-to-ticket automation. Splitting these into independent controls for chats and tickets (across both Messenger and Email) would let each conversation type follow the closure/reopen behavior that actually fits how our support and escalation process works.
Both the Email setting ("Create new conversations when customers reply to closed conversations," Settings > Channels > Email > Advanced) and the Messenger setting ("Prevent visitors replying to closed conversations," Settings > Channels > Messenger > General) only accept a minimum of 1 day. We need this configurable in minutes/hours (e.g. 30 min–1 hour) instead, so a reply shortly after closing doesn't reopen the original conversation. A 1-day window is too long for how quickly our conversations get closed and potentially replied to.
See this thread: https://community.intercom.com/topic/show?tid=32&fid=6
Current Behavior:The workflow action "Show expected reply time" produces incorrect German output in two ways: Pronoun formality ignored: Despite "Fin's pronoun formality" being set to "formal" (Sie), the German output uses the informal "Du" form — e.g. "Du erhältst Antworten hier und an user@mail" — instead of the correct formal "Sie erhalten Antworten hier und an user@mail." Grammatical error: The phrase "Wir antworten normalerweise in ein Tag" is grammatically incorrect. The correct German dative form requires "einem", not "ein": → "Wir antworten normalerweise in einem Tag." Current Output (example): "Das Team wird sich diesbezüglich melden. Wir antworten normalerweise in ein Tag. Du erhältst Antworten hier und an user@mail."Expected Output: "Das Team wird sich diesbezüglich melden. Wir antworten normalerweise in einem Tag. Sie erhalten Antworten hier und an user@mail."Steps to Reproduce:Set Fin's pronoun formality to "formal" in the Intercom settings. Create or use a workflow containing the "Show expected reply time" action. Trigger the workflow for a German-speaking user. Observe the reply message displayed.Impact:The informal "Du" address contradicts the configured communication standard and may appear unprofessional to customers. The grammatical error ("in ein Tag") reduces credibility and trust in automated responses.Proposed Fix:Ensure the "Show expected reply time" action respects the configured pronoun formality setting across all localized strings. Correct the German translation of the reply time string to use the grammatically correct dative form: "in einem Tag."
Allow bulk closing tickets/conversations with setting ticket attributes and ticket state.As well, allow bulk merging of conbvesrations/tivckets.
I would love to have some settings available that would make our workspaces look immediately different. This is gonna be crucial later on when we forget on which workspaces we are currently in. The easiest would be to change its colors or shades of colors, and later on even more.We might get into issues if we somehow reply as a different company in our tickets one day because of this.
CONTEXTJust had a 2 hour conversation with Fin AI that was confusing and it ended with me being told the metric I am using is a Legacy metric, which is why it is not matching with the Intercom-native reports I am seeing. Intercom currently has two Elasticsearch pipelines: a newer one used by current reporting charts and a legacy pipeline used by older charts. Because of this, some metrics in the reporting UI (for example “Conversation created at”) come from the legacy pipeline but are not clearly labeled as such. This makes it easy for users to select them without realizing they may not be the current source of truth. SUGGESTIONAdd a visible “Legacy” badge to these metrics. It would help customers quickly distinguish them from the newer reporting metrics and avoid confusion during the reporting transition.
I am interested in allowing users to be able to test workflows within our test environment, but have been informed that permission sets must mirror the production environment. It would be incredibly helpful to allow more users to publish outbound messages/workflows within our test environment so that they don’t have to ask permission to test workflows within a controlled environment, where the impact to active users is removed.
Feature Request - for our workspace implementation, we've shrank the auto-away time to 10 minutes so we can utilize the new Average Adjusted Handle Time metric, however in doing so, other departments that have much lower inbound volume or that use round robin for back-office tickets, are being impacted. We need the ability to set auto-away time based on teams or brands.
Surface Guidance reporting in the MCP, so I can have my agent review reporting against guidance and ticket data to improve quickly.
When syncing a website for Fin, the crawl often imports a large number of pages. Currently, restricting Fin’s access to specific pages requires manually disabling them in the UI, which does not scale for large sites.It would be valuable to add API support for bulk updating External Pages after a full website crawl, allowing teams to programmatically limit Fin’s availability for selected pages (for example via a bulk update endpoint). This would enable automated pruning of redundant or unwanted pages without manual UI changes.I attempted to set fin_availability = FALSE via PUT /ai/external_pages/{page_id}, but the request failed because the page belongs to an automatic website sync source. Intercom returned:Content Import Source must have API sync behaviour.The current API workflow requires creating an API-based Content Import Source and POSTing pages to the External Pages endpoint to create or update them. Because of this, teams must either:determine the preferred pages before importing via the API, or manually disable pages in the UI after a full crawl.Allowing teams to sync the site first and then programmatically restrict pages afterward would make the process significantly easier.
It would be great to be able to pause multiple series at once, instead of having to open each series - hit te pause button - wait - and then open. the next one. Especially with the holidays I gave about 40 to 50 live flows that I need to pause. Thanks!
Instead of using Balanced or Round Robin, have an option where you can assign a number to each Intercom user based on who should get tickets first.Whoever is in spot #1 would be first to get new tickets (useful for new hires or if someone isn’t pulling their weight) Then it would go down to #2, #3 etc so that the most experienced person on the team is the last to get tickets.Reason I ask this is that balanced isn’t really balanced, if someone is in there all the time working and closing tickets, they get more, whereas they should be last in the queue.
Hi ! I’m running into a limitation with Fin AI and multi-brand setups.I have two brands, each with its own inbox, but currently Fin replies from a single inbox… Regardless of the brand the customer is contacting.This causes issues with context, audience targeting, and consistency.It would be great if Fin could reply using the correct inbox per brand.Hope this feature is considered!
Having an out of office for a particular inbox, rather than workspace. We have teams who aren’t customer facing working on back office tickets/have chats in their name while tickets are being dealt with in Jira. It would eb good to have an out of office for their inbox so customers know to create a new chat for a response from our customer services team as the escalations team wouldn’t deal with this.
Would it be possible to add an audible notification or desktop alert when an agent is automatically switched to Away after 5 minutes of inactivity?This wouldn't change or bypass the idle timer. Instead, it would simply notify agents immediately after they're marked Away, allowing them to switch back to Active promptly if they're still working but were focused on another application, documentation, or troubleshooting.Potential benefits:- Improves agent awareness.- Minimizes unnecessary time spent in Away status.- Supports productivity without changing the intended behavior of the idle timer.- Enhances the overall user experience.Thank you for considering this enhancement.
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.