Product Wishlist | Community
Skip to main content

    Idea Pipeline

    Filter by idea status

    Browse by category

    3157 Ideas

    Tom JendrzejekNew Participant

    Add brand_id to Canvas Kit request context for CanvasKit requestsSubmitted

    ProblemCanvas Kit requests currently include workspace and admin information, but there’s no reliable way to determine which brand the app is being accessed from.This is especially problematic for Home canvases, where there may not yet be an associated conversation. In those cases, apps cannot infer brand context from conversation data, making it difficult to build brand-specific experiences.Suggested SolutionFor Home canvases, the cleanest approach would be to include brand_id inside the existing context object.Suggested request shape:{ "workspace_id": "abcd123", "admin": { ... }, "context": { "location": "home", "brand_id": "15" }}Why this approach works wellKeeps the payload structure consistent with the existing pattern of workspace + admin + context Places brand information alongside other “where the app is being used” metadata Avoids introducing a new top-level field Gives apps a reliable, conversation-independent way to determine brand context Enables clean integrations with multi-brand tooling and workflowsExample use casesBrand-specific Home experiences Conditional UI and workflows based on brand Analytics segmentation Multi-brand internal tooling integrationsAdditional NotesApps can already map the returned brand_id to richer brand metadata using the Brands API. Exposing the identifier directly in Canvas Kit requests would provide the missing link needed to support reliable multi-brand experiences before a conversation exists.

    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.

    Josh WelchNew Participant

    Phone calls need continuous polling, not single-ring dispatchSubmitted

    We run a small call centre on Intercom Phone and the current call routing behaviour is causing us real problems. Sharing here because I suspect we're not the only ones.The core issue: when an inbound call comes in, Intercom rings available agents once. If that ring isn't answered — agent is on another call, notification missed, away from desk — the call drops into silent hold. There's no continuous polling, no signal to agents that a call is still waiting, no queue state they can pull from. The customer ends up sitting on a dead-feeling line until they give up. From our side, it looks and feels like we're missing calls we shouldn't be missing.What we'd expect, and what every other call centre platform does: keep polling available agents until one picks up, or expose a clear queue state agents can manually answer from.A few smaller things point to the same underlying issue — Phone hasn't quite been designed for a working call centre yet. Manual callbacks aren't recognised: miss a call, ring the customer back from the ticket manually, hang up, and Intercom then prompts us to call them again because it doesn't track that an outbound call already went to that number on that ticket. Callers on hold get silence — no hold messaging, no position-in-queue, no reassurance they're still in the queue. And scheduled callbacks fire on a fixed timer-based delay rather than queueing up for the next time an agent is free.The chat, transcription, and AI summary side of Intercom is genuinely excellent and is the reason we picked it. But the voice product feels close-but-not-quite for anyone running a real phone queue. Would love to know if continuous polling and proper queue behaviour is on the roadmap, and if anyone else has worked around this in a way that doesn't involve Slack alerts as a band-aid.Happy to share more detail with the product team if useful.