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
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.
Creating side conversations
If enabled, agents and light agents can create side conversations.
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 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 a side conversation
- From the upper-left portion of a ticket, click the plus sign (+) next to 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.
- For everyone else, enter their email address.
- 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. 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.
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. This doesn’t automatically include the assignee of the ticket or the creator of the side conversation. See Recommendations about side conversations.
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.
Comments
69 comments
I'm looking forward to this feature being enabled for our instance of Zendesk, but I am wondering about the following statement:
If I understand this correctly, if I open a side conversation with an internal party, I need to explicitly ask them to not respond to my email, as any internal discussion will thus be sent to the customer/requester.
If this is correct, are there any plans to improve this? With such behavior, it will be tough for me to implement it knowing we're only one simple human error away from leaking confidential information to customers.
Hi Mikael – that statement only refers to notification emails that are sent via a trigger that you would set up to notify the assignee of the ticket. This trigger does not exist by default and is unnecessary unless you really want the assignee of the ticket to get an email to let them know a side conversation has been replied to. We recommend changing the status of the ticket for views and using the in-product notifications instead.
Replies to the regular emails that Side Conversations send to recipients will not add any comments to the ticket or send emails to the ticket requester. So the internal use case should work just fine for you.
Thanks for bringing this up. We'll likely revise the wording on this to make my above explanation more clear!
Side conversations looks great, and is a feature that I have been missing.
However one thing that would help us a lot is if the From (and maybe the Reply-To) addres would use our domain name instead of zendesk.com
I would often like to send emails to internal systems that only accepts emails from our domain, or which behaves like Zendesk, and using the sender domain to identify which organisation-entity the email should be mapped to. So I can not simply add zendesk.com as "our" domain in those systems.
So by using the default support address (as configured in Settings) in some <UID>+email@domain format would help a lot.
I would rather prefer to have Threads using a email address applicable for the ticket than the 'default email address set in Settings'.
That would be beneficial for wide teams having multiple mailboxes linked with Zendesk.
The actual implementation can of course be discussed. The main point is that the sender domain should be our domain, not zendesk.com. "Default email address" was just a simple way to not introduce any new complex settings.
Yup, makes sense in general :)
Will side conversations also be enabled for customers already on a plan which includes the 'old' light agent add on?
Hi Jalle -
Yes, if you already have the "Light Agent" add-on, you'll be moved to the "Collaborations" add-on automatically. For more info, see the official Announcement for the Collaborations add-on, where this is specified.
@Ola & @Sebastian – the From: address is something we're investigating. There are a few things we're thinking of as possibilities:
It sounds like most of the concern is around the From: address being from the right domain vs. zendesk.com, right?
Hi, and thanks for the explanation.
Yes, it's the domain-part that is of concern.
But it is also important to ensure that replies are handled correctly. And I know there are clients out there that do not behave correctly when it comes to Reply-to, so I think it would be best if From and Reply-to are the same address. Eg. support+1234@acme.com
Thanks for enabling this feature widely! I was part of the EAP and really like the feature
I agree with Ola and Sebastian.
Selecting an email address or setting a default address per brand/agent would be beneficial. Also, would it be possible to add the agent's signature to the email by default?
@Ola – thanks for the follow-up. We'll have to look into the deliverability of emails with a From that includes the +identifier.
@Maurits – glad to hear you're enjoying the feature! Signature support is something we're looking into. Would the same signature that agents have for ticket replies be good for side conversations or do you think they would need a different template?
Hello Toby,
Thanks for the response!
I see no issues in using the default agent signature for our cases at least.
Is possible to measure the side conversations in the reports?
Is there an example?
regards
Sonia
This a feature we have been waiting for for a while, but there's one thing that does not make much sense to us:
"Keep in mind that the creator of the side conversation doesn't automatically receive email replies to side conversations. That’s not the default behavior.
We recommend that only the assignee of the ticket creates side conversations."
Why? The creator of the side conversation is the person interested in the response, sometimes more than the assignee. That could be a light agent (for example) that manages this account, or any other person that is not directly handling the ticket. This almost cancels the value of side conversations for us. Are there plans to change this behavior?
@Sonia – not at this time, but we're investigating the best way to make reporting available on side conversation activity. We definitely know it's important.
@Gal – there are a few different approaches to this we've considered:
I'd love to hear your thoughts on these ideas (or if you have a different approach in mind).
Also, how often do you anticipate side conversations being created by people who aren't the assignee of the ticket they'd be in? And would they always want to reply via regular email, or would they log into Support to reply?
Thanks for bringing this up, it's something we've been thinking about a lot, and real world scenarios will help us move this in the right direction.
Hi @Toby,
Thank you for replying so quickly!
Totally understand the approaches and why none of them is a slam dunk.
For us - out of the three, the third option makes most sense. We intend to use side conversations for internal teams communication, so the email leaking is not an issue. Getting an email on an update you yourself made is a bit ugly but e can live with that.
To give some background - side conversations for us is a solution for Light Agents to talk to each other about a ticket. All company employees who are not agents are light agents, and we try to keep communication recorded in tickets.
For example, agent A is handling a ticket for an large client. The client's Customer Success Director sees his ticket, and may open a side conversion with her team to say "Please all note that this is going on when you get to their office tomorrow!". Or escalate to her manager and say "This is the issue I mentioned yesterday that puts this client at risk".
Generally speaking, side conversations for us are more for collaboration of all the client-facing teams around the implications of this ticket, than for the agent to find resources to resolve the ticket (which is something we have pretty much solved with some dedicated Slack channels). It is this communication that we do want to have in the support platform, documented and searchable, but not visible to end users.
BTW - another solution to our challenge is for light agents to (a) 'Follow' a ticket and (b) @Mention other users in private comments. I know those are not on the roadmap currently but that's the basic functionality/use-case we are in need of. When I saw side conversations are available for light agents it made sense for this use case, and I do like it a lot for it not being a part of the main ticket conversation and causing clutter.
I hope this feedback helps!
Gal
> Replies to the regular emails that Side Conversations send to recipients will not add any comments to the ticket or send emails to the ticket requester
What will such email replies do? I do not see any mention of this; did I miss it?
Our light agents generally will not use the ZD Support web interface. When they get an email, they want to reply to it. This is understandable and logical. I would hope that replies to Side Conversation emails would be posted to the side conversation. are they?
UPDATE: Just started a short trial of this add-on. Yes, email replies do get added to the side conversation. Other questions / uncertainties to follow.
>> 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.
> that statement only refers to notification emails that are sent via a trigger that you would set up to notify the assignee of the ticket. This trigger does not exist by default and is unnecessary unless you really want the assignee of the ticket to get an email to let them know a side conversation has been replied to.
Just to check -- for us, agent email replies are private by default, not public. That would still be the case here, right?
Thanks!
Just started a short trial of this add-on. Nicely done, folks!
I'm surprised to see that there's no event log / audit trail. Is that because the conversation itself fully describes everything that happened when a side conversation is updated in any way? I would still think it useful to preserve these updates in the ticket's event log, in part because otherwise it could be quite painstaking to re-assemble a complex sequence of updates in multiple side conversations and on the ticket. "What happened" is an important question when things go wrong, and event sequence is a crucial part of that question.
Thanks!
Here's an edge-case that seems undesireable:
1) I am the requester of an internal ticket [I doubt if that is a necessary condition for this issue, but do not know]. I also start a side conversation on the ticket. I want to get responses to the side conversation by email, so I include myself in the recipient list of the side conversation.
2) One of the primary recipients replies. I am on the "TO" list of their reply, so I get their email (great) but I decide to reply in the web interface.
3) But even though I'm on the "TO" list of their reply, I'm not on the TO list of my next reply.
4) Therefore, unless I manually add myself back to the TO list of this web-based reply, I won't be on the TO list of any other recipient's next reply, so I won't see it by email.
@Gal — awesome, thanks for the detailed example and explaining your overall workflow, that’s really informative. It’s an interesting use case to is it just for internal discussion of a ticket rather than reaching out to folks, but it does make sense. It’s kind of like a cleaner, more organized internal notes that enable internal discussions with specific subjects and people.
As for including the creator of the side conversation as a participant in the recipients, we’ll look into how that could work and how it could be approached. It likely partially works now, but there may be some quirks that prevent it from being smooth.
I’d love to hear more about how you’ve been using Slack for reaching out to other teams for help on the ticket. Can you provide a quick summary of how that works and any shortcomings it may have?
@Jonathan — thanks for all the feedback and questions! I’ll answer them in order:
Thanks for the responses, Toby.
> (3) Are you referring to the gray box that includes the details of the ticket state and changes made during the event?
Yes. Again, that's super important for forensics. Appreciate your looking into it.
Continuing to investigate...
@Toby
How we use Slack: in a pretty basic way :)
All teams have their slack channels, and additional channels exist for asking questions about different domains of the platform. 95% of slack channels are public, so anyone at Kenshoo can jump in, ask a question, get the answer from whoever is active, and leave the channel (optionally).
The Support teams often do this to get answers. It's easier than email, because you don't need to know who exactly may know the answer for your question. Channels naming conventions _usually_ allow you to understand what they are about, and this way to address multiple people you don't even know (650 employees company, with offices across the globe).
All of this is not documented in the ticket, of course. As an agent, I would go to slack, ask and get answer, and go back to my ticket to continue the conversation with the requester.
As said above, what we are trying to solve are internal conversations discussing the ticket with light agents, usually started by them and not the agent. If we could integrate THOSE into slack as well - that would be amazing. Starting an ad hoc conversation in slack (channel+DM) from within a ticket, and having this conversation logged in that ticket is probably the holy grail here...
Hope this helps! Do feel free to contact me offline if anything is cooking in your product team that I can help steer towards this use case, review, give feedback etc.
@Gal – this is great! Thanks for the info on how you use Slack, it sounds very much in line with how we've been thinking about it. We'll be sure to contact you for further feedback on this type of stuff in the future.
We have been waiting for this feature for a while. We are currently testing it.
Feedback + questions:
1. would it be possible to have the same contact search available in the side conversation similar to the one in tickets? Currenty the system only automatically prompts the names of the agents, but none of the other existing contacts.
2. Currently the enduser has access to his ticktets and the tickets he's on cc: in guide. Are there any plans to include the side conversations in the guide module?
another question:
@toby
I am in the same place as Ola and Sebastian, and heartily agree. The only thing stopping us from wide-spread acceptance and implementation of Side conversations.
In our use case, we deal with the government a lot, and they dislike any sort of change in where we send emails from, and I know they will start a fuss if we try to send things from collaboration@subdomain.zendesk.com
This option works best for is one you mentioned:
Thank you so much for this wonderful addition to Zendesk, and I look forward to future tweaks to make it as near perfect as the rest of Zendesk.
@toby: Please bring us some iteration of the masked domain.
@Patrizia answers below:
@Troy & @Mike sending/receiving emails from custom/brand emails is in the works!
Please sign in to leave a comment.