|Announced on||Rollout starts||Rollout ends|
|November 16, 2022||November 16, 2022||November 18, 2022|
Email side conversations have always been capable of having multiple people involved as participants; however, all recipients would have to appear in the To field in the email.
Now, you can CC and BCC recipients on email side conversations.
This announcement includes the following topics:
With the addition of CCs and BCCs, email side conversations now look, feel, and act like traditional email more than ever.
Note that CCs in email side conversations behave differently than how CCs work in ticket comments with end users (see CCs and followers resources). Essentially, side conversation emails simply add recipients into their respective email headers.
Keep in mind that since Zendesk is a multiplayer environment, any agent with access to the ticket will be able to open the side conversation and see anyone who was BCC’d.
Why is Zendesk making this change?
Having everyone appear in the To field of an email is usually fine. In the age of text messaging, group texts are pretty standard.
Email is of course older and, as a result, has more powerful concepts baked in. Two of those are CCs and BCCs.
Although you no longer need to press hard with your pen while writing a memo so the carbon paper prints legibly, many people use the CC field in emails to communicate that the CC’d recipients are included but aren't the primary recipients. This enables workflows where people can be kept in the loop, but know that there’s no explicit action required from them.
BCCs provide the same functionality without letting everyone know they’ve been included. This is often used for keeping stakeholders or higher-ups informed about communications being taken as a form of accountability or when situations are sensitive.
What do I need to do?
If your Zendesk account has side conversations enabled, CC and BCC fields are available in email side conversations by default; however, if you'd like to learn more, see Adding CCs and BCCs in email side conversations.
Happy carbon copying!
Definitely the best feature ever, good job! AMAZED! How come this has not been added to the actual tickets as well?
Regarding the new functionality, what is the expected behaviour when a person in BCC of a side conversation only replies to the sending support email address (removing all To and CC recipients)?
There are questions about :
- the display that will be made in the side conversation
- the readability of the understanding of the hidden feedback for the agents
- the fact that the initial recipients cannot see this feedback, and that this comment is not included in the history of subsequent exchanges where all recipients are present
Thank you in advance for the details
Taking a look in our instance, the BCC and CC functionality has not been released yet. This announcement states rollout ends on the 18th. Can we confirm if this has been fully rolled out or is there a delay with a new timeline?
This is an amazing new addition to side convos. Well done Toby Sterrett and team.
My only piece of feedback is: I don't like the way the To/CC/BCC displays on the side convo after you've submitted it and that I have to hover my mouse over CC/BCC to see the email address. It would be better visually displayed like it is in an email. It also means that I am not able to click to copy any of the email addresses to which the side convo has been sent too. because they appear in a little popup hover over.
We now have the functionality added.
+feedback: when you add a BCC, it doesn't tell the BCC that they are BCC'd
1. You can't add these via macro- you have to add them after the macro is applied
2. When you click CC or BCC, it auto adds the recipients from the TO section to the CC or BCC sections. If you then go to delete the recipients, it deletes them from all the fields.
Will this be looked at? It's great to have a new feature but not when it's not functioning.
I really appreciate this being added and it is immensely helpful for bridging some of the gaps that occurred when you wanted to include people as an 'fyi' but did not want them to think they needed to do something specific.
I want to echo the feedback of some other users, in that once the side conversation email is sent there's some difficulty in seeing what actually went out. I am actually having mixed results where, up until someone replies, I can see who was CC'd/BCC'd by hovering over names but once a reply is received that information is lost (even from the original record?) and everyone just ends up in the 'To' field even though the email went out with a single 'To' and multiple 'CCs.
Hey all, thanks for the feedback and bug reports!
Great question. In that scenario, the BCC'd person's reply will arrive in the side conversation thread, but won't be sent to any other recipients. At that point, if that message is the last message in the side conversation thread, the subsequent reply from the side conversations UI will be addressed to them and no one else. The recipients can be removed/added on every reply, though.
This does mean the agent will need to be aware of the different recipients that could be involved at any given time, and may need to adjust the recipients in their replies.
This flow makes the ability to reply to individual messages important, and this is something we’re working on for a future update. This would enable a reply to come in from a BCC’d person and the agent being able to reply to the message before it instead of the more recent one from the BCC’d person.
This is actually something that confused us at first as well, but then we realized that being able to view that you are a BCC recipient of an email is actually a Gmail specific thing. On this documentation page, it is noted:
So, in this case, the BCC’d recipient not seeing that they are a BCC recipient may be different if they’re used to receiving emails from e.g. colleagues also using Gmail, but it is the way federated email normally works.
Yes, this is something we still need to work on for a future update.
Thanks for the feedback on the display of the information of the CC and BCC information! We’ll continue to iterate on how that is presented. We are trying to be cognizant of the minimal amount of space available, but making it more apparent sounds like it may be preferable to saving space. We’ll look into some other approaches!
Nora hmm, we can't reproduce this behavior. What browser/OS are you running? I'll make a ticket for you to follow up so you can provide some more details.
Please sign in to leave a comment.