SLA Best Practice

[Keith Ciupak]

Hey All, I am begining to setup SLAs for a group of support teams (60+) that have never used any form of service level management in the past. My understanding of SLAs is to focus on the customer perspective. Response and Resolution times should stay running from start to finish as this is what the customer is expecting regardless of the number of tmes a ticket may get passed from team to team. No pauses or restarts as a ticket moves from team to team. 

My question: Is this the common way you are setting up your SLAs or are you restarting clocks as a ticket moves around? Are you using a universal SLA for the entire company or individual SLAs by team? 

I know we can configure many diferent ways based on how the various levels of leadership wants to use the SLA data. My goal is to ensure it is used to best track the service level provided by the organization and keep the focus on the customer expectations. My challenge is leadership does not know what they want or how it should behave so I am attempting to build the baseline foundation for them to start with.

Your thoughts or exapmles on common practice for start/pause/stop conditions and behavior is much appreciated.

Thx

[Dan O Connor]

Hey @Keith Ciupak so definitely sounds like the first challenge here is your leadership/stakeholders do not know what they want. SLA's shouldn't be just a tick the box exercise to say you have them. They have to provide meaningful value in terms of monitoring and enhancing user experience along with translating to valuable metrics for your Services.

It is also worth remember what SLA stands for - Service Level Agreements. ITIL in recent years defined SLA's underneath Service Level Management. 

SLA's I find too often are being looked at strictly at a team level, and people forget it's about Services you provide users or customers. 

If you are looking to draft a proposal, have a look at our Out of the box incident based SLA's. They are structured based on priority and have response and resolution times. These follow ITIL recommendations and ServiceNow best practice. 

- A response SLA is the measure of how long it took for an Incident to be acknowledged and assigned for work.

- A resolution SLA is the measure of how long it took for an Incident to be resolved. 

SLA's can be structured in many different ways. As you correctly state the user isn't concerned with re-assignments, they just want to know when the issue is resolved. However it can be important to be tracking those re-assignments if you are capturing metrics on a team level.

This is where the structure and design of the SLA's is going to be important.

Is your business' interpretation of SLA's something to create at a support team level, or Service level?

Do you have a well populated Service Catalog and/or CMDB?

Are SLA's being reviewed as a support function as a whole?

Are there third party vendors involved you wish to track?

Having a clear plan and design is going to important to implementing good SLA's that can be maintained and managed. Unfortunately there is no real answer to give here, as it somewhat depends on what you and leadership in your business want to achieve. 

As a starting point, I'd look at the below

1) How are you defining Services. Are your Incidents using our OOTB Service structure, or are you using Categories?

2) Identify your top 5 more important/critical services

3) Implement Response and Resolution SLA's for these services.

Run with these SLA's for a while and iron out any issues that arise. Once you are comfortable with these and they are working well and returning value, it's simple enough to then roll out SLA's for the rest. 

I think the most important part again, for any SLA design is the design itself. Identify and agree how you are going to structure them. Review ITIL recommendations, look at our OOTB setup. Our SLA setup is very flexible so you have options.

As a final thought, if you have never used SLA's before, why not just use the OOTB ones? They will apply to Inicidents regardless of Teams, and will provide a good starting point to see how it works and the sort of metrics you get back 

[Keith Ciupak]

@Dan O Connor Thanks for the insight, Dan. I have been working with leadership to begin using SLAs and building for them now. I was tasked with this effort as the previous owner left the company. Dealing with some lack of planning obstacles that were not originally addressed........They are wanting these implemented asap so I can begin my work with Performance Analytics. Thus the quick foundation startup so they can make some progress on identifying their long-term solution SLAs. I do not see any OOB SLA definitions in the app to look at to review. Perhaps a content pack ws missed??? I would prefer to set them up with OOB before any customizing. Where can I find these?

Also, do you recommend using one SLA for everyone? As it should be focused on the service and not the team. Should we start with just Incidents or is there OOB for Change Requests, Catalog Tasks……Enough to create these too, but don't want to overwhelm the managers when we want to gain their buy in.

Sounds like a best practice is to start with perhaps our service desk team and get them running smoothly before activating for all teams.

[Dan O Connor]

So if you navigate in the platform to Service Level Management - Service Level Definitions you should see the OOTB setup. This requires ITSM to be enabled. 

Worth clarifying terminology. Change and Tasks arn't a Service in this regard. Example of Services (the services you provide end users) would be things like Printing, Email, Single Sign On, Desktop Services etc. There is no SLA's related to Tasks, Change requests etc. Like you could, but I don't see why you would.

So this was my point above, as part of your design you need to understand if you want to structure SLA's based on Services, or if you want to structure them in the sort of legacy method of by teams. 

As a simple start I'd maybe identify who of your 60groups constitute Service Desk(maybe its all 60) and then create basic SLA's against the Incident table.

SLA Response - Priorities 1-4 (Thats four SLA definitions)

SLA Resolution - Priorities 1-4 (That's another four SLA defintions)

The 1-4 means you are setting different SLA's based on the priority of the incident. 

[Keith Ciupak]

Makes sense. They want it structured by teams so creating the SLA for Incidents by Priority is what I am planning to do. One Resp/Res SLA by priority for all teams to share, no need to build for each team, correct? I don't think we will want to generate new SLAs when a ticket bounces around. Would like to collect data on the start to finish of the incident as a whole and not each teams touch.