Functionality to pause an SLA
PlannedHi 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
-
Official comment
Thanks everyone for your patience and support! Last year I provided an update that SLAs were a top priority, and we had plans for a number of enhancements. I can confirm that work is in progress, and the very first customer facing change has rolled out: an easier way to see upcoming SLA breaches.
The next big change will be the ability to apply "Group SLAs" on tickets as well as SLAs. That will be available to early adopters in Q4 and be generally available in Q1. After that, we'll deliver alerts on SLAs in near real-time instead of once an hour for Automations.
We do plan to address this request as well, at some point in H1 2023. If this is functionality you cannot wait for I'd encourage you to check out one of our partners, Cloudset, who offer this kind of functionality today.
-
We have a similar issue when using "next reply", often customers will just say "Thanks!" which then commits us to reply. Even when we set it to Pending, it still is waiting for our reply instead of "periodic update".
-
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.
This is really key - Pending means it's in the consumers court but on-hold means it is with us. In our case if the product we are supporting is a hardware issue, we have to send information to our various distributors to issue the warranty. So even though it is in our organisations court, the support team shouldn't be 'penalised' for violating the SLA as they are simply waiting for paperwork from others outside the Zendesk eco system.
-
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.
-
I agree with all of the above. We've had issues with both periodic update and pausable updates because of the inability to pause SLA's while in the on-hold status. We've had to come up with incredibly complicated workarounds that are still imperfect and unfairly breach tickets.
We use On-hold primarily when our development team is researching an issue, not because the customer asks us to put the ticket on hold. This is contrary to the SLA and reporting metrics in Zendesk, which considers "on hold" to be time spent waiting for the customer.
-
I also agree with all of the above. In fact I was told this is what happens as part of the on-boarding process, so my entire set-up was based on this fact.
Open: For us to deal with
Pending: awaiting user response
On-Hold: awaiting a 3rd party
Any chance anyone has a good solution?
-
Thanks for the detailed examples, everyone. Really helpful information.
There aren't any updates for SLAs planned in the immediate future, but sharing use cases like this is the kind of thing that helps prioritize things in the next round of planning.
-
I also agree with all of the above. Please prioritize this Zendesk.
-
Could Zendesk please create an option to Pause SLA when the ON-HOLD status is applied?
- A nice way would be a switch, to turn on On-Hold pauses SLA just like Pending does.
- A simple way would be to Pause SLA when a Specific Tag is added, and Unpause when that Tag is removed
Anyway to do this currently?
I thought of a potential semi work-around. When a specific Tag is added, it changes the ticket's current SLA to another SLA. However, I think this would create more issues because it isn't pausing SLAs, it is removing it from the SLA and applying another one. -
Thanks for the feedback, Peter.
Again, there aren't any immediate changes planned for SLAs, but we have flagged this thread as one for PM's to read through when they are pursuing improvements to that area of the product.
-
I also agree with all of the above. Please prioritize this feature. We use On-Hold when we are waiting for our development team to resolve a bug or enhancement and our SLAs usually end up breaching during this time since we do not need to update the customer.
-
Thanks, Matt. I don't expect SLAs to be prioritized in the immediate future due to some other things that have to get completed first, but we have flagged this thread for the PM's.
-
+1 for this feature. It would be really useful when putting the ticket to on-hold status. Nicole, is there any workaround available for now?
-
Hi Alex -
Not that I'm aware of, though if anyone else in the community has figured one out, please feel welcome to chime in!
-
I'm also in agreement with all of the above. Please prioritize this feature.
-
+1 to this.
-
The issue we run into is similar to those stated above. Essentially, we provide the customer an update that the issue is with our development team, placing the ticket 'On-hold'. If the customer replies with a "thank you," this turns the SLA clock on again, even if you set the status from 'Open' back to 'On-hold'. The only way to prevent this is to reply again with "you're welcome," which can be gratuitous and time consuming with a heavy ticket load.
-
+1 to this
-
You can kind of implement this functionality on your own but it's not the most elegant. I added a checkbox ticket field called Pause. The tag for this is "paused." For us, this is paired with another ticket field that is a date field cause Pause Until.
I put in an automation that will remove the pause when the date is reached (date is within previous x days).
Modify your SLA to exclude tickets that have the paused tag. This will keep things from breaching. Unfortunately, the clock keeps ticking because the SLA policy looks as the last public reply that may be weeks or months ago. In other words, this delays the SLA breach until the automation removes the pause.
To fix this, when the automation fires, the automation makes a public reply before removing the pause. Zendesk does not allow you to make a comment on a ticket via automation. To do this, I use an HTTP target extension and have the automation notify the target.
The unfortunate thing about this is this is making a public reply. You can suppress sending this to the requester by modifying the notify requester and CCs trigger that there is a comment update. Then, go back and retroactively make the reply an internal note with a trigger so it can't be seen in the help center.
The JSON body for the automation looks like this:
{"ticket": {
"comment": {
"body": "WHATEVER TEXT YOU WANT THE PUBLIC COMMENT TO SAY",
"public": true
}
}
}The extension/target looks like this:
URL: https://YOURSUBDOMAIN.zendesk.com/api/v2/tickets/{{ticket.id}}.json
Method: PUT
Content type: JSON
Basic authentication: enabled and type in your username and password.
-
Notifying the requester is a dealbreaker for us, but I respect the hackiness of this workaround!
-
I'm with Joel regarding notifying the requester is a deal breaker...
There are a number suggestions to not just this problem but others where the response is 'just hack the JSON' which I understand, but many organisations, such as myself, don't have a resource to do so. This is why we are asking Zendesk to provide the solution...
-
+1 I'm also in agreement with all of the above. Please prioritize this feature, Zendesk.
-
This is critical functionality... we're currently planning a move away from Zendesk as the lack of this feature is breaking our SLA reporting.
-
I also agree with all of the above. As a support team for our own company product, we need to pause the SLA clock when awaiting software fix/feature release from our R'n'D.
An option for customizable status fields for both "Support" (operator side) and "Help Centre" (end-user side), as well as relevant mapping, would be a perfect solution.
@Nicole,
"/.../we have flagged this thread for the PM's"
Would you be able to share the timeline, when we could expect changes in the way that ticket status affects the SLA clock?
-
We have managed to work around this fairly simply. We have an additional field called "On-hold reason". It has a number of typical reasons, "Waiting for development", "Waiting for scheduled meeting", etc...
On our main SLAs we have this setup:
We have 2 SLA policies, one for VIPs and one for everyone else. But the On-Hold condition is the same on both.
The other piece of this is a simple trigger. If any ticket goes from On-Hold, to any other status, simply clear the "On-Hold reason". Then the SLAs get picked up again.
-
Hi Tim,
if you doing it like that, it will re-calculate SLA after back from On-Hold and not helpful.
Simple example:
SLA Set 1 = Next Reply Time
SLA Set 2 = No Next Reply Time
Based on your condition, you remove "Next Reply Time" for On-Hold Status, and SLA goal will gone from ticket (visibility) but for Reporting / Agent, after Ticket changed from On-Hold i.e. to Open and "Next Reply SLA" is back, the goal breach directly due to timing is re-calculating and also checking the other SLA Set On-Hold Time.
So from my point of view or for my things not helpful.
/Tobias
-
I like some of that Tim, and also tried something similar (having a tag disable the SLA), but consider the following scenario:
- 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).
- A customer responds with 'Here are the files you requested', which restarts the 24hr update clock (ticket goes from pending to open).
- 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).
- You then put it into an On-hold state with your On-Hold Reason exception being 'waiting for developers' (which temporarily removes the SLA).
- It sits in the On-hold state over the weekend as the dev team reviews the case (48 hrs).
- 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.
-
Is there a way to maybe exclude tickets with a certain tag or status (i.e. on-hold) in Explore when the SLA data is presented, as a workaround in the meantime?
Or what about seleting this metric in SLA settings? It says that it doesn't count on-hold time? It counts the whole journey though...
-
Hi!
+1 here struggling with the same challenge. We have a tickets "on-hold" sometimes very long time, because those are waiting for developers. We do not want these to be included in the "next reply time" SLA.We would need a way to report somehow if we meet our target to reply customers in X hours (periodic update). Has anyone been able to do this in insights by using this: https://support.zendesk.com/hc/en-us/articles/205367047-Insights-recipe-Duration-between-two-or-more-ticket-events-in-minutes ?
If I understand correctly, I'd need to create 3 metrics:
1) Showing timestamp when ticket status changes from "pending" to "open"
2) Showing timestamp when ticket status is "open" and public comment made by admin or an agent
3) Metric showing a difference between these 2 timestampsBut how I could include also tickets that are "open" and remain "open" despite we send an update to the customer?
-
This is also an issue for us. We make use of on-hold for bugs that will be worked on soon and if the customer responds back with a comment like: "Thanks for letting me know" or "That's great" it will negatively affect their SLA metrics.
Giving the option to pause the SLA for the "on-hold" status in a way similar to the "pending" status seems like the lowest lift (from the ZD engineering standpoint) to be able to resolve this.
SLA metrics are inaccurate until this is a feature.
Please sign in to leave a comment.
54 Comments