Product Wishlist | Community
Skip to main content

    Idea Pipeline

    Filter by idea status

    Browse by category

    3473 Ideas

    Trevor
    Innovator ✨
    TrevorInnovator ✨

    Fin Ai Agent Access to Tracker Tickets for SMART bug Categorization, handling, and communicationSubmitted

    The Problem:We have bugs that arise, just like any other tech company. We’re constantly innovating and pushing updates, and therefore encounter unexpected issues. We typically fix widespread issues and outages very quickly. And we link all customers to a tracker ticket. Fin spends way too much time blindly leading a customer through troubleshooting steps, when there’s a deeper issue Fin is unaware of. How we solve today:It takes a lot of effort to create a snippet, and create guidance for the snippet, to quickly train Fin on a known issue. And then that guidance and snippet has to be manually deleted hours or days later when the issue is resolved. It’s constantly evolving, requiring multiple steps. We create tracker tickets to inform customers and human agents of the progress of issues like this. So I’m training my agents and Fin separately, in two different places. The Dream Scenario: Awareness: Fin is aware of all active Tracker Tickets logged by human agents. Mitigation: Fin automatically offers a workaround to the customer if one is documented. Proactive Subscription: Fin asks the customer if they would like to be notified of updates regarding the bug. Automation: Upon confirmation, Fin automatically links the conversation to the Tracker Ticket and converts the conversation into a customer ticket. Persistence: Fin remains the primary point of contact unless the issue requires human escalation. Resolution Loop: When the Tracker Ticket is marked "Resolved," Fin proactively follows up with the customer to confirm the fix is working for them. Proposed Implementation in IntercomTracker Ticket Settings Add a "Sync to Fin AI" toggle on Tracker Tickets (or enable this by default for specific Ticket Types). When enabled, provide specific AI-optimized fields: Symptoms: Describe what a customer would experience (to help Fin match the issue). Workarounds: Step-by-step instructions for Fin to provide. Target Audience: Specific conditions or user segments impacted. Auto-Link: Toggle option to allow Fin to automatically link users to a Tracker Ticket. Auto-Ticket Creation: Toggle option for Fin to generate a linked conversation ticket automatically upon bug identification.

    Christopher HayesNew Participant

    Add Telegram Business functionalitySubmitted

    Right now, Intercom's Telegram channel (Settings > Channels > Telegram) only supports connecting a standalone bot created via @BotFather. Customers have to find and message a separate bot username, which feels disconnected from the actual business.Telegram now offers "Business accounts" (available to Premium subscribers) that let a company keep its real, verified Telegram account — complete with opening hours, quick replies, greeting/away messages, and a business chat link — while automating replies through the Bot API's business_connection feature. A connected bot can send and receive messages on behalf of that real account instead of a separate bot identity.It would be great if Intercom supported connecting a Telegram Business account as a channel, the same way the current bot flow works today:- Conversations from the Business account land in the Inbox, with Fin and Workflows at full parity- Replies go out through the business_connection, so customers see the business's real name and photo — not a bot- Native Telegram Business settings (hours, quick replies, greeting messages) stay usable in Telegram itself, while Intercom handles the actual conversationThis matters most for teams whose customers are concentrated in markets where Telegram is the primary channel — a verified business account feels far more trustworthy and personal than a generic bot. Right now the only way to bridge this gap is third-party middleware, which adds cost and an extra hop. Native support would remove both.

    Gerald PradoInnovator ✨

    Make Help Center Articles Report Data Available via the Reporting API for use with OperatorSubmitted

    What I'm requesting:Expose the data from the legacy Help Center Articles report (found under Reports > Proactive Support > Articles) through the Intercom Reporting API, so it can be surfaced and used within AI-assisted analytics tools like Intercom's own Operator/Copilot assistant.The data I'm referring to includes:Article viewer counts (per article, per time period) Reactions (happy / neutral / sad) Conversations triggered per article Last updated dateWhy this matters:We use our Help Center extensively as a first line of support. This data already exists in Intercom — it's visible in the legacy report — but it's siloed from the reporting API, which means AI tools can't access or reason about it.Right now, when I ask Intercom's AI assistant to analyze help center content performance, it can tell me which articles Fin cited in conversations or what resolution rates look like by topic — but it can't cross-reference that with how many customers actually viewed those articles or how they reacted to them. That's a significant blind spot.The use case is straightforward: combining article view and reaction data with Fin's resolution rates, topic breakdowns, and conversation outcomes would give support teams a complete picture of how their knowledge base is performing — not just from Fin's perspective, but from the customer's.What good looks like:Being able to ask the AI assistant: "Which articles have high views but low positive reactions or high follow-up conversation rates?" — and get a data-backed answer without having to manually cross-reference two separate reports.Who benefits:Any team using the Help Center seriously — especially those using Fin as their AI agent — would immediately benefit from this connection being made. It closes the loop between content publishing and support outcomes.

    Sam Wilson
    Sam WilsonNew Participant

    Internal notes on help center articlesSubmitted

    Problem:There's nowhere on an article to leave a note for other editors. Anything an editor needs to know before changing an article has to live outside Intercom, where the person making the edit won't see it.Examples of what a note would carry:Linked from the product. "This article is linked from inside our app, do not delete it” Used by Fin configuration. "A procedure or guidance rule depends on this article. Check it before restructuring or removing sections." Owner or reviewer. "Technical content owned by the deployment team. Ask them before changing the steps." Change coming. "This behaviour changes in the next product release. Update it then, not before." Approved wording. "Legal approved the security and data handling wording. Don't reword it without sign-off." Deliberate choices. "Kept separate from the related troubleshooting article on purpose. Don't merge them." Or: "Restricted to a specific audience because it covers a paid feature." Known gaps. "Doesn't cover the sandbox case yet. A customer conversation shows the gap."Why it matters:More people are editing articles now, including through Fin's content recommendations, and Fin answers from these articles directly. An edit made without this context can break a link in the product or a procedure, or undo a decision someone made on purpose. Nobody finds out until a customer gets the wrong answer.What we'd like:An internal notes field on each article that teammates see in the editor and that is never published or used by Fin to answer customers. It would help further if the notes showed as a warning when someone edits a protected article, and if the API could read and write them so our own tooling can keep them current.

    Gemma GWConnector

    Side Conversation Delivery Status and Failure NotificationsSubmitted

    Side Conversation Delivery Status and Failure NotificationsOur organization uses Side Conversations extensively to engage external teams, vendors, and partners. We have actively encouraged our users to stop emailing individuals directly from customer conversation threads and instead use Side Conversations as the standard workflow for involving external stakeholders. (Before teams were remove participants, deleting conversation thread, sending a message, then readding participants..)In customer conversations, Intercom provides visibility/error when an email cannot be delivered. However, Side Conversations do not provide any delivery feedback.Today, if a Side Conversation email fails to reach the recipient, there is no notification to the sender, no visible delivery status, and no indication that follow-up may be required (apart from checking whether a message is marked as "Seen" to confirm delivery.) While this can confirm that a recipient has opened a message, it does not solve the primary problem: There is no confirmation that an email was successfully delivered. There is no visibility into delivery failures. Users may assume an external team has received a request when they have not. Critical customer issues can be delayed because senders are unaware of delivery problems.  Requested EnhancementIntroduce delivery and failure visibility for Side Conversations similar to customer conversation emails, including: Delivered status Failed delivery status/Delivery error details where available Optional notifications to the Side Conversation creator or assignee when delivery fails  

    jamiebandoNew Participant

    Display Side Conversations in the User Profile Conversation HistorySubmitted

    Problem Statement / Use Case:Currently, side conversations do not surface in a customer’s Intercom profile under their "Latest conversations" or complete conversation history.This creates a significant blind spot for support and operations teams. When an agent reviews a customer's profile to get a quick snapshot of their history or active issues, they completely miss parallel threads, third-party escalations, or external updates happening inside side conversations unless they manually dig into every single parent ticket.Proposed Solution:We would like to see side conversations integrated into the customer profile timeline. A few ways this could be implemented include:Nested Visibility: Display side conversations as indented or nested items directly beneath their respective parent conversations within the profile history list. Timeline Toggle/Filter: Add a filter or toggle on the user profile (e.g., "Include Side Conversations") so agents can opt into a truly comprehensive timeline of interactions. Cross-Referencing: If an external side conversation is spun up regarding a customer's ticket, a log or reference link to that side conversation should automatically appear on the primary customer's profile.Business Impact / Value:True 360-Degree Context: Agents will no longer miss critical background context or parallel threads involving third parties (like vendors, partners, or internal teams) regarding a customer. Increased Efficiency: Eliminates the need for agents to click into multiple old parent tickets just to check if a side conversation was ever initiated, answered, or resolved. Better Customer Experience: Ensures any agent stepping into a case has immediate visibility over the entire operational picture, preventing communication silos and repetitive internal overlapping.