Recently, a consultant for whom I have a great deal of respect asked me what I thought about wireless SLAs. I said it seemed like a strange concept to me, although I'm certainly familiar with SLAs in the landline and operational worlds. But the consultant who asked knows his stuff, so I decided that it was worth a deeper dive.
The problem is that wireless service is inherently unreliable. It works--and works well--most of the time. But the key word is "most." Further, when it fails, it fails miserably, as a result of power failures, atmospheric conditions or a host of other factors that are often beyond the control of the entity providing the SLA. As Frank Sinatra famously sang, "That's Life." And because wireless service can be so unreliable, wireless SLAs can wind up being so permissive as to be just about meaningless.
On the most basic level, an SLA is designed to provide a customer with some level of assurance that the service being ordered will work as promised by the eager salesperson. More specifically, customers have come to expect SLAs to define acceptable operational parameters. The expectation is that the network/system/device will function as promised 99.5% (or some other suitable percent) of the time. With any luck, as the end user, you'll never have to rely on the SLA or read its very small print to find out what steps are necessary to make good on it in the event of a network failure.
For their part, vendors and the lawyers drafting SLAs recognize that the true purpose of these documents is to provide some level of assurance to concerned consumers. Make no mistake, the SLA was created largely as a marketing tool--no matter what the technology. It's a kind of insurance policy that the product or service being ordered will work as intended (sort of.)
But even if a service provider offers an SLA primarily as a marketing strategy, it still promises a certain level of performance, which you have a legal right to expect. So, whatever great promises are made before the deal is signed, the critical question becomes: What factors can defeat/neutralize/invalidate promises made in an otherwise seemingly "friendly" SLA?
First and foremost, it's the small print. For these purposes, I would define the small print as including two essential components: the steps that need to be taken to invoke the SLA, and the list of those events/conditions/circumstances that the SLA doesn't cover.
Consider the following language that was taken from a major provider's wireless SLA:
XXX does not commit to a specific performance level for the radio network parts of the Service, and this part of the Service is not covered by any SLA. Radio network performance is provided on a "best [efforts]" basis.
The bottom line here is very simple: If the public wireless portion of the network (read: the transmission portion) fails, the vendor who has offered this SLA is off the hook. The vendor is correct to not promise what it cannot deliver--but given this very large exception, why even bother having an SLA?
In another section, the same vendor included the following paragraph:
Achieved throughput depends on the availability and load of the radio network used for any specific communication instance. Thus, XXX does not provide a committed level of throughout and throughput is not a part of XXX's SLA to the Customer. Throughput is provided according to best effort...
Bluntly speaking, if throughput isn't part of the SLA, what is? And if the standard is "best effort," how can that be quantified for the purpose of enforcing the SLA?
The second series of land mines often buried in an SLA involves the required steps to be taken by the customer to invoke the SLA, and the defined time period during which qualifying troubles can be reported to ensure that proper credit can be given when failures do occur.
In most, but not all cases, a call to the local account exec to notify him/her about the issue will not do the trick. It behooves any network manager to be familiar with the terms of the SLA to ensure that proper contact is made within the required time (generally a set amount of time from the outage) and to the right place as defined in the SLA to secure the credits that may be due.
Conclusion
Service and equipment providers exist in a highly competitive marketplace. Each one has its own strengths and vulnerabilities. If an SLA makes a customer feel more comfortable about its vendor choices, it is a good thing. An SLA is an insurance policy, but it's only useful if what fails is covered. The devil really is in the details.
Thus it's essential that should the existence of an SLA be the deciding factor in making a vendor choice, the SLA be read with a critical eye to the fine print. Check what's written not on page 1, but on page 7. With any luck, an enterprise will never need to invoke the SLA for any reason. But if the network's down, the enterprise user's knowledge of what's covered and what isn't is essential.
