Share product ideas and upvotes with our product team
Can you please introduce more options when it comes to picking date ranges for reports? Last Week option Last Month option Last Quarter option (selects the previous complete 3 months) Custom date picker, where you can have an easier calendar option to select the start and end date which allows dynamic selection where you can change the date/month/year separately rather than manually scrolling back month by month to the chosen date OR you can type the date as a shortcut An option for choosing XX days/weeks/months in the past An ‘All Time’ option
Currently, the Intercom inbox displays message timestamps as relative time (e.g. “31 minutes ago” or “14d”). The exact date and time is only visible when hovering over the channel icon next to the message.It would be helpful to add a setting that allows the inbox to always display the full date and time (e.g. “Jun 24, 2026, 10:14 AM”) instead of only the relative format. This would make it easier to quickly see when messages were sent without needing to hover.
Description:Currently, when chat conversations are converted to tickets, Intercom's automatic email notifications continue to use the first line of the original chat conversation as the email subject line. This creates several problems:Generic, near-identical subject lines across all ticket emails, since they all pull from similar opening chat messages. Truncated or awkward text that cuts off mid-sentence. No reference to the ticket itself or ticket #, so customers cannot tell which ticket an email relates to.The result is that every ticket email looks the same in a customer's inbox, making it very difficult for them to track, manage, and prioritize their open tickets.Requested Feature:Add the ability to customize the subject line for email notifications tied to tickets, so that each subject line includes:The ticket number (e.g., "[Ticket #12345]") A meaningful ticket description or title, rather than the first line of the chatIdeally this would be supported through one of the following:A template system for dynamic subject lines (e.g., "[Ticket #{{ticket_id}}] {{ticket_subject}}") Pulling from the ticket's existing subject/description field rather than the chat's first line A configurable default format that applies to all ticket-related email notificationsBusiness Impact:Distinct, ticket-aware subject lines would let customers immediately identify which ticket each email concerns, search their inbox by ticket number, and prioritize responses accordingly. This reduces the risk of missed or overlooked communications and meaningfully improves the customer's ability to self-manage their support tickets via email.Note: this request is related to to the below idea but is not identical.
Description:Currently, when chat conversations are converted to tickets, Intercom's automatic email notifications continue to use the first line of the original chat conversation as the email subject line. This creates several problems:Generic, near-identical subject lines across all ticket emails, since they all pull from similar opening chat messages. Truncated or awkward text that cuts off mid-sentence. No reference to the ticket itself or ticket #, so customers cannot tell which ticket an email relates to.The result is that every ticket email looks the same in a customer's inbox, making it very difficult for them to track, manage, and prioritize their open tickets.Requested Feature:Add the ability to customize the subject line for email notifications tied to tickets, so that each subject line includes:The ticket number (e.g., "[Ticket #12345]") A meaningful ticket description or title, rather than the first line of the chatIdeally this would be supported through one of the following:A template system for dynamic subject lines (e.g., "[Ticket #{{ticket_id}}] {{ticket_subject}}") Pulling from the ticket's existing subject/description field rather than the chat's first line A configurable default format that applies to all ticket-related email notificationsBusiness Impact:Distinct, ticket-aware subject lines would let customers immediately identify which ticket each email concerns, search their inbox by ticket number, and prioritize responses accordingly. This reduces the risk of missed or overlooked communications and meaningfully improves the customer's ability to self-manage their support tickets via email.Note: this request is related to to the below idea but is not identical.
It will be great to have a metric to plot the trend of the “percentage” of reopened conversation over a period of time. This is a key metric to judge the quality of resolution in the first instance itself.
We offer a white-labeled help center for some customer implementations. The vast majority of the content in these articles (should be) identical, except displaying a different brand name (which lives in Intercom already) or an alternative screenshot that captures that specific brand identity. In it’s current state, we must maintain duplicate articles for all of this content creates a significant burden in manual efforts required to keep these articles in sync, and introduces more possible failure points where it’s possible for data to fall out of sync.The ability to write one article that references {{brand.name}} and to attach individual screenshots to {{brand.name}} would be an incredible improvement to this experience for us, and reduce a significant amount of manual work to keep these different knowledge base articles in sync.In an ideal world it’d be possible to flag certain blocks of content as brand-specific, so that even situations in which there is variable content or minor differences between brands we could still maintain one primary article.Alternatively, a reverse version of this where content could be defined in blocks that could be referenced in different articles would help accomplish some of this. Content that is universal can be defined as one of these blocks and individual articles could reference this primary content. Changes made to the primary content would then reflect back on each brand-specific item, where any brand specific content would live.
Often we have content that is formatted in Markdown that we’d like to paste into Intercom to be sent as a reply to a customer. It’d be great if pasted markdown formatting was preserved where that formatting is supported by Intercom. A quick test gave me these results:Not preserved on paste:Bold: **text** Italic: _text_ and *text* Strikethrough: ~~text~~ Inline code: `text` Code block: triple backticks Heading: # (H1) and ## (H2) Blockquote: > text Bulleted list: - item and * item Numbered list: 1. (pastes as plain text, not a styled list)Already handled correctly on paste, for contrast:Markdown link [label](url) renders as a clickable link Single line breaks and blank lines between paragraphs are preserved
Back office tickets should have the ability to be easily re-opened just like normal conversation tickets. Example: if a team-mate replies on a back-office ticket that’s already been marked Resolved/Closed, the ticket should re-open. The use case would be: Back-office tickets are used to track bugs, so visibility is key at every stage.
Currently, when working inside the shared Inbox, the text formatting options in the reply composer are limited to the basics (bold, italics, etc.). When dealing with complex support tickets, long explanations, or crucial warnings, these basic tools aren’t enough to properly structure information for the customer.The Solution We need Font Size and Font Color selectors added directly to the rich-text toolbar in the Inbox reply composer (where teammates read and reply to conversations).Detailed Use Cases & Why We Need This: Highlighting Critical Information: When customers need to be warned about something important (e.g., "Do not click X before doing Y"), standard bolding often gets lost in a long paragraph. Being able to change the text color to red or orange would immediately grab the customer's attention and prevent user errors. Step-by-Step Troubleshooting: When sending a list of instructions, being able to color-code steps or increase the font size of section headers makes it much easier for the customer to read and follow along without getting overwhelmed. Accessibility and Readability: Not all customers have perfect vision. Sometimes we need the ability to bump up the font size of our replies to accommodate users who need larger text, improving their overall support experience. Brand Consistency: Having access to color tools would allow our support team to use our brand's primary colors for links or headings, making the interaction feel more professional and customized. Current Workarounds & Their Flaws: Right now, to emphasize something, we have to rely heavily on bolding, highlighting, or using ALL CAPS. ALL CAPS can come across as aggressive (like yelling at the customer), and too much bolding just makes the text look cluttered.
Hello,We are working with teams that would like tickets to be created automatically for each message. In some use cases, ticket creation would be fully automated. If the customer selects this option, a ticket could be generated automatically and filled with the required information.For this reason, I would like to have the ability to define ticket attributes for these types of automated ticket creation scenarios.
When creating a new ticket form, you’re currently not able to set up attributes with a multi-select list field. I would like to create a list attribute and choose if I want this to be a multi or single select field. The only workaround currently is to create multiple fields which is not a great user experience and makes reporting cluttered and less straightforward.
I saw that the Tickets Portal has been renamed to Customer Portal in the Help Center recently. Is there any plans to have this naming convention customizable?Customer Portal is misleading since that’s something our customers might call our actual platform so if we reference it in our Help Center or other documentation, that could lead to very real confusion. Tickets Portal was working well for us.
It would be incredibly helpful to be able to duplicate help centers / articles for easy audience segmentation without having to recreate the entire thing each time. This way I can do a quick tweaking of what I need.
Right now, the Inbox search only returns results based on text inside conversations. If a company name never appears in the conversation itself, searching for that company will return no results — even though the conversation is associated with that company.It would be helpful if Inbox search could also return conversations based on associated company names, not just message content. This would make Intercom feel more like a traditional inbox where you can search by company and still find all related conversations.
We are building multiple procedures that need to share data with each other during the same conversation. Today, when a procedure ends, the context it built (amounts, decisions, variables) is not reliably accessible by the next procedure or by Fin in a general conversation turn.Our specific use case:We need to pass the refund amount calculated in one procedure to a second procedure (e.g. a refund/credit dispute procedure) so Fin can tell the rider exactly how much they were compensated without asking again or losing that information.What we are asking for:The ability to write a conversation attribute inside one procedure and read it reliably in any other procedure or general conversation turn within the same conversation for example:compensation_minutes set in a procedure → readable in the refund dispute procedure refund_amount set during a credit step → displayable to the rider later if they askWhy this matters:Without this, we are forced to either cram all logic into one mega-procedure (which causes the re-triggering and idempotency issues we already flagged) or lose context between procedures and give the rider a worse, disconnected experience.
Hello,would be great to extend light agent rights, and to be able see conversations not only in which there were mentioned.To see customers assigned to them conversations or something similar.Now it expensive to give full license for sales when tool is used only by support team as example in our case, Light agent license is nonsense because can be used only for reporting or similar
Would be great to be able to change the title of a chat, when it has been sent. Since it would only be visible to the sender for internal purposes, it should not be a problem.
I create dozens of articles with identical settings in Content Type, Fin Audience, Help Center, and Help Center Audience, and they’re all stored in the same folder. It would be great if I could start by selecting the folder and on that basis Intercom would apply the other attributes. It’s basically a template article, but populating some of the main settings instead of the content.
In most companies, the user interface (UI) is constantly evolving. Currently, whenever the UI of a button changes in our system, we must manually find and replace the corresponding image in every article where it has been used. This process is time-consuming and prone to errors.To address this issue, I propose introducing an Image Gallery feature. This feature would serve as a centralized library of reusable image templates, making it easier to manage and update images in articles. Benefits and Features of the Image Gallery Reusable Image Templates The Image Gallery would function as a centralized repository for commonly used images, similar to a clipboard but specifically for images. A button within the article editor would display a list of available images, allowing users to quickly select and paste them into articles. Simplified Updates Across Articles Updating an image in the Image Gallery would automatically update it in all articles where that image is used. This eliminates the need for users to individually replace images in multiple articles whenever a UI change occurs. Streamlined Workflow By reducing the manual effort required to maintain UI consistency across articles, the Image Gallery would save time, minimize errors, and ensure that all articles always reflect the latest UI changes.
.Currently, the Branch condition in Fin workflows only supports Escalation Guidance — you can branch based on which Escalation Guidance was triggered (e.g. Frustration, Legal escalation, Speak to a Human). Regular Guidance articles are not available as branch conditions at all.For example If Fin handles a conversation using a Guidance (e.g. spam detection), we want to route or deprioritise that conversation differently in the workflow — without it being treated the same as a other messages in the workflow. There's currently no way to detect or act on when regular Guidance was used. Add the Branch condition dropdown to include regular Guidance articles alongside Escalation Guidance, so teams can build more granular routing logic based on how Fin actually handled the conversation.
Hi,On iOS SDK there is no ability to switch workspaces - vs. Android SDK where you have such ability (documented here: https://developers.intercom.com/installing-intercom/android/using-intercom#change-workspace:~:text=the%20Android%20SDK.-,Change%20workspace,-Kotlin`changeWorkspace(apiKey: String?, appId: String?)`
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.