Product Wishlist | Community
Skip to main content

    Idea Pipeline

    Filter by idea status

    Browse by category

    3156 Ideas

    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.