Product Wishlist | Community
Skip to main content

    Idea Pipeline

    Filter by idea status

    Browse by category

    3160 Ideas

    Samuel BoylstonNew Participant

    Correct em dash usage in AI Compose generated responsesSubmitted

    Spoke with Fin. Got pointed me here.I wanted to submit a request to have em dash usage removed. For example in "Thank you so much for sharing those examples—they're incredibly helpful!" These response generated currently by AI Compose make it very obvious they have been generated by AI. I believe ChatGpt was able to update this recently. Which gave me the thought of seeing if we could get it corrected. I love AI Compose it’s a wonderful tool! Let’s take it to the next level.  Here’s some info I dug up. Learned something new.That dash is called an em dash.More specifically, in your sentence:“Thank you so much for sharing those examples—they’re incredibly helpful!”you’re using an em dash for a parenthetical break.Proper name Em dash (—) What it’s doing hereIt’s functioning like: a stronger comma, or a more conversational alternative to parentheses You could rewrite it as: With commas:“…those examples, they’re incredibly helpful.” (weaker) With parentheses:“…those examples (they’re incredibly helpful).” (more formal) The em dash adds emphasis and a natural spoken rhythm. How to remove it (practically)1. Replace em dashes with periodsThis is the fastest and cleanest fix.Before (AI-ish):Thank you so much for sharing those examples—they’re incredibly helpful!After (neutral):Thank you for sharing those examples. They are very helpful.This removes: Performative rhythm Spoken cadence Emphasis inflation

    JHarlowe
    JHarloweConnector

    Brand-Level Configuration for Conversation Reopen time frameSubmitted

     Problem StatementCurrently, when a customer replies to a closed conversation after seven days, the platform automatically creates a new conversation. While this is configurable to change from 7 days to another time frame. It is global and not configurable per brand. Our Services Team (Brand) conversations frequently resume weeks or even months later. A common example is a student following up to reschedule training or re-engage on a previously planned service. In these scenarios, the automatic creation of a new conversation fragments context, increases handling time, and requires agents to manually search historical threads to regain continuity. For other Brands other than the primary, there may be teams like Services or Training where maintaining a single, long-lived conversation thread materially improves clarity, efficiency, and customer experience. Current LimitationThe conversation reopen window is controlled by a global workspace setting. This creates a structural constraint where behavior optimized for one Brand cannot be differentiated from another Brand or other long-cycle engagement models. Proposed EnhancementIntroduce brand-level configurability for the closed-conversation reply window.Specifically: Allow the reopen window to be configured per brand, rather than globally Enable extension of the window beyond seven days, for example 90 days or longer Optionally allow the window to be disabled entirely so late replies continue in the original conversation  Business ImpactThis enhancement would: Preserve conversational context for long-running engagements Reduce agent effort and cognitive load caused by fragmented threads Improve internal efficiency and training delivery workflows Allow organizations to align Intercom behavior with multiple Brand engagement models within the same workspace  Strategic ValueAs customers increasingly use Intercom across Support, Services, Training, and Customer Success, brand-level configurability enables Intercom to better support differentiated operational models without compromise. This change would unlock greater platform flexibility while maintaining sensible defaults for Support-centric teams

    Option to move "Open in Help Center" to top of Articles in MessengerSubmitted

    The current behavior: When viewing a Help Center article inside the Messenger, the "Open in Help Center" link — which opens the article in a full browser tab — appears only at the very bottom of the article (screenshot below). The problem: The users who most want to open an article in the full Help Center are the ones reading long articles — the Messenger pane is narrow, so long articles mean cramped screenshots, a squeezed table of contents, and a lot of scrolling. But to discover the "Open in Help Center" option, those users have to scroll through the entire article first. The link's placement is backwards relative to the people who need it: by the time they find it, they've already done the cramped reading it was meant to save them from.The request: Show "Open in Help Center" at the top of the article as well — near or just below the article title (mockup below) — or give us a setting to choose its placement (top, bottom, or both). Keeping the bottom link is fine; readers who finish an article sometimes want the full URL to share or bookmark. The ask is simply that the option also be visible before someone commits to reading the whole article in the pane.  A lightweight alternative: even a small "open in new tab" icon in the Messenger article header would solve this without adding a text link that pushes content down — whichever fits the Messenger design best.The payoff: users who prefer full-width reading get there in one click instead of after a full scroll, and long-form documentation becomes genuinely usable from the Messenger. Thanks for considering!

    Ryan WinklerNew Participant

    Fin AI: run a durable backfill job across existing tickets + conversations (no open/close workaround)Submitted

    Everyone is just getting onto AI and starting to understand Fin and what it can do. But the reality is: most teams are sitting on a mountain of dirty, unstructured historical data. That blocks us from using our own history for trend analysis, routing, automation, and learning loops in any meaningful way. Intercom already shows the pattern works: Topics Explorer retroactively assigns topics/subtopics via a “backfilling” step (currently described as the last 90 days) and then does daily inference on recently closed items. That’s the right idea — now we need it beyond topics, and we need it for tickets and conversations as a first-class capability.  What I’m asking for Give us the ability to run a durable, resumable backfill job on existing tickets and conversations that re-runs Fin AI classification/enrichment and writes results back to our chosen fields/attributes — without requiring us to open/close every ticket. This should feel like a real platform primitive:  “Re-run Fin classification on dataset X” “Apply current labeling logic to historical items” “Populate ticket + conversation attributes consistently”   Why product leadership should care This isn’t a “nice-to-have automation.” It’s foundational for making Fin real at scale:  Data integrity & reporting If only net-new items are enriched, every metric you show to customers is biased toward “post-AI era” data and hides the baseline. That makes it harder to prove impact, especially as you expand Fin AI Agent reporting metrics/attributes and reporting labels.  (And yes — this ties directly to the discussion I already raised in my Fin thread replying to the upcoming reporting-labels/metrics work.) Customer journey intelligence Teams want to map the full journey: pre-sales → onboarding → incidents → renewals. If history is unstructured, journey analytics stays cosmetic. Fin gets smarter when customers can iterate Intercom is actively enabling customers to improve Fin with “content from conversations.”  Backfilling is the missing partner to that: as customers refine knowledge and classification, we should be able to re-run enrichment over history to validate improvements against real volume. Outbound + automation is about to create even more data You’re already pushing Fin deeper into outbound follow-ups. Great.  But if we can’t retroactively structure historical data, outbound-driven automation will widen the “old data vs new data” gap and make reporting/segmentation messier over time.   “This already exists… just not where it needs to” Intercom has job-style infrastructure for exporting data (including date-range export jobs, with concurrency limits). So this request is straightforward conceptually: a managed backfill job, except it writes back Fin-derived fields rather than just exporting raw records. Also: Intercom notes bulk exports for conversation content are API-driven and time-bounded (and UI bulk export isn’t available). That’s exactly why this should be a first-class back-end job with safe controls, not a hacky “open/close everything” workflow.  Trust, privacy, and “don’t make me create a compliance incident” If you ship backfill, it should be designed like a serious platform feature with guardrails:  Scoped access controls (who can run it, which inboxes, which time ranges). Audit logs (who ran what, when, what changed). No customer re-notifications (analysis + field updates only). Data minimization (store only needed derived labels; don’t replicate raw content). Resumable, idempotent processing (safe restarts; deterministic outputs).  And this is where it gets bigger than “support ops”: backfill can become a trust & safety accelerator if it supports sensitive information classification and remediation workflows. Intercom already has security features like PAN redaction. A backfill pipeline could optionally scan historical  conversations/tickets for sensitive categories and support governance controls (e.g., classify → restrict → redact → retain evidence). This matters because customers are dealing with real legal obligations, including:  GDPR DSAR / portability / erasure workflows (exports + deletion expectations).  DMCA / legal takedown style requests (content traceability + audit). CSAM and other illegal-content reporting requirements (classification, quarantine, strict access, audit trails).  If you want to be the AI-first customer comms platform, you can’t ignore that “AI over historic data” intersects with compliance and safety — and doing it deliberately is a competitive advantage.  Minimum viable requirements  Background job + progress + completion summary (counts, failures). Scope filters: inbox/team, date range, open/closed, tags/attributes, ticket types. Choose outputs: conversation attributes, ticket attributes, selected fields. Idempotent + resumable + rate-limited. Clear “no customer impact” guarantee (no state changes, no outbound triggers). Optional: dry-run sampling + estimated impact.   User interview I want to talk to the team building this. I’m in Dublin, Ireland, and happy to do a user interview (also happy to meet anyone in Dublin). If helpful, I can share the volume we’re dealing with, the exact attributes/labels we want to backfill, and the reporting gaps this would close.