Product Wishlist | Community
Skip to main content

    Idea Pipeline

    Filter by idea status

    Browse by category

    3155 Ideas

    ImmortalNew Participant

    Allow workflow interactions without reopening closed conversationsSubmitted

    We use an Intercom workflow triggered by “If teammate changes the conversation state” to collect CSAT after an agent closes a conversation.The workflow has multiple branches based on the customer's CSAT response, so we need to continue performing different actions after the conversation has already been closed.At the beginning of the workflow, the customer is presented with two button options:Continue Chat Rate a chatThe problem is that when the customer clicks one of these buttons, Intercom treats the button click as a new customer reply. As a result, the closed conversation is reopened and, because we have automatic assignment enabled, it can immediately be assigned to an available teammate.This creates an unwanted side effect: a simple interaction with a CSAT workflow can become a new assigned conversation and affect agent workload and conversation statistics. We currently add a Close conversation action at the end of the workflow to close the conversation again.However, this is not ideal because the conversation has already been closed, and the customer's interaction with the workflow should not necessarily create a new conversation/reopen the existing one in the first place. It would be useful to have an option for workflow buttons/actions to interact with a closed conversation without reopening it or treating the interaction as a new customer reply.

    JHarlowe
    JHarloweConnector

    Configurable CSAT attribution modelSubmitted

    Greetings team, we wanted to surface a request around CSAT and configurable attributions ProblemCSAT is currently attributed to the most recent visible agent who interacted with the customer, regardless of who owned, managed, or resolved the case. This creates inaccurate and potentially unfair attribution, particularly in collaborative or multi-region support models.A common example: an engineer owns a case end-to-end, performs the troubleshooting, identifies the issue, and provides the resolution. Due to time-zone coverage, a second engineer in another region sends a brief follow-up and closes the conversation. The customer submits a CSAT rating. That rating is attributed to the closing engineer, who had minimal involvement in the actual resolution.The reverse also occurs: an engineer receives a negative CSAT simply because they sent the final message, even when the customer's dissatisfaction relates to earlier interactions, product behavior, delays, or factors entirely outside their control.When CSAT is used as an individual performance metric, this attribution model distorts the data and reduces confidence in the scores as a meaningful measure of agent contribution. Requested FeatureConfigurable CSAT attribution, allowing workspace admins to select from the following models:- Conversation owner: attribute CSAT to whoever owns the conversation at resolution. Best fit for case-ownership support models.- Last visible agent: current Intercom behavior, retained as an option.- Team or conversation-level attribution: distributes CSAT across contributors, useful for collaborative support models where multiple agents share a case. Business Impact- Individual CSAT scores become more representative of actual case ownership and contribution.- Reduces attribution errors caused by regional handovers in follow-the-sun support models.- Improves the reliability of CSAT as an input into agent performance measurement.- Better supports collaborative support structures where case resolution is shared across teammates.

    Priscilla SNew Participant

    Track ticket submitter by team and teammateSubmitted

    ProblemTicket reporting does not support filtering or breaking down data by the ticket submitter (the teammate or team who created the ticket). While reports allow filtering and grouping by the assigned teammate or team, there is no way to report on where a ticket originated. Feature RequestAdd Ticket Submitter (Teammate and Team) attributes filter to Intercom's ticket reporting module.This would enable "origin-to-destination" reporting to track who creates back-office or internal escalation tickets, rather than only tracking who ultimately resolves them. Why It Is Needed Cross-Departmental Visibility & Operational Efficiency: Without a submitter attribute, managers cannot identify which internal teams generate the highest volume of back-office requests or track how issues move across teams. Having this data allows operations to optimize ticket routing, address root causes, and target staff training where demand originates. Agent Productivity & QA Audits: Tier 1 agents who triage incoming issues and create secondary tickets for Tier 2 teams currently get no visibility or credit in reporting once the ticket is reassigned. Reporting on submitters ensures full accountability for created tickets, enables quality audits on submitted tickets, and accurately measures internal support demand. Complete Workflow Analytics: Assignee-based metrics only tell half the story—they track who completed the work, but mask the origin of internal demand. Submitter reporting bridges this gap to provide full end-to-end visibility into internal support workflows.