Service Manager has different classes of work items for which SLAs can be configured. This recipe will show how to set up SLA management of the Incident class for two common SLA categories, First Response Time and Resolution Time.
You should be familiar with the following recipes:
- Creating SLA metrics
- Creating priority queues
- Configuring business hours and non-working days
- Creating Service Level Objectives
- Creating management packs to save your SCSM personalization in Chapter 2, Personalizing SCSM 2016 Administration
The following steps will guide you through the process of creating the incident management SLAs.
Perform the following steps in this order:
- Creating Priority Queues: Repeat the Creating priority queues recipe until you have a queue for each priority. Usually, this will be five queues for Priority 1 - 5 Incident types. Each time you create a new queue, ensure that the name, description, and value for priority change to reflect the priority.
- Configuring business hours and non-working days: Only one calendar is required based on the hours/days that you provide Incident Management services to your customers.
- Creating SLA metrics: Use the example in the recipe for Resolution Time based on Created Date and Resolved Date.
- Creating Service Level Objectives: Create a SLO for each priority; usually, this will be five SLOs for Priority 1 - 5 Incident types. Each time you create a new SLO, ensure that the name and description change to reflect the priority it is based upon and ensure that the correct priority queue is also selected.
For each SLO, you will need to supply a target and warning threshold value. The following table shows common values that can be used, but it should reflect your organization's specifically defined requirements and/or agreements with your customers:
|
Priority |
Target |
Warning threshold |
|
Priority 1 |
4 hours |
2 hours |
|
Priority 2 |
8 hours |
4 hours |
|
Priority 3 |
24 hours |
12 hours |
|
Priority 4 |
80 hours |
40 hours |
|
Priority 5 |
160 hours |
80 hours |
Perform the following recipes in this order:
- Creating Priority Queues: Keep repeating the Creating priority queues recipe until you have a queue for each priority; usually, this will be five queues for Priority 1 - 5 Incident types. Each time you create a new queue, ensure that the name and description change to reflect the priority. You may have already created the queues for the Resolution Time SLA configuration. You can reuse the same queues; do not set up new queues based on the same priorities just with new names for response time SLAs.
- Configuring business hours and non-working days: Only one calendar is required, based on the hours/days that you provide Incident Management services to your customers. Again, the same calendar used for the Resolution Time SLA configuration can be reused.
- Creating SLA metrics: Follow the recipe, but instead of using Created Date and Resolved Date, this time use the following:
- Start date: Created date
- End date: First Response date
- Creating Service Level Objectives: Create a SLO for each priority; usually, this will be five SLOs for Priority 1 - 5 Incident types. Each time you create a new SLO ensure that the name and description change to reflect the priority it is based upon and ensure that the correct priority queue is also selected. Select the First Response Time metric you created in the previous step.
For each SLO, you will need to supply a target and warning threshold value. The following table shows common values that can be used, but should reflect your organizations specifically defined requirements and/or agreements with your customers:
|
Priority |
Target |
Warning threshold |
|
Priority 1 |
30 minutes |
15 minutes |
|
Priority 2 |
2 hours |
1 hours |
|
Priority 3 |
8 hours |
4 hours |
|
Priority 4 |
16 hours |
8 hours |
|
Priority 5 |
24 hours |
12 hours |
By defining the different parts that make up your organizations requirements and tying them together with a SLO, Service Manager now enables you to model your SLA requirements and keep track of how the service is performing. The ability to measure when incidents are nearing or have breached their SLA allows for escalations to be put in place, preferably before a breach, and for notifications to be sent to those people that need to be informed.