Service Level Agreements - please share your feedback!

34 댓글

  • Heather Rommel
    Community Moderator
    Zendesk Luminary
    The Product Manager Whisperer - 2021

    Scott Allison,

    I think I've posted this before but I can't find it for the life of me so here goes:

    • What works well today with the SLA feature? 

    SLAs are easy to apply in vanilla instances where a ticket is created and FRT or Next Reply SLAs are needed. 

    • What limitations do you hit while using it?

    For Pausable Update, our biggest frustration is there MUST be a comment submitted as OPEN for the timer to ever appear. Well, support reps as part of their normal cycle are taught to make a comment and submit as Pending, because we're usually waiting to hear back from the customer. Well, when we want to apply Pausible update, no timer ever appears because we don't ever make comments and submit as Open. 

    Pausible Update should apply if we make a comment in Pending and just pause the timer. That's expected behavior and therefore a bug in our eyes at the moment. Do you know how hard it is to get 100+ agents to remember to take extra steps on every ticket? Please allow the Pausable Update to apply when we make a comment and hit Submit as Pending!!!

    • What do you wish it would do differently for you? Why?

    We wish we could get pausible update timer to appear if we make a comment and submit as pending. LOL. I think you get that.

    Also, we have needs to change the priority of a ticket or apply a different SLA and want the timer to count FROM THE TIME OF THE CHANGE, not from the ticket created time or last comment time. So in other words, I have Next Reply time on a ticket. But my assignee determines they need to move the ticket to a different team. We want to re-apply next reply time from the time of group change, not from last reply.  

    Lastly, we need to be able to check via trigger whether an SLA timer is applied on a ticket. In other words, I want to alert someone via email that a ticket does not have a timer applied. We need a condition in triggers to check for whether an SLA is present and which SLA policy please!

    • What is the impact on your business?

    Agent frustration is the biggest impact. We don't understand why it's not more flexible.  We struggle daily to educate and reeducate assignees, but it's just not intuitive with the Pausible Update in particular!

  • Dan Cooper
    Community Moderator

    What works well today with the SLA feature?

    • The concept for setting them up is very clean.  It's great that Zendesk business rules largely follow the same patterns for how they are setup and configured.  

    What limitations do you hit while using it?

    • Group SLAs.  We need a way to measure first and next reply time for a group assignment.  
    • Manager resets.  We get a lot of requests to reset an SLA timer due to an accidental fulfillment.  This may be due to a non-support member (but still agent) commenting on a ticket, a first reply that doesn't meet the "spirit of a first response" (e.g. a substantial comment vs a "Let me check into this" comment).
    • Agent "customers" fulfilling SLAs.  We have internal teams that submit tickets to us in Zendesk.  SLAs don't always apply for them as they either don't activate or resolve based on their comments. 
    • Schedule clarity for business hours tickets.  It would be good to have better displays as to the business hours a ticket is adhering to.  Agents ask questions when ticket timers don't align to published SLAs and customers can submit tickets out of business hours which can result in confusion if a ticket normally comes in fresh with a 24 hour timer, but a ticket submitted 5 minutes earlier before business hours starts is due only 8 hours later. 

    What do you wish it would do differently for you? Why?

    • When a ticket is transferred to a group, I'd like the new Group SLA feature to count down to first reply.  Optionally, count down to next reply.  It would be good to have the option to require the reply to come from the ticket assignee to avoid fulfillment from other staff. 
    • Allow for reply time metric fulfillment to be restricted to the ticket assignee.  This would address scenarios where internal staff members are the requester on a ticket and SLAs either don't activate or fulfill based on their comments.  In addition, it would solve a lot of manager reset scenarios where a manager needed to make a quick comment but isn't owning a ticket, or the agent as a customer scenario mentioned above.
    • Give us ad hoc SLAs.  These could be one time SLAs that can be applied in addition to current SLAs that allow for scenarios where an SLA was accidentally fulfilled and we need an update within the next few minutes/hours.  Managers could trigger an additional ad hoc metric that provides a timer, but doesn't impact other SLA metrics that are being tracked. This way we can still control when responses happen in scenarios that fall outside of standards SLA metric flows.  Treating ad hoc SLAs as another target can help in reporting as well to allow a team to see how often they are manually intervening. 
    • We need more granular breach notifications.  I should be able to notify for an upcoming breach in the next 15 minutes.  The hourly automation cycle is far too slow. 

    What is the impact on your business?

    • We have a lot of SLA hacks in place to address issues with non-support agents impacting SLA fulfillment, setting timers for group transfers, and we have page earlier than necessary to not miss SLAs.  These lead to complex process docs that take time to enable staff on and slow down ticket processing.
  • Katie Cerrone

    Need SLAs to accurately report on tickets that transfer between agents.


    We use "tiers" as different levels of support. When creating a report to show us our % of SLA achieved broken up by tiers, we noticed that if we sort by "tier" the tier is actually measuring the response time from when the ticket first appeared, and not the response time of the tier the ticket is currently in. For example, T3 shows as 100%, but that is only because the ticket was initially on T1 and T1 responded in SLA. So, the tier is only reflected as the tier the ticket is currently in, not the tier in which the SLA was achieved or breached.

    Each tier should have it's own SLA. If a ticket comes into tier 1, it has a specific SLA. If it is transferred to tier 2, it should have a new SLA. We want to see a report with the % achieved for both of those tiers to see how well the tier 1 team did AND how well the tier 2 team did. It seems though like the way it is set up now it only checks when the ticket was created and then from that point onwards it only checks resolution times.

    When I reached out to Zendesk, they let me know that this is a current product limitation. "The SLA belongs to the ticket as a whole, not each individual and ultimately the last assignee will inherit all of the SLA targets in reporting. For this reason, SLAs do not accurately report on tickets that transfer between agents."


    We really need this in order to more effectively understand how our teams other their Tier 1 are doing.

  • Scott Allison
    Zendesk Product Manager

    Thank you all for providing your feedback on this thread, it's truly appreciated. We have been monitoring and collecting your comments, and feel we have the information we need to make our ongoing product decisions. We are now going to close out this thread for comment. There are still specific requests for SLA enhancements in the Community, and I'd encourage you to upvote those if you have not already. We still have an exciting roadmap ahead for SLA enhancements and will publish announcements with every release. If you want to follow those, you can click on the follow button on this page


게시물 댓글 달기가 중지되었습니다.

Zendesk 제공