Product Wishlist | Community
Skip to main content

    Idea Pipeline

    Filter by idea status

    Browse by category

    3479 Ideas

    Luke CaporaleNew Participant

    Ticket email notifications use chat's first line instead of ticket number and subject lineSubmitted

    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. 

    Luke CaporaleNew Participant

    Ticket email notifications use chat's first line instead of ticket number and subject lineSubmitted

    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. 

    Thomas Hils
    Thomas HilsNew Participant

    Add support for brand based variable content in knowledge base articles to improve white-label/multi-brand use casesSubmitted

    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. 

    Hernando ConeoNew Participant

    Feature Request: Font Size and Color Options in the Inbox Composer for EmailsSubmitted

    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. 

    BrigitaNew Participant

    Dropped email recipients need proactive visibility (notifications, attribute or conversation reopening)Submitted

    The issueThe new dropped recipients behavior is a sensible safeguard, and I appreciate that the drop reason is now shown in the conversation. The problem is that this is the only signal. A dropped recipient is surfaced passively — a red icon, red text, and a hover tooltip inside the conversation stream — and nothing else happens:No notification or alert to the sender, the assignee, or the team. No attribute set on the contact or the conversation to flag that a drop occurred. The conversation is not reopened, or moved to any view. No event/webhook we can hook automation onto.So unless someone happens to reopen that exact conversation and read the recipient line, the failure is invisible.Why this matters for usThese are not marketing emails. We use Intercom for account and support communication — replies to tickets, account notices, security- and billing-related messages. When one of these silently drops, the customer simply never hears back from us.In practice we only find out one of two ways:By chance, if an agent happens to revisit the conversation and notices the red recipient. When the customer contacts us again asking why we went quiet.Both mean a real delay in getting an important message to the person, and a worse experience for a customer who did nothing wrong (e.g. a temporary "mailbox full" suppression, a bounce that's since been resolved, or a domain block).The frustrating part is that we usually can still reach these people — through chat, or via an alternative contact email on the account — but only if we know the drop happened. Right now we don't.What we'd like to seeAny one of these would help; together they'd close the gap completely:Automatically reopen the conversation when an outbound reply is fully dropped, so it returns to a human instead of sitting closed with an undelivered message. A notification when a drop occurs — to the sending admin and/or the conversation assignee, and ideally configurable at the team/workspace level so it can route to a shared inbox or channel. A contact and/or conversation attribute set on drop (with the drop reason). An attribute would let us build: Filtered inbox views / segments of "messages that didn't deliver" Workflows that reopen, reassign, or tag the conversation automatically Reporting on how often this happens and for which reasons (Nice to have) A retry action once the underlying issue is resolved, instead of having to compose and send a brand-new message.