SLAs and Service Agreements

The original ITIL books defined a Service Level Agreement (SLA) as follows.

A written agreement between an IT Service Provider and the IT Customer(s), defining the key service targets and responsibilities of both parties. The emphasis must be on agreement and SLAs should not be used as a way of holding one side or the other to ransom. A true partnership should be developed between the IT provider and the Customer, so that a mutually beneficial agreement is reached, otherwise the SLA could quickly fall into disrepute and a culture of blame prevent any true service quality improvements from taking place.   — ITIL: Best Practice For Service Delivery, Office of Government Commerce, 2001.

The last decade has seen ALOT of hype about Service Level Agreements, or SLAs – every service and everybody has to have one. Empirically, one may find such a device to be very important but maybe not for the exact reasons one would expect from reading the media. One should classify services agreements into two categories: that which is offered to IT from its vendors (ITIL calls these “underpinning contracts”) and that which IT offers its customers. The latter can just as or more important to the IT manager.

Most of the advice from the media and professional associations centers around SLAs from big vendors offering services of network uptime, data center uptime, or product support. Written service expectations are essential in these scenarios; however, on some occasions they do not carry the significance you would think. Unless you are a big, big customer, do not expect too much remuneration for failure to meet an SLA. And even in larger companies and it is surprising how little pull one has with vendors, except maybe around contract re-up time.

Using SLAs to actively set expectations to IT’s internal customers is likely a more productive discussion. Often many tend to use the term “service agreement” rather than “service level agreement”. Some organizations do not want to use the term “SLA” as they feel it infers a legal commitment. And in fact, used in this context, it is not a legal commitment. Service agreements are a vehicle for the IT manager to set expectations of their customers. They are a point of reference to staff around, plan maintenance around, and budget around.

For example…

  • Until expectations for a 30 minute response time are put into writing, it’s difficult for the IT manager to justify that extra headcount for a support tech.
  • Until expectations for a monthly maintenance window are put into writing, it’s going to be difficult for the IT manager to solicit downtime from customers to perform patching.
  • Until expectations for uptime are put into writing, it’s going to be difficult for the IT manager to get that redundant server/circuit/data center into the budget.

And if IT does not create service agreements for the items it services, its customers will assume the same service level for everything, i.e. HIGH PRIORITY. A revenue generating e-commerce application crashing late Saturday night may be worth waking up and rallying the support staff, but an accounting or reporting application going offline may not be. Having a service agreement for each goes a long way to preventing customer satisfaction issues before they happen. And it may be that a call to a VP or CIO will force the support team to go into a weekend SWAT mode, but still, the IT manager has set the expectation that this is above the normal call of duty… that is an extra cost to the organization.

Services agreements are indeed more paperwork and more back-and-forth negotiation and approvals. But sooner or later they will come in very, very handy for the IT manager.

Maybe the most difficult part of creating service agreements is deciding what to include. Here are some examples.


<<–Back to Process