Share product ideas and upvotes with our product team
The ability to use email signatures when replying to a ticket.We have all email conversations converting to tickets to support some integrated functionalities, and need signatures to send out with those replies. Having the team have to use personal macros and remembering to use them every time is a pain and a weird lift.
We enabled the email channel within the Intercom platform but there is a default assignee group in Settings>Inbox>Assignments>General>Default Assignee.The problem: Whenever an email comes it, it defaults to one of our chat channels first then the workflow picks it up and assigns it to the Email Inbox as designed. You can see this within the event logger showing each waterfall flow where it marks as default assignee then workflow. Ultimately with automatic routing of chats to agents, the emails are automatically getting assigned to them before the email workflow kicks in. Because of this and the default assignment is in place, it won’t take it out of default once assigned to rep.Temporary Fix: We have to mark conversations as Unassigned by default which now requires users/supervisors to monitor an unassigned queue.The ask: Why not have a default assignee inbox by Channel rather than the entire workspace.Expected Behavior: Chat Default Assignee = Chat_Inbox; Email Default Assignee = Email_Inbox; SMS Default Assignee = SMS_Inbox
Hello team,One thing I often feel is missing when working with reports, is the ability to switch between absolute numbers and percentages. This is particularly useful when using more than one metric. For instance, how many support tickets did we receive in January, and (2nd metric) how many of these were from France? Great to have absolute numbers and we can do the math, but even more useful if you could toggle this to a percentage view. It becomes even more powerful when you have more variables obviously: How many support tickets did we get in France, and how were these distributed among all our customer countries? If you have customers in 30 countries this adds a lot of value. Different example: I want to see how our support volumes are distributed over the days of the week for an 18 month period. Also possible with absolute numbers, but percentages here would add more value. Thanks for reading this and for upvoting!Regards,Christian Osmundsen, Deliverect
Hi Intercom community! At the moment there's no way to stop a conversation closing for inactivity while a procedure is running. If a customer drops off halfway through, the conversation just closes. The procedure doesn't finish, nothing gets escalated, and we've got no reliable way of finding it again afterwards. That's fine for most topics but it becomes a problem for anything high-risk or high-priority, where we need the case seen through whether or not the customer comes back to us. The only workarounds are adding tags and creating extra workflows to reopen these conversations. It would be great to have functionality within the procedure itself to escalate if the user becomes inactive, or a global setting that always escalates to the default inbox if the conversation contains a certain tag & the user went inactive (this might be more future-proof, incase of new features or the same problem found in other existing features)
Currently, Fin stops responding when a teammate replies or an inactivity timer is reached. Manually closing a conversation does not interrupt a "Let Fin Handle" workflow.We'd love the ability for manually closing a conversation to immediately stop any active Fin workflow.This would allow us to use Fin's automatically generated follow-up responses while still giving teammates the flexibility to end a conversation when appropriate, rather than relying on a fixed "Customer has been unresponsive" workflow or waiting for inactivity timers.
It’d be great if we could trigger workflows based on customers clicking a button at the end of a tour or as part of a tooltip. The current workflow launch options are a bit limited for our use case - it’d help us automate more if we could (for example) trigger a workflow based on a customer pressing a “yes” or “no” button after: - doing a product tour - seeing a tooltip - reading a specific particular article - giving a survey response. These would help us make sure the right people see the right message before launching the workflow (as a pop-up not just in the chat window)
I’d love to see some features to enable an article review workflow. For example, additional status categories (pending review, in review, reviewed), reviewer markup and/or comments.
Conversations already include custom_attributes as key-value pairs in the API response, but there’s no way to filter or search conversations by those attributes via the Search Conversations API (even though this is possible in the Intercom UI).This creates a gap where teams can segment conversations in the UI but can’t do the same programmatically, which limits automation, reporting, and integrations that rely on custom attributes. It’s also inconsistent with other areas where attribute-based filtering exists (for example, the Tickets API).Intercom, we are in 2026, we have Claude Code etc, this feature is just a one-shot query for AI implementation 🙏
CSAT responses currently get assigned to the last respondent on a ticket which makes sense for chat scenarios or shared convos/tickets but doesn’t always make sense for tickets. This should be configurable to allow us to assign CSAT to the assignee of a ticket instead of the last respondent.
For users, being able to schedule upcoming “away” statuses. Useful for focused teams who have people that will be working same ticket types to allow clearer customer expectations.
On the “Classics” styling option you could adjust length of the Search Bar. This cannot be done on the “Modern” version. A strength of the classic version was the very clear Search Bar that invited users, but this design feels like it’s prioritized it. It’s opaqueness also makes it harder to see.
For inboxes where multiple teams are active (L1/L2 teams) it would be good to have the ability to call that team, it may help with reporting to see how many calls have been directed to a specific inbox as well.
Contexto del problema: Tenemos un equipo multilingüe que gestiona tickets de clientes en varios idiomas (italiano, portugués, francés). Con la implantación de AI Inbox Translation, los mensajes del hilo de conversación se traducen correctamente, pero el campo de descripción del objeto ticket no se traduce, lo que obliga a los agentes a trabajar con descripciones en idiomas que no dominan antes de poder empezar a gestionar el caso.Este problema se agrava porque la opción "languages you also speak" fue eliminada con el nuevo sistema de AI Inbox Translation, lo que significa que los agentes con perfil multilingüe ya no pueden configurar excepciones por idioma. Hemos abierto tickets de soporte al respecto (mayo y junio 2026) y se nos confirmó que el opt-out anterior ya no está disponible.Solicitud concreta — dos opciones alternativas:Opción A (preferida): Extender AI Inbox Translation para que cubra también el campo de descripción del objeto ticket, igual que ya cubre el hilo de conversación.Opción B (alternativa técnica): Exponer el campo de descripción del ticket como variable de plantilla disponible en el paso "Add a note" de los workflows (p. ej. {{ticket.description}}). Esto permitiría crear un workflow que automáticamente pegue la descripción como nota interna en el hilo, donde sí queda cubierta por AI Inbox Translation.
WhatsApp supports sharing contacts as native contact cards, but these messages are not properly represented or usable when the conversation is handled through Intercom.When a customer shares a contact in WhatsApp, teammates should be able to see the actual contact card in the Intercom Inbox, including the contact name and phone number, instead of an unsupported, incomplete or unclear message.Intercom should also allow teammates to send a contact or vCard so that the customer receives it as a native WhatsApp contact card rather than as plain text or a generic attachment.Expected behaviour• Display inbound WhatsApp contact cards directly in the conversation.• Show the contact name, phone number and any other fields provided by WhatsApp.• Provide clear actions to copy the number, save or download the contact, or start a conversation where appropriate.• Allow teammates to send an existing Intercom contact or upload a vCard.• Render outbound contacts as native WhatsApp contact cards on the customer’s device.• Preserve the contact-card metadata in the Conversations API and webhooks.This should work consistently for manual Inbox conversations and, where supported by Meta, macros, workflows and automated messages.Why this mattersContact sharing is a standard WhatsApp behaviour. Without proper support in Intercom, agents lose important context and have to ask customers to resend contact details manually, creating unnecessary friction and increasing handling time.A broader community discussion titled “WhatsApp updates” has mentioned contact sharing, but there does not appear to be a dedicated, votable product idea for full contact-card support.
WhatsApp supports sharing contacts as native contact cards, but these messages are not properly represented or usable when the conversation is handled through Intercom.When a customer shares a contact in WhatsApp, teammates should be able to see the actual contact card in the Intercom Inbox, including the contact name and phone number, instead of an unsupported, incomplete or unclear message.Intercom should also allow teammates to send a contact or vCard so that the customer receives it as a native WhatsApp contact card rather than as plain text or a generic attachment.Expected behaviour• Display inbound WhatsApp contact cards directly in the conversation.• Show the contact name, phone number and any other fields provided by WhatsApp.• Provide clear actions to copy the number, save or download the contact, or start a conversation where appropriate.• Allow teammates to send an existing Intercom contact or upload a vCard.• Render outbound contacts as native WhatsApp contact cards on the customer’s device.• Preserve the contact-card metadata in the Conversations API and webhooks.This should work consistently for manual Inbox conversations and, where supported by Meta, macros, workflows and automated messages.Why this mattersContact sharing is a standard WhatsApp behaviour. Without proper support in Intercom, agents lose important context and have to ask customers to resend contact details manually, creating unnecessary friction and increasing handling time.A broader community discussion titled “WhatsApp updates” has mentioned contact sharing, but there does not appear to be a dedicated, votable product idea for full contact-card support.
Currently, links sent through WhatsApp conversations in Intercom appear only as plain URLs. They do not generate the rich previews users normally expect in WhatsApp, such as:• A preview image or thumbnail• The page title and description• Open Graph metadata (og:title, og:description and og:image)• A YouTube thumbnail and video previewThis makes links sent through Intercom less visual and engaging than links sent directly from WhatsApp or through other platforms.Expected behaviourWhen an agent, workflow, Fin, or WhatsApp template sends a supported URL, Intercom should allow WhatsApp to generate its native rich link preview.For example:• A Help Center article should display its title, description and featured image.• A product page should display its Open Graph image and metadata.• A YouTube link should display the video thumbnail and title.• The agent should ideally be able to preview the resulting card before sending the message.This should work for:• Manual replies from the Inbox• Workflows and automated messages• Fin-generated responses• WhatsApp message templates, where supported by Meta• Help Center article links inserted from the InboxIt would also be useful to provide an option to enable or disable the preview for each message.Why this mattersRich previews make links easier to identify, increase trust and improve click-through rates. They also create a more consistent experience between native WhatsApp conversations and conversations managed through Intercom.Related community requests include “Ability to link Help Centre articles in WhatsApp conversations”, “Is it possible to insert images in WhatsApp templates on Intercom?” and “Be Able to Preview Workflows for WhatsApp in Intercom”. These address parts of the same problem, but do not specifically cover automatic rich previews for external links and YouTube videos.
Feature Request: Add MTTR, MTTI, and SLA Columns to the Nile Portal Customer Ticket ViewSummaryWe have integrated Intercom with the Nile Portal; however, the customer ticket view currently supports only a limited set of columns. We would like to request the ability to add additional ticket metrics, specifically MTTR (Mean Time to Resolution), MTTI (Mean Time to Identify), and SLA status.Problem StatementCustomers use the Nile Portal as their primary interface to track support cases. Currently, these key support metrics are not available in the customer-facing ticket view, and there is no option to customize the portal by adding additional columns.As a result, customers are unable to quickly view critical support KPIs without requesting separate reports.Requested Enhancement Add the following columns to the customer ticket portal: MTTR (Mean Time to Resolution) MTTI (Mean Time to Identify) SLA Status (Met/Breached/In Progress) Allow administrators to configure and customize the columns displayed in the customer ticket portal. Make these fields available as default or optional columns in the ticket list view. Business Justification MTTR, MTTI, and SLA are industry-standard support metrics. Multiple customers have requested visibility into these metrics directly within the portal. Eliminates the need for manual monthly reporting. Improves transparency and customer experience by providing real-time operational insights. Reduces the effort required by support teams to generate custom reports. Expected OutcomeCustomers should be able to view MTTR, MTTI, and SLA information directly from the Nile Portal ticket view without requiring manual reports or additional support intervention.
Currently, the system has limited visibility of team activity on tickets. While there is some functionality to see others on a ticket, it's not consistently reliable or prominently displayed. Moreover, there's no indication of when someone is actively composing a reply.As a support team member, I need a more robust presence indicator to prevent ticket collision and duplicate responses to better coordinate with colleagues on complex customer issues. An improved system showing who's viewing tickets and actively responding would significantly reduce overlapping work and enhance our collaboration efficiency.Other platforms like Zendesk and Freshdesk implement this with avatar indicators in the conversation header. A similar approach would be intuitive for Intercom users.Implement a visual presence indicator system that shows:Profile pictures of agents currently viewing the conversation Clear indication of which agent is actively typing a response Optional preview of what's being drafted (similar to Google Docs collaborative editing)
Hi,I'd like to log a feature request and get your read on it.We rely heavily on automation and an AI agent in our support setup, and one of our biggest time sinks is duplicate tickets — the same user opening two or more conversations about the same request. We'd love to deduplicate these programmatically.The Merge into action already exists in the Inbox UI and is exactly what we need. The gap is that it's UI-only — there's no REST API endpoint or Workflows action to trigger it, so our automation and AI agent can't use it. I've confirmed this in your developer community (the "Conversation Merge via API" thread), where your team confirmed merging is currently manual-only.My ask: could you log a request for the existing merge action to be exposed via the API? Since the feature already exists in-product, this should be surfacing it rather than building something new.And to double-check before we plan around it — is there genuinely no current API or Workflows path to merge two conversations? If there's anything on the roadmap here, even rough timing would help us decide whether to build a workaround in the meantime.Thanks,DanielPraktika
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.