A service level agreement, or SLA, is a policy you define that specifies and measures the response and resolution times that your support team delivers to your customers. There are seven metrics you can use to define SLA policies.
Advanced settings are available for the First reply time metric. They change the logic for when an SLA metric is activated or fulfilled on an individual policy basis. You can define advanced settings for both new and existing SLA policies.
Defining advanced settings for these metrics allows you to customize your SLAs so that they apply in more situations and measure what’s most relevant to your business. This leads to a more efficient support process and an improved experience for agents and end users.
This article contains the following sections:
Related articles
Defining advanced SLA settings
Advanced settings for SLAs are available for the First reply time metric. You can define advanced settings for both new and existing SLA policies.
When you define advanced settings for an existing policy, your reporting may change as SLA achievements or breaches would be measured differently than before. To compare reporting changes before and after you make changes, note the date when you update your policies.
Alternatively, create a new SLA policy with a different name, using the same criteria as before, but with the new advanced settings applied. If you choose to create a new policy, make sure you reorder your policies so that the old SLA policy doesn’t apply.
To define advanced SLA settings
- In Admin Center, click
Objects and rules in the sidebar, then select Business rules > Service level agreements.
- Define a new SLA policy or edit an existing policy.
Ensure that the policy you’re editing or creating has a First reply time metric defined.
- Click Advanced settings.
- Select the check boxes for the settings you want to apply to the policy.
See Understanding advanced settings to learn more.
- Click Add, then Save policy.
The advanced settings you applied to the metrics take effect the next time a ticket that matches the policy’s criteria is created or updated. If you edited an existing policy, note that SLA policy changes only apply when tickets are subsequently created or updated. They are never retroactively applied.
Understanding advanced settings for SLA metrics
This section outlines the advanced settings available for the First reply time metric. In the metric’s advanced settings, the dimmed check boxes describe the standard criteria for how the metric is activated and fulfilled. The standard criteria can’t be edited and always apply to how the metric is activated or fulfilled.
Any advanced settings that you select are applied in addition to the metric’s standard criteria.
First reply time
The First reply time metric is used to measure the time between ticket creation and the first reply from an agent.
Activating the target
The standard settings for first reply time activate the target when an end user submits a request with a public comment, an agent forwards an email from an end user to create a ticket, or when an agent creates a side conversation child ticket.
With advanced settings, the target can also be activated when:
- A ticket is created on behalf of an end user with a public comment, whether this is done by an agent, API, or other means. This also applies to voicemail tickets.
- A ticket is created on behalf of an end user by a light agent forwarding the ticket by email.
- A ticket is created where the agent is the requester. This can be helpful when an agent reaches out to an internal department for help.
Fulfilling the target
The standard settings for first reply time mark the target as fulfilled when an agent adds the first public reply.
21 comments
Johannes Garske
When we will have the option to define when a SLA is not fulfilled?
We want to have a stable reporting and this is only possible when the SLA breach is visible without any public or private comment.
Otherwise it will jump, depending on when the SLA was updated.
2
Scott Allison
Johannes Garske Thanks for the feedback! Can you tell me more about this need, specifically?
0
Johannes Garske
Hey,
at the moment the SLA is only achieved/ breached when an agent reply (i don't include the news from the post).
When we report on these numbers the calculation in Explore is constantly changing because some tickets are getting older (e.g. potential bugs). Thic ticket counts into the week where the SLA breaches or achieve (SLA update), independent from the date we solve it.
We need one number and this is only possible when the SLA breach shows in the week it breaches, independent from an reply or an internal note.
The reporting is totally inaccurate without this. It just jumps randomly between different achievement-rates.
0
Brett Bowser
Hey Johannes Garske , it looks like we have a ticket open with you regarding this issue you're running into with your reporting. We will continue working with you in that ticket to figure out what's causing issues with reporting on your SLA's.
Appreciate you bringing this to our attention!
1
Cameron Eng
Hello! We have the next reply time start setting, "When any end user replies to a ticket and that reply is added as an internal note", enabled.
However, we have noticed that third-party internal note responses where the response is flagged because the end-user was not “part of this conversation” are not setting a next reply time.
Is this an expected behavior? Is there anything we can do to change this?- We want all external end-user internal notes to set a target regardless of whether they were originally part of the conversation
1
Patrick Beebe
Wondering if anyone got answers to their questions?
0
Joel Parmer
I have this same question Cameron Eng
0
Colleen Hall
On October 31, 2024, Zendesk removed advanced SLA settings for the Next reply time and Periodic update metrics. Additionally, the options available for the First reply time metric advanced setting have changed. Please follow the announcement for updates.
-1
Shai Eyal
Hi Scott Allison , we have some internal SLAs that cannot be achieved by group SLA, for example Jira updates,that require us to update the customer (so the customer will receive a message, but it will not be due to them sending one, but due to our communication). We would love to see an option of customizing SLA based on those updates, regardless of end-user activity, since we want to ensure those updates are relayed to the customer in a timely fashion. Will this be available sometime?
0
Lara McCaleb
Colleen Hall Where is the communication that functionality has been removed and the reasoning? When can we expect to hear an update? I have a need to track SLA first reply time when a ticket is created with an internal note (read: voicemail). A customer leaving a voicemail, regardless of whether we want that set to internal or public for our ticketing system, should technically be considered a public message from a customer and I need to be able to track our first reply SLA metric against it.
0
Rositsa Pavlova
Hi,
I have an SLA in place for first reply time via Live Chat. However, I’ve noticed that if a chat is initially missed by Agent A, the SLA is breached, and when the chat is reassigned to Agent B, the breach is recorded against Agent B.
Is there a workaround to ensure that the SLA breach is not attributed to Agent B when it was missed by Agent A?
Best,
Rose
0
Sydney Neubauer
Colleen Hall we have been excited to use Advanced settings for SLAs. It was unclear as to what settings were being removed but bu the looks of it, SLAs for internal notes has been removed:
Does this also apply for Voicemails?
When will this setting be returning? We have had a request for this since February and we were about to implement until it was removed. Is there a timeline?
0
Salvador Vazquez
Hello all,
Thank you for continuing to check in on these advanced settings. I understand this is not the ideal case to have some of the settings removed but we wanted to make sure you all have reliable SLA activations and fulfillments. Customers who were already using the new advanced SLA settings were notified by email. Zendesk is working toward a long-term fix before reintroducing these settings; however, the date when they will be available again is still being determined.
In the meantime you can refer to this document for which settings are still enabled and working. And follow this announcement to keep up with the changes to the advanced settings.
Thank you all for your patience as we work through this and get your functionality back.
1
Sydney Neubauer
Salvador Vazquez
Thanks for the update. However we are not seeing the settings that is described in that article. Here is what we see in regards to Next reply:
Compared to what should be there for Next reply:
There is no option for advanced settings for Next reply. And we can't comment on the article you mentioned. Can you confirm if the article is up to date or if there is an issue?
0
Colleen Hall
Hi Sydney Neubauer, this article, Customizing your SLAs with advanced settings, is up to date. Advanced settings for Next reply time and Periodic update were temporarily removed on October 31, 2024.
1
Nicky Clark
Colleen Hall do you have any clearer definition of ‘temporarily’ at this time?
0
Colleen Hall
Hi Nicky Clark, not at this time. As soon as there is more to share, the announcement will be updated. Please follow the announcement so that you're notified of any new information.
1
Cristina Mercado
Follow up on this inquiry
Hello! We have the next reply time start setting, "When any end user replies to a ticket and that reply is added as an internal note", enabled.
However, we have noticed that third-party internal note responses where the response is flagged because the end-user was not “part of this conversation” are not setting a next reply time.
Is this an expected behavior? Is there anything we can do to change this?- We want all external end-user internal notes to set a target regardless of whether they were originally part of the conversation
0
Jennifer Landry
Are there any plans to enable the configuration of SLAs based on a field other than "Priority"? Our SLA agreements are centered around "Severity," which presents several challenges:
Priority and Severity represent different concepts. While they are often aligned, there are instances where they differ, leading to reporting inaccuracies across systems. Engineering uses "Priority" to determine the resolution timeline, whereas "Severity" reflects the impact of the issue on our systems.
It would be beneficial if we could either rename the "Priority" field or configure our SLAs based on a "Severity" field.
Currently, I have created a "Severity" field and instructed our team to set both the Severity and Priority to the same values. This approach ensures our reporting terminology aligns with our contractual language and will also provides accurate SLA times based on the Priority field.
0
Tom Bradley
Is there any news when advanced functionality will be put back in?
In particular we would need the ability to track “Periodic Updates” based on internal notes.. this way Private or Internal tickets are still tracked and would require regular updates to be kept up to date.
Thank you
Tom
1
Harrison Meesschaert
+1 for Tom's question above…
We've struggled to maintain quality and efficiencies without the ability to fully rely on SLAs for all tickets - especially those created with First Reply Time generated from APIs.
It's been months without these features, when will they be returned? Is there a plan, a timeline, or anything?
0