Service Level Agreements - please share your feedback!

Afixado Em destaque

14 Comentários

  • 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.
    5
  • 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.
    2
  • Gaëtan Tobie-Echeverria

    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. 

    2
  • 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!

    Best,

    Amie

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

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

    0
  • Amie

    Hey Lolu,

    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. :)

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

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

    0
  • 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!

    1
  • Dave Dyson
    Zendesk Community Manager
    Thanks for this detailed feedback, Dan! (Always nice to hear what does work!)
    0
  • Praveena Balasubramanian

    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.

    0
  • Gaurav Shar

    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.

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

    0

Por favor, entrar para comentar.

Powered by Zendesk