Share product ideas and upvotes with our product team
My team supports multiple products and so has multiple “inboxes” for incoming phone calls. While the primary and Secondary inboxes seem to work for conversations (they are assigned to primary people first and secondaries as a fallback) this logic does not work for phones. The result is that some people get phones calls for products they do not support (but need to be on the inbox just in case cover is required). Ideally if someone is listed in a Phone Inbox as a “Secondary” they should only be assigned a call if NO primary teammates for that box are available
There should be an easy way to merge users, leads, companies, etc. Sometimes duplicates happen and I should be able to easily merge them (think Hubspot or Apple contacts). This is a common feature in other apps. I know there is a workaround, but I shouldn’t have to put in all of that work to fix an error.
If you are working on a ticket or conversation the outbound call options are limited to the user only.As an IT team we often need to talk to other people at the users end or speak to their IT team.Being able to dial a different number and keep the call within the existing conversation would make audit logs and the process itself much smoother and save a lot of time.
We have recently moved to Intercom and are using it for incoming Chats, Tickets and phone calls.It would be a massive help if a user had granular control of their notifications - for example being able to set different sounds and volumes for new items being assigned, replies to existing items or incoming phone calls. As it stands there is a single sounds for all notifications, and the incoming call “ringer” appears to be hard-coded as I can’t find ay settings for it.
Goal: Display the specific type of SLA (First Response, Next Response, or Close Time) directly in the team inbox and custom views. The Problem: Currently, the conversation list only displays the time value and color (e.g., "5m" in a red oval). While this indicates when a breach occurs, it doesn't show which SLA is breaching. Agents cannot distinguish between a Next Response breach (high urgency) and a Time to Close breach (lower immediate urgency). This makes it impossible for agents to effectively prioritize their workflow at a glance without clicking into every ticket.Proposed Solution: Add a visual identifier or label (e.g., "FRT" for First Response, "NRT" for Next Response, etc.) next to the SLA timer in the conversation list. Allow the conversation list to be sorted or filtered by those specific SLA types so agents can tackle specific types of breaches first. Business Impact: Enables smarter triage, ensures faster customer responses, and prevents agents from wasting time on low-priority breaches while critical response windows are missed.
The ProblemCurrently, advanced routing features (specifically Priority Routing and Secondary Inboxes) are exclusive to the Balanced assignment method.While the Balanced method aims for equal workloads, it creates a "Efficiency Tax" for our team: Performance Penalty: High-performing agents who close tickets quickly are immediately served new ones, while slower agents "protect" themselves from new volume by holding onto open tickets. Lack of Flexibility: To access the critical logic of Priority Routing, we are forced to adopt a distribution model that we find suboptimal for team morale and throughput. Solution A: Decouple Advanced Logic from Assignment MethodsDecouple Priority Routing and Secondary Inboxes from Balanced and enable them as global features that can be toggled on, regardless of the distribution model. This would allow us to keep the objective fairness of Round Robin while still ensuring VIP tickets are surfaced first and overflow is managed via Secondary Inboxes.Solution B: Introduce a New "Advanced Round Robin" MethodIf the Balanced architecture is too distinct for decoupling, we propose a new assignment method: Advanced Round Robin (or "Round Robin+"). This method would function exactly like the current Round Robin (circular distribution) but would include the "perks" currently exclusive to Balanced: Priority-First Distribution: The Round Robin "wheel" spins only for the highest priority tickets first. Secondary Inbox Support: The ability to route to a backup inbox if no agents in the primary Round Robin pool are available. Use Case & Business Impact Fairness: Round Robin ensures an objective distribution of leads/tickets regardless of an agent's current backlog speed. Criticality: We need Priority Routing to ensure our VIP customers are seen first, regardless of the distribution method. Workflow Efficiency: Secondary Inboxes are vital for our tiered support structure. Being unable to use them with Round Robin forces us to choose between "fair distribution" and "organized workflows." Summary of Requested Changes UI Update: In the Team Inbox settings, allow the "Priority Routing" toggle to remain active when Round Robin is selected. Logic Update: Allow "Secondary Inbox" selection to be compatible with the circular assignment logic of Round Robin.
When the end user is viewing their conversation and ticket history, they should be able to easily filter out closed / resolved tickets so that they are only viewing open issues.
It would be nice if you could disable self assignment. This way that you’re able to ensure that the round robin function takes place. Right now we have to monitor the queue in order to prevent cherry picking during peak hours.
This would be especially helpful when snoozing conversations far in advance for specific type of follow-ups on a certain date. Being able to see the snooze duration or reopen date directly in the Snoozed view would make it easier to keep those conversations grouped and plan ahead.Right now, since that information isn’t visible, I have to track the date separately outside of the product. Having this visible would make scheduling and managing future outreach much more efficient.
currently a bit of a nightmare for our customers - would be great to have more control over the way it works!
1. The Problem:Currently, when an inbound email contains an attachment that Intercom rejects (due to size limits, unsupported file types, etc.), the system leaves a generic note in the conversation stream: "Attachments were dropped from this message." Because there is no context regarding what was dropped, support agents are forced to reply to the user and ask them to clarify what file they were trying to send. This creates unnecessary back-and-forth, delays resolution times, and creates a frustrating experience for both the agent and the customer.2. Proposed Solution:Update the "Attachments were dropped" event log to include the basic metadata of the dropped file.Example of current state:📎 Attachments were dropped from this messageExample of desired state:📎 Attachments were dropped from this message:Feature_Request_Bribe_v2.pdf (6.7 MB)Definitely_Not_A_Virus_Jared.zip (4.2 MB)Please_Build_This_Jared.png (2.2 MB)image001.png (45 KB)3. Why this matters (Business Impact):Context: Agents instantly know if the dropped file was a crucial document (like a PDF checklist) or just a harmless email signature image.Efficiency: Eliminates the need to ask the customer "What did you attach?"Customer Experience: Customers don't feel like their files disappeared into a black hole without explanation.4. Technical Feasibility:Since Intercom's backend already receives the Multipart MIME message and parses the headers (Content-Disposition, Content-Type, etc.) to evaluate whether to keep or drop the payload, this metadata is already being temporarily held in memory. Writing these specific header values to the conversation event log before purging the file data should be a highly feasible, low-lift addition that provides massive value to support teams.
For now it is not possible to change SLA settings once they have been created. If something needs to change, new SLA settings need to be created and used in the workflow. It would be much easier to be able to change those settings.
I’d love the option to be able to set Fin attribute reasoning to be hidden, or perhaps follow the “Show conversation events” flag, We have several attributes and it can be quite noisey.
When using an email code for data connectors I’d like to be able to configure two options: Choose the time out window myself Automatically communicate the time out window (regardless of whether it’s custom or not) to the customer whenever the security code is invokedA 10 minute window is very short and customers are often stuck in a loop requesting new codes over and over. This could be off-set with a longer window, and better communication about these timeouts. It seems like an industry norm to communicate time out windows by default and it’s strange that this isn’t done.
As of now, the Glossary only controls how terms are translated in outgoing messages. It does not apply to incoming customer messages. Fin guidance can’t rewrite or “correct” how inbound customer messages are translated in the Inbox either.Goal: to control how terms are translated in inbound messages.Use case: to ensure Fin connects with the correct internal knowledge or concept when translating phrases or messages from other languages, e.g. the same concept can be referred in a very specific phrase in a specific language that if translating literally will never get to the right reference.
In some cases, we need to proactively reach out to users via Intercom. For these situations, we use macros as templates for our messages. To better support our global user base, we also rely on real-time multilingual inbox translation.Currently, when using the multilingual inbox, it would be helpful to have the option to set the conversation language at the time of initiating the message. This way, the message could be automatically translated into the user's preferred language from the start, making the user experience even better.
It would be beneficial if agents could search for macros by their content in addition to their titles. This would allow them to quickly locate the specific macro they need without having to recall the exact title of the macro.
Hi, Whatsapp supports typing indicators, it would be amazing if this could be added into Intercom so customers can have more certainty that they will receive a response. See here: https://developers.facebook.com/documentation/business-messaging/whatsapp/typing-indicators/Thanks!
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.