Service Level Agreements - please share your feedback!
ÉpingléeOver 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.
-
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.
- 从组织的角度来看,我们可以把SLApretty 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.
-
Hello,
Thank you for requesting feedbacks.
我们正在做B2B和量身定做的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.
-
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
-
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.
-
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
-
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. :)
-
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
-
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.
-
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!
-
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
-
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.
-
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.
-
FYI I have a thread for this - might help to comment there as well to try bring some attention to this fairly major flaw...
-
Neill ShurvilleThank you for your feedback! We do in fact have a plan to support reply time SLAs for Messaging conversations, and this is currently scheduled for Q1 of 2023.
-
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.是很让人困惑的te没有任何标签ll 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.
的得失,这有助于提高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. -
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.
因此,我的建议是我们可以添加一个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.
-
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.
-
Terry KnoxThanks for the feedback, it's really appreciated. I'm one of the Product Managers here at Zendesk and we're currently working on a range of improvements. I'd like us to solve for the reporting need, but don't a firm timeline on that at present. Regarding the column names in views, that's something we're working on. Soon it will just be labeled "SLA".
-
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:
- the messaging channel has great SLA limitations 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
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.)
客户必须有信心SLA工具帮助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..
-
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!
-
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.
Vous devezvous connecterpour laisser un commentaire.
32 Commentaires