Functionality to pause an SLA

Planned

53 Comments

  • Official comment
    Scott Allison
    Zendesk Product Manager

    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 will start to roll out next week: an easier way to see upcoming SLA breaches.

    The next big change will be the ability to put OLAs (internal SLAs between teams) on tickets, and that will come sometime in Q3 this year. 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 likely towards the end of this year, and I'll share an update nearer the time. 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.

  • Andrew 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".

    9
  • Andrew Goetz

    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.

     

    9
  • 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.

     

     

    3
  • 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
  • Ben Luo

    I'm also in agreement with all of the above. Please prioritize this feature.

    2
  • Kevin Ford
    Community Moderator

    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
  • Andrew Kaye

    +1 I'm also in agreement with all of the above. Please prioritize this feature, Zendesk. 

    2
  • 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
  • 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
  • Kalle Windefalk

    I also agree with all of the above. Please prioritize this Zendesk.

    1
  • Peter Hur

    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
  • 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
  • Joel Koh

    +1 to this. 

    1
  • Joel Koh

    Notifying the requester is a dealbreaker for us, but I respect the hackiness of this workaround!

    1
  • 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
  • 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
  • Tobias Hermanns

    @Zendesk

     

    Any plan to enhance SLA "ON-HOLD" to Stop Next Reply Time?

    1
  • Fabio Strasser

    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.

    1
  • Martin Cubitt

    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.

     

     

    1
  • AKQA - United Kingdom

    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?  

    1
  • Sylvain Buttazzoni

    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

    1
  • Nicole Saunders
    Zendesk Community Manager

    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
  • Nicole Saunders
    Zendesk Community Manager

    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. 

    0
  • Nicole Saunders
    Zendesk Community Manager

    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
  • Nicole Saunders
    Zendesk Community Manager

    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
  • 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
  • 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

Please sign in to leave a comment.

Powered by Zendesk