SLA Workaround for Replies that Require no Response | Community
Skip to main content

SLA Workaround for Replies that Require no Response

  • June 16, 2017
  • 3 replies
  • 0 views
R

We're trying to track our agents "Next Response Time" SLA, however, due to the nature of our business, we end up having to put things on hold for extended periods waiting for responses from third party organizations we have to contact and have complete an on boarding process with for our users.

Now, generally we will reach out to an end-user and advise that we'll get back to them when this is done.  If they don't respond, this works great, HOWEVER, if they respond with a reply like "ok thanks" and don't require a response, and we have no sensible way of stopping that SLA counter at this point.

Our workaround currently is creating a tag/checkbox that stops any email from sending on that ticket (we add that tag as a no go for our email triggers), activating it, making a public reply with something like "Ticket on hold", then removing that tag, which is needlessly time consuming for our agents.  Need a way to 'Pause' or reset that SLA clock.

    This topic has been closed for replies.

    3 replies

    Z
    • Zac11
    • June 16, 2017

    Did you consider excluding those tickets from the SLA entirely? Since you are waiting for a third party and would prefer to pause the counter, maybe you could remove it altogether. It sounds like you may be able to set the SLA "tags" condition to "contains none of the following", and use some type of tag such as "sla_exclude".

    Then, you could use a macro to put those tickets on hold for the third party. The macro will add the tag "sla_exclude", and might have a few extra goodies like setting the status on-hold automatically! Based on your description, it seems that could exponentially increase your efficiency.

    P
    • Phil17
    • June 17, 2017

    Ryan, thanks for the post. We also have exactly this problem. We considered your workaround, but could not figure out a a way to prevent notifications to the customers CCed on the ticket. We ended up using Zac's workaround. The problem with that one is that it doesn't seem to actually stop the clock. One the tag is removed, it is then already in SLA breach.

    Our next bit of research is figuring out what happens in this sequence:

    • Ticket in SLA.
    • Ticket tagged to suspend SLA (SLA excludes tickets with the tag, as Zac outlines ).
    • We wait.
    • Ticket tag removed, and SLA now shows as in breach.
    • We run a report on SLA breaches.

    Does the ticket then show as a breach ( messing up our stats ) or not? It comes down to how the SLA breaches work. Do they mark as breached, or achieved, when the public comment is made? If so, then we should be alright, as long as we don't comment while the ticket is in breach.

    Phil

     

    R
    • Ryan16
    • Author
    • June 19, 2017

    You'd have to modify the Notify End-User Ticket Created and Notify End-User Ticket Updated triggers to have a condition something like this in the Meet all of the following conditions section:

    Ticket: Tags contains none of the following: sla_exclude 

    That should prevent any emails going out. Once update has been posted you should be able to either remove the tag, or uncheck a checkbox if you've used that to add the tag.  Could be usefull to have a secondary trigger that sends the agent an update if it's not sending a notification, as well, just in case someone forgets to remove the tag. Could send a notification saying something like "This email is to advise you that the public comment you just posted was not sent to the end-user as the ticket contained the sla_exclude tag".

    Terms & ConditionsCookie settingsAccessibility statement