Product Wishlist | Community
Skip to main content

    Idea Pipeline

    Filter by idea status

    Browse by category

    2599 Ideas

    jhochbruecknerNew Participant

    Feature Request: Export Functionality for Intercom Tracker TicketsSubmitted

    The Problem StatementCurrently, there is a functional gap in Intercom’s Tracker Ticket system. While we can associate multiple customer reports with a single Tracker, there is no native "Export" or "Download" functionality for the associated data.To generate a list of impacted customers for Stakeholders (Leadership, DevOps, or Network Teams) during a P1/P2 event, agents must manually aggregate data. This is: Time-Consuming: Adds 15-20 minutes of manual work per event. Error-Prone: Increases the risk of missing high-priority customers in the report. SLA Impact: Diverts senior resources away from technical resolution to administrative tasks. Proposed EnhancementAdd an "Export to CSV/XLSX" button within the Tracker Ticket view.Functional RequirementsThe export should include the following fields for all associated tickets: Company Name Customer Ticket Number Ticket Status (Open/Pending/Closed) Priority Level Assigned Agent Use Case Example“During an unexpected outage on Server 1, Support identifies 25 associated customer reports. Instead of manual transcription, the Lead Agent exports the Tracker data instantly to provide the Network Team with a real-time list of impacted VIP accounts, allowing for prioritized restoration.”How this helps us: MTTR (Mean Time to Resolution): Keeps the focus on fixing the server, not the spreadsheet. Reporting Accuracy: Ensures 100% data integrity for post-mortem analysis.

    ImmortalNew Participant

    Global Behavioral Rules for FinSubmitted

    We’ve noticed a limitation in how Fin handles instructions when support logic spans multiple categories or requires conditional behavior.Currently, instructions are expected to fit neatly into isolated sections/intents. However, some support scenarios require layered logic that combines:topic classification, policy enforcement, escalation restrictions, conditional responses, and fallback behavior.A good example is our “custom code” support flow.In this case, we need Fin to:recognize requests related to CSS, PHP, JS, SQL, regex, or custom code in general; clearly explain that these cases are outside standard support scope according to our policy; still attempt to help when possible; avoid suggesting escalation to a live agent if Fin cannot solve the issue, because the live support team follows the same policy and cannot provide custom coding assistance either; only address escalation if the customer explicitly requests a human agent; and in that case: remind the customer about the policy, explain that the live team has the same limitations, and suggest alternative resources such as community help or custom development services. Right now, Fin tends to:split such logic across multiple sections, recommend restructuring instructions into separate categories, or fall back to default escalation behavior.This makes it difficult to implement nuanced support policies where:the topic, escalation behavior, and communication strategy must stay connected within a single instruction flow.