Share product ideas and upvotes with our product team
I have an Escalation Rule that is built on Attributes but it’s causing issues with batch testing as attributes are not set. I can not use an Audience as that is already needed in my batch testing to control the KB. Ideally you allow us to set the attributes before triggering the batch testing as you allow in simulations.My escalation rule is Attribute is not [name] and Attribute2 is not [name2]. This allows me to use FinAi for new use cases and then escalate to an existing nonFinAi workflow for existing use cases. Over time we will move all to FinAi but that is not possible right now. This escalation rule is built on Attributes so why is there no solution for batch testing? I will try creating a test user with the attribute set as a workaround. That will then require everyone to use this test user and that is not ideal.
A centralized view of all the tickets my team has raised with Intercom — not just my own. I’m managing support on behalf of our whole organization and I have no visibility into the open tickets nor answers you provide on the tickets.
When holidays in default office hours are defined, the SLA pushed the next SLA target after that holiday. Howerver, when the ticket is created within that holiday, the system cannot push the next target and the ticket breaches during the holiday. It would be nice if the SLA pushes the next target within the valid office hours also when the ticket is created with the holiday period.
The current Lite Agent permissions are too restrictive and hinder productivity. Currently, Lite Agents can only navigate via direct ticket links or mentions (which are difficult to manage, as noted in Request 1). Additionally, it is highly inefficient that Lite Agents cannot use macros—not even text-only ones—forcing them to store standard internal replies in external documents.Request: Access to Views: Allow Lite Agents to access (custom) Views. This is essential for navigating tickets efficiently, especially since we operate with multiple brands and teams within Intercom. Access to Macros: Grant Lite Agents the ability to use macros (or at least text-based macros) to streamline the process of writing internal notes.
The Problem:We have bugs that arise, just like any other tech company. We’re constantly innovating and pushing updates, and therefore encounter unexpected issues. We typically fix widespread issues and outages very quickly. And we link all customers to a tracker ticket. Fin spends way too much time blindly leading a customer through troubleshooting steps, when there’s a deeper issue Fin is unaware of. How we solve today:It takes a lot of effort to create a snippet, and create guidance for the snippet, to quickly train Fin on a known issue. And then that guidance and snippet has to be manually deleted hours or days later when the issue is resolved. It’s constantly evolving, requiring multiple steps. We create tracker tickets to inform customers and human agents of the progress of issues like this. So I’m training my agents and Fin separately, in two different places. The Dream Scenario: Awareness: Fin is aware of all active Tracker Tickets logged by human agents. Mitigation: Fin automatically offers a workaround to the customer if one is documented. Proactive Subscription: Fin asks the customer if they would like to be notified of updates regarding the bug. Automation: Upon confirmation, Fin automatically links the conversation to the Tracker Ticket and converts the conversation into a customer ticket. Persistence: Fin remains the primary point of contact unless the issue requires human escalation. Resolution Loop: When the Tracker Ticket is marked "Resolved," Fin proactively follows up with the customer to confirm the fix is working for them. Proposed Implementation in IntercomTracker Ticket Settings Add a "Sync to Fin AI" toggle on Tracker Tickets (or enable this by default for specific Ticket Types). When enabled, provide specific AI-optimized fields: Symptoms: Describe what a customer would experience (to help Fin match the issue). Workarounds: Step-by-step instructions for Fin to provide. Target Audience: Specific conditions or user segments impacted. Auto-Link: Toggle option to allow Fin to automatically link users to a Tracker Ticket. Auto-Ticket Creation: Toggle option for Fin to generate a linked conversation ticket automatically upon bug identification.
A new feature with delayed messages has recently appeared, allowing you to send a message and cancel its sending before the timer expires. However, when sending such a message, you cannot see the content of the message, for example, to check yourself for typos. It would be a good idea to add the display of the message content that will be sent during the selected delay, so you can double check it before it goes out.
It would be very useful to be able to sort chats by linear ticket status and priority. As well have specific inboxes for chats with linear tickets.
Problem:When a conversation is converted to a ticket, attribute values on the conversation are not automatically populated into matching ticket fields, even when identically named fields exist on both objects. The two remain linked but maintain fully independent attribute sets.This gap is not surfaced to users at the point of conversion, making it non-obvious until a workflow fails or an SLA is missed. ImpactThe most immediate consequence is SLA policy behavior. Because SLA policies in Intercom evaluate at the conversation level, a ticket with Urgency set on the ticket attribute, but not on the corresponding conversation attribute may not trigger or breach correctly. Teams populating ticket fields in good faith could be inadvertently creating invisible SLA gaps. Additionally, any workflow conditioned on a ticket attribute will not fire as expected if that attribute was not populated at conversion time. This affects routing logic, automation triggers, and any Fin-based attribute detection, which does not carry over to tickets automatically.Requested FeatureA native attribute mapping configuration allowing workspace admins to define field-level mappings between conversation attributes and ticket attributes. When a conversion occurs, values from mapped source fields would be written into their designated target fields automatically before any workflows evaluate the new ticket.
The ability to have a toggle in the Help Center settings to have the messenger default to open on the Support page. Java script like Intercom('showSpace', 'home') exists for other pages, but we cannot add it to the Intercom Support page.
At this time, all tickets are be shown in the tickets portal, by default all tickets states are selected.We would like to be able to configure that resolved tickets are not visible by default.The customers would still need to be allowed to select the Resolved state so that they can view those tickets, but by default the Resolved state should be unchecked.
At this time the columns that are visible in the tickets portal cannot be configured.It would be nice to be able to decide for ourselves which columns are usefull for our customers and which are not.
At this time merged tickets are visible in the tickets portal, but they cannot be filtered out.It would be nice for our customers to be able to filter out the merged tickets.
The new UI update on inbox may have affected the behavior of side conversations.Current behavior: When composing an email in a side-conversation, closing the sidebar discards the draft entirely. Reopening the sidebar shows an empty compose field.Expected behavior/previous behavior: Drafts should be preserved when the sidebar is closed and reopened, consistent with how regular conversation drafts already behave.It's common to need the main Intercom window for research, looking up customer details, or referencing other conversations while drafting an email reply. Having to keep the sidebar open the entire time (or risk losing the draft) makes this awkward, and aligning side-conversation behavior with regular conversation behavior would remove that friction.Thanks!
Hi Intercom team,I’d like to suggest a feature request : the ability to create custom channels / custom connectors that fully support two-way messaging, not just outbound notifications.The core idea is to give teams more flexibility in how messages are sent and received while still relying on Intercom as the single unified interface for all conversations. A custom connector with full bi-directional capabilities would unlock several use cases, such as: Enabling SMS messaging in regions where Intercom SMS isn’t available (e.g., France). Syncing conversations with CRMs or project-management tools that include their own messaging system, ensuring users can message from those platforms while our teams continue to reply directly in Intercom. Building tailored workflows for industry-specific channels without needing to leave the Intercom UI. This functionality would significantly increase interoperability and reduce operational fragmentation for teams managing conversations across diverse systems.Thanks for considering this request!
When using the main inbox search you are able to use keywords to filter data. When not in the main inbox search keywords are not supported (See screenshot) In this small search box you are unable to use the same keywords and only supports text only. On top of that the filters under Last activity does not include Assignee which the only work around to filter by who the case owner is to filter the entire view for one user which creates endless amounts of users based views which is not ideal to set up.
When creating workflows, it would be helpful to have the option to use both AND & OR. When trying to filter by something like Categories for tickets, I might want categorys is: Feature Requests OR bugs, but there is other logic that needs to be applied, such as AND ticket type:customer AND state:resolved. If I did Category: Feature Request AND Category: Bugs, this would break the logic and nothing would apply to the workflow. This flexibility would be a huge help!
Currently when I go to add a tag, if I misspell or click enter too soon it creates a new one automatically. It happens often enough that it’s wasting my time going through the steps to delete the tag. There has to be a more efficient way or some type of blocking or “are you sure you want to create a new tag”. Something...please.
ProblemSetting list-type custom attributes on tickets via the API is painful enough that our engineering team now recommends against using list attributes — even when they'd be the better UX for our agents. Specifically, the issues that lead us to this recommendation are:1. Read/write asymmetry. Intercom returns the display label on read, but rejects that same label on write and requires an internal UUID. Round-tripping a value we just received does not work.2. UUIDs aren't exposed in the UI. The only way to obtain them is to make a specific API query — there's no admin screen or export.3. UUIDs differ between sandbox and production. Every list option must be re-discovered and re-mapped per environment; no config promotion path exists.4. Downstream cost. We now maintain one ENV var per list option per environment, just to translate stable concepts onto volatile UUIDs. The maintenance burden is steering us away from the feature entirely.Suggested fixes (any one would help; together they'd align with API conventions):1. Accept the display label on write, rejecting with a clear error on ambiguity.2. Support customer-defined stable keys per option (e.g. Stripe's lookup_key, Salesforce API names) so the same identifier works across workspaces.3. Expose UUIDs in the attribute admin UI, copyable.Bottom line: we want to use list attributes — they're better for our agents than free text — but today's API ergonomics outweigh that benefit. Closing this gap would let us adopt them broadly.
Enable users to reorder default conditional attributes within the conversation attributes panel (e.g., Issue Type, Product Attribute). This would allow teams to prioritize and organize fields based on their workflow, making the interface more intuitive and efficient when handling conversations.
Most of the teams in our company are fully remote and don’t want to be sat their desk wearing a headset all day in case a phone call comes in.It would be great if there were options to set which output device is used for the ringer vs the call itself - for example setting the incoming call alert to come through the PC speaker and the call itself to come through the headset.
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.