Product Wishlist | Community
Skip to main content

    Idea Pipeline

    Filter by idea status

    Browse by category

    3157 Ideas

    Roy
    Top Expert ✨
    RoyTop Expert ✨

    Why Fin Needs a "Persona-Based" Architecture 🎭Submitted

    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 🇬🇧

    Kayla LattaNew Participant

    Ability To Display Public Articles In Multiple FoldersSubmitted

    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.

    Katee SafferActive User

    Route “Resolved” Fin Conversations to a Team (via Workflow Trigger)Submitted

    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

    Make Back office tickets available in the Conversations AppSubmitted

    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.

    WestleyNew Participant

    Allow end users to subscribe to Help Center article updatesSubmitted

    SummaryLet customers subscribe to Help Center articles and receive a notification when that article is updated. Today, once an article is published, there's no built-in way for readers to know when it changes. This forces customers to either re-check articles manually or rely on us to broadcast every update through other channels.Use caseOur Help Center hosts articles that change as products, firmware, and integrations evolve. Examples include known issue trackers, device compatibility lists, troubleshooting guides, and changelogs. Customers actively rely on these articles to stay current on the state of their deployments.When we update one of these articles (for example, marking a known issue as resolved, or revising a workaround), the customers who care most about that article have no way to find out. They either keep checking back, or they file a support ticket asking for status, which creates avoidable inbound volume for the support team.Proposed behaviorAdd a "Subscribe to updates" or "Notify me of changes" option on each Help Center article, visible to logged-in and anonymous readers. Anonymous readers enter an email address to subscribe. Logged-in / identified readers can subscribe with one click. When an article is meaningfully updated (admin-triggered, not every minor save), subscribers receive an email notification with the article title, a short summary of what changed (optional admin field), and a link back to the article. Admins can see subscriber counts per article and choose whether a given save event should trigger notifications. Subscribers can unsubscribe from a single article or from all article updates with one click.Why this mattersReduces inbound "any update on this?" tickets Keeps customers proactively informed without requiring outbound campaigns from the support or product teams Increases the value and stickiness of the Help Center as a source of truth Aligns with how other knowledge base platforms (e.g. Zendesk Guide, Notion, GitBook) already handle article subscriptionsWorkaround todayWe currently have to manually email or message affected customers when a known-issue article changes, or hope they happen to revisit the page. Neither scales. I’ve seen free page-change monitor tools like Visualping, Distill.io, or Wachete that let anyone paste in a URL and get an email/Slack notification when the page content changes, but it seems a bit ridiculous to ask customers to do this, so we will not be doing that.