A service level agreement, or SLA policy, is an agreed upon measure of the response and resolution times that your support team delivers to your customers.
For example, you can define an agreement where you respond to urgent tickets in 10 minutes and resolve them within 2 hours.
Setting up SLA policies
Each SLA policy has aset structureconsisting of conditions that a ticket must meet and the metrics you choose to measure. Note that you don't need to set a target for every metric when setting up an SLA policy. SeeBest practices for using metrics together.
To set up an SLA policy
- InAdmin Center, click
Objects and rulesin the sidebar, then selectBusiness rules > Service level agreements. - ClickAdd policy.
- Enter aPolicy Name.
- Optionally, enter aDescription.
- Select theConditionsfor the policy.
Start typing the condition to autocomplete or select an option from the drop-down menu.
- In theReply targetssection, enter a time target for each metric and ticket priority.
See回复时间指标to learn more.
Note:The minimum target time you can set is one minute. You can enter hours, minutes, or both. - In theUpdate targetssection, enter a time target for each metric and ticket priority. It's recommended to use only one of the two update time metrics.
SeeUpdate time metricsto learn more.
- In theResolution targetssection, enter a time target for each metric and ticket priority. It's recommended to use only one of the resolution time metrics.
SeeResolution time metricsto learn more.
- If you'veset a schedule,select either calendar hours or business hours forHours of operationfor each priority.
- ClickSave.
The SLA policy is created.
If you have existing SLAs, the newest SLA is added to the bottom of the list. The order of your SLA policies determines how they areapplied to tickets.
To make your policies most effective, you should roughly order your policies with the most restrictive policies at the top, and your least restrictive policies at the bottom (seeOrdering SLA policies).
Community tip!Mat Cropper shows how to set up SLAs so the correct policy is always applied inRunning triggers, automations, and reporting based on ticket SLAs. And Mark Powell shows how to set up SLAs for time zones inUsing SLAs with different time zones, contracts, and business hours.
Understanding which SLA metrics you can measure
You can define SLA service targets for seven different metrics, which include reply time, update time, and resolution time metrics.
回复时间指标
回复时间指标help you understand how your team is performing in regards to responding to your customers.
Reply time SLA policies aren’t currently supported for chat or messaging tickets.
First reply time
First reply time is the time between ticket creation and the first public comment from an agent. Use this metric to specify how much time it should take your agents to get back to your customers.
The first reply time target starts when a customer submits the ticket and stops once an agent makes a public reply to the customer. This is the most common workflow and typical behavior. In the example below, the first reply time is a combination of segments A and B:
If an agent creates a ticket on behalf of a customer with an internal note, the first reply time target starts when the customer makes a public comment and ends when the agent makes a public reply. See the example below, where the first reply time is a combination of the segments C, D, and E:
- The first reply time isnotcalculated on tickets if the agent creates the ticket with a public comment. This is because the SLA first reply time target is immediately satisfied. It does not activate or record an achievement.
- If a light agent makes the first comment on a ticket with an internal note, the SLA first reply time target starts at their comment and runs through the next public agent comment.
- SLA first reply time targets for side conversation tickets have additional considerations. SeeDefining OLA policies using internal SLAs and child ticket side conversations.
Next reply time
下一个回复时间是最古老的una之间的时间nswered customer comment and the next public comment from an agent. Use this metric to set the amount of time it takes for your team to get back to your customers.
The next reply time target starts at the oldest unanswered customer comment and stops when an agent makes a public comment. In the example below, the next reply time is shown in segment E.
The following example demonstrates the next reply time as a combination of segments C, D, and E:
Update time metrics
Update time metrics help you set how frequently you’ll keep your customers informed while their issue is being resolved.
Periodic update
Periodic update measures the time between each public comment from agents. Think of this as how often you want your customers to be provided updates from your team.
This metric uses the agent’s public comment as a starting point and resets after each public comment an agent makes. In the example below, periodic update is a combination of segments C, D, E:
Pausable update
Use the pausable update metric as an expectation of how long agents will spend on a ticket. In the example below, the pausable update is the combination of the segments B, D, and E:
The Pausable update metric applies when an agent makes the first public comment on a ticket with a New, Open, or On-hold ticket status. It pauses when the ticket is changed to the Pending status. It resumes when the status is changed to Open or On-hold with either a public comment or an internal note.
Resolution time metrics
The resolution time metrics use the ticket status (or status category ifcustom ticket statuses activated) to determine the amount of time that was spent on the ticket.
Note that while you can choose multiple resolution time metrics, it is considered a best practice to limit your selection to one to avoid confusion.
Resolution metrics always use the status of the ticket for starting, pausing, and stopping, as opposed to comments. The following graphic shows how the resolution time metrics fit in with the lifecycle of a ticket:
Requester wait time
The requester wait time is the combined total time spent in the New, Open, and On-hold ticket statuses.
Requester wait time starts when the ticket is created and stops once the ticket is solved. It pauses when the ticket has a Pending status.
In the example below, the requester wait time is the combination of segments A, B, D, and E.
When you set this metric, consider the amount of time it should take your team to fully resolve the issue.
Agent work time
Agent work time is the combined total time spent in the New and Open ticket statuses.
This metric pauses when the ticket has an On-hold or Pending status.
In the example below the agent work time is a combination of segments A, B, and E.
When you set this metric, consider how much time an agent should spend on a ticket.
Total resolution time
Total resolution time is the total amount of time it should take to resolve a ticket, including time in a Pending status. It measures the entire lifecycle of a ticket, from when it's created until when it's solved. It doesn't pause on any ticket status changes.
Best practices for using metrics together
You don’t need to set a target for every metric in an SLA policy. The example below illustrates all the metrics and how they overlap:
- First reply time is straightforward and a good starting point if you’re not sure of which metrics you want to hold your team accountable to.
- Pick only one resolution time metric: Requester wait time, Agent work time, or Total resolution time.
- It is possible to have both next reply time and periodic update time metrics active. Your target status will display the metric closest to becoming breached.
Reopening tickets effect on an SLA
- First reply time, Next reply time:如果一个票重新开放了a public end-user comment and all conditions are met, the relevant Reply Time metrics activate new targets.
- Periodic update, Pausable update:如果一个票重新开放了an end-user comment, nothing will happen. If a ticket is reopened with a public comment from an agent, the relevant Update metrics activate new targets.
- Agent work time:This metric reactivates the same target with the same amount of time elapsed/remaining, and it treats the time in Solved status like a pause. If the ticket goes to Pending/On-hold status, it will remain paused until the ticket goes to Open status.
- Requester wait time: This metric reactivates the same target with the same amount of time elapsed/remaining, and it treats the time in Solved status like a pause. If the ticket goes to Pending status, it will remain paused until the ticket goes to Open/On-hold status.
- Total resolution time: This metric reactivates and continues to count from the ticket creation time.
95 Comments
HeyMaribeth Toleco! I know it's been a while since you posted, but the behavior your agent was seeing does sound odd! I think this would require a deeper look into your account and with that agent, so if they are still experiencing this please reach out to ourSupport teamso we can assist further!
HelloWhitney! There are three possible ways to create a side conversation at this time: email, Slack, and ticket. If you are creating side conversations with the ticket option, you can set up SLAs/OLAs following the example in this article:Defining OLA policies using internal SLAs and child ticket side conversations. Since the other two methods of side conversations create threads that aren't actually tickets, we can't determine which SLA policy the conversation would meet and thus can't capture SLA information. That being said, we are always looking for ways to improve our system, so I would highly recommend posting your feedback and use case to ourGeneral Product Feedback topic!
Super excited for the "total resolution time." However, is there any way to get the SLA to pause when the ticket is on hold?
Hello Holly,
不幸的是,没有办法暂停的SLA"Total Resolution Time" metric on any status change. As mentioned in its definition, "It measures the entire lifecycle of a ticket, from when it's created until when it's solved. It doesn't pause on any ticket status changes."
Hi,
When we receive a ticket the SLA is 8 business hours, but the system is adding the Periodic Update to SLA and it is increasing the time for agents to give the first reply.
Do you know why it is happening?
Thanks.
Priscila.
Hi Priscila,
I've gone ahead and created a ticket on your behalf to investigate your issue further. Please check your email.
Thank you.
Pleasesign into leave a comment.