You’re sitting down to a service review with your outsourced provider at the end of a dreadful month that has involved a number of Major Incidents that have had significant business impact.
Reviewing the core operational metrics, you are surprised to see, once again, that the outsource provider has miraculously met all their SLAs, and the service is recorded as being green.
You question these results based on your knowledge of the number of major incidents that month, and are reliably informed that the SLAs are based on metrics taken directly from the Service Management tool, and therefore aren’t wrong.
So what is going on? You are being beaten up by the business for the level of service being provided, but there doesn’t seem to be anyone responsible.
Later in the review you are presented with statistics on the age of incident and request tickets. Despite clear guidance that there should be very few tickets over 30 days old, there seem to be a significant number.
You query these numbers and are again told that the figures come straight out of ITSM and that the majority of these tickets are in a pending state.
Again, what is going on? Why are so many tickets aged over 30 days.
In both cases we are experiencing the bane of all service managers, especially those who have to deal with outsourced providers, the clock stop.
The theory behind the clock stop is that it is designed to ensure that IT are not held accountable for an SLA breach that it is not responsible for or has control over. By stopping the clock, the SLA counter is paused until the clock is restarted. This means that the recorded SLA reflects the actual time that IT were responsible for the ticket.
There are challenges with this approach, not least of which is stopping the clock when raising a ticket with a third party supplier, only for it to be identified that the issue wasn’t with the supplier. Frequently tickets are raised by an outsourcer, with suppliers, and clocks stopped, just because a support agreements are place. This removes the pressure on the outsourcer to deliver to the SLA .
The use of clock stops means that the measurement of the SLA does not reflect the actual business impact, and can mask the responsibility for a breach of SLA.
So how can clock stops be addressed?
There are options. The first is to ensure that there are two measurements taken, the first reflecting the actual time of the business outage, the second the length of time that IT (or the outsourcer) worked on the ticket. This doesn’t actually resolve the issue of the incorrect use of clock stops though.
The second is to contractually ensure that the calculation of the SLAs reflect period of business disruption, and where the responsibility for the breach actually lies. Therefore, if the responsibility for the breach lies with a supplier, then IT (or the outsourcer) is not seen as being in breach of contractual SLA, but is of business SLA. Whereas if the responsibility sits firmly with IT (or outsourcer), regardless of how long the ticket was with a supplier, the SLA breach remains with them.
Whatever you decide to do, when dealing with the measurement of SLAs, be aware of the dangers of clock stops and the impacts that they can have on dealings with outsourcers, and the message that you provide to the business.
If you would like to find out how iCore can help you with your SLA management, then contact us on 0207 868 2405 or email firstname.lastname@example.org.