Loading...
 

Should we force everyone to manage to the SLA deadline

By ITIL® from Experience ©

Many ITSM and ITIL® experts believe that the secret to good customer service is simply to deliver by the SLAs1 deadline.

Many Service Desk and operations managers would like this since measures and controls for Service Level Agreements (SLA) are easy to implement:

  1. Get senior management's buy-in (see Do we need CIO support to succeed)
  2. Have clients to sign their SLA (see We need SLAs. Should we start with Service Level Requirements)
  3. Load the SLA values loaded in the ITSM Tool
  4. Create reports from the ITSM tool (see Is there a book to help us develop Key Performance Indicators (KPI))
  5. Finally, get management to have some "teeth" to enforce the SLA (see What does it mean to have CIO and management support).

However, experienced professionals understand that managing to the SLA clock is only one ingredient to a great customer service recipe.

Many businesses are wildly successful by carefully managing customer expectations and relentlessly communicating during the fulfillment process. Take Amazon for example. They under promise and over deliver while continually informing their customer on the progress or changes to the delivery date. Its true that their Prime program is an SLA nonetheless, they have been, and continue to be, successful without it.2

Managing to the SLA results in the organization focusing on itself. When IT focuses inwards instead of outwards, it no longer centers itself on its customers consequently; it will take action to benefit itself usually at the detriment of client.

It also corrupts team work. Once management focuses on measuring SLA breaches people quickly find creative ways to avoid breaching their SLA or Operational Level Agreement (OLA)3. People quickly use the "stop-the-clock" feature, re-assign the ticket to another team or to the client by simply asking a question which may not even be relevant to the incident or service request (e.g. please confirm the version you are using). It’s like playing "hot potato."4 People throw the ball into the other's court as quickly as possible so that they are not the cause of the SLA breach5.

Some suppliers also play this game. The infamous statement: “It is in / is not in the contract/SLA” which typically leads to animosity and a sour relationship with the service provider.

As a result, an attitude of "I did my job by the book" creeps in the culture of the organization at the expense of doing the right thing for the customer (see You had one job). It’s the equivalent of a doctor saying: "the operation was a success but the patient died." Needless to say, the patient may want the operation to be a little bit less successful and still be alive! Patients more easily accept and understand challenges when they are continually informed of a changing situation (and it goes a long way to avoid lawsuits). The same goes for a pizza. Clients would prefer a properly cooked pizza in 45 minutes with a polite delivery driver rather than a half-baked pizza in 30 minutes simply to honor the SLA. The point here is that it is more important to set client expectations and to quickly communicate changes than to blindly attaining the SLA thinking that customers will undoubtedly be happy.

Forcing people to manage to the SLA clock is managing to a micro-metric. It is an easy pitfall to manage to a micro-metric at the expense of the macro-metric of customer satisfaction (i.e. KPI)6. In other words, managing the task instead of focusing on the outcome.

A metric is like a dial in a plane's cockpit. A plane’s cockpit has many dials and being on time is only one metric. The pilot does not simply look at the clock to make the trip a pleasant one. Thus, for success, it is better to manage to the overall client’s experience and satisfaction than to the SLA clock and for management to stay away from an SLA witch hunt.

Close the ticket and open a new one.

- Why? The work is not done

Yes, but this way we don't breach the SLA

Last updated on: 2018-10-09 Published on: 2018-10-01

Quote:
Improvement by criticism do not result in lasting performance improvements

More Quotes

Related:

More on Service Level Management

From Around the Web:

Category: Implementation > People ITIL Process > Service Level Management (SLM)


1. Service Level Agreement (SLA): (ITIL® Continual Service Improvement) (ITIL® Service Design) An agreement between an IT service provider and a customer. A service level agreement describes the IT service, documents service level targets, and specifies the responsibilities of the IT service provider and the customer. A single agreement may cover multiple IT services or multiple customers Source: ITIL® glossary and abbreviations, 2011 https://www.axelos.com/Corporate/media/Files/Glossaries/ITIL_2011_Glossary_GB-v1-0.pdf
2. Without Prime, Amazon can still be considered to have an SLA. The expected delivery date of each product that the client accepts (“signed”) by placing their order can be deemed an SLA.
3. Operational Level Agreement (OLA): (ITIL® Continual Service Improvement) (ITIL® Service Design) An agreement between an IT service provider and another part of the same organization. It supports the IT service provider’s delivery of IT services to customers and defines the goods or services to be provided and the responsibilities of both parties. For example, there could be an operational level agreement:

- Between the IT service provider and a procurement department to obtain hardware in agreed times - Between the service desk and a support group to provide incident resolution in agreed times.

Source: ibid
5. Several ITSM tools have a feature to send an email alert when a ticket has been reassigned too many times (e.g. Axios assyst and Marval MSM). Thus, this behavior is prevalent in many organizations.
6. We know of an IT Service Desk manager that made a rule that every ticket had to be updated daily. Agents quickly learned that adding “No updates” to every ticket got the manager off their backs. Needless to say that time to resolve tickets did not improve.

Disclaimer


Copyright 2018 - ITIL® from Experience - D.Matte