Side conversations are spaces in a ticket where agents can have a side conversation with a specific group of people, or discuss a specific area of concern or course of action. You can use them to organize information about a ticket.
This feature is only available if it has been enabled by the administrator.
The Collaboration add-on is required for side conversations. For more information about add-ons and light agents, see About add-ons (Professional and Enterprise).
- Advantages of using side conversations
- Recommendations about side conversations
- About side conversation channels
- Rich text editing in the side conversation composer
- Creating side conversations
- Viewing and replying to side conversations
- Closing and reopening side conversations
- Adding ticket comments to a side conversation
- The Support mobile app does not support side conversations
Advantages of using side conversations
Problems often consist of multiple parts, and solving them often consists of conversations with different people. It gets confusing for everyone involved when all of the questions and answers are mixed together in one place without any kind of organization.
For example, let’s say you need to discuss something with your Legal team, but don’t need or want other people involved.
- Find, organize, and manage information about a specific part of an issue
- Have a conversation with the right people
- Find specific questions, answers, and replies. Ensure conversations happen outside of the main conversation with the requester
- Have multiple standalone conversations that are separate from each other
- Get outside help without pulling others into the main ticket directly
Recommendations about side conversations
- The assignee should create and manage side conversations in the tickets they're responsible for. This allows administrators to create triggers based on the assignee role, and enables easier handoff between agents.
- Set up triggers to take advantage of the side conversation event conditions in order to fully integrate them into your workflows and to keep agents on top of the activity within them. See Setting up trigger conditions for side conversations.
- Create trigger conditions for side conversations to make sure that assignees know when a side conversation is created, closed, replied to, and reopened. Without them, the agent assigned to the ticket (ideally, this person is also the creator of the side conversation) may have a hard time knowing what’s going on with a particular issue.
- Remember that the creator of the side conversation doesn't automatically receive email replies to side conversations. That’s not the default behavior. Also sending side conversations to your own support address is not supported and will result in those side conversations ending up in the Suspended tickets view.
About side conversation channels
When you create a side conversation, you can choose to have the side conversation in one of these channels:
-
Email—Creates an email-based side conversation as described in this article.
-
Slack (if enabled)—Creates a Slack-based side conversation (see Using Slack in side conversations).
-
Ticket (if enabled)—Creates a side conversation child ticket (see Using side conversation child tickets (Collaboration add-on)).
Rich text editing in the side conversation composer
The side conversation composer is a rich text editor that includes a toolbar with options for editing and formatting your text. Rich text editors are sometimes called WYSIWIG (what you see is what you get) editors.
The formatting options in the composer vary a little depending on the side conversation channel involved (Email, Slack, or Ticket). For example, these are the formatting options for email:
The composer for Email and Ticket side conversation includes a full array of formatting options because email supports full HTML display. The composer for Slack side conversations includes fewer formatting options because Slack uses a subset of Markdown for formatting. With Slack side conversations, you can also use Markdown-style shortcuts while typing in the composer, and they will be converted to rich text. For example, if you type bold, bold is applied to the text in composer.
This table lists the editing options that are available with different side conversation channels.
| Formatting option | Email & Ticket side conversations | Slack side conversations |
| Bold | Available | Available |
| Italic | Available | Available |
| Bullet list, Numbered list | Available | Available |
| Quote | Available | Available |
| Code span | Available | Available |
| Code block | Available | Available |
| Heading | Available | --- |
| Outdent, Indent | Available | --- |
| Link | Available | --- |
Note the following limitations with the composer:
- The composer doesn’t support inline images. You can, however, add images as attachments.
- If you paste complex rich text into the composer, you will likely lose some formatting.
Creating side conversations
If enabled, agents and light agents can create side conversations.
You can create side conversations on open or closed tickets. When someone replies to a side conversation on a closed or archived ticket, triggers won’t be run on it even if they have side conversation conditions, but a follow-up ticket is automatically created (see Understanding follow-up tickets for side conversations (Collaboration add-on)).
Any time someone creates a side conversation, a notification appears in the Zendesk Support interface for 60 seconds.
Side conversations must be enabled by an administrator.
To create an email-based side conversation
- From the upper-left portion of a ticket, click the plus sign (+) next to Side Conversations and then choose Email.
For information about using side conversation channels other than Email, see Using side conversation child tickets (Collaboration add-on) and Using Slack in side conversations).
- Enter the recipients, a subject, your message, and add attachments. You have these options:
- For agents (and light agents) that are already in the system, type their name. When you see the person you are looking for, click their name. Address autocomplete for agents and light agents include a badge to show they are agents.
- For everyone else, enter their email address. You only have to type or paste the full email address once. The next time you initiate a side conversion with that person, the address will autocomplete.
- An email address highlighted in red has incorrect formatting and needs to be corrected.
- When you add attachments, you can select a file from your computer or include one or more attachments that already exist in the ticket. Click the attachment icon (
) and select From computer or From ticket.
Tip: Instead of downloading ticket attachments to your computer to include them in a side conversation, you can add attachments directly from the ticket.
- For agents (and light agents) that are already in the system, type their name. When you see the person you are looking for, click their name. Address autocomplete for agents and light agents include a badge to show they are agents.
- Click the Send button.
All of the recipients on the side conversation receive an email notification with your message. This doesn’t automatically include the assignee of the ticket or the creator of the side conversation. See Recommendations about side conversations.
Viewing and replying to side conversations
Reply to side conversations from the Zendesk Support interface rather than from one of the email notifications generated by side conversations.
When someone replies to a side conversation notification created by a trigger, 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. This is especially important if your side conversations include sensitive information. Generally speaking, it’s a just a good idea to know who you're replying to.
Recipients of a side conversation can reply through email, just as they would to any other email. Side conversations retain the original formatting of incoming emails. The assignee on the ticket can also reply to a side conversation through the ticket from the Zendesk Support interface. Regardless of how a response was sent, it appears in the ticket for the assignee.
The people on a side conversation can be inside or outside of your organization.
You can create side conversations on open or closed tickets. If someone replies to a side conversation on a closed ticket, triggers won’t be run on it even if they have side conversation conditions.
To view and reply to a side conversation
- From the bottom portion of the ticket, click the View side conversation button for the side conversation you are interested in.
- Click the Side Conversations bar to see a list of side conversations. Click the one you are interested in.
- Scroll up to review earlier replies in the side conversation, if needed.
The conversation opens to the first unread reply for the agent viewing conversation. The most recent replies appear at the bottom of the side conversation.
- Update the list of recipients (if needed), add your reply and attachments, and then click Send.
Each message has its own set of recipients, which can be edited at reply time.
When you add attachments, you can select a file from your computer or include one or more attachments that already exist in the ticket. Click the attachment icon (
) and select From computer or From ticket.If you changed your mind and don’t want to send the message, click the delete icon (
). The delete icon () does not delete the entire thread. Once you start a thread, you cannot delete it.
All of the recipients on the side conversation receive an email notification with your message. The message being replied to is included as quoted content on outgoing emails.
This notification doesn’t automatically include the assignee of the ticket or the creator of the side conversation. See Recommendations about side conversations.
If you have an email signature set up, it is automatically inserted into the message. If you have personalized replies enabled, these settings are also included in your message. Conversations are sent from the support address associated with the ticket, and if configured, include the address name.
Closing and reopening side conversations
Closing a side conversation changes the status of the side conversation to Done. Closing and reopening side conversations does not result in any additional email messages to people on the side conversation. It’s also important to note that closing a side conversation does not prevent people from adding new replies.
Status information associated with a side conversation is meant only to help the agent. It is not for the benefit of the end user or other people on the side conversation. That's why closing a side conversation doesn't prevent people from adding new replies. They may have additional questions or comments later, even after the side conversation has been closed.
It is up to the agent to decide whether a reply to a closed side conversation requires reopening the side conversation.
You can create side conversations on open or closed tickets. If someone replies to a side conversation on a closed ticket, triggers won’t be run on it even if they have side conversation conditions.
Any time someone closes or reopens a side conversation, a notification appears in the Zendesk Support interface for 60 seconds.
To close and reopen a side conversation
- Open the side conversation (see Viewing and replying to side conversations).
- Click the Mark done button.
The side conversation status changes to Done.
If you want to reopen the side conversation, repeat step 1 and then click the Reopen button. The side conversation reopens and no longer includes the green Done label at the top of the side conversation.
Adding ticket comments to a side conversation
You can include one or more ticket comments as part of a side conversation. This prevents you from having to copy and paste relevant information.
To forward a ticket comment
- On a ticket, locate the comment you want to include, then select Start a side conversation from the drop-down menu.
A side conversation appears with the ticket title and comment already included, ready for you to add introductory text and include a forwarding address. You can start a side conversation from any comment in the ticket.
To include multiple comments
- Start a side conversation. You can start the conversation from an individual ticket comment or from the upper-left portion of the ticket.
- Click the comments icon (
) at the bottom of the message.
A page appears with a list of ticket comments to include.
- Select the comments you want to include. You can select each comment separately, or select Ticket comments to include all comments.
- Click Add.
The Support mobile app does not support side conversations
Side conversations is not supported on the Zendesk Support mobile app. You cannot create, view, or reply to side conversations from the Zendesk mobile app at this time. These tasks must be performed from Support on your computer's browser. However, you can still use the email client on your mobile device to receive and reply to side conversation notifications.
160 Comments
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.
@Sonia – would you mind giving me a sample scenario where this would be the case?
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.
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!
@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?
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.
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?
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?
@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.
@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}}.
@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.
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.
Ola, Andea and Toby, thank you.
@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.
@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?
@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:
Thank you!
@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:
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!
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.
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...
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.
@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).
@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.
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)
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!
@Mike ok yup, that makes perfect sense, and it's something we're actively working on! Thanks for the clarification.
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.
@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?
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.
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)".
@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.
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.
@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?
Please sign in to leave a comment.