Things to consider when defining SLAs, OLAs and UCs

General Add comments

In addition to a blog I have written two years ago about defining SLAs in this blog I want to go a bit deeper into the things to consider when you start defining your SLAs, OLAs and UCs. I hope this blog will give you some guidance.

Types of Agreements
First of all, why are we agreeing SLAs: these agreements are used to ensure that a pre-defined set of expectations and services are delivered in time. These expectations and services could be between the business and IT, inside the IT-department or between an IT-department and its suppliers.


Lets start with some definitions:
Service Level Agreement (SLA) – Level 1 support

ITIL definition: An Agreement between an IT Service Provider and a Customer.

These are the agreements an IT department or company has with the end-users (end-customer). What can the end-user expact in terms of service delivery when they report an issue or order a new laptop.

In other words: Measure and monitor the performce of the IT department against the agreed terms and conditions.

Typical examples of SLAs are:
· Reaction time per priority
· Resolution time per priority

Operational Level Agreement (OLA) – Level 2 support
ITIL definition: An Agreement between an IT Service Provider and another part of the same Organisation.

So, these are the agreements within the IT department or with other parts of the organisation. Important note is that the OLA must always support the SLA (see the chapter ‘Make all Agreements Fit’).

Typical examples of OLAs are:
· Response time on incidents when assigned to another team
· Time needed to come up with an RCA
· Lead times for certain changes

Underpinning Contract (UC) – Level 3 support
ITIL definition: A Contract between an IT Service Provider and a Third Party (vendor/supplier).

Obviously these are the agreements between the IT department and its suppliers. The difficult part in these agreements is to make sure that UCs supports both the OLAs as well as the SLAs.

Things to Consider:
Make all Agreements Fit
Too many times I see agreements that simply won’t fit! In other words, when defining SLAs with your business, make sure that the OLAs (with internal IT departments) and UCs (with suppliers) will fit the windows in you agreed in the SLAs.

Example: If you agree with your business that a priority three ticket will be resolved within three working days make sure that the agreement with the supplier responsible for delivering the service is also three working days, or even better, two working days to give you some slack.
Make crystal clear when you are delivering a Service. Will you deliver a service 7×24 or just working hours like 5×12 or 5×8. And do all services have the same schedule?

When you’re not delivering a 24×7 service in a large multinational company keep in mind that some countries have different weekends, Friday and Saturday instead of Saturday and Sunday.
Also make sure to include bank holidays. Are you sure you deliver a service on a bank holiday when you agree a 7×24 service?

Example: If, next to e.g. The Netherlands, you also deliver a 5×12 service to Abu Dhabi, keep in mind they are probably working on Sundays, meaning your employees must work in shifts spread over 6 days to cover both The Netherlands and Abu Dabhi.

Working Days or Calendar Days?!
There’s a big difference between working days and calendar days. Especially off course when you’re not delivering a 7×24 service but e.g. a 5×8 service. Just mentioning days in your agreement will lead to unnecessary unclearities and discussions.
Time Zones

With companies working in different time zones you should define in which time zone you are delivering a service. A 5×8 window in Los Angeles is really different then a 5×8 window in Amsterdam. Are you following the time zone of the end-users location, the IT-departments location on even maybe the CI location.
Not to Complex
Please, KISS (Keep It Simple Stupid). Try to define generic SLAs. Don’t end-up into a bowl of spaghetti with different SLAs for different services for different users for different locations for different priorities with different schedules with a different color etc. etc. You will most definitely get lost.

Make sure that your tool supports to display what you agree on and that you can ‘easily’ pull information out of it to create reports. You really shouldn’t be needing any additional resources just to create your SLA reports… J

If you have any questions, please don’t hesitate to drop me an e-mail on .img[at].img

Leave a Reply