CoreITSM 101: Call a call a call

Contract and SLA negotiation is always an interesting experience., especially when they've already been signed, which is when I usually end up getting involved.

Here is a typical scenario. The original negotiations have been intense, both side think they've got what close to what they want. The big guns have sorted out the sexy clauses. What nobody has noticed is the time bomb lying in wait. Nobody has noticed it because they think it is something they all agreed on, and anyway it is trivial and obvious what the contract means.

What is the time bomb?

It is the clause about the volume of activity that the service desk will handle.

You see for all the good stuff about service strategy in ITIL v3 it is the simple stuff that trips us up time after time. Like saying "calls" when we mean "incidents" or "incidents" when we mean "requests" or...well it goes on, and ITIL, for all the talk of providing a common vocabulary, doesn't always help.

Let me give you a couple of real world examples of the chaos that can be caused both by not using the right words and by not understanding the implications when it comes to setting performance targets and penalties.

An organisation that should know better - not least because it claims to sell ITIL consultancy - outsourced their Service Desk in a separate contract to their main outsourcing deal. The contract specified the number of incidents the Service Desk supplier was supposed to handle and the target time to answer and first time fix rate.

What the supplier did not realise was that the customer considered the number of incidents to be both a target in itself and independent of the other metrics.

Think this through.

The Service desk supplier has limited control over the number of incidents it has to handle. It has rather more control over the number of calls, but we'll save that for the second case. The number of incidents is driven by the underlying quality of the service. In this case they were also classing requests as incidents, and requests are driven by service demand, which again is largely out of the control of the Service Desk.

So we have a supplier being judged against a target that is almost entirely out of their control.

Needless to say the underlying quality of service was not there, and a rapidly changing business model meant large numbers of requests. As far as the customer was concerned this was all the Service Desk's problem.

It goes without saying that handling 25% more incidents the Service Desk struggled to meet the targets for call answering.

Result?

The customer invoked the penalty clauses against the Service Desk provider.
The customer did not renew the Service Desk provider's contract.

The tragedy is it what was a really, really great Service Desk.They were performing miracles to handle the extra calls and stay within budget - a budget that also had to take the hit of the penalty payments.

OK, I hope most people wouldn't be so profoundly stupid, would they?

Case number two is more understandable.

The customer's in house IT had always provided a good basic service and whilst the internal Help Desk wasn't the greatest on the planet it fulfilled the "log it and flog it" role quite well, and because they were good at pro actively informing the user of what was happening the ratio between calls and the combined total of requests and incidents was pretty much 1:1. Unfortunately they didn't really track the difference between incidents and requests. I'm sure you do though, don't you?

For really good reasons they outsourced both the IT infrastructure and the Help Desk to the same supplier, and combined it with a massive change in technology.

In the contract they specified how many calls the service desk should be able to handle.

The supplier did a validation exercise and agreed on the number of calls being dealt with prior to the handover.

This isn't the place to discuss why the technology shift didn't work out as planned, but it didn't.

What is important is that because in the past there had been a 1:1 relationship between calls and incidents/requests the contract only specified expected call volumes.

So what happened?

The technology didn't work, so there were lots of incidents. Because there were so many incidents the desk got overwhelmed, so any pro-active communication went out the window. As a result the number of calls per incident also shot up dramatically to something like 3 calls per incident/request.

The supplier blamed the customer for generating more requests, although they weren't tracking the ratio of requests to incidents despite it being a contractual obligation.

The customer blamed the poor quality of service and the lack of communication back to the users.

And I invoked the penalty clauses and cursed whoever had signed the contract.

It wasn't pretty.

In this case there was happy ending of sorts because a period of stability proved that the customer had specified the call volumes to be expected with a stable service and that the desk the supplier provided could cope with those volumes.

But all that pain could have been avoided if there was a clear understanding of the differences between calls, requests and incidents.

Next we will look at the use and meaning of call, incident, request, ticket, alert and event with an emphasis on their importance in producing meaningful management reports