Product Wishlist | Community
Skip to main content

    Idea Pipeline

    Filter by idea status

    Browse by category

    3155 Ideas

    Daniel Rönnberg
    Daniel RönnbergActive User

    Hide unused Fin roles in content settingsSubmitted

    We only use Fin for Service, but when managing which roles content should be used for, Sales, Service, and Ecommerce are all shown as options. I can turn Sales off, but Service and Ecommerce appear to be linked, meaning Ecommerce cannot be turned off without also turning off Service. Likewise, turning Service on also turns Ecommerce on.From a user perspective, this is confusing because it looks like these roles can be managed independently, even though they cannot. Since we don’t use Fin for Sales or Ecommerce, I’d ideally like the option to hide or disable those roles entirely from our workspace, or at least have clearer UI messaging explaining that Service and Ecommerce are linked.The current setup creates unnecessary friction when managing content because I have to keep seeing and accounting for roles that are not relevant to our use case. It also makes the settings feel more complex than they need to be for teams that only use Fin for support/service.Suggested improvements: Allow admins to hide or disable unused Fin roles at workspace level. Allow Service and Ecommerce content settings to be managed independently. If they must remain linked, make this explicit in the UI before users try to toggle them. Consider simplifying the content management experience for teams that only use Fin for Service. This is not blocking us from using Fin, but it adds avoidable confusion and makes content governance harder than it needs to be.

    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.