CC problem

If person B wants to send a private message to the assignee (maybe that he doesn't want person A to know), he will simply hit reply, delete person A from the TO or CC field of his email and send it over. As soon as his email arrives to zendesk, system will forward his email to person A and something embarrassing gets happened.

You know most of the users do not know about those zendesk codes in the subject line and other complex rules that gets his email forwarded to other people CCed to the ticket. Only thing they look out for is the TO and CC fields of their own email. So you can never explain him why his private email gets delivered to other people.

We had a couple of situations like this a while ago and that was really really embarrassing...

Is there any way to solve this? I've checked community as well as every side of zendesk settings for several times but can't find any solution. (except this one but the solution offered in here is just not enough...: https://support.zendesk.com/entries/26959287-CC-Logic )

I think a simple option like "Do not forward ticket comments to CCs & Requesters, if it gets sent by a Requester and/or a CC" may solve this. Or something like "Only public assignee comments gets forwarded to requesters and CCs" like I believe that this would work because, wether you CC'ed someone on zendesk or not, people will always keep CCing others on their own email. Because they never understand/care how CC works in Zendesk. They only know how CC works in email clients.

Would love to hear if other zendeskers got any problem like this and got any solutions?

PS: We've created some advanced notes on zendesk comment update emails, like their emails will be forwarded to people CCed on the ticket automatically by the system. But after a while, they got used to those messages, just ignore them and try to send a private message to the assignee by replying email again. We have to stop zendesk forwarding comments to CCs and Requesters.

112 Comentários

Thank you all for your feedback! You have successfully helped to make Zendesk's tools and products work better for you. The new CC's and Followers functionality has begun rolling out, and this process will continue over the next several weeks.

I'm sorry this has been frustrating, I know our Product team is aware of situations like this and is wants to look at what could be done to improve how CCs work and what agents can control about them. They also know that calling it a "CC" is a little confusing. Nothing is on the horizon, they just recognize that it could be easier to work with.

Just to understand a little better and see if any of our built-in options would help, in your example is Person B an agent? If so they can use things like the mail API to put in an instruction in the message to make the comment private. Alternatively you could set it so that agent replies via email are private by default (you could do this overall too). Head to Settings > Tickets for these.

If the CCs are end-users then their comments will always be public. Even if they delete the requester from the "To" line their reply is still updating the ticket which means the requester will get an update if you have triggers in place to notify requesters of ticket updates. What might help is to set your triggers that notify requesters of ticket updates to only fire if the comment is made by an agent, that condition would look like "Other: Current user is agent" - the updates sent by the CC would still update the ticket and be visible in the web portal, but they wouldn't cause emails to be sent out to the requester.

If you truly want to hide comments from requesters they need to be internal comments, i.e. made by agents. Zendesk is designed to help keep the conversation centralized and organized so trying to separate it becomes complicated. I know you understand this, and I realize it can be hard to communicate to people who don't use a ticket system frequently. I'll pass your feedback along, use cases are always helpful.

. I've used your suggestion: "Other: Current user is agent" That worked when CC is updating the ticket and requester won't get his update. But if requester updates the ticket, system keeps forwarding emails to CCs. So, at least, %50 of the problem solved! :)

As I said on my previous post, some rule like "Only agent public comments get forwarded to requesters and CCs" would do the job.

Glad to hear that the suggestion is somewhat helpful, I know it's not a complete solution.

A setting that prevents CC responses from being public responses and added to the ticket as public comments would help this situation - it would also be a significant change to how end-user comments are treated generally. We'll have to see what happens in the long term!

We've had similar occasions where person A said something about person B, while he was unaware of person B still being in the CC. The end-users clearly don't expect this kind of behavior.

It's not just those painful situations, we also see it a lot with our technical helpdesk. Where the requester puts half of the world in the CC initially, but it's unclear when they should be left out (this should be the decision of the requester sometimes). This results in people feel like they are being spammed with notifications.

In my opinion the point is: Zendesk can explain this CC functionality to their customers clearly, but how do we explain it to our customers?

I don't think this can be solved textual like in Sean's article. In our case most of the customers don't even know what a 'ticket' is. They just send and receive e-mail and expect to see the people in the CC field of their client.

It's not a major issue for us, but once in a while it does lead to confusion or even a painful moment ;) So I would rather have an e-mail kind of CC.

Our situation is that our people internally will reply to emails. In our previous support ticketing system it was possible to blacklist senders. We'd blacklist our internal email domain and everything was fine. It does not seem like Zendesk allows this. There is an option to black list new tickets from certain domains but I have a feeling this won't apply to ticket updates. The other problem is that you cannot blacklist an existing organization.

The other option is to simply allow an agent to hide a certain update. Hiding it will basically make it internal. This requires Zendesk to only email requester (bob@customer) when a agent actually sends an update but that sort of makes sense doesn't it? If someone sends an email to support@organisation but does not include bob@customer, why would Zendesk send out an update that includes bob? That doesn't really make sense to me.

You are correct in that you can't blacklist an org, but you can blacklist that org's domain.

Also, you will be able to make agent comments internal if they were posted publicly:http://screencast.com/t/54y9qXRi2L
You will see this option once you have selected the "show all events" button when looking at a ticket.

CC needs to do internal comments only. In its current state, it is no more than bait to push the customer into paying for a higher tier to get light agents. The obfuscation of the CC documentation basically pulled the wool over my eyes - if only I had chosen to subscribe monthly instead of choosing to save a few bucks. Read into that what you will - powers-that-be.

How about considering ala-carte options? Considering your competition and how much less expensive they are for what looks to be more features, I would say the time is now to get on the bus.

Hi Zendesk team - we'd love to see some changes here as well. It's becoming more urgent for us because we work with K-12 teachers and are developing a new product that might encourage teachers to cc a student on some of their requests. In this scenario it could get particularly complicated if the student were unintentionally cc'd on a message down the line. We're considering adding a cc notification to our email templates ( as suggested here.) Besides that being a bit difficult to understand for the requester, it doesn't give them many options if they'd like to continue the conversation without the cc, besides starting a new ticket and causing confusion on the agent side.

I am currently experiencing this problem too and I had to take a decission. I set the "Only agents can add CCs" which is reducing but not solving the situation, since an answer from one of my company's end-user about a client removing the client from his email will generate a notification to the client if the user is in CC.

I believe there are several possible solutions to this:

1.- Add an option where end-users may remove CCs. On that way, Zendesk will be working as an email inbox, respecting the CCs on the end-user mail. This could set a bad situation where users are just answering the ticket and it is not populating to other users which should be in communication.

2.- (already considered here) Add an option where only agents' public comments may be CCed. That is the most logical solution. If the end-user would want to have someone CCed, he would have set it in his original email.

I believe adding these options may look like a complication to the system but it is also making it more versatile. We are working with this tool in an non-support oriented team using it as a Case Management, and we miss functionality which could be easily added. This is one of them, and a very important one.

I would like to add my voice to the discussion.I am pretty new to Zendesk but I have been carefully reading all the discussions here in the Community regarding the CC problem.

I have adopted a solution I would like to share with you. I am aware it is not the best fix but it does work for us and it might help some of you too.

We decided to use Zendesk as our ticketing email app and, since a ticketing software IS NOT a mail client, we keep using Gmail to send outbound emails to our costumers without having the need to create a ticket for them. My solution as far as i can tell, works only using a Mail client together with Zendesk.

We have a ticketing main email A@mycompany.com (this is the support address within Zendesk) we shared with our costumers and we have a secondary email we created to prevent the CC problem. I will call this email B@mycompany.com. IMPORTANT: The second email is created as an Alias of the first email.

When a costumer writes to A@mycompany.com we have to make a decision. We keep the conversation within Zendesk or we take it to Gmail.

1) We use Zendesk if we want to CC others and create a collaborative conversation email making clear to everyone that the conversation is now public.

2) We use Gmail if we want to CC others without risking the unwanted CC replies. In Gmail we would reply using the Alias B@mycompany.com. The advantage of using the Alias is to have all the emails within the same inbox as our Support address. We can then FORWARD, CC or even BCC as a standard email without risking an email being sent to someone that is not visible in the recipients.

Receiving an email to an address (A@mycompany.com) and responding from a different address (B@mycompany.com) is of course not the most elegant solution however they are from the same domain and as long as we create general names like INFO@, BOOKING@, SALES@, COSTUMERCARE@ it should be something we can live with.

If anyone has a different approach or sees flaws within my solution, I would love to hear.

this CC issue is really giving me headaches. So i tried to come up with another solution.

I noticed that when we access tickets through our online help center there is a gray box on the right with all the tickets details. It also lists all the people CCd on that ticket.

If i was a copied end-users and I would reply online to that conversation then I would see if others were CCd in the conversation and as a classic Online Forum I could guess that any reply I would be making would go public to the other copied end-users within that conversation.

No1 should get confused anymore.

The problem is how to achieve this?

Maybe we could set up a trigger that makes a conversation web-only accessible whenever other users are CCd on that ticket. The email people in Copy would be receiving is not the conversation (otherwise they would just hit reply on their email) but it would be a link to access the Help Center and sign up.

So the main idea is 1-to-1 conversation would go through email and 1-to-Many conversation would go through the Help Center.

Yikes, this just happened to us for a very personal HR matter. I see a lot of articles without any real solution. Has anything changed since this article was posted?

Person A emailed our Command Center which got forwarded to Zendesk. Command Center forwarded Person A's email to HR from our gmail box. HR responded to the forwarded email which was logged in Zendesk and person A received the comment. Then Person A responded to what she thought was just our Command Center but HR was then invisibly cc'd and received the comment.

Can someone point me in the direction of a good solution? Do I just need to turn off ccs?

Just can't stop it from happening for the last 3 years :) Love zendesk but something emberassing just keeps happening. As I said 2-3 years earlier, one lower level option (a checkbox maybe) may simply solve this;

"Do not forward ticket comments to CCs & Requesters, if it gets sent by a Requester and/or a CC"

Christina, there is no way to prevent this kind of disclosures as far as I know. To make it less likely to happen, here are some suggestions:

A: you turn off CCs or

B: you turn off CCs for end-users, and uncheck 'Agent comments via email are public by default' so end-users are not mistakenly informed.

B assumes all your agents (including light agents) are company employees, and that you're okay with 'internal mistakes', and hopefully don't have any internal auto-forwarding rules in place.

You can put informational messages in your notification emails for the recipients, but mind nothing prevents these from being removed, ignored, or even understood.

If you do use CCs, mind in your informational messages that recipients may have been added by new updates through email or by agents since the email notification was sent out, and mind your support should best avoid changing the requester, since that will increase the risk of miscommunication a lot.

Also note you shouldn't rely on HTTP targets to remove any CCs already present when the your ticket is updated through email, this will not reliably prevent notifications going off to CCs, and also note that notifications to CCs are hard-coded, and cannot be disabled, like the requester notifications can.

This is the number one issue with Zendesk for us too, and as others in this thread, I'm eagerly hoping for improvements in this area as soon as possible.

We are relatively new Zendesk customers and this is a big problem for us too. Our scenario:

Requester = Client

CC = Broker

The broker wants to be kept in the loop with what is happening with their client. On occasion they may want to respond to us (agent) with a comment that may be sensitive (e.g about the client's suitability for a product). Naturally they will simply strip the client off the email and reply back to us - not knowing that they email will end up going to the client!

Yes, we could adjust the CC template to warn the Broker but that is not a failsafe approach.

And removing CC would be highly inefficient as our Agents would have to maintain two separate tickets (ticket 1 with the client, ticket 2 with the broker).

My idea - flawed but removes the risk factor - is that all CC replies become internal notes and not public replies.

I have also upvoted this issue. We have two internal groups. One group loves the "sticky CC" feature because the nature of the communication often requires many of our client's teammates to be looped into the thread. When sticky CC's are turned off, that group is at high risk of someone important missing out on communication. Occasionally, they run into problems where a client has dropped someone off of CC but the CC remains in Zendesk. Negative consequences from that are slim chance, but still exist.

Our other group HATES sticky CC's. The way they interact with clientele, the requesters often drop people from CC and our agents do not know. We had one client who should have been dropped from CC continue to be looped into the ticket thread. Needless to say, it caused us some major pain as a result.

I often hear from my team - "Why can't Zendesk CC's act like email????" :-*(

While that might be a tall order to fill, I think a simple addition to the triggers page could be helpful. Under conditions for the action to take in the trigger, we already have "Ticket: Add CC". Can Zendesk add an option that is "Ticket: Remove all CCs"? In that case, we can turn sticky CC setting on for the whole account then write a trigger that says "if a ticket is created and send to Group B, then remove all CCs".

That would be dead simple and SO HELPFUL.

I'm really surprised that there are so few votes on CC issues as I imagine many customers are running into these very issues.

Perhaps the ability to add information about who is CCed and BCCed to every email notification is a good solution. I don't see this option in the email placeholders. Hopefully Zendesk will consider a placeholder such as {recipients} which will list all the recipients of the email and who will receive a reply of the user responds.

Furthermore, it's confusing the way it is now. From a clients perspective, they are likely frustrated that their CCs appear to be removed from communication, where in reality they're just send a separate email notification.

I understand that when a Light Agent forwards an email from a client, Zendesk will automatically make the requester the client. However, if the client CCed anyone, those CCs are not included in the ticket. The light agent can copy and paste those who CCed the client in the forward. Ideally, I think there could be an email tag that includes CCs. For example:

#includeCCs true

If this tag is present, then Zendesk should know to include all CCs as well as the end user who emailed the light agent.

Wow! I am amazed that this problem is still going on three years later, and doesn't seem to have ever been addressed.

We just had this same issue come up - Customer A emailed our support. I replied, cc'd one of my founders. Founder replied to (he thought) me only, and it ended up going to our customer as well. Very embarrassing!

I don't understand why the email gets copied to a person whose email address has been manually removed from the chain. We have all been trained by email apps over the years to expect all recipients on an email to be visible in the distribution list. It's not realistic to expect every team member, working from gmail or another email app, to anticipate something they have never encountered before, every time they hit send.

As a work around, I have reset my default settings for tickets by unchecking the boxes for "Agent comments via web are public by default" and "Agent comments via email are public by default". Which, I think begs the question of why internal comments aren't the default setting to begin with.

I would much prefer to take the time to resend an appropiate email to one of my customers than have to take the time to explain and make up for an embarrassing situation.