Recent searches
No recent searches
Functionality to pause an SLA
Posted Dec 12, 2017
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
46
63 comments
Official
Scott Allison
Thank you everyone for continuing to share your needs for this. Unfortunately we didn't get to this in the timeframe I previously shared. This year we launched Group SLAs, Total Resolution Time, and reply time SLAs are now supported in Messaging conversations.
But we still want to deliver the ability for you to customize exactly how SLA targets get measured, including how an SLA timer is activated and fulfilled. This will give you more control and the ability to capture things like first reply time on agent created tickets, or pause next reply time while a ticket is on hold. These enhancements are planned for the first half of 2024. Later next year we'll offer realtime alerts, notifications and reminders for SLAs.
Thanks again for your feedback, we truly appreciate it.
0
Andy Dyer
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".
10
Tony Williamson
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.
6
Andrew Goetz
We actually use on-hold the most in the following instances:
Our structure is:
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.
9
Chandra Mullineaux
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.
2
Product Team
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?
1
Nicole Saunders
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.
0
Kalle Windefalk
I also agree with all of the above. Please prioritize this Zendesk.
2
Peter Hur
Could Zendesk please create an option to Pause SLA when the ON-HOLD status is applied?
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.
1
Nicole Saunders
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.
0
Matt Beecher
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.
1
Nicole Saunders
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.
0
Alex Tanayno
+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?
1
Nicole Saunders
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!
0
Ben Luo
I'm also in agreement with all of the above. Please prioritize this feature.
3
Joel Koh
+1 to this.
1
Jake Martin
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.
0
Jess Healy
+1 to this
0
Kevin Ford
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.
2
Joel Koh
Notifying the requester is a dealbreaker for us, but I respect the hackiness of this workaround!
1
Tony Williamson
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...
0
Andrew Kaye
+1 I'm also in agreement with all of the above. Please prioritize this feature, Zendesk.
3
Jay Goodison
This is critical functionality... we're currently planning a move away from Zendesk as the lack of this feature is breaking our SLA reporting.
0
Mateusz Toruński
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?
1
Tim Schiller
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.
2
Tobias Hermanns
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
0
Andrew Goetz
I like some of that Tim, and also tried something similar (having a tag disable the SLA), but consider the following scenario:
---
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.
0
Dion Van de Kamp
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...
1
Jonna Tolvanen
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 timestamps
But how I could include also tickets that are "open" and remain "open" despite we send an update to the customer?
0
Rick Kadlac
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.
1