Child Ticket Side Conversations introduce the ability to have side conversations with groups or agents within your Support instance via a child ticket assigned to them. Check out the docs to get started now.
When we first launched the side conversations functionality the only available channel was email. This worked well since email can reach anyone, but we received feedback that it would be great to start side conversations with teams that were already managed as groups in Zendesk. While it would have been feasible to use groups as a sort of mailing list, we realized that these teams are already managing their ticket queues in Zendesk and the best way to make a request of them is to file a ticket. Child ticket side conversations enable exactly this.
How child tickets work
Creating a child ticket side conversation is easy. The user interface is very similar to starting an email side conversation, with the only real difference being that the “To” field accepts either an individual agent or group to be assigned rather than email addresses. While it may sometimes be preferable to assign to a specific person, we’ve found that it’s often most flexible when assigning a group so another team can triage and handle the request however they normally would.
When the side conversation is sent, a ticket is created under the hood that is assigned to the recipient and linked to the parent ticket via the side conversation. The assigned group can then triage and handle the ticket however they normally would, making internal notes, settings fields, etc. When an agent makes a public reply on it, the side conversation in the parent ticket will receive the reply as a new message. If the requesting agent replies in the side conversation the child ticket will receive it as a public comment. It works very much like a regular email/ticket conversation.
Getting started
To get started with child tickets, go to the Settings > Tickets > Side conversations section and toggle Enable child tickets.
Please note: Since the workflow centers on public comments, light agents will not be able to create or comment on child ticket side conversations.
Use case example
Let’s say you’re an agent working on a ticket and you realize you need to reach out to the legal team to get their approval on some details. Luckily, the legal team is also in Zendesk managing their own ticket queue. Since this is a pretty common occurrence, you’ve established some workflows with the legal team and have a macro set up to initiate a child ticket side conversation assigned to them with some boilerplate text in the body that they usually need.
Using that macro opens up the child ticket with the Legal group set as the assignee and the subject and message pre-filled:
When this side conversation is sent, a ticket is created and assigned to the Legal team, which will appear in the Legal team’s main ticket view. When opened the ticket will indicate it’s a side conversation from another ticket:
They can then triage it however they normally would. As the Legal team works on the ticket, any public comments they make will be sent back to the originating side conversation and any replies by the requesting agent in the side conversation will appear as public comments on the child ticket. Any internal notes or side conversations the legal team makes will remain in their ticket. The side conversation will show all the public replies and current status of the child ticket:
This workflow will let agents leverage any other team working in Support to get the assistance they need while letting those teams retain their existing processes and workflows. It also ensures that all communications are consolidated in Support, leveraging existing workflows and keeping everything in one place for posterity and reporting. The agent assigned to the main ticket can orchestrate all the conversations necessary to solve the issue, firing off tickets to all the supporting teams to get it done, with a centralized record of everything that went into it right there in the ticket.
Speaking of reporting…
Since child tickets are, well, tickets, this means we can do some reporting on them. All child tickets created by side conversations will have the new “side_conversation” channel, which can then be used in things like trigger conditions, and also in Explore.
Filtering down to tickets in the side_conversation channel will show all the internal tickets created by side conversations, which will enable seeing the reply time metrics, solve time metrics, etc. Further filtering by group will show how long a specific group takes to respond to internal requests.
And since we have a new channel type, it’s possible to use it in conditions for setting up service level agreements. This opens up some interesting opportunities around establishing internal agreements between teams.
Child tickets created by side conversions matching these conditions will have an SLA timer applied to them. If the requesting agent adds a new message it won’t count against the reply metrics. This is very early days, but will hopefully unlock some additional accountability between teams who work closely with each other on a regular basis.
Any things to keep in mind?
We have a lot of ideas and plans for the future of this feature, but we always love hearing your feedback on how you’re using it and what could be better.
- You may want to tweak your notification triggers using the new “Update via side conversation” condition if you want to have more control over when things like email notifications are sent.
- Macro initiation currently only enables setting a group as the assignee.
- There is no connection between the status of the child ticket and the side conversation that created it. While the side conversation does show the status of the child ticket, solving the child ticket will not automatically mark the side conversation as solved.
- Depending on the configuration of ticket permissions, the requesting agent may be able to view the child ticket, and the agents managing the child ticket may be able to view the parent ticket. Links are provided from each.
- When testing, please keep in mind that it’s going to be a little weird if you’re the only person in the parent ticket, side conversation, and child ticket. It’s best to try things out with some colleagues.
As always, we look forward to learning more about how child ticket side conversations can become a part of your workflows and hearing your feedback!
12 Comments
Hi Toby,
that's a great new feature!
I wanted to activate it in all of my instances, but it was only available in a few of them. Is this currently being rolled out globally? When do you expect it to be available everywhere?
Additional first feedback:
Please give us the option to decide whether the comment should be public or internal. This would solve the "split ticket" problem that's mentioned a lot in the helpcenter community.
I could then assign the new child ticket to another agent/group and tell them to handle it with an internal comment.
Also for this "split ticket" problem it would be great if you could easily set the requester of the child ticket to the requester of the original ticket.
Two different possibilities for that:
Hi Toby,
This is a really helpful feature for us.
However, I've found a bug:
As a user I cannot create a macro to initiate a side conversation in a group I am not a member of. Manually creating the side conversation allows me to select any group.
Dylan Cunniffe you should now be able to set up a child ticket macro that includes all groups.
Hi Toby Sterrett, I finally had some time to try out Child ticket side conversations and I'm loving it!
I would like to have the ability to set the child ticket requester at creation, freeing up more use cases where child tickets can have other requesters than the initiator of the side conversation (while remaining tied to the parent ticket).
Even more important, in Explore I would like to be able to report on the parent-child relationship, so we could see which child tickets belong to which parent, also things like average response time of child tickets that have parents in group x is such and such. I hope that makes sense.
Hey Jacob, glad you're enjoying child tickets so far! We've gotten requests for being able to set the requester on creation, and we have some ideas for how it could be done, but this first release is focused on the internal use cases of requesting something from others teams in the same instance. Out of curiosity, how would you make use of being able to set a different requester?
As for Explore reporting, we don't yet have any reporting on the relationships between specific tickets, but you should be able to do things like average response time of child tickets between team by filtering on the groups and the side conversation channel type.
Thanks for the quick reply, sounds great!
The use case for setting the requester that I'm thinking of is within an HR context but could probably extend beyond that. Imagine a new hire situation, where a parent ticket is assigned to an HR agent who needs to coordinate the onboarding of this new employee. The agent needs to reach out (via child tickets) to multiple departments - IT, payroll, etc., and these child tickets should have the new hire be the requester in the child tickets - so IT can enquire about the color of the iPhone they would like for example. This would have the parent ticket keep the overview, but avoid having the parent ticket agent playing middleman between the child ticket assignees and the parent ticket requester. I hope that makes sense 🙂
Hope to have more reporting capability on the parent-child relationship soon.
Hey Toby Sterrett
An use case we have would be the amazon/marketplace where you will receive a ticket from a buyer, you will need to create a child ticket to contact the seller and once the child ticket it's resolved, you will need to contact back the buyer.
We would need to have triggers that allow you to open parent tickets once the child ticket gets resolved.
Also, I don't want the buyer to be receiving the content from the seller tickets because he does not have a direct relationship with the seller but with the marketplace
Jacob J Christensen - Cloudhuset A/S - that's an interesting point, makes sense. Would the new employee being onboarded have access to the parent ticket as well in your use case?
Dani Ruiz is there a reason the contact going to the seller needs to be a ticket instead of an email? You could potentially currently do that workflow with email side conversations.
Yes, the requester would be the same for both parent and child tickets in this scenario.
We have a naming convention where we prefix a group name with the Brand Name. Consequently, we have multiple groups starting with IT (e.g., IT - App Support, IT - Desktop Support, IT - Zendesk, etc.). The Child Ticket seems to only allow up to 12 matching suggested groups, which is fine. However, we cannot seem to specify a group outside of the first 12 alphabetically. Nor can I copy exactly the group name from Admin/People and paste it into the To: field for the Child Ticket. I can filter the To: field with a word like "App," but a word later in the alphabet, like "System" or "Zendesk," does not bring up any results when we have group names with those values. Am I missing something?
Thanks for the message Jamie, we'll take a look into this.
Hi Toby,
In reading the above and the related support articles, it looks like Side Conversation Child Tickets cannot be used if you want to communicate with third parties outside your instance?
We currently use email side conversations quite extensively to communicate with vendors and other partners that have the status of end users in our instance and we would very much like to be able to measure their response times, etc. (at the moment we are working to setup the side conversation API end point and crunching the numbers ourselves, but we'd like the flexibility to adjust side conversation SLA's, etc. using Zendesk's native tools).
Please sign in to leave a comment.