|
Contact Us! |
 |
What is a "Gotcha?" It's when you don't see something in a contract or don't think it through and it comes back to "get you." Professional negotiators claim to detest gotchas. However, both ASP buyers and sellers succumb to the temptation of using the "Gotcha' Model" because the technology is new, the marketplace is chaotic and the stakes are high. For example, one of the most common 'gotchas' is availability metrics, where engineering meets marketing. |
The first two articles [see Part One and Part Two] of this series examined where service level agreements (SLAs) come from and what they often fail to cover. We shall now address why providers make huge, sweeping promises--such as 99.999% availability rates--and why those promises often prove to be meaningless contract "gotchas."
In any business deal, when things go wrong, customers tend to place the blame on their vendors. This tendency especially proliferates within information technology (IT) deals. The IT industry has a long, consistent history of sweeping promises accompanied by slow or missing follow-through. This makes IT customers understandably skeptical when faced with new, rapidly growing players in the IT industry, such as Application Service Providers (ASPs). While these points certainly ring true in many circumstances, customers also share responsibility for the equal proliferation of unreasonable, inflated, essentially meaningless SLAs.
ASPs and their customers face serious challenges when negotiating Service Level Agreements (SLAs.) The typical ASP deal encompasses a bewildering array of variables: changing technologies, broad ensembles of providers, shifting market share and the ever-present drumbeat of hype. These variables often make negotiating a realistic SLA virtually impossible.
ASPs face cutthroat competition, ever-rising customer expectations, changing business models and the demands of their venture capitalists and other investors. Customers learned some hard lessons from earlier, highly publicized Enterprise Resource Planning (ERP) project failures. Executives and shareholders now demand and expect tangible benefits, increased reliability and lower costs from IT. Both sides believe that the ASP model provides a strategy to satisfy these demands. Both sides want concrete, meaningful measurements upon which they can base appropriate service levels.
Unfortunately, meaningful statistics remain in short supply.
Concrete service level metrics rarely reflect the actual impact of excellent or poor service on a customer. Negotiators prefer them because of their ease of use and the fact that they provide the illusion of hard and fast guarantees. Under any circumstance, at the completion of negotiations, both sides can point to columns of pretty numbers in their contract.
Many ASP SLAs prove virtually meaningless. They are vague as to the actual operation of the ASP model, relying on their hollow numbers as well as failing to address the actual business needs of the customer adequately. These metrics prove equally meaningless from a business and legal perspective, because they are so complex and difficult to change that customers fail to enforce them.
Most ASPs, given the extreme difficulty in determining user requirements, offer a "one-size-fits-all" SLA model. This is fine, just so long as the customer understands in advance that they are not getting specific, absolute guarantees. In order to accelerate acceptance of the ASP model, however, some ASP negotiators phrase narrow, technical details as broad-sounding promises, which can mislead non-technically oriented customers.
An example of this can be found in the most commonly used metric in any SLA--availability. Here we encounter a critical difference of opinion between technical and business experts. Most business experts would define availability as, "the application delivers services as promised, during the hours promised, in such a way as to enable the business function supported by that application."
Such a broad definition would horrify most ASP providers. They tend to prefer something along the lines of, "availability is based on a series of packets traversing the ASP-controlled network from the telecommunications access point, through servers, back to the telecommunications access point, measured using X analyzer set on Y settings with 99.999% reliability."
Naturally, the ASP sales and marketing team drops everything but the last two words, "99.999% reliability". Non-technical business people like the 99.999% part, but feel bewildered when confronted with the detail behind the number.
Telecommunications companies pioneered what we can call the "Confusing Detail School of Metrics." "Confusing Detail" (CD) occurs when a customer can only comprehend the service metrics if they have extensive, specialized technical knowledge. CD focuses on single measurements with no context and few real-world causes or effects. This may or may not be intentional. Taking a skeptical view, CD started out as an honest attempt to meet every need with a measurement, but the concept has morphed into a tool used to avoid responsibility.
Non-technical business people often assume that if their company contracts for voice telecommunications services, availability means that they get a dial tone when they pick up the phone. This simplistic assumption elicits peals of laughter from telecommunications negotiators. The reality of technical contracts is far more complex and remains impossible to "boil down" into a single operational test. Most ASPs, especially those with a telecommunications background, present incredibly detailed metrics designed to protect themselves from shorthand promises made by their marketing departments.
|
Remember, the clearest, fairest metrics in the world become meaningless if irrational Force Majeure provisions or the actions of a third party invalidate or suspend the SLA. Address these issues before delving into the technical discussion of how to measure performance. |
Why does service measurement get so complicated? As in many negotiated arrangements, both the buyer and the seller share culpability.
Buyers--ASP customers--anticipate and expect performance that matches the blanket promises made by the ASP. Buyers insist that the text of the SLA reflect their perception of their purchase. Unfortunately, many buyers go beyond this reasonable insistence, demanding that the SLA address expectations that exceed even the salesperson's promises. Why does this happen? Scores of answers emerge, ranging from lessons learned in past IT deals to the fact that a buyer executive overheard that a competitor negotiated a stratospheric level of protection.
The latter "me too" cause is common and remains very difficult to resolve in negotiations. If a buyer executive believes that a better standard of coverage may be available for the asking, the ASP finds itself in a predicament. Unreasonable expectations are most likely to become an issue when the buyer does not fully understand the technical details behind service and protection requirements, but insists on 'maximum coverage' anyway. While this may seem unreasonable, sellers must understand that if the buyer does not get that "me too" protection, their CFO may want to know why. If a major failure transpires and a mainstream business magazine mentioned the same issue months before the negotiation, the project leads will enjoy a tough session with their executives. After this happens once or twice, buyer negotiators will strive to get everything into the ASP SLA.
Sellers--the ASPs--become trapped by ever-expanding customer expectations. The ASP must agree to buyer demands in order to make sales, maintain current market share and survive in a rapidly consolidating marketplace. Sellers accept that customers will always demand aggressive SLAs in a new technology or industry sector. As such, in this market, ASPs have to either agree to hyper-aggressive SLAs, gambling their business on the hope that nothing will go wrong, or miss an opportunity that could keep their company on the map. It is not surprising that many elect to take the gamble.
Sellers then attempt to mitigate their risk by writing SLAs that contain numerous "outs," ensuring that service levels--especially those backed by cash remedies--reflect areas they actually control. The best example of this behavior concerns ASP internal networks versus third-party "partners." ASPs will usually make firm, clear guarantees about their own network and servers. They become vague and look for cover when the buyer expects them to be responsible for third-party networks that they cannot control. This attempt to mitigate risk is often quite fair, but it puts the ASP at odds with their in-house sales and marketing efforts. If, for example, a salesperson promises the buyer a "seamless experience," they build an expectation in that buyer's mind. When that expectation runs up against risk-limitation efforts in the ASP SLA, it calls the salesperson's credibility into question.
"99.999% availability" guarantees exist as a classic example of reducing a very complex idea--in this case, an IT SLA--to a shorthand marketing number. The difference between a 99% guarantee and a 99.999% guarantee equals the difference between a maximum of 87 hours of annual downtime vs. 5 seconds. This becomes a useful negotiation ploy if the ASP intends to divert attention from other issues, such as whether their product is any good in the first place. Customers gain illusory satisfaction by negotiating an apparently unreasonable number--87 hours of annual downtime--to a fantastic number--5 seconds. This satisfaction distracts customers from other, harder questions while giving the ASP the appearance of agreeing to a rigorous, fantastic standard.
No ASP can honestly promise 5 seconds or less of total downtime per year. They do genuinely promise that unplanned downtime caused by factors within the ASPs control will be held to the agreed-to standard. This number usually does not cover routine, forecasted downtime for provisioning, maintenance and telecommunications work. Downtime outside the provider's control, including telecommunications outages, customer or third-party server or software problems and malicious attacks on the customer's systems also exist outside of the SLA's coverage.
Many ASP customers claim to believe that this 99.999% guarantee exists as a "come hell or high water" promise. Most know better, but believe that they can force ASPs to deliver a higher quality service by taking this unreasonable position. On the other side, ASP executives, many of whom come from an IT customer background, know that buyers are doing this. Such gamesmanship adds to the climate of suspicion in an industry where trust is already in short supply. The most dangerous customers are those who do not view 99.999% availability as a marketing number and bet their business on it.
|
This author believes that most providers would be happy to fully explain their metrics, but feel afraid to do so because they might lose business to less honest competitors. Any IT business that tries to be honest can miss opportunities and so they keep quiet. The result is that in most small-to-medium sized (SME) enterprises the CIO ends up explaining to their fellow executives what a vendor's 99.999% guarantee really means. This usually happens around the second or third planned outage--for maintenance and telecommunications work--or the first unplanned outage caused by a factor that suspends the SLA. |
While availability guarantees form a critical part of the ASP delivery model, they often rely too heavily on outside factors to be a valuable indication of whether the ASP itself idoes a good job. Some of the best, most reliable ASPs look foolish to customers because of shoddy performance by a customer-selected telecommunications company. ASPs that fall into the trap of focusing on availability while soft-pedaling the external factors find that their customers have built up unreasonable expectations. Unless the customer understands up-front that failures outside the ASP's control invalidate the guarantee, they will be unhappy to learn this fact during a high-visibility outage.
Continually stretching to meet unreasonable customer expectations will eventually break any business. Building up and then failing to meet customer expectations may discredit the ASP model and potentially cripple the industry.
IT salespeople are used to customer negotiators who demand ironclad guarantees and 100% uptime. This position is not unique to the ASP model; data center and enterprise software segments have dealt with it for years. A classic salesperson response to this position is to ask, "What service level do you get today?" Customers very rarely have an answer, because they do not measure internal service levels. Some customers believe, without any serious substantiation, that they have a world-class IT infrastructure and staff. Often, an outsourcing arrangement like ASP is the first time the customer is faced with the fact that they are not as world-class as they thought.
Enlightened customers examine what it takes to make the ASP model viable and look at the supply chain allowing the ASP to function. This type of customer's first question is not, "How can I make them give more?" It is, "How can they stay in business while giving me what I need?" The best deal in the world is useless if the vendor cannot make money and goes out of business. Be wary of providers that offer incredible terms in their contracts. If they are offering them to all their customers, they may not have the business acumen to be in play for the long-term.
ASPs must present a realistic picture of the costs, risks and benefits of the ASP model. Customers must evaluate their actual costs of doing business in a fair, equal environment. Only when both parties negotiate in an open, realistic and cooperative manner can a model such as ASP really work. Trying to make ASP work under the "gotcha model" will be impossible.
A brief word on performance guarantees. Most ASPs base their service level agreements on availability and performance. "Availability" means that the application is accessible when promised. Performance means that the ASP will ensure that sufficient computer power is available so that the application is useful for its intended business purpose.
So far, so good.
Customers run aground with performance guarantees if they fail to realize the external factors affecting the speed and reliability of ASP-hosted applications. If the customer's internal network, telecommunications company or applications vendor/integrator does a poor job, a performance dispute with the ASP will usually result.
The organization that wants to use technology only to cut costs is often an organization that has cut corners in the past. This is not a surprise; many outsourcers discover that their customers have inadequate networks, poor software compliance and unreliable internal support--often the primary reasons why the customer chooses to outsource in the first place! Ironically, such customers also tend to be the most aggressive when negotiating SLAs, demanding stellar quality, reliability and service at rock bottom prices. A good rule of thumb for ASPs, if a prospect does not know how many servers they have, but demand NASA-level service guarantees, storm clouds will shadow the deal from day one.
So, how can we rationalize SLAs and make them easier to understand and manage?
Buyers and sellers must agree that any SLA metrics that they use need to work in a simple, consistent way, so that all parties to the SLA understand. Each metric must directly represent a business need of the customer that the ASP believes they can fulfill. If a particular metric does not fit this principle, find another metric. If the negotiators cannot find a metric that satisfies this principle, the issue may simply be Confusing Detail.
When negotiating SLA terms, buyers must realize that if they do not understand a term, it becomes virtually impossible to enforce. Today, some unscrupulous sellers take full advantage of this--creating SLAs with great remedies, but with incomprehensible metrics. To step back from the brink, negotiators must address Confusing Detail SLAs with a business process model, rather than a strictly engineering model.
To reiterate: if non-technical business people cannot understand a measurement, do not expect a judge to. If a judge cannot understand it, then odds are that a judge will not rule that the contract be enforced or honored. If the contract is unenforceable, then all of the terms and conditions the customer entrusts its safety to prove meaningless.
|
"Continually stretching to meet unreasonable customer expectations will eventually break any business. Building up and then failing to meet customer expectations may discredit the ASP model and potentially cripple the industry." |
A healthy movement exists in service levels, metrics and even remedies in the ASP model. The challenge for ASP customers remains determining whether the ASPs they evaluate make a genuine effort to provide quality service with guarantees or engage in a dead-end "me-too" marketing battle with their competitors. While ASPs can easily dispense confidence-building numbers, ASPs must meet the true challenge of helping their customers examine their genuine needs and then build SLAs that address and answer those needs.
Key Points
Negotiators often try to implement inflexible, quantifiable metrics in deals where the scope, technology and goals are still vague; this desire leads to vague, essentially empty promises such as 99.999% availability
Faced with an ever-spiraling set of customer expectations, some providers make their SLA measurements so technical, so confusing, as to make it impossible for a non-technical customer to dispute them
If the customer does not understand the measurement and what impact it has on their environment, it is a useless measurement; a measurement that cannot be explained to a layman will be very difficult to explain to a judge
Customers must apply the principles of supply chain management to their ASP, asking, "How can you stay in business if you make these promises to all of your customers?"
Customers need to understand what they hope to achieve with the technology first, then decide what service levels will ensure that achievement; when they do it the other way around, the situation is ripe for a big dispute