SLAs (Service Level Agreements) enable you to set goals for handling tickets, and make it easy for your agents to track them.
These goals might represent a formal SLA with a client who is paying for a certain level of support, or just an internal quality standard.
Tickets that are close to failing the goal (you define what is considered ‘close’) enter a warning condition, and tickets that exceed the goal have failed.
There are two effects of SLAS:
- Tickets close to or failing an SLA are highlighted in the agent interface: tickets on warning are edged amber, tickets that have failed are edged red.
- SLAs can run automatic actions to modify the ticket on warning or failure.
One ticket can have multiple SLAs applied. The worst state will be the one highlighted in the agent interface.
Creating an SLA
Create a new SLA by going to Tickets > SLAs and clicking Add.
Set Type to decide whether the SLA tracks:
- time until first response
- time until ticket is resolved
- user waiting time until ticket resolution (total)
You can use Hours to set whether time should be counted 24x7 (continuously), during default working hours (as defined in Tickets > Settings > Default Working Hours), or during custom hours that you define.
Define an SLA Warning time (when the ticket is considered close to failing) and a SLA Failure time.
The value you enter in SLA Failure is the total time elapsed, not the time since the warning.
For example, if you set a warning time of 6 hours and a failure time of 8 hours, the failure will happen 2 hours after the warning. It doesn’t make sense to have a failure time less than the warning time.
These times are always counted from the point at which the ticket was created, not when the SLA was applied. For example, if you set a failure time of “8 hours until ticket is resolved”, then manually apply the SLA to a ticket that’s 9 hours old and unresolved, the ticket will instantly fail the SLA.
If you set an SLA to run during working hours (default or custom), and set a warning or failure time in days, DeskPRO will interpret “1 day” as “24 working hours”. This means that it can take two or three real days for “1 day” to elapse.
Suppose your working day is 9 hours long, and a ticket comes in first thing. The first day counts as 9 hours on the ‘elapsed time’ clock, the second day counts as another 9 (bringing the clock to 18), and the ticket fails on the third day, after another 6 hours elapse and the required 24 working hours have passed.
If you want an SLA to count “one working day”, set it to the length of your working day in hours.
You can define actions that run automatically at warning and at failure. For example, you might want to increase the urgency of a ticket that is about to fail an SLA, or assign the ticket to a more experienced team.
Click the + Action button under SLA Warning or SLA Failure to add actions that will run on warning.
Use SLA Application to set which tickets are affected by the SLA:
- Apply to all tickets: this applies the SLA to all tickets created from now on (not existing tickets)
- Agents manually apply the SLA: agents apply the SLA from the SLAS tab of the ticket
- Apply to new tickets that match certain criteria: you can enter conditions that tickets must meet for the SLA to apply.
A new SLA that’s applied automatically (to all tickets, or that match certain criteria) will only apply to tickets that are created after you make it.
Setting SLAs with triggers
You can add or remove SLAs with the Set SLAs trigger action.
This action is useful if you want to link an SLA to the value of a different ticket field.
For example, suppose you want to apply ‘Resolve in 1 week’ SLA to tickets with ‘Standard’ priority, and ‘Resolve in 1 day’ SLA to tickets with ‘Urgent’ priority.
You use the SLA Application to apply each SLA to new tickets with the appropriate priority, but what if the priority of an existing ticket is changed?
The solution is to create a Ticket Update trigger for each priority to change the SLA:
You also can change the state of SLAs with the Complete SLAs trigger action.
This enables you to instantly cause a ticket to complete an SLA, fail it or go into warning state.
Different SLA response times for weekdays and weekends
Suppose you have to fulfill an agreement to provide a 4 hour response time for tickets that come in during the week, but a 12 hour response time on the weekend. How can you track that using an SLA?
The answer is to use two separate SLAs - one that is applied if a ticket is created on a weekday, and one that is applied on the weekend.
You can use the SLA Application section to do this. First, create the weekday SLA:
Then a complementary weekend SLA:
This solution can be improved. If a ticket comes in at 11:55 on Friday night, you probably don’t want the 4 hour SLA to apply. You can make the weekday SLA only apply until 7pm on Fridays:
Of course, if you do this, you should then change the weekend SLA so it starts at 7:01pm on Fridays.