Community Discussion: How do you manage multiple conversations in tickets?


12 Comentarios

  • Kate Styer

    We have only recently launched a few teams into Zendesk, but we are already getting tangled in the mess of collaboration.  Whether using one of the apps above, creating a new ticket, changing requester, or printing to PDF and taking it out of Zendesk, our teams are use duct-tape and band-aids to collaborate with their key contributors to get work done.  This is causing pain and consternation because we migrated from a solution who had solutions for many of these scenarios.

    They love Zendesk for everything else but this is a pain we would love to see solved as soon as possible. 

    They collaborate with teams out side of Zendesk.  Example, customer sends a ticket for a unique experience when they visit one of our locations.  The individual locations (80+) do not have Zendesk but need this info to provide the exceptional customer experience we are known to provide.

    Depending on the ticket you could see conversations with two to three teams that are not currently working in Zendesk. 

    Soon, when you we migrate more users the complexity will only grow as they will have their own use cases for collaboration outside of Zendesk.

    Reporting would be helpful to know how many times we are engaging these other teams and the outcomes for feedback at a later date.

    Feel free to reach out to me directly.

  • Dan Cooper
    Community Moderator

    This is a great question, and I'd love to share my recent experience with collaborating with different teams from Zendesk.  I'm in the process of rolling out a new Zendesk experience to a team that has been largely focused in a system that primarily acts as an email client.  Many of the workflows for these teams are heavily based on email, so much of our collaborations efforts have significant downsides as Zendesk is not an email client, and those workflows don't directly translate.  I'm excited to hear about the features called out above, but this is what we are doing today, along with some of those pain points we are working through as we add new users and adapt our teams to a Zendesk world. 

    Reassigning in Zendesk

    For our teams in the same Zendesk instance, we are changing group assignments and using internal notes.  This is wonderful. 

    Forwarding (No Response Required)

    We have teams that we just need to forward tickets to that are not in Zendesk.  In order to pass a ticket onto another group we have resorted to using a rebuild of the ZCC Zendesk Labs app.  This app allows us to forward public comments from a ticket to multiple addresses, but we run into some challenges with the app not being able to select an outbound email address and not being able to send private comments. Not being able to select the outgoing address with the dozens or email addresses we have today causes problems on a reply to our address as we have to use a default address that isn't tied to any specific group to work.  I'm sure with some additional coding we could make this work, but right now it's a solution that meets maybe 60% of our forwarding need in a scenario where we just need to pass the ticket forward.  I would love to have the ability to simply send the current public (and optionally private) comments to any email address. 

    Forwarding (w/ Possible Reply Back)

    We also have scenarios where we have to forward a ticket to another group, and sometimes we need a response back, or maybe just will get one for clarification.  We use the Linked Ticket app in order to accomplish this workflow.  The linked ticket allows for us to create a second ticket in order to hold the conversation with a different group of people that does not include the original customer.  We do have some challenges with this approach, the conversation is now divided, and we cannot use the macros we've created without first using the app, and then opening the second ticket to update the ticket there.  This adds extra steps into what is an easy process in the system we are migrating from and has lead some of our agents to just consider going to Outlook which is less complicate and can accomplish the same end goal.

    CC Blast

    In combination with the above solutions we employ, we do use the traditional CC option.  However, since many of the teams we work with aren't in Zendesk, we can't just CC them on the same ticket as a customer.  So we find ourselves using Linked Ticket, then adding everyone we need to notify in the CC field.  This works well, but is cumbersome when someone responds and everyone gets a response.  With the other end users in the CC field, the replier can't control who gets a CC notification since the ticket controls this.  We have adjusted to add everyone to the CC field, and remove them after adding them.  This solution can also be tedious for us as sometimes we need to bulk CC more than 20 people which is the limit for end user CCs.  In addition, adding CC's via macro or other business rules is limited to agents so we have to resort to cut/pasting from a macro to ensure we communicate with the right people for each of our hundreds of potential collaboration combinations.  

    New Ticket

    Our Zendesk implementation is still relatively new and our teams have been using another system for a few decades that is largely based on email.  Zendesk is great in a lot of ways, but it is still very different from a pure email based system.  Because of this, some things like apps have been challenging for some groups and they've opted to just create a new ticket to split the conversation.  This works well and reduces complexity of learning a new app, but we when the end goals is just to forward a message from a customer, its still a tedious solution of copy/paste/complete. 


    Email heavy workflows are just easier to do in an email client.  Sometimes our teams are just throwing their hands up and resorting to their email clients.  We don't want this necessarily, but CC/BCC/Forwarding just work as expected for our teams.  Until we fully solve for adapting away from email based workflows it's what we've got. 

    The future and other options

    We are looking into a lot of ways to resolve some of our challenges above. When it comes to Linked Ticket, we are leaning towards developing an application that just clones the current ticket and lets us set a requester and/or CCs.  This way we can quickly duplicate a ticket and send it on it's way.  Linked ticket requiring us to fill out fields slows down a process that was faster in email and we are looking to simplify the steps of splitting a ticket conversation. 

    We are also looking at options to security enable distribution lists so we can resolve our issues with sending to more than 20 email addresses as CCs.  In addition, many of the teams we have to reach out of Zendesk for, we are going to put them in Zendesk.  So some of these challenges will resolve as we pull more people in.  

    Ticket sharing is still also on the table for us for teams in different Zendesk instances as well. We haven't hit the need for it yet, but I'm watching out for it.

    We've talked about light agents, but at this time it isn't really an option for the sheer amount we'd need. 

    What I'd like to see from a solution

    I'm sure as soon as I type this out and submit, another requirement will pop into mind.  But I'd love to see the following to enable broader collaboration with email based teams from Zendesk: 

    • Enables me to share/split the ticket comments of my ticket with others without including the original ticket requester/CCs into it's own comment thread
    • Enable adding a secondary contact in a process that is as simple as adding a CC (or extremely close to this)
    • Enables the addition of end users into this process via macros, triggers, or automations
    • Enables smart notification that can restrict notifications to ticket users that aren't part of their thread
    • Enables me to track all threads within the same ticket screen
  • Toby Sterrett
    Zendesk Product Manager

    Thanks for the great feedback Kate and Daniel, this is awesome.

    @Kate, your workaround examples sound very familiar, except for the PDF, but I can imagine it makes sense sometimes :) What were some of the solutions the team was using before the migration to Zendesk Support?

    @Daniel, thanks for all the detail! I think the solution we're working on is heading in the right direction based on your bullet points. I'd love a bit more detail on the "Enables the addition of end users into this process via macros, triggers, or automations" point, though. What are the scenarios where this would come into play? Also, what would your ideal "smart notifications" system work like?

  • Dan Cooper
    Community Moderator

    Hi Toby,

    When I mentioned, "Enables the addition of end users into this process via macros, triggers, or automations" I meant that I would love for the existing 'Add CC' actions to allow me to choose end users. Possibly even an 'Add BCC' option as well.

    Smart notifications is something I haven't fully thought through, but here are some thoughts on approach.

    # CC Muting
    I'd love an option to choose a group of people that aren't the requester to collect updates from. In today's world, I CC several people who aren't in Zendesk. Ideally, they are talking with me, and not each other as they all work on different tasks. When they reply, all the other CCs get a notification when really I just want me and maybe my requester to get an update. I feel like this might be a different type of user on a ticket, but CC is the closest we have today.

    This could potentially be superceded by the next thought...

    # Threaded Notifications
    I mentioned threading above with different branches in a conversation. I'd love the opportunity to split a ticket multiple ways and have notifications split the same way. That way I'm only including the people in each thread in the email notifications.

    In our use case, many of our collaborative scenarios are with legal teams. We would like the option to maintain notifications with multiple teams who may not need to have all the information to support our customer.

    # CC Template Customizations
    I'd love more control over CC notifications. I feel like these should act the same as a regular Email user action versus their own restricted template. Today I have custom templates that don't apply to CCs so they get a different experience than out requesters.

  • Toby Sterrett
    Zendesk Product Manager

    Hey Daniel, thanks for the follow-up.

    What are the situations where you want to add end-users as CCs on a ticket via macros/triggers/automations?

    The notifications clarification makes sense... basically, only the recipients of an individual thread should receive emails for that conversation rather than alerting everyone in the ticket to a conversation happening on the side. That's in line with how our new feature is shaping up, so that's good to hear.

    As for the CC templates, the approach we're taking with the threads feature is to make the emails look and feel as much like regular email as possible. So that means no templates / delimiters are involved and the recipients will receive emails that are more akin to what they'd receive if the agent sent it from their regular email client. Also, everyone receives the same email with multiple recipients rather than a separate CC email going out. We felt like it was appropriate to treat these types of conversations more along the lines of an agent reaching out for help or to pass along information, and less like a "ticket." Does that make sense?

  • Dan Cooper
    Community Moderator


    We have several scenarios where we need to CC multiple locations and teams related to a customers needs.  In these cases, we have macros that we run per location to ensure we have the correct verbiage in place.  However, we also need to have the right people CC'd and most of our agents don't know everyone by name, they just know that they need the representative at location A etc.  When multiple representatives need to be included, then the process slows down significantly as each person may need to be researched to ensure the right people are on the thread.  

    A macro would give us the ability to ensure that quality is increased as one update can be made to the list of people to CC that benefits everyone.  As a trigger or automation, we could have certain individuals automatically CC'd if we need them to follow along in a conversation.

    Today, we have the list of email addresses at the top of each macro for the team to cut and paste from the comment.  However, there is a risk that those comments get left behind and sent out with a public comment.  This is coachable, but minimizing the risk would be nice. 

  • Kate Shaw


    Are you still looking for user stories? Our team relies heavily on gmail to communicate with both internal and external stakeholders regarding customer issues that come in via Zendesk tickets (emails). Happy to go into more detail if you have any questions or need more specificity. Thanks, and excited to see this roll out!

  • MiiiA Pty Ltd

    Hi All,


    May be a side-topic but I feel it's related.

    When working on tickets right now (as we all know) things are linear, and Internal Notes and Public Replies stack in order of time committed. This can be a little confusing despite the fact it's chronological.

    We often work with issues that involve debugging, investigation, research etc.
    What I would like is a separate TAB to hold a thread of Internal Notes that we could use for research, debugging info that is in a different space than the customer interaction/chat etc. 
    For larger bits of work we sometimes use Microsoft OneNote for this as an example, but for smaller issues/tickets that is overkill.

    I loved the sound of the future direction, and the ability to open parallel threads within the same ticket, each being able to handle communication with each relevant party/internally or externally. Not sure if this parallel style could accommodate my desires for a separate area for Internal Notes, images, files etc but could be.

    Exciting developments.



  • Toby Sterrett
    Zendesk Product Manager

    @Daniel – thanks for the detail! So it sounds like as part of a macro it would be important to be able to set the recipients of the side conversation as well? Would these folks generally be internal agents/light agents or external email addresses?

    @Kate – that would be great! I'm always eager to hear more real world use cases :)

    @Dan – it sounds like the Side Conversations feature would get you a long way toward that. It enables every ticket to be able to have as many standalone conversations as necessary, each with its own subject and recipients. It could definitely clean up multiple threads of conversation that would normally be happening in the chronological linear comment list. You can read more about it on the product page and the announcement post!

  • MiiiA Pty Ltd

    @Toby - Thanks. Side Conversations looks great. One thing I couldn't quite tell from all the material I read, could I start a side conversation with myself to just allow me to add another stream/chat to my own ticket? without involving other users/parties?

  • Daniela Catarino

    Hi Toby,

    Not sure if you're still looking for examples, but I'd like to give my feedback on a couple of apps that I thought could be extremely helpful to solve our problems with multiple conversations.

    We have 2 situations where we have to communicate with people that are not Zendesk users:

    1. People inside our company who don't use Zendesk, but to whom we may need to ask clarification or support in certain situations, and them to us;

    2. We're a marketplace that works with 2 different sets of customers (Tenants and Landlords), and often to be able to solve the problem presented by one of them, we need to communicate with it's counterpart.

    We believed that the Slack app could help us solve problem 1, but after doing some tests, we realised that some features lack in it:

    • When creating a ticket through Slack, one cannot choose group nor assignee, nor any other fields that would allow us to build a proper workflow & reporting for internal communication;
    • When there's a reply to that ticket that was created through Slack, the thread on slack does not update, so the requester won't know the status of the situation, nor will he be able to ask for an update in the same thread;
    • Some agents have asked to be notified on slack when their tickets are updated, but currently we can only build a channel on slack to give updates on Tickets from a given Group, not assignee.

    As for problem 2, Linked Ticket app seemed like a good solution initially (ex.: we received an email from the Tenant saying the room he booked was dirty upon arrival, we could create a child thicket for the Landlord, asking him to go clean the room). But we rely heavily on macros for our workflows (they apply tags, set Forms, fill Ticket fields, etc), and currently it's not possible to apply a macro when creating a child ticket through the Linked Ticket app.

    Hope this is helpful, would love to know if there are some plans to improve any of these 2 apps.


  • Toby Sterrett
    Zendesk Product Manager

    @MiiA – this is something we've thought about and heard from some customers. You can currently address a conversation to yourself and things should work. However, you'll still receive the emails in your email client since we're not currently suppressing email delivery based on the recipient. However, if this type of use case looks like it would be helpful to lots of customers, it seems like something we could work on improving. Would you mind providing some examples of when you would use side conversations in this way?

    @Daniela – thanks for the great write up on the details of your use cases and the feedback on the Slack integration. It sounds like the Collaboration add-on could be a good fit for your team, especially with some of the upcoming enhancements and features that we are working on. We have support for initiating a side conversation via a macro action coming up, which would let you set the tags and everything you need in the original ticket, as well as bring up the new side conversation with the subject and body pre-filled with template text that can take advantage of placeholder replacement.


La publicación no admite más comentarios.

Tecnología de Zendesk