SLA Not Working with Merge Tickets and Flagged Comments

Hi Alex - For merging tickets, I don't think there would be a workaround for this one.

In terms of the Next Reply Time SLA not triggering for a ticket in which the customer responded from a different email address, there isn't a workaround to help you trigger the Next Reply Time SLA for that specific ticket update (at least, that I'm aware of) but I do advise our team to ensure that they are switching the requester over before they respond back to the customer.

That way, as long as the customer continues responding to the ticket from that same email address, all future Next Reply Time SLAs can be triggered. 

We also have a Slack webhook that helps us identify tickets that are stuck in the back of the queue so that we can still get back to the customer within the timeframe of their plan's SLA policy, even if we don't get "credit" for it in Zendesk. More info here in case you're interested.

Thanks, Chandra. I was thinking similar thoughts. I just wanted to make sure I didn't miss anything. 

Hi @Chandra Robrock

Can you please clarify what you meant by this: "I do advise our team to ensure that they are switching the requester over before they respond back to the customer."

Thanks

Hi @riah - sure thing!

Let's say a ticket comes in with a Requester of test+testing@test.com which triggers the First Reply SLA. The agent responds to their email which then satisfies the First Reply SLA.

Now, let's say the user responds to the ticket, only this time the email is coming from test@test.com. In this case, Zendesk would flag this comment as suspicious since the latest comment was added by an email that does not match the email listed as the Requester (test+testing@test.com) and, as a result, this comment wouldn't trigger a Next Reply Time SLA.

In these cases, I advise our team to first leave an internal note that says "Switching requester over from test+testing@test.com to test@test.com for SLA purposes" and then switch the actual requester on the ticket to be test@test.com instead.

That way, the next time the customer responds to the ticket, their comment won't be marked as suspicious as long as all future comments are added by this email (test@test.com), which is typically the case in that specific scenario. Hope that helps!

Hi @Chandra Robrock,

Thanks for the explanation. I have follow up question though, to "switch the requester on the ticket", which of the following do you do to achieve that? 

1. Change the actual requester email address to test@test.com from the ticket?
2. Add test@test.com as secondary email of the requester?
3. Add the test@test.com as CC on the same ticket?

Thank you!

@riah That's really just one example of a comment that is flagged, so I'm hesitant to say exactly how to switch the requester over in every scenario where a comment is flagged. In our specific cases, we find this happening for email aliases, CC'ed individuals that respond to tickets without clicking on Reply All, etc.

For that reason, I generally advise agents to do #1 and also CC the original requester's email on the ticket. However, the best process that works for your team could vary based on what tickets you're seeing this occur on, how you report on tickets, etc.

Hope that helps point you in the right direction!

The issue of merged tickets and the non-requester replying also causes issues with our SLA policies and metrics from applying.