The binding nature of SLA

The cloud business brings some very interesting and unique characteristics in the way customers and vendors are engaging: For the first time in computer history massive amounts of data are processed and stored outside the physical boundaries of the enterprise (its LAN or WAN). Also, vendor companies can reside thousand miles away from the customer premises and they are run by people that most probably the customer will never meet in person or maybe even talk on the phone.

These unique characteristics make the customer/vendor relationship very interesting and also somewhat difficult to describe. Such relations are typically governed by the Service Level Agreement (SLA) which the customer signs or in some cases just “accepts” with the click of a button on the web page of the cloud service they’re subscribing to.

Many times there is no option to “discuss” or “negotiate” such a document the way an “end-user license agreement” was negotiated in the past, when a piece of software was “sold”. Customer may or may not accept the terms (and move on to the next available choice). This very fact builds pressure on customers to accept a document that perhaps it does not find them exactly in accordance and also to vendors to come up with a collection of technical and legal terms that are “safe” for them but also not “intimidating” for the customers: something that can persuade customers to get on board the service instead of driving them away. These two “opposite forces” tend to reach some kind of equilibrium and this post investigates what this equilibrium point is.

One way to describe the customer/vendor relationship is to have a very detailed SLA, defining all possible outages or out-of-service conditions and that’s what many customers are looking for. But I would argue that the more detailed an SLA is, the more safe it may become for the vendor, leaving the customer uncovered (or, better, inadequately covered) in some cases. How can this be? Here is an example: The customer asks for specific provisions when there is data loss in the cloud service. This raises the question of what will the vendor’s obligation be for damage caused by such data loss? Obviously, it can’t be a number many times larger than the yearly fee that the vendor collects, otherwise the vendor has built a high-risk business, which makes no sense. And then, it can’t be a number too low, otherwise the customer doesn’t have adequate insurance for their data. In the hypothetical case where the SLA does not provide anything for this case, then the customer might ask for astronomical figures making the case that the data loss has seriously damaged its business. The vendor, on the other hand, could argue that they owe nothing to the customer, since the SLA did not include any specific clauses. A real mess in the customer/vendor relationship, I’m sure, and a real deal-breaker. But what is the mitigation for such risks? Perhaps a very detailed SLA that includes specific provisions for each distinct case? I wouldn’t agree that fast! You see, analyzing every little detail will work not only for the customer’s benefit but also for the vendor’s. The vendor might use these clauses to limit their risks to an absolute minimum. So, it is probable that in the above example of data loss, the vendor is obliged to offer some discount or re-imbursement on the next invoicing period and they are “off the hook”, that easy.

The point here is the following: A very detailed SLA covering all possible cases of risk, quantifying each and every small detail is not the “holy grail” of customer/vendor relationship that all customers should seek. Instead, customers should also look for other ways to make sure that their selection of vendor is correct, like investigating the “word of mouth”, asking for real-life references, and in general performing due diligence on the vendor selection process.