Because email is an important channel for tickets, the user experience in email applications such as Gmail matters for both end users and agents. End users can carry out entire ticket conversations using their email application; agents routinely get ticket notifications in their email application—for example, when a ticket has been assigned to them.
Simplified email threading improves the way that email messages appear to your end users and agents in modern email applications such as Gmail. It removes redundant messages to make conversations easier to follow and more productive for both end users and agents.
This article covers the following topics:
Understanding the end user experience
This section shows an example of how a ticket email thread may appear to your end users after you implement simplified email threading.
Suppose an end user submits a support request using Gmail and the agent replies by adding a comment to the ticket in Zendesk. In the original experience, the end user receives an email notifying them that their support request has been updated. The message not only shows the agent's reply, but it also repeats the user's original message as a threaded comment with the agent's reply.
The simplified email threading experience is more conversational. The same interaction looks as follows in the end user's email application:
The difference is more noticeable when the end user adds a second comment and the agent replies to it. In the simplified email threading experience, the interaction looks like a normal conversation in the end user's email application:
The same interaction looks as follows with the original email threading experience:
In the original email threading experience, each subsequent message in the conversation repeats the full thread of the conversation to that point.
Including only the comment in each message allows the end user to better use the native threading capabilities of their email application. In long email threads in Gmail for example, only the first message and the last two messages are shown with an option to expand the thread. Example:
If an agent adds a user as a CC in a long conversation, the message shows the comment along with the three most recent public comments to give the newly added user some context of the conversation:
Zendesk also sends the message history as a quoted reply with each message. The quoted reply is usually collapsed in the user's email application, but the user can expand it. In Gmail, for example, the user clicks the ellipsis (…). In the unlikely event that Zendesk can't pull the entire message history to populate the quoted reply, a snapshot of the last three messages in the ticket is sent to provide context on the thread history.
Understanding the agent experience
Although agents work mostly in the Zendesk agent interface, agents routinely get ticket notifications in their email applications—for example, when a ticket has been assigned to them. In the simplified threading experience, email notifications sent to an agent include more information about the ticket, including metadata the end user does not have access to.
As in the end-user experience, each message sent to an agent only includes the comment made by a user or agent, not the complete email thread to that point. However, in the agent's case, the message also includes a ticket info card with key information about the ticket as well as a button the agent can click to view the ticket in Support:
Internal notes and warnings can also appear. In the screenshot below, agent Jenny Kim hasn’t been included in the ticket, but has permission to view it and leave comments. She left an internal note for her fellow agents, which is indicated above her comment. Because she had not been added to the ticket before commenting, a warning appears at the top of the comment letting agents know her status.
For comparison, here's a similar message in the original email experience:
22 Comments
We've received a Support pop-up notification on Simplified email threading, though it's not available yet, as neither of the new placeholders seems to be rendering.
Charles NadeauCould you please clarify whether the new "ticket info card" is added via the
{{footer}}placeholder?
Additionally, will there be an equivalent version for the end-user? While invisible, it could be useful for us to extract ticket data via Liquid functions.
Hi Rafael, thanks for the question. We are still in the process of rolling out Simplified Email Threading to all customers, so the placeholders should be available to you within the the next week. Please let us know if you're still not seeing the placeholders after next week!
The {{footer}} placeholder includes the ticket info for agent-only communications as it always have, but will have the new look and feel (the ticket info "card") when used in conjunction with the new Simplified Email Threading placeholders mentioned inthe Implementing Simplified Email Threading HC article. Right now, we only have plans to include this info in agent-only communications.
Thanks for clarifying,Benjamin Kirsch
It was enabled in our production instance last night, showing the following banner on the Email settings page:
I've played around with it and am noticing that the{{footer}}placeholder is now sending the different ticket info cards based on placeholder presence, as expected.
I've noticed it in a Trigger that notifies agents of ticket assignment, in which we're only including{{ticket.id}}and{{ticket.title}}placeholders, as it's still sending the old card, while I've seen the new card format in a test trigger to experiment with the new HTML placeholders.
It would be great to have the option to enable the new card for agent email's footers, regardless of the notification's placeholder content.
Examples of those received:
I was curious about its format to be able to show conditionally in the Email template.
This is what I've prepared so far to show the card for agents using ZD in English, for a specific ticket group and brand pair:
{% if footer contains "zendesk.com/agent/tickets/" and "{{group_name}}" %}
{{footer | remove_first:"This email is a service from{{brand_name}}."}}
{% endif %}
Hi,
Does this change anything in the Zendesk agent interface?
Hello Bruno,
No, it doesnt change any UI elements in Zendesk Support. This only affects how notifications are displayed in emails.
There seem to be quite a few bugs with this recent release when it comes to the end user experience:
1. The quote button only appears for the end user, when the last message sent was also by an agent. If the last message sent was sent by the user, the user sees a standard email quote.
So this only seems to really work when an Agent sends two consecutive replies. Otherwise a standard email quote thread is displayed to the end user:
2.CC's do not seem to get the three most recent messages. They also do not get the quoted button. They only get the standard email quote format.
3. Agent email addresses appear in the quoted content (though this one seems to have already been addressed and will hopefully be fixed soon)
Thanks for the feedback Shayan! We have taken note all of these points and appreciate it for better improvement of this feature
Hello
I have a few customer complaining they haven't seen our reply. I can't have complain like this.
Can we de-activate this function?
Or can you give clear explanation what to update from our side ?
Thanks
Hey Frédéric,
I'm going to create a ticket on your behalf so our Customer Care team can look into this with you.
You'll receive an email shortly stating your ticket has been created.
Cheers!
Is there a simple way we can just add this instead of having to manually do all the steps above? Seems like quite a long setup process i'd like to just be able to check a box if we want to use this feature. Will that be coming soon?
Is this an 'all or nothing' activation? We're intrigued to see if this represents a better world to our users - but would prefer to be able to activate it in a limited way to 'trial' with a set of users and get feedback before launching globally.
嗨,马克,谢谢你的问题!这不是一个ll or nothing activation and you can implement it on as many notification triggers as you'd like. Because all of the functionality is tied to the new set of placeholders listed above, they can be used to customize each notification trigger individually. One way to test for example, would be to create a temporary notification trigger with the new placeholders to see what the new experience looks like first hand.
Is there a way to disable the 3 most recent interactions in the CC flow?
Unfortunately, I don't think there's a way to do that. Can you post your use case to ourFeedback - Ticketing System (Support)topic, using thistemplateto format your feedback?
With simplified email threading enabled - private comment notifications that agents receive, no longer show the person who posted the comment. This is quite bothersome - are there any plans to update the template, so when agents are tagged by another agent and receive an email notification, they will know who was the person that tagged them?
Use case: Being able to identify who posted a private comment within the email directly, would help readability and understanding of an issue.
I've noticed a couple articles seem to limit this functionality only to Gmail and others say "like Gmail" - does this functionality apply to other web applications such as Outlook via 365, for example?
I have tested it using 365 and it behaves similar to Gmail.
In some cases it is possible that might want to include some additional content in the trigger, that you would like to show right after your last comment. Example would be an included satisfaction query when solving ticket with comment:
Unfortunately current implementation would show it only after quoted content, so in many cases the requester would not see it.
Would it be possible to show the whole content body from the trigger before the quoted content?
Unfortunately this looks like its working as designed, as the message body is an email reply. This is going to cut off where it detects the "quoted content" (and on wrote headers above it). If it were the very first Comment in a Ticket in a thread, the whole email would be present. At the moment, your desired behavior isn't possible.
We thank you for your insights and sharing your use-case. I would recommend that yourmake a post to the feedback forumso our developers can review.
Hi,
我们得到反馈,后续邮件we are sending is coming in like a new email to the recipient, instead of it showing as a thread. We show a thread in our end though but they are complaining that sometimes, they do not know what we are referring to, though it was already on the previous email. Here is a sample also of another feedback.
Thanks for your feedback. Could you please check our default triggers? ->About the Support default triggers. Did you modify your default triggers? Please check this trigger -Notify requester and CCs of comment update. Do you have many requesters there?
Keepinginborn system rules应该帮助创建一个更强的连接和the leading ticket. Becauseticket.idis unique and just one requester is more consistent than many.
I hope it helps to keep your email chains without any auto-splitting.
Thank you
Pleasesign into leave a comment.