We’ve been discussing Service Levels for the last few weeks. We covered construction, setup, drafting and even some recommendations on how the Service Levels might look. But what happens in the event that the Service Levels aren’t met (they’re “blown”)?
We should start with a review of why we sought Service Levels in the first place – which is usually because you really just want what you’ve been promised in terms of service or performance. In this case, remedies for blown Service Levels should be two-fold: 1) to get service restored as quickly as possible, and 2) to recompense for any damages caused as a result of the blown service level. So you’ve probably even drafted the Service Level metrics so as to put a lot of importance on fewer outages or less downtime – with significant financial penalties. But you don’t really want the money, you want great service. The net result is that in the event of a blown Service Level, you probably won’t enforce the financial penalty… it’s more bark than bite. But you are a stickler for responsiveness and attentiveness, and you will enforce the remedies if you feel that not only have the Service Levels been blown, but that you’re getting ignored, too. This is justifiable.
But maybe you’ve got a little more jaded view and you already know that you’re not going to get exactly what was promised. You drafted the Service Levels with really tight controls – trying to count every little thing (without regard to what’s really important) in the particular deal. You instead feel that software or services are exact sciences and that if the vendor is silly enough to make a promise, you should get everything you’re “entitled” to. The result is that at the first hint of a blown Service Level, you’re on the phone with the vendor asking for service credits (never mind restoration of service).
Personally, I hope you’re in the first group of folks and not the second. Software and Services, by their nature, are going to have hiccups. This is just how it goes. Even older, established products can have difficulties (environments are constantly changing). So instead of trying to beat the vendor with your contract, you use the contract strategically to make sure that you’re getting what is really important to the deal … and not some sort of small financial benefit for each blown level.
However, there are times where it is absolutely justifiable to use the contract as a sword and a shield. One of these cases is what’s known as “death by ducks” – the situation where you have many small Service Level issues. None of them, on their own, would be worth enforcing as a true blown event. But together, you get pecked to death by the small things because they cumulatively add up to a significant performance issue. Here, you should have anticipated this issue and have a small extra section in your Service Level language detailing the remedies available in the event of x number of small issues that add up to a certain Severity Level. Heck, you can even define it as a certain number of Sev3’s = a Sev2. And a certain number of Sev2’s = a Sev1. How would you handle it?