How to become a smarter buyer of cloud services

Cloud seems to promise transparency in cost, service effectiveness, and support, but after years of interviewing buyers - from both IT and line of business roles - of software and services, I've seen firsthand how complicated and confusing it can...

Share

Cloud seems to promise transparency in cost, service effectiveness, and support, but after years of interviewing buyers - from both IT and line of business roles - of software and services, I've seen firsthand how complicated and confusing it can be for them to evaluate SaaS and cloud services.

Smart customers will familiarise themselves with how to read and evaluate the SLA, understand the LoL, and have good expectations about the provisions - what the customer gets back in compensation if the provider defaults on its promises.

After years of interviewing buyers - from both IT and line of business roles - of software and services, I've seen first-hand how complicated and confusing it can be for them to evaluate SaaS and cloud services. These buyers may fully understand the KPIs and functionality they need, and usually can pinpoint a price, and term, that works for them, but they struggle with effectively managing risk at the time the sign the contract, because they often don't understand the give-and-take of the SLA, and specifically, the contractual limits of liability (LoL).

Cloud seems to promise transparency in cost, service effectiveness, and support, in part because the social web has become a sounding board for customer experiences, both good and bad. But while prospective customers may hear about service downtime, a poor support experience, or functionality falling short, they rarely hear about specific contract terms, "customised" SLAs, or "street" price (versus MSPR). Customer expectations about lower total price for multi-year commitments, and lower total cost for buying more seats, or committing to a higher rate of transactions, are often not the reality.

Customers will often try to rewrite the SLA provided by the supplier, rather than struggle to understand its sometimes-confusing terms. In the past few years especially, providers - themselves struggling with customers which seek legal review for SLAs and comparison-shop for terms, have made great strides to simplify SLA terms and actually provide evidence - comparisons with other providers, for example - that they are offering a good deal. The smart thing for customers to do is to familiarise themselves with how to read and evaluate the SLA, understand the LoL, and have good expectations about the provisions - what the customer gets back in compensation if the provider defaults on the SLA in a way that goes beyond the LoL.

What's In an SLA?

Generally, an SLA is a contract guaranteeing for the minimum acceptable levels for the availability and quality of a service. It specifies terms such as:

  • Uptime (service availability)
  • Downtime (within 30 mins, 60 mins, etc etc)
  • Provider-based latency (usually part of "per-transaction" billing, but generally means slow internet - hard to prove it is the SaaS providers' fault)
  • Physical location of data (key to maintaining sovereignty for compliance and audit purposes)
  • Loss of data (usually measured by data table) and Breach of data
  • Timing and prior notice for planned system maintenance
  • Problem response and resolution times
  • Physical and virtual security of the data centre
  • IT support and customer (user) support
  • Transparency/availability of service uptime reports/analysis

Is there flexibility in "negotiating" an SLA or a LoL?

While providers typically have built boilerplate SLAs with legally-prescribed limits on their liability, the larger ones have a heterogeneous set of customers and when dollars are on the line, there is room for negotiation in some things, such as time-to-response (TTR) on support calls, data audit services and long-term data storage, et cetera. So the short answer is, yes, there is absolutely room to move the bar in some areas.

For every kind of IT capability that exists, there is (or soon will be) a service-delivered counterpart, and so there is tremendous variability in delivering on the one hand, a complex financial accounting package, and on the other, an instance of a test environment for building a new web application. Availability of a highly-transaction service, like consumer-facing call/contact centre software, or eCommerce software, is measured in fractions of a second, during peak periods, whereas email services can have message delivery tolerances of up to 2 seconds.

Your provider will know what they are capable of and they will very likely be within acceptable standards of service fulfillment, and the business model of a cloud service is that every "tenant" on the system gets a standard/similar experience, but customers also know what they need to get from their applications, and within reason there is often room for bargaining.

What happens if things go wrong?

Most customers will go through life happy with their cloud provider and will experience only mild service interruption or cause for complaint. Most - we estimate 75% - of times that providers fall short of their SLA commitments, it is the provider notifying the customer of the lapse, not the other way around. But sometimes things go awry, and there are definitive remedies built into the providers' limits of liability LoL to satisfy customers.

Most providers build specific damages into the SLA, in the form of both service credits, and, for serious infractions, payment or repayment of cash. Most problems around availability are taken care of with service credits - either for more time on the system, access to different premium tiers of functionality (ie, new modules, new reports) or stepped-up support, or some combination. In some bases service credits just extend the customers' contract for a term - a day, a week, or more - without additional cost. Providers are very careful to spell out how availability (aside from agreed-upon maintenance intervals) is to be measured -x% uptime per week, month, or quarter, for example, so they can have flexibility in meeting the specified target.

The LoL for each will be highly variable, and emerging SLAs make provisions for LoL to be different based on the spectrum of infractions to the SLA as listed above. When a more serious problem arises the LoL will provide for some share or multiple of annual contract value (ACV) to be awarded, in lieu of or in addition to service credits. All are tied to annualised ACV as a "unit of measure", and we've seen everywhere from 1/12 ACV (for slow support) to 4x ACV (for serious data breach resulting in loss of over $x business). The norm is about 2x ACV, an amount which supplies more than adequate incentive for providers to take their terms very seriously.

Posted by Robert Mahowald VP SaaS and Cloud Services

Enhanced by Zemanta

Find your next job with computerworld UK jobs