Andrew Goetz

I just turned on Agent Workspaces today, and came here to report a bug thinking that this obviously must not be intended behavior. Sadly found this thread and am surprised to see a 'Draft mode' be created rather than the must easier and more intuitive 'old way' that used to allow agents to toggle back and forth.

Yellow background is 'safe', white is 'not safe' when it comes to drafting replies and things of that nature. Draft mode is not a solution that we will use.

I am sure my team will continue to have to copy-paste our messages from internal notes to public replies, adding an extra step is what used to be a simple and fluid workflow.

James G Thanks for this guide, just what I was looking for to modify the existing brackets of Agent Replies Brackets metric.

However, I hit a snag when building the Standard calculated attribute for the Public Agent Reply Brackets attribute. When I enter the formula, I get an error on each IF line that says I can't use COUNT(Public Agent Replies) in a calculated attribute and would need to wrap it in ATTRIBUTE_FIX or ATTRIBUTE_ADD function.

Ran through the steps a few times and keep getting stuck here, and when trying to make the suggested change from the error message, I don't think I can as its an IF/THEN value rather than a normal metric.

Anything I can do to get around it or maybe the behavior has since changed?

I like some of that Tim, and also tried something similar (having a tag disable the SLA), but consider the following scenario:

1. You have an SLA policy with a 'Pausible Update' of every 24 hours (purpose is to ensure your team gives daily updates for important cases).
2. A customer responds with 'Here are the files you requested', which restarts the 24hr update clock (ticket goes from pending to open).
3. Your team then responds with 'Thank you, we will pass this to our developers and update you as soon as we can.', which also resets the 24hr clock (you will need to respond within 24 hours from this message to meet this SLA).
4. You then put it into an On-hold state with your On-Hold Reason exception being 'waiting for developers' (which temporarily removes the SLA).
5. It sits in the On-hold state over the weekend as the dev team reviews the case (48 hrs).
6. On Monday morning, the customer replies with 'Any update to this investigation?' which sets it from On-Hold to Open, which reapplies the original SLA which was expecting an update that never happened over the week, and you instantly breach the original SLA policy.

---

This is the case I am in, and simply having On-hold *actually* pause the SLA is the only method I can think of to ensure this 'instant breach' doesn't occur.

+1 

Not that I am expecting my request help move this functionality forward (so sad to upvote a 10 year old feature request)

We actually use on-hold the most in the following instances:

• Customer requests help with something in the future, so we put it on-hold until that date and time.
• The customer has hit a bug which will be fixed in the next release of our product, so the ticket is on-hold until we release the new version (after which we inform them, ask them to upgrade, make sure it works as expected, then close the ticket)

Our structure is:

• Pending is ball in customer's court
• Open is ball in our court
• On-hold is timeout (or halftime/end of period/whatever sport analogy you prefer)

This mean that on-hold is for tickets that are blocked, waiting third party input, or any situation where action is not required by neither the customer or us.

When that is the case, it does not makes sense to have an SLA apply to a ticket in this state.

 

Hi team,

Imagine that I have an SLA policy that requires first reply in 30 minutes and updates every 1 hour following that.

Very often, customers will write in with an urgent issue and request a screen sharing session right away. Our first reply is either to get quick initial info, or to simply send them our screen sharing link and ask them to get on the call with us.

These initial responses will satisfy our first reply SLA, but we run into problems when dealing with the 1 hour updates as we might be on the phone call with the customer for over an hour. This means that we are actively engaged with this customer providing them support, but zendesk is only tracking ticket updates, which an agent is not expected to submit while they are talking on the phone to the person who filed the ticket.

I understand that "Pausible update" is available, but this only allows me to pause an SLA when the ticket is pending. We use the Pending state as "we are waiting for the customer to respond", and being on a phone call with them working through an active troubleshooting session is not appropriate for the Pending state.

What I need is a way to pause an SLA while we are on the call that is not: setting it to Pending while on the phone, having it removed from our Open investigation queue, then setting back to Open and replying, then setting back to Pending, and so on.

Most of our SLA breaches are incorrect and are due to this type of reporting failure, and should not be considered real breaches.

I tried to work around this with a checkbox ticket field titled "Currently on a call" that an agent would check when they are on the phone with a customer and would apply an "on_a_call" tag to the ticket and our SLA policies exclude tickets that contain that tag, however this does not actually pause the SLA timer, it just deactivates the SLA and then reapplies the SLA from the previous reply time.

This means that if you are on a call with the checkbox checked for an hour and a half, then end the call and uncheck the box, the SLA will be reapplied and instantly breach as you are 30 mins past the last reply time.

Simply adding "on-hold" to be included in the pausible updates would be a solution, or something more involved where there is an actual option in a ticket to deliberately pause an SLA.

Thank you for your consideration.

Andrew Goetz