Share product ideas and upvotes with our product team
The current MCP only supports updating articles in the account’s default language.Being able to update articles through MCP is already super useful and powerful. We can automate updates to our articles following releases, code changes, business rules updates, etc.But given that we support multiple languages (2), any kind of automation falls short because we still have to manually go into the UI to update the translations.It would be a huge unlock for anyone with a multilingual Help Center, and I can’t help but think it shouldn’t be a big lift to support.Thanks!
Hey everyone! 👋 I’ve been diving deep into the new multi-role capabilities for Fin, and while the "one agent for everything" approach is a great start, I believe the next evolution of Fin should be Persona-Based. Right now, we have one "Fin" with one name and one tone across the whole journey. But in the real world, a customer's needs change as they move from the storefront to the support queue. Here’s why I think Intercom should develop the ability to define distinct Personas (e.g., "Mike" for Sales vs. "Thomas" for Support): 1. Trust is Built on Context 🤝A "Sales" persona needs to be proactive, persuasive, and high-energy 🚀. A "Support" persona needs to be empathetic, cautious, and technical 🛠️. Using a single "Humorous" or "Professional" tone for both feels like a compromise. 2. Visual Continuity & Human-Centric Design 🖼️By allowing us to set different Names and Avatars for different services: For Sales: A friendly face (Mike) that feels like an account executive. For Support: A specialist identity (Thomas) that signals expert assistance. This helps customers mentally "switch gears" and sets the right expectation for the conversation. 3. Specialized "Tool-Belts" for Agentic AI 🧰If we treat these as separate personas, we can define specific Permissions and Data Connectors for each: Mike (Sales) could have access to HubSpot or Salesforce to check lead status 📈. Thomas (Support) could have access to internal dev docs or API logs to troubleshoot bugs 🐛. 4. Cleaner Analytics & Handoffs 📊Separating personas allows for role-specific KPIs. We could measure "Mike" on Conversion/Booking Rate and "Thomas" on Resolution/Deflection Rate. It also makes the "AI-to-AI" handoff possible—imagine Thomas realizing a query is actually a sales lead and "transferring" the user to Mike! The Vision: Moving from a "Generalist Bot" to a "Specialized AI Team." 🏛️🇬🇧 I’d love to hear from the product team and the rest of the community—would you prefer one consistent Fin, or do you see the value in a squad of specialized AI personas? #FinAI #ProductFeedback #AgenticAI #CustomerEngagementCheers, Roy 🇬🇧
Intercom's current table editor in Help Center articles is limited to basic cell input with no control over column widths, text alignment, cell padding, or header row styling. This makes it difficult to create clear, readable reference tables — especially for content-heavy articles like bug trackers, feature comparisons, or release notes where structured data is central to the article's value.
Today, temporary attributes in Intercom are limited to the lifecycle of a single procedure. This creates friction in conversations that involve multiple procedures or handoffs, since any intermediate state is lost when switching contexts. To work around this, we currently promote short-lived data to permanent attributes, which introduces latency, adds complexity, and clutters our data model.We’re requesting a way to make temporary attributes persist for the duration of a conversation (i.e., session-scoped), so they can be shared across procedures without needing to be written to permanent storage. This would allow us to pass state more efficiently between workflows, reduce unnecessary read/write cycles, and improve responsiveness.A conversation-scoped attribute layer—automatically cleared when the conversation ends—would make it much easier to build fast, reliable, multi-step conversational experiences without compromising performance or data hygiene.
I have a workflow to send a notification to slack when we receive a phone call to our Intercom number. I cannot edit what Intercom sends to Slack. Intercom sends an illogical, fairly useless set of information. It takes one of two forms:“Received participant added notification” instead of says who sent the message and previewing that message [Name] received new phone call event - this is closer to what I’m looking for but [Name] is the person making the call, not receiving the call. The text should be “[Name] called you.”I want what Intercom posts to Slack to be useful for my business but I have no way to adjust what is delivered in Intercom. Can you fix this?
Intercom mobile app is missing some key features, like send a new message (email, sms, (WhatsApp)) like a ordinary email app. And we use Reusable Workflows quite much in conversation for lead updates that we can start from browser but not from mobile.Its a hassle to see some messages and cant answer or want to send a new email and we need to wait until the day after when we get in the office to our computer to answer or send the email.If we would move totally to intercom these need to be added in mobile app. Also the UI would like a update and the Speed .-)We been using intercom many years now and mobile app has not had a major update, It´s about time!
SummaryWe’d like the ability to place a single public article in multiple folders within the Help Center, rather than being limited to just one.Use CaseWe organize our Help Center both by user role (Onboarding paths) and by feature/topic (e.g., Transaction Management).For example, Transaction Management articles are highly relevant in multiple contexts: As part of Onboarding folders tailored to specific user roles (Agents, Admins, TCs) Within a centralized Transaction Management folder for ongoing reference Currently, we have to choose one location or duplicate content, which creates issues with: Content maintenance (updates must be made in multiple places) Version control and consistency User experience (articles aren’t always surfaced where users expect them) Proposed SolutionAllow public articles to be: Displayed in multiple folders (multi-location support), or Referenced/linked across folders without duplicating the article itself Impact / Value Reduces duplicate content and maintenance overhead Ensures consistency across Help Center content Improves discoverability for users navigating by different paths (role-based vs. topic-based) Supports more flexible and scalable knowledge base organization Additional ContextThis would be especially valuable for teams with more complex onboarding flows or multiple user personas, where the same content naturally belongs in more than one place.
We are having to duplicate internal articles so they’re located in multiple sections. Previously we used Guru, and there we were able to show a singular article in multiple sections, avoid duplicating work - which then becomes problematic in the future keeping them up to date.
Topic: Help Center — Notification for newly published articlesArea: Intercom / Help CenterContext: The News tab in Intercom is reportedly not intuitive enough for end users to discover new content. Users are missing newly published Help Center articles because there is no proactive notification mechanism in place.User Story: As an end user, I want to be notified when new Help Center articles are published, so that I can stay informed about new support content without having to check the Help Center manually or asking FIN if there is new content available.
We’re looking for a way to route conversations to a human team after Fin AI Agent has resolved the user’s questions — specifically through Workflows, not Procedures.Important context:We need this workflow to be triggered based on conditions like specific URLs (e.g. contact buttons or pop-up proactive messaging on a specific page)And at this time, that requires Workflow-level control. This cannot be handled in a Procedure currently, as far as I understand. Use case:There are certain topics where Fin can fully answer questions, but a manual action is still required afterward.Example:A user lands on a migrations page and clicks “Contact us” Fin answers all their migration-related questions The conversation is resolved But we still need it routed to our team to process the migration requestCurrent limitation:If we force routing early, we lose the benefit of Fin answering questions first If we let Fin resolve, the conversation never reaches the team Procedures don’t solve this because they can’t control post-resolution routing based on entry conditions like URLWhat we need:A Workflow-based solution that can:Trigger from specific entry points (e.g. URL, button click, referral source) Allow Fin to fully handle and resolve the conversation Then automatically route the conversation to a specific team Optionally mark it for internal follow-up without reopening it to the userWithout this, we’re forced to choose between automation or operational workflows, instead of combining both.Ideal behavior:Workflow triggers → Fin handles conversation → Fin resolves → Workflow routes to team for internal processing
The ProblemCurrently, the Intercom mobile app lacks critical parity for Back Office Tickets. For teams with field agents, managers on the move, or back-office staff who need to collaborate away from their desks, the mobile experience is currently a bottleneck.The specific limitations include: Missing Context: You cannot see the Ticket Title or Description. Data Blind Spots: Ticket Attributes (custom fields) are not visible or editable. Collaboration Gaps: The ability to cross-post internal notes or see linked conversation history is limited or non-existent. The Use CaseWe have a back-office team that needs to collaborate on tickets "on the go." Whether they are commuting, moving between buildings, or working on-site, they need the same level of visibility as the desktop version to ensure SLAs aren't missed, and information remains accurate.Proposed SolutionWe need a "Ticket View" parity update for the mobile app that includes: Full Header Visibility: Display the Ticket Title and ID clearly at the top of the mobile UI. Attribute Access: A dedicated tab or "Details" section within the mobile ticket view to see and edit all Ticket Attributes. Cross-Posting & Internal Notes: The ability to add internal notes to a ticket and see the full thread of internal collaboration, just as you would in a conversation. Description Support: The ability to read (and ideally edit) the initial ticket description/summary. Views for Tickets: have views in the app The ImpactImplementing this would allow back-office teams to remain truly mobile, decreasing response times for complex issues and ensuring that "Work from Anywhere" actually applies to the ticketing side of Intercom, not just the chat side.
Hey team! This is something quite straightforward, but I thought I’d share it anyway: I’m building multilingual workflows based on the user's browser language and currently have to make duplicates for other language versions since I can only start applying conditions after the initial message (Path A) I would ideally prefer to have different language versions within one workflow as it allows better language/version control.
Assign X random conversations per teammate for review (including phone calls and Fin not involved)I need some kind of tool that assigns an specific amount of conversations from my teammates for my review on a weekly basis. Some of these conversations are phone calls, some of them do not have 2 messages from Fin nor 2 responses from the customer.Monitors is a great tool, but it only works for conversations with at least 2 messages from Fin and 2 messages from the customer, and I need a sample of all conversations, not only those with the previous criteria.
Today, Workflows can’t be started just because a user/ticket attribute changes. It would be really useful to have a trigger that fires a Workflow when a specific attribute is updated (for example, “plan”, “status”, “region”, or a custom attribute). This would let us automate follow-ups, routing, or internal actions based on attribute changes, without needing a customer message or other event.
When discovering issues with Product Tours, it tells you which step they failed on, e.g. ‘Step 7’ but the steps in teh builder aren’t labelled as such. It would make it so much easier if they were when making edits, additions, and finding errors, etc.
When Fin is deployed over E-mail there is a DMARC security (setting) before Fin will answer to the e-mail. In my case; like 20-30% of the incomming e-mails aren’t getting answered because of this problem: "Fin did not try to answer because the sender could not be authenticated"Fin escalates the conversation immediately, even when Fin could answer the e-mail so easily. Right now, there aren’t any options to troubleshoot this problem or any triggers to solve it automatically. So my question is: Can you guys find a way to automate the process what fixes the error and so can Fin the e-mail that was sent in the first place?
Edit: seems like despite it saying it’s making an update, it does ask for confirmation once it’s finished the proposed update. The thought process as it loads give the impression it’s going to make the update without confirmation,Just like with Claude, the ask feature is too eager to make changes to things. I want guardrails in place that it always asks before updating procedures, guidance, etc rather than just updating itself and having to click “stop” before its too late.
Sometimes, we decide to convert an email conversation into a ticket in the middle of an ongoing conversation. It feels odd to the customer when they see an email notification that a ticket is created under a submitted status, as they have already been in touch with us. I wish we could select the ticket status while converting it
Is anyone else noticing that the Intercom Phone, when customers call, when it's connecting it sounds like the UK Dial Tone (https://www.youtube.com/watch?v=0aJYmQp4Q7U) and not a US dial tone (https://www.youtube.com/watch?v=j2Hck4Bmifw)I understand Intercom is compatible in other countries but how can we establish a clear US based ring?
When showing users (e.g. in the conversation list and in the "User" column), when there are multiple users, it should prefer to show the customer's user, not users from our own domain (which appear e.g. when replying or forwarding via email), so that one can see who the customer is. Right now we have the problem that when one of our team forwards an email to Intercom or replies via email, they show up as colleague@example.com, and in the conversation list, often that then shows up as the primary users. This means we cannot easily see in the conversation list who the actual customer is; instead we see primarily our own colleague. It would be great that if Intercom could solve it like this: In the conversation’s participants list, sort users that are not from our own email domain _before_ users that are from our email domain.For example, if our email domain is @example.com, and the participants list is [me@example.com, colleague@example.com, customer@company.com], it should sort it as [customer@company.com, colleague@example.com, me@example.com], so that customer@company.com is the first one that determines what’s shown in the conversations list (“customer@company.com and 2 others” is a lot more useful than “me@example.com”).
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.