Product Wishlist | Community
Skip to main content

    Idea Pipeline

    Filter by idea status

    Browse by category

    3494 Ideas

    Vlad LConnector

    Changing the Unsnooze Behavior of a Conversation with a Linked TicketSubmitted

    Hi everyone! :)I’d like to propose a change to the unsnooze behavior of conversations when a linked ticket is involved. Current behavior:At the moment, any activity in a back-office ticket triggers the unsnooze of its linked conversation.Proposed Behavior:The snooze/unsnooze state of a back-office ticket, along with changes to its status, should not affect a linked conversation that is in a snoozed state. Conversations should wake up based on cross-post notes (primary trigger) or the closure of the linked back-office ticket (secondary trigger):What should not wake the conversation:Snooze/unsnooze of the back-office ticket. Status changes (e.g., Submitted, In Progress, Awaiting Provider, etc.).Primary trigger from the back-office ticket to wake the conversation:Cross-post notes.Secondary triggers (these events should ideally already include cross-post notes):Transition to the "Resolved" state. Closure of the back-office ticket.P.S. This is essentially the same logic applied to tracker tickets. If I’ve missed any relevant triggers, feel free to share them with me!This change would prevent unnecessary re-openings of conversations where the chat agent’s attention isn’t required. The ideal solution would be to allow for manual toggling of the expected behavior.  An example from our experience We use back-office tickets to escalate issues to other teams. For example, the Second Line team, which handles more complex technical issues and communicates with third parties.Here’s how the process works: On the first line: Client inquiry → Chat agent’s work → Escalation (creating a back-office ticket) → Waiting for resolution (chat snoozed). On the second line: The ticket enters the queue (Submitted) → The ticket is assigned to a responsible team member (In Progress - wakes the chat for the first time) → The Second Line investigates the case and sends an additional request to the third party via a side conversation → Waiting for a response (Snooze - wakes the chat a second time) → Third-party response arrives (Unsnooze of the back-office ticket - wakes the chat a third time) → Additional email sent (Snooze - wakes the chat a fourth time) → Another third-party response (Unsnooze - wakes the chat a fifth time) → Resolution is reached, and a cross-post note wakes the chat correctly. Throughout this process, the chat agent repeatedly re-snoozes the assigned chat because the triggers for contacting the client are:A clarification from the client. The ticket resolution. Deadlines requiring us to reach out to the client to update them on their request.Additionally, the ticket-sharing functionality allows us to share the current ticket status with the client, along with sending automatic email notifications. All of this can happen without the involvement of the overwhelmed chat agent who constantly has to click "Snooze." 😅 The more actions taken on the back-office ticket, the more times they have to click. Thank you for looking into this!

    Ash EdwardsNew Participant

    Product Improvement Suggestion: Jira for Tickets IntegrationSubmitted

    Product Improvement Suggestion: Jira for Tickets IntegrationIssue:Currently, all tickets created via the Jira for Tickets integration in Intercom are assigned in Jira under the name of the person who installed the integration, rather than the agent handling the Intercom ticket.This creates two key problems:Notification Overload: The installer of the integration receives a flood of Jira email updates for tickets they are not actively involved in. Confusion for Jira Responders: Since tickets are created under the installer’s name, rather than the actual Intercom assignee, Engineering teams find it difficult to track the correct point of contact for each issue.Workarounds & Challenges:We explored using the Reporter field as a workaround, mapping the Intercom assignee to the Jira reporter via parameterized configuration. While this did help clarify ownership, the Jira tickets were still technically created by the integration installer. This led to:Confusion among Engineering teams about who was responsible for the issue. Lack of Jira email notifications for the actual reporter, further reducing visibility.To mitigate the notification issue, we’ve set up workflows to push Jira updates back into the related Intercom conversation. While this helps keep our agents informed, it doesn’t solve the manual effort required to escalate issues between departments.Proposed Improvement:We would like to see an enhancement that allows Jira tickets to be created under the name of the assigned Intercom agent rather than the integration installer. This would:Reduce unnecessary email notifications for the installer. Improve clarity for Jira responders. Minimize manual copy/paste efforts for agents, ensuring a smoother, more efficient workflow.Leveraging the integration for single-click ticket creation—while ensuring the correct agent ownership is reflected—would allow us to use the integration to its full potential.