Service Level Agreements - please share your feedback!

34 Comentarios

  • Monica
    • Internal only tickets - We have some internal tasks that don't have public replies which means we're reliant on the agent work time SLA for these tickets. There's desire for a first review within a short period of time, but full resolution in a longer time. I achieve this currently by one SLA without the tag and the shorter SLA, agent adds the needs further review macro with tag, then the longer SLA applies. However, rather than 15 min per update, they have 30 min total when the longer SLA is applied. To do multiple updates, I'd need to set up more tags and SLAs. Ideally, a flag or limitation for how many updates are allowed along with tracking in Explore for SLA breach/achieve for X number of updates would be helpful to mitigating gaming the system.
    • Requester's language - We have different teams with different SLAs based on the customer's language. SLAs do not use Requester's language so we rely on a custom ticket field that reproduces the Requester's language field on a ticket. This creates the need for triggers and automations to ensure alignment between the two fields for each language we support.
    • Tickets without SLAs - When the non-requester responds to a ticket, it often does not have the SLA apply despite the ticket being set to open because their comment is not public. While I appreciate the comment not being public, we are limited in sorting our queues by next SLA breach since we'd then need to manually triage tickets without an SLA.
  • 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!

  • Terry Knox


    The big thing we need is the ability to report on SLA performance/adherence based on the ticket assignee at the time of the event. Currently all reporting is based on the current/final assignee. We're basically looking to give agents response time SLA targets, but we can't reliably do that right now. 

    Also, a tiny thing, but can we rename "Next SLA Breach" in Views-look at all the dead white space.

  • CJ Johnson

    Feedback from agents after a couple months of testing: 

    It's very confusing that SLAs that are breached but later met, like FRT, stay visible in the ticket and drop down about SLAs, frozen in the time state when the SLA was eventually met. 

    It's very confusing to not have any labeling to tell you which SLA is which in the views. Combined with the above problem, it's rendered SLAs being viewable in tickets, completely meaningless/useless to agents. There's no way to tell if the SLA being shown is for FRT and was actually met now and you can stop worrying, or next reply time, or full resolution time. 

    The lack of ability to notify of breaches and upcoming breaches in real time is a huge con. If there's no ability to notify on breaches or upcoming breaches, and you can't see which SLA metric is dictating the position of the ticket in a view, you've effectively removed all avenues for proactive management of SLAs. The value is reduced to slightly simplifying reporting on how long it took for a first reply, full resolution, and total wait time the customer experienced. 

    The inability to select *specific* SLA metrics to organize a view by, is another desperately lacking feature. I don't need the ticket that is a week over the breach for "Full resolution time" but having consistent back and forth every day still, at the top of my view of tickets needing action because it's got the longest breach. 

    In the pros, this helped somewhat with improving the order of tickets, to ensure a balance between responding to customers who have been waiting the longest for an agent reply for follow-up, and those still waiting for a first reply. This was not possible without this feature. However, as mentioned above, if you use full resolution time as a policy as well, anything that runs over will get then be at the top of the view consistently until it is closed, even if it was replied to the same day already. I can always remove the full resolution metric from SLAs, but it seemed prudent to mention that it will always have this undesirable behavior with the current way of working and function of SLAs. 

  • Chris Bulin
    Community Moderator

    Hi Scott! Thank you for requesting feedback.

    What works well today with the SLA feature?

    • We rely on the SLA feature heavily in our support queues. We really like being able to arrange the view by the First Reply SLA for that group. It also works really well for processes that have Resolution SLAs and allow us to understand how often we are hitting the target there. The team really likes the heatmaps I'm able to create in Explore using our SLAs.
    • From an organizational perspective, we can tie SLA pretty neatly with satisfaction. This allows us to establish value for the reply times that we set and help us convince other departments of the need for more scrutiny of their own reply times.

    What limitations do you hit while using it?

    • One of the main ones are tickets that have already met the SLA and fall to the back of the inbox. We have tried multiple ways of fixing this (using next reply SLAs, grouping by status because those come in as Open). I would like to be able to give some weighting to tickets that meet the SLA but should be concurrent in the view. These primarily come from one of two things, an agent is out of office and one of their tickets receives a reply or we have a ticket transferred from a team that is using our CRM, in which case the first reply was by the other team, and we're being asked to follow-up.
    • Another thing that we have run into is that we use the Zendesk app SLA Event Tracker. I would love to see that just incorporated into the interface in some way so folks can accurately see when a multi-SLA ticket is near breach on the non-focal SLA. Having a history of the SLA timer would also be useful.
    • We see a lot of confusion around what resolves a First Reply SLA with folks new to Zendesk. The first confusion is around private comments and SLA as Monica noted above. The second confusion is when we send out a proactive message and the user replies 3 weeks later, our first reply time gets tanked. We have created a workaround on this by tagging all of our proactive messages and then excluding them from First Reply SLAs, but it would be really nice if those tickets would count First Reply as the time between the user's response and ours, rather than from our originating message and our response. If we could reduce user confusion and get a more accurate SLA in these cases, it would be a win-win.
  • Gaëtan Tobie-Echeverria


    Thank you for requesting feedbacks.

    We are doing B2B with custom tailored SLA. See attached, we have a new policy based on only three priority and the last one is "open", meaning the countdown won't really applied. I have created a custom field (Prority_new) and a trigger to populate this field but I'm stuck at the SLA creation because the only SLA definition possible is based on the native Priority field. As a workaround I have to rework all the reports in Excel before submitting it to Customer. 

    My request is to be able to have SLA based on custom fields. 

  • Lolu

    As a ZD user, I think it's important to be able to create triggers based on SLA breaches. Our support time is usually in seconds so when we have an SLA breach, we don't want to wait for an hour before notifications and alerts are sent out. 

    It's very odd that we cannot do something as basic as adding a tag to the ticket immediately SLA is breached

  • Lolu

    Hey @amie it doesn't help :). I know what triggers and automations do. I simply want SLA breaches to be used as triggers instead of automation. We want to take action IMMEDIATELY there's a breach. Actions like send an email or notify slack, or use other external tools to alert the assigned agent. Automation only gives us the option to take action 1 hour before or after the breach. We use messaging and typically respond in seconds, our first response SLA is <60 seconds. We don't want to take action a whole hour after there has been a breach

  • Dan Reyes-Cairo

    Yikes, Neill Shurville - can you confirm whether, in your experience, SLA's don't work at all (i.e. Zendesk chose to not enable SLA's within the messaging experience), or whether they're just unreliable (dependent upon an agent updating the status of the message ticket - which is uncommon).

    Not having functional SLA's would be a blocker for us enabling messaging for our team.

  • asAlmas

    Hello there,

    A pausable update service level agreement has been added to our SLA for our clients recently.

    There are a lot of great things about this feature and it is one of the reasons why we have been having some issues with the SLA not kicking in on time for us.

    As a result of Zendesk support's update, we have found that in order for the SLA to be effective and to work properly, the agent will need to write a comment on a new ticket and set it to any other status other than pending, and after that, the agent will have to write one more comment and set it to pending so that this SLA will be active.

    Consequently, my suggestion is that we can add a feature that would enable the SLA to kick in as soon as a ticket is created and active throughout its lifecycle. However, the SLA will cease to operate when the ticket is in the pending state and will reappear when it is in an open state.

    Therefore, this will provide us with a solution to the problem that the SLA is not in effect when a ticket is awaiting feedback from the customer, and when it is open or on any other status the agents will have to put in regular updates on the tickets in order to maintain the SLA.

  • David Brown

    We need a way to activate and deactivate SLAs, not simply delete them. I have a feature request created for this.

  • Amie

    Hey Team,

    As a ZD Partner who configures a lot of Zendesk accounts, i'd love to share my feedback:

    - No ability to deactivate a SLA. Sometimes customers need to disable a SLA temporarily and then reactivate it again. Right now its a pain in the ass having to delete it and re-create it everytime they need to do that. 

    - Lack of categorization. It would be great if we could categorize SLAs like we can with triggers. I've had some customers who end up with 20+ SLA's and a giant list can be quite hard to manage, 

    - SLA's only work for tickets. Many customers are now wanting to apply SLAs to Talk tickets. The current SLA logic doesn't apply for Talk tickets since the SLA looks for the first comment. When on Talk tickets that doesn't happen so SLA'S go entirely out the window. It's crucial for customers to be able to ensure they are meeting their incoming calls within suitable time periods. Sometimes ZD Clients offer to their customer particular SLA's pending on subscription level to the business on how quick the turn around time is for interactions. 

    - I'll also second SLA's based on requesters language. I've got some global customers with 10+ brands that require different SLAs for different languages around the world based on the customs in that country

    Looking forward to seeing some of this come to fruition in 2022!



  • Dan Reyes-Cairo

    Hi all, glad to have found this thread.

    What works well today with the SLA feature?

    We're pretty happy with the opportunity to create SLA policies based on customer segments and reply times. Things can get pretty complicated when it comes to prioritizing who gets helped first and the SLA framework provides some much-needed structure to allow agents to focus on a "top-of-the-bucket" list so they spend less time evaluating for priority and more time assisting customers.

    What limitations do you hit while using it?

    Currently we're noticing that certain scenarios will force a First Reply Time ticket to deflect to the bottom of the queue with no applied SLA:

    1. Scenarios where a ticket is re-opened by the user writing in from a different email address, or a separate user who was CC'd in on the thread but wasn't on the original ticket
    2. Issues that originate from a Chat (our agents are using the Agent Workspace for chat sessions) since FRT SLA's only target email responses to a ticket and typically if a ticket originating from a chat session remains open or unanswered from an agent, there is no public reply from the end-user.


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

    Ideally there should be no scenario in which a new ticket is created in the Agent workspace by an end-user, regardless of channel origin, so that the First Response Time SLA triggers. This will assure that users receive timely responses and agents are free to focus on tickets that are prioritized according to SLA response times.


    What is the impact on your business?

    Currently we have to adapt our process to account for these outliers, and although we do a pretty good job, tickets do slip through the cracks. Not only does this impact a customer first impression (we typically maintain a 45-minute FRT SLA), it negatively impacts the accuracy of our reporting which de-values the data we're receiving from Zendesk.


    Thanks for looking into this!

  • Neill Shurville

    They don't work at all for "time-based" SLAs i.e. all SLAs that rely on a "public comment". It seems that they don't count social messages as a public comment...

    Some, such as "working time" still work, because that's purely based on status.

    They either need to:

    • Count social messages as public comments for the sake of SLAs
    • OR add more SLA types based purely on status change (so it doesn't rely on the public comment)

    Check out the following section RE SLAs and messaging tickets:


    It's not great product design by Zendesk IMO.

  • Neill Shurville

    Riccardo Centomo

    Nice comment, very good description of the current limitations on SLAs.

    RE the messaging limitations, check out my post here:

    Our team has huge issues with SLAs as we offer true omni-channel support (phone, email, whatsapp, instagram, facebook). It's really frustating Zendesk allows these channels, but then doesn't support basic SLAs for them.

    Please comment on my post if you have any more thoughts, I'm hoping to get some momentum towards this issue!

  • Brian Haine

    As a new ZD customer, so far the SLA feature is very useful.

    we have found a few things that we would like to modify.

    1st is an SLA option that doesn't get paused. it is all too easy for an agent to set a ticket to pending to pause the timers.

    we have SLAs of 5 & 15 mins but the SLA breach doesn't go that granular so sometimes we don't see a breach until an hour later. 

    we would like to generate emails based on the upcoming SLA breaches.

  • Peter Peckarsky

    I would love to have SLAs that mark time since X status. For example, next reply time is helpful, but if we need to reply to a customer, transfer them to another department internally, and then send another follow up, I'd like to know how long it's been since the ticket has been open (the time the customer first replied to the ticket) even though we've already replied once. 

  • Dave Dyson
    Thanks for this detailed feedback, Dan! (Always nice to hear what does work!)
  • Praveena


    What works well today with the SLA feature?

    SLA allows to have comprehensive conditions with different targets.

    What limitations do you hit while using it?

    The main limitation comes to one touch tickets where the status is changed from New to Solved, there is no SLA target activated. While in Ticket events we could see the SLA with no targets applied, the explore reports this as No SLA triggered.

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

    Enforce a ticket background update so that SLA target gets activated before the ticket is marked solved. When the agent submits the ticket as solved with SLA trigger conditions, ticket should have an auto update identifying the SLA and then mark as solved.

    What is the impact on your business?

    We have a majority of tickets falling under one touch resolution and has huge impact to our SLA metrics. Manual intervention is required to update the SLA status in our report.

  • GS Admin


    We have recently added pausable update SLA for our customers .

    I feel that this is a really great feature , but we have been facing a few issues with this SLA not kicking in on time .

    on update from Zendesk support we have found that for the SLA to kick in and work efficiently the agent will have to post a comment on a new ticket and put it in any other status other than pending and on then the agent has to post one more comment and set it to pending for this SLA to kick in.

    So my suggestion will be if we can add a feature where where the SLA kicks in when the ticket is created and is active in the lifecycle of the ticket but stops when the ticket goes to pending and resets when it is open or any other status .

    So this will help us solve the problem that the SLA is not active when the ticket is in pending and waiting for customer response and when it is open or on any other status the agents will have to put in regular updates on the tickets.

  • J P

    It would be excellent to see what SLA is applied to a ticket in Support when you hover over the badge from the Views page. It can be pretty time consuming to have to go into a ticket, click on Event button, and scroll to find out what SLA was applied or what the latest SLA is (since it can change when a ticket is updated). This is especially true for tickets that have several comments back and forth between the agent and the customer.

  • Jodi Freeman

    It'd be great if you could add holidays by business hours instead of full days, since there are certain holidays where SLAs should only pause for US business hours but be active for all other business hours, etc.


  • Trudy Slaght

    I would like to be able to choose which business schedule an SLA is using.

    Our current SLA are all based on business hours, and it would be great to be able to have an SLA that could use a specific schedule to count business hours. 

  • Neill Shurville

    As per my topic posted here, SLAs really should work for messaging channels... see my points below...

    • As per this article, time-based SLAs that rely on agent updates do not work with messaging.
    • The reason given in the article makes no sense*
    • Messages sent by agents through a messaging channel should count as an update, or at least count as such when it comes to SLAs.
    • Without this, SLAs are useless for any company running omni-channel support (one of the main selling points of Zendesk)


    *the reason given is that agents typically don't update the status of a ticket when replying via a messaging channel - but that makes no sense because time-based SLAs don't rely on status changes. It just

  • Neill Shurville

    FYI I have a thread for this - might help to comment there as well to try bring some attention to this fairly major flaw...

  • Riccardo Centomo


    • What works well today with the SLA feature?

    We are ZD integrator partner, today the SLA in ZD is a nice colour flag in the view and in the ticket. The ZD customer that we help to onboard like this at the first time, like during the demo etc.

    • What limitations do you hit while using it?

    When the customer explore better the usability of the SLA we face off all the point that CJ Johnson has describe above: 

    Other limitations:

    - the messaging channel has great SLA limitations describe here:,General%20functionality%20limitations,-The%20following%20limitations   and also here: 

    A lot of customer (Europe) ask to us to enable the Whatsapp channel to meet the end user expectations, but the think it's like the live chat and every time we have to explain there is SLA and reporting limitations..

    - Our customer have more than one support level, so they ask to us the OLA, but ZD have only SLA metrics and it's not possible to manage well OLA's and the work around to create child ticket to manage OLA's is not practicable because customer don't wanto to manage duble ticket for the same end user (requester)..

    We also use ZD for our help desk and we are in the same conditions. We have different step of the process to manage the ticket and it is assigned from the first support level to the second at certain point, but the SLA are not able to replicate our SLA defined in the contract the customer has signed. The SLA of ZD aren't able to manage specific metric to manage OLA between the ticket assignment from the first to the second level and back..

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

    It's not easy to understand every time what SLA metric is concern in the ticket by the SLA Event Tracker app. Our customer doesn't use it, too much hard to understand..

    SLA and OLA have to help to understand agent to manage ticket priority. Help them with real time alert via AW, ZD app, social channels (Slack, Teams etc.)

    Customer have to feel confident the SLA tools help their agento to work on time to the ticket, and if they don't they are promptly advise on this. Our customer what get better CSAT from the requesters so the can approve the customer service budget for the next year..

    • What is the impact on your business?

    Our ZD customer are not always confident to utilize well the actual SLA, so it have an impact also to the Explore reports and the negative loop came back to how manage better the ticket..?

    OLA is required to fully manage the ticket inside the support organizations with more than one level. It has to be custom metric configurable to adjust the OLA with the customer agreement signed

    SLA should not be teach to understand what you are viewing in the view or in the ticket.. The agent must understand itself..

  • Kerry Sorenson

    Hi! I'd love the ability to see what revisions were made to SLA policies (similar to how you can see changed within triggers). I had an issue where an SLA stopped and started working, but had no ability to see what changed within the timeframe (11075045).

  • Danilo Brandileone Scardua

    I may be late here but worth a try.

    • What limitations do you hit while using it?

    It's impossible to define the target response time for working hours and outside working hours into the same SLA policy.

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


La publicación no admite más comentarios.

Tecnología de Zendesk