SLA is nothing new to any service provider. Everybody (well, almost) has at least one, with their clients. Of course there are those who say we don’t have SLAs as our customers didn’t ask for it.

While drawing up an SLA, a service provider are exposed to, and very often falls into traps like:

  • Going with the “Standard” SLA (standard to whom?)
  • Agreeing to what customer asked. (Customer is the king!)
  • Taking over ‘existing’ SLA from current service provider (typically as part of transition in outsourced contracts)
  • Adopting ‘best practices’ from industry!!! (best practices on SLA targets?)

One cannot emphasize enough, how important it is to have a closer look of each SLA parameter that you are going to commit ( or in many case, have committed already!).

Each of the SLA parameters need to be assessed (BEFORE committing to or agreeing with customer) for aspects like:

  • Does the parameter really reflect what is important to the customer?
  • How important this parameter is, to the service and to the customer/users?
  • Does the service provide has capabilities in place to provide those levels at the current cost/pricing framework?
  • Can the parameter be quantified?  (Quantified parameters are measured on data, Qualitiative are measured through perceptions!)
  • Can this be measured? (feasibility, having the right tools, resources, time)

There could be many such aspects added into the assessment, but the above would give a good starting point.

Let me take a couple of examples (kind of funny, but actual scenarios that I came across) to illustrate the need of such an assessment:

1. This organization was having a metric/target combination as below:

% of user requests in a day, handled within SLA . Target 99%

Which simply means they need to handle 99% of the requests that are received from the users in a day within SLA.

This metric and target doesn’t make sense, unless there are at least 100 requests they are getting in a day (which they didn’t have! The maximum no. of requests they were getting was 10!!)

2. The business got tired of email bouncing/delivery errors related issues. They demanded an SLA on that front, from IT (of course for the part which is under the control of IT. In other words, if the email is bouncing or failing because of the issues on the other side, it is not counted in SLA).

After a long analysis and debate, IT proposed an SLA as:

% of emails committed for successful delivery : 99.9%

Business didnt accept it! Why? Because of the simple fact: if  there are on an average 50000 emails that are sent in a day (which this organization had), this SLA meant that 50 emails can bounce/fail!

3. This organization took over Service Desk operation for a client with the following SLA parameter:

  • Acknowledgement time for all user logged tickets:  within 5 min.

They were continuously meet this SLA (100% tickets meeting SLA), till the  client realized that the service provider had configured the tool itself to send auto acknowledgement, once the ticket was logged!

4.  This outsourced provider were responsibile for managing 20 (almost identical) servers of a global customer with a 97% uptime commitment.  The customer organization asked them to come up with a summarized SLA reporting , rather than giving detailed uptime report of each server separately. This provider came up with a one-line report to client:

Average uptime of 20 servers for the last month was: 99%.

Though looked fine initially, customer realized the trap: 19 servers were up 100% of the time; while the remaining one of the server was down for 20% of the time!

I am sure there are many such examples (tricks, traps, misinterpretations) on SLA definitions.  Would be nice to hear about more…