Product Wishlist | Community
Skip to main content

    Idea Pipeline

    Filter by idea status

    Browse by category

    3482 Ideas

    Shawna ScottNew Participant

    Feature Request: Make list attribute values easier to set via APISubmitted

    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.

    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!