Example SLA configurations
Here are some example SLA configurations and workflows.
Basic SLA
This example looks at how you might create a very basic SLA for a service project with a basic workflow:
- All highest priority and blocker issues must be resolved within 24 hours.
- You provide 24/7 support for certain customers (these issues are labeled with 24h).
- You provide 9-5 support for all other customers, but you don't track SLA metrics for them.
Set the following conditions:
| Condition | Value |
|---|---|
| Start | Issue Created |
| Stop | Resolution: Set |
Set goals in the following order:
| Issue | Goal | Calendar |
|---|---|---|
| priority = Blocker OR priority = Highest AND labels = 24h | 24h | Default 24/7 calendar |
| priority = Blocker OR priority = Highest | 24h | Sample 9-5 calendar |
| All remaining issues | No target | Sample 9-5 calendar |
SLA that doesn’t track continuous time
This example looks at how you might create a more complex SLA by pausing the time counter during the workflow:
- Support wants to complete all issues within 40 hours.
- Time spent waiting on the customer doesn't count against the 40 hour goal.
Set the following conditions:
| Condition | Value |
|---|---|
| Start | Issue Created |
| Paused | Status: Waiting for customer |
| Stop | Resolution: Set |
Set the following goals:
| Issue | Goal | Calendar |
|---|---|---|
| All remaining issues | 40h | Default 24/7 calendar |
SLA with multiple cycles
This example looks at how you might create a more complex SLA by starting and stopping the time counter throughout the workflow.
- Support wants to respond to Service requests within two hours: this includes responding within two hours when the issue is created, as well as each time the issue is updated with more information from the customer.
- All other issues have a response time goal of 24 hours.
You might set up an SLA like this to track response times (for example, how long it takes your team to respond each time a customer updates an issue with more information). This example also illustrates how goals for different issue criteria can be tracked from a single SLA.
For further information about how SLAs with multiple start and stop conditions appear in the SLA tracker, see Setting up SLAs.
Set the following conditions:
| Condition | Value |
|---|---|
| Start | Issue Created, Entered status: Waiting for support |
| Stop | Resolution: Set, Entered status: Waiting for customer |
Set goals in the following order:
| Issue | Goal | Calendar |
|---|---|---|
| Issuetype = “Service Request” | 2h | Default 24/7 calendar |
| All remaining issues | 24h | Default 24/7 calendar |
SLA based on due date
Here's an example of how you might create a more dynamic SLA by pausing the time counter until a specified due date has passed.
- Support want to complete all hardware requests within 24 hours.
- They want to pause the SLA until they receive the hardware from their supplier (on the expected due date), then unpause the SLA when the due date has passed.
- All other issues have the same response time goal of 24 hours.
Set up an SLA like this if your team can't begin their work until a date in the future. For example, setting up a workstation when a new hire starts.
For this SLA to trigger, configure the Due field to display on the Issue type screen, and set the Due field when the issue gets created. Learn how to set up issue type fields
If the due date is not filled when an issue is created, time is counted from the next condition in the list. That is, time from when the issue was created and the SLA isn't paused.
Set the following conditions:
| Condition | Value |
|---|---|
| Start | Issue Created, Due Date: From Empty |
| Pause on | Due Date: Not Passed |
| Stop | Resolution: Set |
Set goals in the following order:
| Issue | Goal | Calendar |
|---|---|---|
| “Customer Request Type” = “Request New Hardware (CTF)” | 2h | Default 24/7 calendar |
| All remaining issues | 24h | Default 24/7 calendar |
