Share product ideas and upvotes with our product team
I'd like to request a feature to add granular reporting capabilities for inbound calls that fail to connect to an agent.Currently, as shared by Mohib on the 9/21/26 change-log: ““Until now, an outbound call that didn't connect showed a generic result, so teammates couldn't tell whether the number was wrong, the line was busy, or the call was blocked.Calls that don't connect now show a specific reason on the conversation: invalid number, line busy, declined by recipient, blocked by carrier, or region not permitted. If a call can't be placed at all, the teammate who dialled sees a message explaining why.”While it's great that Intercom captures this behavior at the individual conversation level, we currently lack the ability to analyze these specific disconnect reasons at scale. Granular reporting capabilities for each of these reasons would be impactful.
We have over 600 customer Slack channels that are connected into Intercom via Workflow and via that integration. We find it really useful to use broadcast to notify customers of feature updates or important changes to our platform using Slack broadcasts. But right now, we're limited in this because the only option to segment which channel should receive messages is based on a dropdown with a checkbox beside each channel name. It's really inefficient for the volume we're operating at. Ideally, we would be able to segment directly in the broadcast itself and add details related to those Slack channels, potentially by associating it to a company record. The simplest solution I see in the meantime is having an upload-a-CSV option that could then select all of the channels that are included in the CSV.
Right now, ticket attributes can only be edited in the web Inbox sidebar before closing a ticket. The mobile Conversations app doesn’t show this section, so attributes can’t be filled in on mobile.This creates a gap for teams that work primarily from their phones. It would be very helpful if the mobile app allowed teammates to view and set ticket attributes directly before resolving a conversation.This would make mobile workflows much smoother and reduce the need to switch to desktop just to complete required ticket data.
We have recently started using the “Ask for more information before handover” setting within the “Let Fin Handle” workflow step.We’ve noticed an issue where, if a customer asks “Talk to a person” but then doesn’t respond to Fin’s follow-up question, the conversation is automatically handed over to a teammate after 30 seconds.Could you consider adding an option to customise this timeout period, or alternatively disable the timeout entirely?30 seconds can sometimes be too short for a customer to provide a complete explanation of their issue, particularly when they need to gather information, review details, or formulate a more detailed response. Having the ability to increase the timeout, or remove it altogether, would give customers more time to provide the requested information before the conversation is escalated.
Hi Team,Can we please allow searching of ticket_id via API?Currently, we can only search using the conversation Id.https://developers.intercom.com/docs/references/rest-api/api.intercom.io/tickets/searchticketsIt doesn’t make sense as the conversation Id is not exposed to non Intercom users. We want to build integrations that would allow our internal team to check a ticket status using the ticket_id that they got from their customers.Please consider. Thanks!
Feature Request: Resizable Reply ComposerIt would be great to have an option to expand/resize the reply composer in Intercom while typing, especially for longer replies.Ideally, we could expand the composer vertically to give us more space to see and review what we're writing, then collapse it back down when we're done.Why would this be helpful?When writing longer replies, the current composer can feel a bit cramped, making it harder to review the full message before sending. Having a larger, expandable writing area would make it easier to: Review longer replies before sending Edit and proofread without constantly scrolling through the text Get a better overview of the entire response Work more comfortably when handling detailed or complex tickets Even a simple expand/collapse button or a draggable resize handle would make a big difference.This would be especially useful for Support, where replies can sometimes get a little... essay-ish. 😂
⚠️ Problem StatementCurrently, when a Procedure Builder configures a flow to fetch external data (e.g., retrieving a list of recent orders, linked accounts, or purchased products via an API), the experience often breaks continuity. After the data is fetched, Fin has to ask the user to manually type out the specific order number or product name into a blank text input. This manual transcription introduces friction, increases the margin for user error, and degrades the premium "app-like" messenger experience. ✅ Proposed Solution / Feature ConceptIntroduce an automated, temporary messenger app experience generated dynamically from API payloads. Instead of returning raw text or forcing a manual text reply, Fin should leverage an ephemeral UI component (a "Preview App") directly inside the messenger canvas.When an API response returns an array or an object collection, the Procedure Builder should be able to map those objects to interactive UI elements. The customer can then simply click/tap their selection from the visual response to advance the flow. 🛠️ Example Use Case / Flow Step 1: Fin initiates a backend check: "Display all orders for this customer." Current State: Fin lists the text or drops a blank input box: "Please type the order ID you are referring to." Proposed State: Fin renders an interactive list/carousel card component showing the last 3 orders (Order #, Date, Total). Step 2: The customer clicks the specific order card. Step 3: Fin instantly updates the context and moves to the next interactive picker: "Which product from this order are you referring to?" (Renders clickable Product Items).
Today, we often need to create and maintain duplicate content because guidance differs depending on the audience consuming it. For example, we may create:One article intended for Fin responses A separate article intended for Copilot that includes guidance/talking points intended only for our agentsWhile much of the content is identical, audience-specific instructions require us to create and maintain separate articles. This increases content duplication, creates additional governance overhead, and introduces the risk of inconsistencies when updates are made to one article but not the other.Proposed SolutionAllow content creators to define audience-specific sections within a single content item. For example:Visible to Fin only Visible to Copilot only (For agents) Visible to all audiencesThis could be accomplished potentially through audience targeting, conditional content blocks, section visibility settings. BenefitsReduces duplicate content creation and maintenance. Improves content governance by establishing a single source of truth. Decreases the risk of conflicting or outdated information across multiple articles. Simplifies content updates by allowing authors to maintain one article instead of several versions. Improves reporting and content lifecycle management by consolidating related guidance into a single asset. Creates a better authoring experience for teams managing content across multiple support channels and AI assistants.Example Use CaseA reservation transfer article may contain:General policy information applicable to all audiences. Guidance that should only be surfaced through Fin. Additional context and troubleshooting steps intended only for agents taking cases.Rather than maintaining multiple copies of the same article, a single article could contain all guidance with visibility controlled by audience type.Business ImpactThis enhancement would help reduce content sprawl, improve governance and compliance, streamline content maintenance, and ensure consistent customer and agent experiences across Fin, Copilot, and other support channels. It would also support scalability as new AI-powered experiences and content consumers are introduced.
We have two old email addresses (in use before our company was acquired) that we've set up to forward/reroute into the same Intercom inbox as our current support address. This works fine for receiving mail, but Intercom doesn't let us change the sender identity that gets used once a conversation originating from one of those old addresses comes in — replies still go out looking like they're tied to the old email context rather than our current one.Why this matters: We're actively trying to migrate customers off the legacy addresses and onto our current one. Right now we have no lightweight way to use these interactions as a nudge — e.g. showing our current/preferred email address more prominently, or noting in the reply that the old address is being phased out — because the sender/from identity on that thread is locked to whatever the original inbound address was.What we're asking for: The ability to override or customize the "From" display name/address (or at least append messaging) on conversations that come in through a rerouted/forwarded legacy mailbox, so we can use these touchpoints to "re-educate" customers to use our current email address instead of the old one, without having to manually catch and edit every reply.
Right now there's a hard split in Intercom: Outbound messages (and the automated "away/auto-reply" message) can use full HTML, custom templates, brand colors, logos, buttons, but the moment a conversation is live and a teammate (or a Macro) replies from the Inbox, the composer drops back to plain rich-text only (bold, italic, headers, lists, links). No HTML block, no template selection, nothing.This creates a jarring inconsistency inside the same conversation thread: the customer's first automated message looks polished and on-brand (logo, structured layout, buttons), and the very next message — the actual human reply looks like it was typed in Notepad. For companies that specifically chose Intercom for its modern, branded messaging experience, this is a real gap between what the product promises and what customers actually receive in their inbox.Concrete example: a customer submits a sensitive request (e.g. an image-rights/compliance complaint). Our automated first response is warm, structured, on-brand. Our actual substantive reply, the one that matters most, addressing their specific case, arrives looking like an unstyled wall of text. That's backwards: the more serious the reply, the more it should look intentional and professional, not the opposite.This isn't a new/niche request: it's been raised in the Intercom Community repeatedly, for years, by different customers hitting the same wall:"Is there a way to customize the format of email replies through Intercom?" (2023) — Intercom support confirmed formatting limitations are "out of our hands" on the Inbox side. "Can I format email replies sent from Inbox?" (2022) — community answer: "I do not see a way to do it when you go from Inbox... you can do so from Outbound." "Help with Formatting Emails from Intercom" (2025) — teams working around this with screenshot-based signatures because there's no real styling option in Macros.Multiple paying customers independently hitting the same ceiling over multiple years is a signal this isn't an edge case.What we're specifically asking for (pick any, all would help):Let the existing Company/Personal email templates (already built for Outbound) be selectable when replying from the Inbox, including when using a Macro. Or, at minimum, bring the "+" → Insert HTML/button/list option, which already exists in the email signature editor, into the main Inbox/Macro reply composer. Allow Macros specifically to be authored with the same template/HTML support Outbound emails have, since Macros are effectively "pre-written emails" and should get the same treatment.Thanks for ur time!
Add more timeframes for Goals (Series and Emails). For example 14 days
Many users sent us a suggestion to mark all newsletter messages as read in the chat button as the red notification is disrupting and they do not want to mark each separate message as read. Currently there is no such option.
Right now, Intercom doesn't support default email signatures the way standard email clients (Gmail, Outlook, etc.) do. Agents have to manually trigger a macro to insert their signature on every conversation, which adds an extra manual step that's easy to forget — especially for high-volume teams where consistency matters for brand and professionalism.Request:Allow agents (or admins, at the team/workspace level) to set a default signature that auto-populates on outgoing emails, without requiring a macro. Support two distinct signature variants: Opening/new conversation signature — a longer-form version that can include banners, links, disclaimers, social icons, etc. — similar to what you'd send when initiating contact. Reply signature — a shorter, more concise version for follow-up messages in an existing thread, avoiding visual clutter and repeated banners on every reply. This mirrors how most email platforms already handle signatures (e.g., Gmail's "signature for new emails" vs. "signature for replies/forwards" settings), and would reduce agent workload while improving consistency across customer-facing communication.If you've run into this same gap on your team, please upvote and drop a comment below — it helps the Intercom team gauge how many workspaces this is affecting.
We’d love the ability to run audits, draft new/updated macros, and engage with usage data via the Intercom MCP. We also have use cases for teams outside of support who don’t have Intercom seats and are already have a harness of choice. Is this on the team’s roadmap?
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.