CC problem

Completed

112 Comments

  • Official comment
    Nicole - Community Manager
    Comment actions Permalink

    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. 

    For more information and to learn how to use the functionality, please see the comprehensive list of CC's and Followers Resources. 

     

    This thread will now be closed for comments and archived in the near future.

    If you have questions about CC's and Followers, please post those in the Support Troubleshooting and Q&A topic.

    If you have feedback about the new functionality, please start a new post in the Support Product Feedback topic

  • Laura Desmond-Black
    Comment actions Permalink

    Hi Barış, 

    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. 

    Let us know if we can help with more questions!

    0
  • Barış BIÇAKCI
    Comment actions Permalink

    Hi Laura,

    Thanks for the reply and your suggestions.

    . Yes, all personA and personB are end users and not agents.

    .  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.

    Thanks for your help anyways,

    0
  • Laura Desmond-Black
    Comment actions Permalink

    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!

    0
  • Barış BIÇAKCI
    Comment actions Permalink

    Thanks Laura,

    At least, it is nice to know that someone's listening and may find a solution sooner or later :)

    Wishing all the Zendesk family a happy new year!

    0
  • Laura Desmond-Black
    Comment actions Permalink

    We definitely are - always. 

    We wish you a happy new year as well!

    0
  • Sebastiaan Wijchers
    Comment actions Permalink

    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.

    0
  • Cbonzol
    Comment actions Permalink

    Hiya, just wondering if there is any update on any changes with ZD to help with this issue?

    0
  • Barış BIÇAKCI
    Comment actions Permalink

    +1. We're also still having difficulties about this situation.

    0
  • Laura Desmond-Black
    Comment actions Permalink

    Hi Cbonzol, 

    There haven't been any changes to CC functionality, no. 

    One of our Customer Advocates recently wrote an article that might be helpful about CCs and ways to avoid some of the confusion around people knowing who is CC'd on a request, you can find it here

    0
  • Sebastiaan Wijchers
    Comment actions Permalink

    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.

    2
  • Dennis Geerlings
    Comment actions Permalink

    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.

    0
  • Minhkhoa Le
    Comment actions Permalink

    Hi Dennis,

    You are able to blacklist both users and domains. For more information on this, please refer to this article:
    https://support.zendesk.com/entries/20549932-Using-the-whitelist-and-blacklist-to-control-access-to-your-Zendesk

    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.

    Also, you have the option of using the mail API to post private comments to a ticket. For more information on that, feel free to refer to this article:
    https://support.zendesk.com/entries/21543427-updating-ticket-properties-from-your-inbox

    Hope that helps!

    0
  • Daphna Tsachor
    Comment actions Permalink

    Same problem here... very embarrassing situations with customers! 

    Zendesk team - this should be top priority for you, guys. It's unbelievable that you can't avoid these emails.

    1
  • Adam Rohacs
    Comment actions Permalink

    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. 

     

     

    0
  • Risa
    Comment actions Permalink

    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. 

    0
  • Rosie
    Comment actions Permalink

    +1 for this. It seems like a relatively easy solution. Are there any plans to put this in yet Zendesk?

    0
  • Rafael Marquez Montes
    Comment actions Permalink

    Hi there

    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.

    1
  • Emiliano
    Comment actions Permalink

    Hello everyone,

    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.

    E.

    0
  • Emiliano
    Comment actions Permalink

    Hello everyone,

    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.

    Does this make any sense?

    E.

    0
  • Christina Fountain
    Comment actions Permalink

    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? 

    Christina

    2
  • Sebastiaan Wijchers
    Comment actions Permalink

    Hello Christina,

    This is going on for many years now. I'm afraid it comes down to risk assessment. Can you take the risk that this will happen more often to you? As it will happen more often...

    If not, then I would advise to disable the CC functionality. I love Zendesk, but this is by far the biggest weakness. I also think this should have been taken care of a long time ago.

    Maybe somebody else has a good solution, but to my knowledge there is none.

    With kind regards,

    Sebastiaan

    P.S.

    Even with CC disabled you are not entirely safe from things like this to happen:

    If I read your situation right, then that's basically what happened to you as well. So it's not really (just) a CC problem, but an original requester problem.

    2
  • Christina Fountain
    Comment actions Permalink

    Thanks for your help, Sebastiaan - I really appreciate it. 

    We aren't completely live with Zendesk yet (just internally for now) so I suppose I should be thankful for the heads up early in the process. 

    0
  • Barış BIÇAKCI
    Comment actions Permalink

    Hi all,

    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"

    Or

    "Only public assignee comments gets forwarded to requesters and CCs"

    1
  • Joel Hellman
    Comment actions Permalink

    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. 

     

    0
  • Theo Fryer-Smith
    Comment actions Permalink

    Hi everyone,

    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.

    1
  • Putri Pangesti
    Comment actions Permalink

    Hi everyone, 

    This can be very frustrating.

    I'm a bit shocked to see the fact that the issue still last after 3 years.

    Zendesk product team: we're really hoping you can solve this.

    3
  • Lauren Espiritu-Philson
    Comment actions Permalink

    Hi Zendesk - 

    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.

    1
  • Kevin Lange
    Comment actions Permalink

    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.

    ~Kevin

    1
  • Jessica Goldring
    Comment actions Permalink

    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.

    Zendesk - please fix this!!!!

    3

Post is closed for comments.

Powered by Zendesk