“The aim of Zen practice is to discover [this] Buddha-nature within each person, through meditation and mindfulness of daily experiences. Zen practitioners believe that this provides new perspectives and insights on existence, which ultimately lead to enlightenment.” —Wikipedia
As silly as it sounds, the way to master service levels is to draft them over and over. Yeah, this is the same way to get better at anything, contracts especially. But service levels are a little special. I think it’s because they’re going the way of the Dodo. As few people ask for them, even fewer know to even think about them. It’s the same cycle that increases the quality of service levels – just in reverse. Pirsig’s book was focused on trying to define “quality” and in the end, he settled upon a mix of rationality and romanticism.
I said before that service levels have to be SMART: Specific, Measurable, Attainable, Relevant, Time-Bound. We’ll blend the rationality and romanticism as we go.
Specific – Service levels start with an understanding of the exact quantities of some metric. This could really be anything, but tempered with the next quality, you have to be able to count it. Typically, we start with things that are time-related: uptimes and downtimes, repair times and fix times. Rationality wins here almost every day (the truly romantic notion is that service levels aren’t needed at all because everything’s going to work out as planned) – these things are really easy to measure… and frankly, ease of measurement is necessary because the folks who will be monitoring the service levels aren’t really interested in tracking them. But why not be a little romantic, too? Pick something unique about the particular situation. Maybe you’re licensing software that processes transactions (so you’d count the transactions processed), or maybe you’ve hired an outsourcer to answer your support calls and service levels could be managed based on the number of successful versus unsuccessful customer service resolutions.
Measurable – This might seem obvious, but you’ve got to be able to measure what it is you’re going to base any metrics upon. Just counting isn’t necessarily enough. Rather, you might need to be able to track start/stop times/days (and then do the math to calculate the difference). If the calculation is manual, you also need people who can keep track. This, perhaps, is the most problematic part of any service level management… as the folks who want the benefits of the service level (usually managers) are not the people watching the clock or experiencing the outages first-hand (the staff). So unless the staff has some sort of reason to monitor the metric accordingly, none of this is going to matter.
Attainable – I promised you before that the Myth of the Nines would come back into your life, and here it is. The simple truth is that Five-9 availability is a pipe dream. 5.26 minutes of downtime a year. Just think about how long your average PC takes to power-cycle. Servers are typically a little longer. Even with redundant systems, backups, high-availability resources and every other techincal resource… it’s just not reasonable. Notice I didn’t say that it was impossible. It’s 100% possible. You can have 100% availability. The issue is cost. No one ever wants to PAY for that kind of availability. Not even your most demanding customers. Wanna’ test this theory? Price it out from your vendor(s) (as it’ll take more than one to keep even a single service up 24/7/365) and ask your most demanding customer if they’ll pay for the ENTIRE service themselves (since that’s the real cost to get it). Let me know if they’re willing to do it, because I have a bridge or two to sell them. Seriously, I’m not trying to be facetious. I’m a pretty demanding customer myself, but even I know and understand financial limits.
Relevant – Tied to measurable and specific is that each of your service level metrics be relevant to whatever service you’re receiving/providing. So if you’ve chosen to measure successful versus unsuccessful customer service resolutions, but it’s not tied to the behavior of the service provider, that’s not a relevant metric. The provider doesn’t have any control over what is being measured, even with perfect behavior. So where is their incentive to work towards meeting the metrics (or agreeing to them in the first place)?
Time-Bound – Service levels are limited to time. At first, this sounds quite limiting, but we’re not talking about time in terms of the length of the relationship (service levels should extend for the entire length of the relationship). Rather, the time we’re talking about here is the time frame in which each metric will be measured. So, perhaps you’re watching uptime on a daily basis… or the number of widgets produced in a week… or the number of successful service calls completed in a year… or the average length of time it takes to fix a problem of a given severity level over the span of a quarter.
OK, so now that you’ve considered all five requirements, you should have one or more appropriate service levels. If you still need some ideas, check back with me for the next installment. Meanwhile, if you have some ideas for inclusion in the next installment, send them along!