News in SCSM12 (Beta) #1 – Service Level Objectives (SLO)

I’m very excited to present the first of many blog posts for the new version of Service Manager 2012!  The Beta is now public and I am now allowed to blog about all the great features that we all were waiting for! Let’s go …

With Service Manager 2012 it is possible to measure the efficiency of your Service Desk. Many companies want to know if Incidents or Service Requests are processed within the defined time frames (Service Levels). The new Service Level Management feature allows us to do that in very detail.

The complete SCSM SM12 (Beta) Series:
#1 – Service Level Objectives (SLO)
#2 – Service Requests
#3 – Automation of Service Requests
#4 – Enable Self-Service for Service Requests
#5 – Parent/Child Incidents
#6 – Release Management
#7 – Connectors
#8 – Permissions for triggering System Center Orchestrator runbooks

In the Administration area you have several objects to configure the Service Management feature. Let’s take a look at those.



With the calendar it’s possible to define a set of hours that you are working with specific tickets. For more important tickets you could use a 7×24 calendar, for less important tickets you could use a calendar that defines the regular business hours. In this example I create a single calendar that reflects the business hours of our company.




Metrics define what exactly to measure. When talking about Incidents, it could be interesting to measure the Incident resolution time or the Incident reaction time. You can create as much metrics as you need and use them later in the Service Level Objectives configuration.



Service Level Objectives (SLO)

Now it’s time to bring everything together. In this example, I want to define a Service Level Objective for all Priority 1-Incidents: they should be resolved within 4 hours and if this is not the case, the Service Level should breach. Let’s take a look at the configuration.


First, define what class objects you are interested. In my case, I’m interessted in Incidents.


Now we have to define what Incidents the new SLO should apply to. In this example I want to apply the SLO to all Priorty 1-Incidents. Therefore I have to create a queue that holds all those Incidents and select the queue here. All other Incidents will not have a SLO assigned. So in a real world scenario you would have a bunch of SLOs for Incidents with specific Priorities, for VIP Users or for Incidents that relate to specific Business Services.


Last, I must choose what calendar and what metric to apply to the Priority 1-Incidents, and I have to define the target time for the resolution as well as a warning threshold.


That’s it. Now it’s time to check the configuration. I created an incident and did not resolve it within the time defined in the SLO. If I open the incident now, a message is displayed immediately telling me that at least one SLO has breached.


When switching to the Service Level-Tab,  you can see the details and the status about the different SLOs that apply to the Incident. Based on the configuration it’s possible that multiple SLOs apply to a single Incident.


To get a better overview, you will find two views to display all Incidents in warning or breached state in a single list.


With this new feature it’s possible to configure your Service Level Objectives in very detail and let Service Manager measure things for you. This is great and a huge step forward from what we had in SM10.

Stay tuned for upcoming SM12 blog posts!

This entry was posted in SCSM and tagged , , , , , . Bookmark the permalink.

31 Responses to News in SCSM12 (Beta) #1 – Service Level Objectives (SLO)

  1. Carsten says:

    Would it be an option to handle multiple customers without having to alter SM via authoring tool?

    • Hey
      It depends what your goals are. Even with SM12, there are no new features regarding multi-tenancy. But you can of course manage multiple customers without any customizations. As soon as the customer itself has access to SM somehow, you may need some modifications.


    • Is there a way of triggering a workflow to monitor the braches and e-mail a SLA manager about the breach?

  2. Pingback: News in SCSM12 (Beta) #2 – Service Requests |

  3. Pingback: News in SCSM12 (Beta) #3 – Automation of Service Requests |

  4. Pingback: News in SCSM12 (Beta) #4 – Enable Self Service for Service Requests |

  5. Pasha Labin says:

    Thanks, great job!

  6. Pingback: News in SCSM12 (Beta) #6 – Release Management |

  7. Pingback: News in SCSM12 (Beta) #5 – Parent/Child Incidents |

  8. Pingback: News in SCSM12 (Beta) #7 – Connectors |

  9. Pingback: News in SCSM12 (Beta) #8 – Permissions for triggering System Center Orchestrator runbooks |

  10. Darryl says:

    Do you know of anyone who has not been able to create a SLO? I have upgraded 2010 and i get an error message and no option but to cancel out….

    I believe i have followed your steps as outlined above?

  11. Darryl says:

    Done already thanks

  12. Ozge says:

    Dear Marcel,

    Thanks for the valuable info. I have created 2 SLOs one with resolved time in order to measure the resolution SLA and the other with assigned time in order to measure the assignment SLA.

    I have created 2 incidents queues.

    For Resolution Time SLA: I set the criteria for P1 incidents and Assigned to SID is not empty. Because I want to measure among the assigned incidents.

    For Assignment Time SLA: I set the criteria of Assigned to SID is empty. Because I want to measured among the unassigned incidents.

    So far everything works fine. However when comes to subscription notification I cannot seperate these notifications. It doesnt allow me to choose the queues so that for only that specific queues the notification should trigger. The criteria I can set is status changed to Warning or Breached. But I have 2 different SLA criteria for different queues.

    Is there any solution to this?

    • Hey

      I did not invest that much time in this area yet. But I have seen this relationship –> System.WorkItemHasSLAInstanceInformation. I have a feeling that this must be used to reach your goal 🙂 Maybe I find some time later to try out. If you find out a solution I would be very happy if you post it here!


      • Conley says:

        Marcel. I am surprised this has not come forward more. I have the same unresolved issue. I created two SLO’s:
        1. P1 Assignment SLO – (warning at 14 breach at 15 – if not assigned)
        2. P1 Resolution SLO – Warning at 1 hour, breach at 2 hrs – if not resolved.

        (For the first 1 i am only interrested when it actually breach the Unassigned SLO, thats why the times are set so close)

        The problem comes in that the first SLO set the status to warning and breach, and there is not way to distinguish when the second SLO reach “warning-status” or “breached” as it has already happenned on the first SLO
        Would appreciate if you can help?


      • Hey

        If you breached the incident at the first assigned time it is breached. Whatever happens afterwards does not matter from an ITIL perspective. At least that’s how I look at it. If you only want to measure the first assigned date but the SLA should not be marked a breached then you should look for a workaround by using SCORCH or a custom workflow.


  13. Maroof Malik says:

    Hi Marcel,
    I am trying tothe find the best way for one SCSM 2012 server to cover UK, US, Singapore, Australia and Dubai time zones. I have techs in each of these locations but can t work out how i can create a queue to differntiate Incidents between these time zones so that i can apply to an SLO.
    many thanks

    • Hey

      There are different approaches. Whithout knowing anything about your processes, environment etc., why dont you add a list property to the incident class called “area” and fill this for every incident? Then you could use this value later to create your queues. Or you could use the city/country attribute of the “Created by” to create the queues. Maybe one of those approaches work for you …


  14. Fixx says:

    Hi Marcel,

    Some background info:
    Currently I have set the default priority to 5, which has a 24 Hour SLO and is set to warn at 4 hours.
    Priority 1 is 2 hours and warns at 1 hours.

    Now I can get into it 🙂

    When a new Incident is created, it is assigned priority 5 (a 24 Hour SLO). If say…20 hours pass and for some reason the Incident is escalated and becomes a Priority 1. The new SLO will immediately breach is it takes it’s time from when the Incident was created.

    Is there any way to configure an SLO to start the clock from when it is applied to the Incident?
    Also, do you know of a way to pause an SLO?

    Any advice, gratefully received.
    Best Regards,

    • Hey

      Sorry for the delay …

      Not sure, but it should be possible to remove an Incident from the queues that you use for SLO (by configuring a specific attribute).


  15. Fixx says:

    Hi Marcel,

    Thanks for the advice, I’ll have a look into that.


  16. Pingback: More transparency in SLO Management by reusing the “Target Resolution Time” field |

  17. hareesh says:

    Hi Marcel,

    Please can you provide, is there any way to pause the SLA clock, when the status changes to pending?

    Thanks in advance,


  18. melba guzman says:

    Hi Marcel,

    How can i get a notify when an service request in on warning state?


    • Hey
      You need to setup a subscription/notification for the class “Service Level Instance Information”. Check out this article for more details >


      • melba guzman says:

        hey, I did. but we still have some problem; we set the notification in work hour 8am to 5 pm but they don´t meet the criteria. we receive warning notification on weekend, on midle of the night but if you check the service request in console everything is ok. thnx

        El Jueves, 23 de marzo, 2017 4:07:10, escribió:

        #yiv6725137305 a:hover {color:red;}#yiv6725137305 a {text-decoration:none;color:#0088cc;}#yiv6725137305 a.yiv6725137305primaryactionlink:link, #yiv6725137305 a.yiv6725137305primaryactionlink:visited {background-color:#2585B2;color:#fff;}#yiv6725137305 a.yiv6725137305primaryactionlink:hover, #yiv6725137305 a.yiv6725137305primaryactionlink:active {background-color:#11729E;color:#fff;}#yiv6725137305 Marcel Zehner commented: “HeyYou need to setup a subscription/notification for the class “Service Level Instance Information”. Check out this article for more details >” | |

      • OK, this is normal because the warning threshold is calculated “breached” minus “warning”. It does not respect the calendar/workhours that is used in the SLO configuration. If you want this to work, you need to create your own workflow that respects the SLO calendar/workhours. Use the Authoring Tool or Visual Studio (better) for this.


  19. melba guzman says:

    Thnxs a lot.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s