Using side conversations in tickets (Collaboration add-on)

Have more questions? Submit a request

103 Comments

  • Sonia Radaelli

    Hi Toby

    I would like to strenghten Patrizia's point 2 as it is important.

    In the case side conversation is used with a Zendesk user, he have to see it in his Guide.

     

    0
  • Toby Sterrett

    @Sonia – would you mind giving me a sample scenario where this would be the case?

    0
  • Sonia Radaelli

    Hi Toby,

    Our typical scenario for us is using side conversation with our salesmen (that are users) on a customer ticket.

    Agent have to receive a reply from salesman before replying to the customer and close the ticket with a customer. Now we are creating an incident ticket to manage this scenario. Side conversation can be a useful method.

     

     

    0
  • Mary Thomasson

    We really like side conversations and are looking forward to future improvements.  One thing we would like to see is the a "print view" of a side conversation that can be saved as a PDF, similar to the ticket print view.  Currently if we need to capture a side conversation we can only take a screenshot (or multiple screenshots, if the conversation is too long to fit on the screen).

     

    Thanks!

    0
  • Toby Sterrett

    @Sonia thanks for the details!

    @Mary we've gotten this request from another customer as well, so we have thought about it. Out of curiosity, what is the use case for using the PDF or printout of a side conversation? And I'm assuming you want to be able to print/PDF individual side conversations, not including them in the printout of the ticket itself or anything like that, correct?

    0
  • Mary Thomasson

     Use case is at times we need to use the side conversation as documentation of an event in another ticket.  For example if an escalation to another team results from a side conversation.  Sometimes we will need to include the ticket printout, and sometimes we won't, so preferably we would have the ability to print the side conversation separately.

    0
  • Andrea Moore

    I agree with others that using our domain is essential. My company deals with the government and health care facilities. They all have strict security protocols that only lets them accept emails from approved senders.

    I was also wondering if there were a way to add a signature to the side conversation. If not the signature we have set up on our domain, can we add at least the agent name? Maybe with a trigger?

    0
  • Graeme Carmichael

    This does not sound like good design to me:

    >When someone replies to a side conversation through an email notification, the reply becomes a public reply on the ticket, not a reply to the side conversation. This means that they are replying to everyone on the ticket, including any customers on the ticket, instead of a limited subset of people in a side conversation.

    But in practice, I just created a side conversation, received and email, replied to the email and the reply became part of the side conversation rather than a public ticket comment. That seems more logical to me.

    Am I missing something?

    0
  • Ola Thoresen

    @Graeme: The wording of that paragraph is a bit confusing. The point is that if you set up a _trigger_ that will send a notification eg. to the assignee that a new message has arrived in a side conversation, and the recipient of that notification replies to that notification via email, this reply will become public.

    0
  • Andrea Moore

    @Graeme - when someone replies to a side conversation, the agent who created the side conversation will get a Growl notification. You can set up a trigger to send an email notification to the agent any time a side conversation has been updated. If the agent replies to this notification, then it will become a public reply on the ticket.

    I set up my notification to say:

    Someone has replied to a side conversation in ticket {{ticket.id}} - {{ticket.title}}.

    Please respond back in Zendesk: https://{{ticket.url}}.

    0
  • Toby Sterrett

    @Andrea – signatures is being worked on. The plan is to use the same signature that the agent would have sent along with regular ticket replies.

    @Graeme – Ola and Andrea are exactly right, that caveat is only applicable to email notifications sent as the result of triggers, not the emails sent to recipients of the side conversations. Like in Andrea's example, the trigger notification emails can only really let you know that something has happened, so it wouldn't make sense to reply to them anyways.

    0
  • Ola Thoresen

    Once "we" have settled on what the from-address will be, I would love to have another feature - the ability to see that address without sending myself an email.  That way we can enter the side-conversation email-address as a Cc in third party systems without sending them an email first.

    So the process would be something like:
    a) Create a new side conversation
    b) Copy side conversation email-address
    c) Paste email-address to 3. party 
    d) Receive their updates directly in the case

    in particular this is useful when we are waiting for updates from various monitoring systems, 3. party development processes etc. where we can add a recipient of updates directly in a web ui, but where we do not have anybody to send an email to. 

    0
  • Graeme Carmichael

    Ola, Andea and Toby, thank you.  

    0
  • WinCo Foods

    @Toby, are there plans to allow embedding the Ticket Comments?  We've recently updated plan and purchased the add-on, having this option would make the upgrade worth the investment.

    0
  • Toby Sterrett

    @Ola that's a really interesting use case for having easy access to the conversation's direct email address! I'll put that on the list of things to investigate for upcoming updates.

    @Winco Foods do you mean easily being able to put the content of a ticket's comment(s) into a side conversation to pass along, similar to forwarding a message? Can you give me an example of what you're looking to do in the context of one of your workflows?

    0
  • WinCo Foods

    @Toby, correct - for example, I want to start a side-conversation with a department that is not part of the support department, but can help us investigate the issue.  Here's a sample:

    • Customer opens ticket listing their specific concern and details
    • The area that the customer is asking about it related to our networking team
    • We open a side conversation, asking the networking team to investigate the issue based on ticket details
    • Networking replies, support makes a decision and delivers resolution to customer

    Thank you!

    0
  • Toby Sterrett

    @WinCo Foods ok great, thanks for the example! We are indeed working on a few different ways to accomplish getting ticket comments into a side conversation:

    • Starting a side conversation from a comment – opens up a new side conversation with the subject and the text from the comment included
    • Comment insertion – when composing a side conversation message, you'll be able to insert a ticket comment via a menu
    • Macro initiation – a new macro action that will let you specify a new side conversation's subject and body, including standard ticket placeholder replacement. This feature will enable you to include the ticket's description (first comment), ticket ID, custom field value, etc.

    These new features are in development and undergoing internal testing. We don't have a firm date on if/when these will ship, but we are definitely thinking about these types of problems and how to make the workflow you've described easier!

    3
  • Jeremy Holmes

    We are testing this now and were hoping to see many of the same options available in regular ticket so we can track data on the side conversations as well. We would like the ability to use macros, independent tagging, use of forms, etc, but under the initial ticket. I know that will take a lot more work, but it seems like it would be the logical way to move with this. It would allow for a simpler front end when dealing with multiple parties, but more complex reporting in Insights to track the data. 

    0
  • Michael Adams

    Is it just me or are all the side conversations not forming a thread. As I test it out and we send side conversation emails back and forth... a thread forms on the Zendesk side, but not for the person who is getting the email.

    So if I send a side conversation that is asking a question, that person doesn't respond, so I send a followup comment that says "Hey did you get this"... the email the person gets is literally "Hey did you get this" and not the initial comment + "Hey did you get this".

    Is that an intended function? If so, I don't know how I could use this anymore...

    4
  • Jeremy Holmes

    We came across the same issue Mike stated. I agree that this greatly reduces the functionality. The main reason we are look at this feature is so we can have communication with other services on problems tied directly to the customer ticket they are associated with. If the chain is broken with each message, it will potentially cause much more confusion than having to track separate tickets like we are doing now. 

    1
  • Toby Sterrett

    @Jeremy we're definitely trying to work toward a good balance between lightweight side conversations and recreating full tickets (which we don't have any plans to do). We are working on the initiation of new side conversations by macros, but not necessarily having macros within side convos for replies. We've had some folks suggest tagging of side convos, which sounds interesting but we're still looking into the use cases around it. However, I think something like implementing forms moves more toward actually using another full ticket. You mention wanting to track data on side conversations – would you mind giving me some more details on what data you'd like to track at the individual conversation level, and the types of reporting you'd want to do?

    @Mike & Jeremy the emails that side conversations send are definitely intended to thread in the recipient email clients. We'll take a look to see if something is currently not working in that regard, but we are sending In-Reply-To headers etc. to enable clients to group them together. I just tried Mike's scenario in a couple email clients and it worked as intended. What client are you seeing these emails not thread in?

    Also, it sounds like you may also be referring to including the original quoted message along with the new message when sending emails. This is something we're actively working on right now, so that will be coming in an update (along with some other email improvements). That way if it doesn't thread (they trashed the original email or something) then it'll still contain the context of the original message(s).

    0
  • Michael Adams

    @toby... it is grouping the emails in the email client... that's not the concern. The issue is that the email itself doesn't have the email chain as comments are posted back and forth. 

    Follow these steps to check.

    1. Zendesk user sends a side conversation to Email user saying: "Please order product A"
    2. Email user does nothing and does not respond.
    3. Zendesk user adds a comment to the side conversation saying: "Did you get this? (see below)"

    The expected email to be sent, and what you would expect get if using plain email would look similar to this below:

    Did you get this? (see below)

    On Aug 7, 2018, at 3:38 PM, Michael Adams (Workforce Support) <collaboration@mydomain.zendesk.com> wrote:

    Please order product A

     

    What Email user gets instead is a single email that simply says

    Did you get this? (see below)

     

    See there is no other context that email that includes the prior email. 

     

    Does that make sense?

    Thanks!

     

     
     
     
    1
  • Toby Sterrett

    @Mike ok yup, that makes perfect sense, and it's something we're actively working on! Thanks for the clarification.

    0
  • Jeremy Holmes

    We work with a lot of vendors that handle different things for us. It is not uncommon for one ticket to be associated with four or five others for a single issue. It is then a task to track all of the tickets separately even though they are all related. We have used and created different apps and views that have helped though none seem to do what we ultimately would like. Before we moved to Zendesk, our home grown system of doing things had a simple place to see all interactions by showing them as a thread the same comments of our order management system so they were easy to read through to get a complete picture of what was happening. That was about the only thing that system had going for it though and we moved to Zendesk for better overall functionality on other things. When we heard about this feature, we were hoping it would help us organize things better and bring all the interactions of one incident into one organized place so if any parties involved responded, it would bring that ticket with all the details to the attention of an agent. Once some of the fixes that are planned go into effect, it is likely it could still help, but we don't want to lose some of the reporting aspects and we encourage the use of macros on everything we can. A use case would be to use our RMA-Defect macro to a supplier and have that message tagged with the things we normally tag such as the brand of the products, and then be able to track how many side conversations were RMAs for a particular organization tagged for a certain brand with a form that list the return reason as defect. When we report, we would want only the RMAs generated as a side conversation due to defect, not every side conversation where there is an RMA. We understand that the main ticket could be tagged with some of this or try to include these types of details in the forms on the main ticket, but then we run into instances where we are working on an RMA for a customer due to defect, replacement shipment that may have shipped from a different warehouse, and a secondary service provider to assist the customer with installation. While a new ticket for each makes sense, the reality of telling a customer that you need to look at 4 other tickets that we have to search for just to know what is going on with a situation can be frustrating for our agents and our customers. 

    0
  • Toby Sterrett

    @Jeremy awesome, thank you for the details, this helps a lot. In the near term, I think the approach of using macros to set tags and fields for reporting purposes would be the way to go, but I realize that it won't address the more complex cases you described. Would the addition of something like tags to individual side conversations get you far enough? It sounds like you'd need multiple bits of information per conversation, so something like tags (as opposed to a single  "category" dropdown or something) would be more flexible. Aso, aside from reporting, would you use these tags for anything else in the UI, such as filtering or display?

    0
  • Jeremy Holmes

    Tags would be a benefit that we could definitely work with, but we have found that taking the time to build appropriate forms is more beneficial, allows more specific reporting, and necessary for routing because routing does not use tags at all. Tags do have a lot more flexibility in the type of data we can add to a ticket and we can still report off of them, and we can have macros add an appropriate tag to make sure it is listed correctly. There is a bit more granularity when we build exactly what we want into a form and allow the agent to modify as needed. We currently use tags for multiple things including the filtering of views, running automations or triggers, and some daily report views and I can see that we would want similar functionality with tags within side conversations as well if they are available. So, we would definitely benefit from the use of tags and I feel this product would be something we definitely use if it was available, but I do think that eventually combining forms with tags would be the most powerful option. 

    0
  • A.J. Bouchard

    I have been following the discussion in these comments about the From: email address being more appropriate to the ticket, rather than a zendesk.com email address. 

    Another aspect I'd like to bring up is the From: name. Testing this out, it appears to take the agent's full name and then in brackets put the name of the instance. For example, above in Mike Adam's comment, he has "Michael Adams (Workforce Support).

    1. Can we make it so that the agent name only shows either their first name or their profile's alias?

    2. In the brackets, can we have it so that it reflects the From: name that is set in for the ticket's email address? (Where we go to Settings>Email and then click "Edit" beside the email addresses). Then it's more specific to that ticket's brand. We have multi-brand and multiple email addresses. Our instance's main name would not suit them all.

    That way, the From: name would be something like "Mike (Workforce Billing Support)".

    1
  • Toby Sterrett

    @Jeremy great, thanks for the further details.

    @A.J. great questions, thanks for bringing that up. Both of those are things we should be supporting, so I'll put them on our list.

    0
  • Steven Rothberg

    Hi Toby, the ability to paste screen captures into a side conversation and have a viewer for side conversation that is a little more full featured and displays embedded images would be a great advantage. We'd love to use side conversations to reach out to vendors which support tickets relate to but we need to supply screen captures regularly so they can trouble shoot our problems. Could you look at this in the future.  

    1
  • Toby Sterrett

    @Steve we'll definitely be taking a look at this type of functionality for future releases. We're currently testing incoming HTML messages with inline images, so that's on the way.

    It sounds like your normal workflow is to take a screenshot to your clipboard and then pasting it into the message, vs. saving a screenshot to your computer and selecting the file and/or dragging it in... is that correct? Is it normally one image or does it vary?

    0

Please sign in to leave a comment.

Powered by Zendesk