Stop Playing Whac-a-Mole With Your SLAs

I’m so tired of hearing PSA implementers, coaches, and IT service providers saying, “We have to focus on the SLAs so that we never break one!” That’s actually really a bunch of very backwards B.S.

Where do the PSA implementers get it from? They get it from the PSA vendors. Where do the coaches get it from? The PSA vendors backed with a possible firsthand bit of success at actually keeping SLAs wrangled. Where do the IT Service providers get it from? I think you know, but I’m going to say it anyway. They get it from the PSA vendors, implementers, coaches, and their own internal feeling that they need to hurry up and fix the clients' sh!t.

What is this SLA thing anyway? The SLA is supposed to be an agreement between the vendor (IT service provider) and the client on how fast we will “get on it” when something comes up. In big-boy and girl businesses, you actually find language in the agreement about discounts for the client if you don’t hit your SLAs and bonuses to the vendor if you consistently do. But in small and micro businesses, there is no such language. I don’t know if it’s because no one told the small IT business owner how these things are really supposed to work or because it would be too confusing to try to explain (and sell) to the similarly small clients they have. But that’s how the SLA is supposed to work. I can assume these people have relied on this thinking because they have never known another way to approach it.

So what if you focused more energy and efforts on optimizing the service process, the end result of which would be tighter SLAs and higher Customer Sats? My experience has shown me that when you focus on driving Lead Time (time from New Ticket/Issue/Incident to Closed) and Cycle Time (time from first In Progress to Closed), you end up with response times that are far better than if you run around opening every new ticket just to stop the clock.

One important problem with chasing SLAs that many (if not most) providers don’t quite get is how having too many tickets open, relative to the total number of tickets in the system, at the same time actually increases the queue length in front of every team member, the lead times of tickets, and the pressure on the team.

And then there is the cost of context switching for the techs and the stale conversations with the client. Have you ever had a client call and say, “Yea, so-and-so called me a week ago to get my password, and I never heard back, and no one has fixed my thing.”?

Think about it this way - Prove that, on average, you can meet a particular level of service. Not relevant to what your competition claims they can meet, but one that you can, in fact, deliver on. Then boast the hell out of it on your website and in your newsletter and marketing. Own that score! Then sell that score (with a proper contingency time padding) knowing that you will almost always be well in front of the SLA. Continuous incremental improvement will also drive it down.

Oh, and your techs will be a lot happier... and that’s invaluable! :)