Product Wishlist | Community
Skip to main content

    Idea Pipeline

    Filter by idea status

    Browse by category

    3157 Ideas

    Madeline G.New Participant

    Enable Priority Routing & Secondary Inboxes for Round RobinSubmitted

    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.

    EduardoNew Participant

    Feature Request – Color-Coded Tags for Improved QA & Operational EfficiencySubmitted

    Hi Intercom Team,My name is Angel Sanguino, and I’m reaching out on behalf of the QA Specialists team at Stake Colombia.We would like to propose a feature enhancement regarding the tagging system within Intercom. Currently, tags are limited to names, descriptions, and emojis, which, while helpful, do not fully support efficient visual categorization in high-volume environments.Use CaseIn our daily operations, we handle a large number of conversations that require precise categorization for QA audits, reporting, and performance tracking. For example:COL - Verification COL - Dormant account reactivationIf tags could be assigned fixed or customizable colors (e.g., green for Verification, orange for Dormant accounts), it would significantly improve the way our team processes and reviews tickets.Proposed EnhancementWe suggest introducing:Custom color assignment per tag Consistent color visibility across Conversations and Contacts Optional color legend or grouping for better organizationExpected ImpactImplementing color-coded tags would provide:Faster visual identification of ticket categories Improved accuracy in manual tagging Reduced cognitive load for agents and QA reviewers More efficient auditing and reporting processes Better scalability for high-volume support operationsWhile emojis offer some level of differentiation, they do not provide the same clarity and immediacy as color-based categorization, especially when managing large datasets. I attach an image. ClosingWe believe this enhancement would bring strong value not only to our team but to any organization relying on structured tagging systems for quality assurance and operational efficiency.Thank you for considering this request. We would be happy to provide further context or participate in feedback sessions if needed.Best regards,Angel SanguinoQA SpecialistStake Colombia

    Ashley MNew Participant

    Fix teammate presence, it’s causing duplicate workSubmitted

    Show teammate presence while a teammate has the conversation open (even if not actively typing), until they close the tab or move on.Teammate presence in conversations needs to persist while someone has the ticket open, not just while they’re actively typing.Right now, presence disappears too quickly or inconsistently, which leads to multiple teammates working on the same conversation without realizing it.This has happened repeatedly: I’m actively working in a ticket, step away briefly (5–10 minutes), come back, and someone else is already in the same conversation. In multiple cases, they didn’t see my presence at all, even though I never left the conversation. At the same time, I could see their indicator, so it’s also inconsistent.This is not just a minor UX issue, it directly wastes time and creates duplicate work.Impact:Teammates unknowingly duplicate effort Drafts and in-progress replies get overridden or conflicted Requires Slack or external coordination to avoid stepping on each other Creates unnecessary friction between teammatesExpected behavior:Presence should persist as long as a teammate has the conversation open There should be a clear indication when someone is “in” a conversation, even if idle Draft presence should be reliably visible across all teammates - super important! This is a core workflow issue for teams and should be treated as a priority improvement. Thank you! 

    Julian BurkeNew Participant

    Feature Request: Show Email Attachment File Metadata Logs (especially when attachments are dropped)Submitted

    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.