CCs and followers – Tickets replied to by a CC get no SLATerminée
The new CCs and Followers feature is great, but has one major downside: when a ticket is reopened because a CC'd end-user replies, that update does not reset the "next reply time" SLA clock.
With the new feature, if a CC hits "reply" instead of "reply all" (so not including the requester), that reply becomes a private comment. See this article.
The problem is, we order our queue by the "next SLA breach," based on the "next reply time" SLA. This is what we use to approximate a "first in, first out" workflow (which Zendesk doesn't support natively). But now, tickets reopened by a private comment from a CC get no SLA time. This means they get stuck at the bottom of our queue.
When a customer gets an SLA guarantee, they don't have the expectation that it only applies when the initial requester of the ticket is the one doing the replying. Customers frequently collaborate on tickets with colleagues, or even themselves at different email addresses. Regardless of who replies, they should get the SLA.
My improvement request is that the SLA clock should start any time any end-user replies to a ticket, regardless of if they're the requester or not.
Hey Everyone. Thanks for your patience on this while we figured out a solution. I have some good news to share! This will now work, as long as you have the "Make email comments from CCed end users public" setting checked to on. (Default is off). This can be found in Tickets / Settings. Highlighted below in blue:
@... +1, we're having the exact same issue and organise queues by SLA for the same reason. I'd be interested to hear how many others have a similar issue. Additionally, I cannot understand why Zendesk doesn't support any other options to sort a queue if your workflow is based on first in, first out.
This still seems to be an issue. We have customers writing in from one address and using CC to include another of their addresses. When they reply or update the ticket from the CCd address it loses the SLA and is dropped to the bottom of the view. Without someone watching that for this to happen it will just sit at the bottom.
This should be fixed.
Hi @..., original poster here. I have joined a new company and run into this exact same issue. I've looked at the solution here, and I'm disappointed. The core of the problem is that tickets frequently end up with no SLA. The issue Charlie describes above is maybe the most common cause of the missing SLA problem, and this solution does nothing to fix it.
The real silver bullet solution would be an option to make all SLA's treat any end user comment the same as a public comment. Regardless of whether it's public or private, it's still a person who now has to wait in line, and the SLA's should apply.
If that's not possible, then we should be able to make a reply from any end user be public, regardless of whether they are CC'd.
This specific issue, and more broadly, the absurdly challenging (maybe impossible) task of trying to ensure that all of our open tickets get SLA targets, is forcing me to advocate for a change of support platform for our company. SLAs should be a central feature - why are they treated like an afterthought?
@... Gook @Zach Hanes (and all) - Good news from our Zendesk success rep: this particular behavior (end user who was not part of conversation replies to ticket, comment populates as internal note) can be disabled by Zendesk upon request from the account owner. We just put in our request, so yet to confirm that it'll work as expected, but wanted to let you know.
To mitigate the security risk, I just added a big disclaimer to our email template along the lines of "All replies to this email will be visible to the ticket requester. To initiate a new request, please send a separate email to [support email]"
I have a strong suspicion that the current proposed solution would not make it past our legal team. It's reasonable to expect that when you reply to an email, it's only going to the addresses included in the "to" line.
If it's from a user who is not CC'd on the ticket, and they do include the requester in the "to" line, I would expect it to be a public comment (not the current behavior).
If it's from a user who is CC'd on the ticket, but their reply doesn't include the requester in the "to" line, I would expect it to be a private comment.
But in both of these cases, there has been a reply by an end user, who is now waiting for our team to engage again, so the ticket should get an SLA. It seems likely that this logic (SLA's not running after private comments) was designed when private comments were only made by internal users, but that's not the case anymore. The SLA feature needs updating to account for this.
I've been asked to put a feedback post together about having an SLA that runs on any end-user comment, but I've discovered that one has already been made here. I would encourage everyone on this thread to follow and comment on that one.
Seconded — I understand that another party who isn't on the ticket (perhaps the requester forwarded) would be flagged and might not reset the SLA, but internal notes from CCs who used Reply instead of Reply All keeps tickets at the very back of our queue.
We are having the same issue as we are sorting tickets by SLA.
If you receive + 1000 tickets / day, those tickets will always stay at the back of the queue without any possibility to put them back in the queue with an SLA.
Do you plan to do something for this ?
So we would need a bit more information on how you have set this up. Could you share what SLA target you have configured and any other information on how you have this running on your end so we can troubleshoot this further for you?
@... This is about the "Next Reply Time" SLA target which fails to update when a private comment is added to a ticket. It's problematic that CCed end-users who respond aren't counted as a public comment. I think Zack explained it quite clearly in the original post.
Thanks for alerting us, Ed, and Stephen, thank you for clarifying for Devan. We'll share these comments with the appropriate product manager.
Hi all, thanks so much for your feedback. We don't currently have any plans to implement this in the near term, but we'll continue to evaluate and consider it as we prioritize our roadmap. Thanks again for raising this, it's always helpful to understand more detail from the community about how you're using Zendesk.
+1, honestly, treating such comments as internal notes and not public comments looks like a real crutch to me
This has also been a significant problem for us since changing to the new agent experience. We weren't aware of it up front as a limitation, which is unfortunate but since our priorities and metrics are based on the next reply SLA, this has definitely caused some issues. We've attempted to manage this by having a single point of contact on tickets but this is just not practical in many cases. There's a number of options that would work for us to address this:
- Allow a ticket comment to be public if the cc is a registered user/is added to the ticket by an agent/is part of the same organization
- Allow internal comments from ccd users to trigger SLAs
- Allow ZD admins the ability to set up a trigger that would apply either of the above actions (so it would not necessarily have to be global)
We have this issue even when the CC'd user is included in the ticket CCs and their comment comes in as a valid public reply.
Only responses from the original requester are accounted for in SLAs and the 'Last updated by requester' metric. There doesn't appear to be any metric we can use to properly sort our views based on the time passed since the most recent response from an external party.
This is especially problematic with large organisations who very commonly CC in several people on each ticket, and different people will reply as needed. It's something we're really struggling with for ensuring tickets are being prioritised effectively and clients aren't sitting at the bottom of the queue.
BTW this is the best workaround we've managed to find so far: Creating a notification to identify tickets that are stuck at the back of the queue due to no SLA being applied
Thanks for looking into this. There's still one case that's not accounted for: when an end user who was not part of the original conversation (i.e. wasn't the requester and wasn't cc'd, but was forwarded the ticket thread separately) responds on the ticket thread, their comment populates as an internal note. This is true whether or not the "Make email comments from CCed end users public" setting is checked. Can we please add an option to change this behavior? We need all end user comments to be public replies in order for our SLA policies to work.
Thanks Charlie, you're right. Our fix doesn't address that behaviour. We're looking into that and whether it makes sense to count that in the same way. I'd be interested to hear what others think of that.
To give more context on the use case where someone replies who is not a CC:
I represent a company that signed up for an app using a shared address, e.g. email@example.com. This address is an alias that distributes messages to myself and two of my colleagues. When I submit support tickets, this is the address that is used as the requester.
I submit a ticket under this address. A support agent replies, and the message is distributed to my address, firstname.lastname@example.org. I reply to the message, forgetting that I submitted under the hello@ address or unaware that it makes a difference what address I reply from. The ticket has no record of email@example.com being a requester or a CC, so my reply becomes a private comment and the ticket reopens with no "next reply" SLA.
This may sound like a rare situation, but we get 1,000+ of tickets per day, so this happens many times a day, enough to make SLA-based routing unworkable for us.
@... seconding the last comments from Zach: this "Make email comments from CCed end users public" setting is not new, and it's not a proper fix for the problem, more of a temporary workaround. It's explicitly said "not recommended" as one risks exposing comments from end-users who might send them in reply-to mode intentionally
I'd like to add our use case to this thread.
We have all of the same issues as the above users, but for us it's also crucial that we do not turn on the "Make email comments from CCed end users public" setting. We deal with a high volume of sensitive payroll and employment information in our company, so presenting the wrong info to someone it's not intended for would be a massive breach of our clients' trust.
As a result, the workaround above doesn't work for us at any level - users who respond to a ticket they weren't originally on or users who were CCd in can not be handled within SLA rules for our business at the moment, which is creating a lot of manual effort monitoring for tickets that are floundering at the bottom of our queues.
We would love to see an improvement to the functionality that's so central to the way we use Zendesk.
Edit: further to this, our Sales team often forward client enquiries to us. As they are Zendesk Sell agents, these tickets come in as internal notes without an SLA. These enquiries are usually from newly registered clients who should be 'Urgent' priority, but they sit a the bottom of our queues.
Vous devez vous connecter pour laisser un commentaire.