Functionality to pause an SLA
PlanejadaHi 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
-
Comentário oficial
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".
-
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.
-
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.
-
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'm also in agreement with all of the above. Please prioritize this feature.
-
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.
-
+1 I'm also in agreement with all of the above. Please prioritize this feature, Zendesk.
-
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.
-
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?
-
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. -
+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 to this.
-
Notifying the requester is a dealbreaker for us, but I respect the hackiness of this workaround!
-
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?
-
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.
-
@Zendesk
Any plan to enhance SLA "ON-HOLD" to Stop Next Reply Time?
-
I wouldn't even restrict it to the on-hold status. Just having an option to manually pause an SLA would be great.
1st use-case:
A customer writes us, we call him back to answer him. After the call, we set the ticket to "pending" because there are still open topics for him to answer. We don't actually send a reply though, so the "next/first reply time" SLAs keep running.2nd use-case:
We send the customer an email "sorry we're keeping you waiting, we're on it ....". He just replies "ok". Because of his answer, the "next reply time" SLA starts again. -
We often put a ticket on-hold when it has been agreed between the customer and ourselves (usually at their request) that there will be a period of no focus on the support request until an agreed, future date.
In this scenario, for the SLA pausable update to consider it a breach when there is no public comment update from an agent between the required timeframe is somewhat ridiculous.
On hold by the very nature of the term implies that there is no work expected on the request, so I agree with the others that on-hold should be excluded, or at the very least configurable whether to include or not, so that for those companies can enjoy accurate SLA reporting.
-
This was initially flagged in 2017. It is now the end of 2021. You say improvements like this one are on your roadmap "for the next 9 months".
Why are Zendesk so slow at listening to their customers?
Maybe you need to remove the Zen from Zendesk?
-
Hello,
when will it be possible to pause SLA? Each workflow is different from one company to another, and this absence is very constraining.
In the meantime, why not create a new SLA policy including only the Open status?
Thanks in advance for your feedback -
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.
-
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.
-
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!
-
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
-
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...
Por favor, entrar para comentar.
54 Comentários