Service Level Agreements - please share your feedback!
PinnedOver the next few quarters we'll be working on a range of improvements to our SLA feature set. We'd love to learn more about what you need, and where we should focus our efforts.
Current State:
Our SLA feature set works for some customer facing use cases, but less well for any internal ones. It's also not consistent and available in all channels (e.g. Chat/Messaging). There's also no way to get notifications in real-time or in-product.
Our questions for you:
What works well today with the SLA feature?
What limitations do you hit while using it?
- What do you wish it would do differently for you? Why?
What is the impact on your business?
How to help:
Please let us know your thoughts in the comments below. This post will remain open for one month, at which point we’ll close it and incorporate our findings here into the rest of our research.
We are also interested in having a 1:1 conversation to dig deeper with a few customers. If you’re interested in participating in our research that way, please please indicate that in your comment as well and we’ll follow up via email.
Thank you!
-
- 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.
-
我想我已经发布过但是我找不到我t 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?
Pausable更新,我们的最大的挫折是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? Pleaseallow 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!
-
Hello!
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.
-
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. -
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.
- 我们看到很多困惑什么解决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.
-
Hello,
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.
-
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
-
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
-
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.
-
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.
-
We need a way to activate and deactivate SLAs, not simply delete them. I have a feature request created for this.
-
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!
Best,
Amie
-
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:
- 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
- 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!
-
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:
https://support.zendesk.com/hc/en-us/articles/4408821805338#topic_u4c_wzp_wnb
It's not great product design by Zendesk IMO.
-
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!
-
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.
-
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.
-
Thanks for this detailed feedback, Dan! (Always nice to hear whatdoeswork!)
-
Hello,
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.
-
Hi,
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.
-
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.
-
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.
Thanks! -
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. -
As per my topic postedhere, SLAs really should work for messaging channels... see my points below...
- As perthisarticle, 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
-
FYI I have a thread for this - might help to comment there as well to try bring some attention to this fairly major flaw...
-
Hi,
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 thatCJ Johnsonhas describe above:https://support.zendesk.com/hc/en-us/community/posts/4410323216922/comments/4935400391322
Other limitations:
——消息传递通道有伟大的SLA的局限性describe here:https://support.zendesk.com/hc/en-us/articles/4408822351642-Limitations-in-messaging-functionality#topic_pws_pfb_rqb:~:text=Mobile%20limitations-,General%20functionality%20limitations,-The%20following%20limitationsand also here:https://support.zendesk.com/hc/en-us/community/posts/4409222716954-Social-Messaging-First-Reply-Time-SLA-missing
很多客户(欧洲)问我们启用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?
这不是每次我SLA,容易理解tric is concern in the ticket by the SLA Event Tracker app. Our customer doesn't use it, too much hard to understand..
SLA和OLA帮助联合国derstand 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..
-
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).
-
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.
-
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.
-
HeyLolu,
What you're looking to do here is already achievable inside Zendesk with the use of automations. I think you may have your wires crossed here on what a trigger and automation can do.
Trigger = event-based.When an update is made on a ticket then a trigger will run. This is classed as an event-based update.
Automation = time based.When enough time has passed on the ticket, and it matches the automation settings, the automation will then perform the actions required on the ticket.
Below is an example automation of how you could achieve adding a tag to a ticket once the SL:A has breached.
Hope this helps. :)
Pleasesign into leave a comment.
32 Comments