|
Contact Us! |
A service level agreement (SLA) without realistic remedies qualifies as a waste of time for all concerned, both during the actual negotiations as well as for the life of the relationship. A well-written contract depends directly on its ability to respond to failure with appropriate mechanisms proactively designed to restore the agreement's integrity. Remedies must answer the question, "What happens if the other side fails to deliver as promised, when promised?"
Unfortunately, most high-tech contract remedies do more damage to the project--as well as the wider business relationship--than either party can imagine during negotiations. Poorly thought-out, hyper-aggressive remedies can liquidate vendor incentive and subtly damage performance.
Negotiators employ many synonyms for remedy: penalty, liquidated damages and--in a telling example of corporate doublespeak--performance incentives. With every different term comes a slightly different interpretation of its definition. With the current media and consultant frenzy surrounding application service provider (ASP) service level management, remedies exist as the least understood component of effective SLAs.
Most customers that consider the ASP model feel concerned by the rapid consolidation of the industry, relative immaturity of ASP vendor offerings and consultants who constantly change their minds about ASP's impact on software licensing. In this environment, customers will not accept the typical software industry, “We will give it our best shot” service promise. Customers demand remedies. They want something to happen if the vendor cannot meet rosy projections or extreme promises. Conversely, vendors respond to this demand inconsistently. This divergence retards any emergence of industry performance standards.
In more mature segments of the information technology (IT) marketplace, such as consulting or application development, customers often fail to secure any substantive remedies for poor vendor performance because deliverables are rarely well-defined by the customer. Both sides also acknowledge that deliverables will likely change over the course of the agreement. Negotiating an effective contract in this group is time-consuming, difficult and requires experts on both sides. Because of this, most IT contracts are left purposely vague, given that a vague contract is difficult to enforce with meaningful remedies.
To lock an effective remedy into a contract, the deliverable must be identified in such specific detail that failure to reach the goal is obvious and actionable. Software, integration and consulting giants build and sustain their empires on the fact that nobody can really spell-out all of the deliverables in a negotiated contract.
The ASP business model appears far more straightforward, at least in its initial form. ASPs claim to deliver applications to the end user in a consistent, reliable, easy-to-manage format. This simplicity, alongside the now well-documented consolidation of the ASP market, enables customers to propose significant remedies during negotiations. The environment remains highly charged though, because many of these current or potential customers turn to ASP as a tool to recover from enterprise resource planning (ERP, the last darling of media and analysts) integration nightmares. These customers resolve not to get "burned" again and demand very stiff, often excessive remedies for failures that may or may not be within any ASP's direct control.
Negotiators tend to push for all they can get in price, quality, delivery or remedies. This confrontational attitude can be useful during simple, early stages of negotiation, but the complex nature of deliverables and remedies requires a very different approach.
While many ASPs offer remedies, rarely does any direct link exist between the remedy and the severity or business impact of the fault. This fact leads to a disproportionate relationship between cause and effect that tends to enrage customers when a performance element fails. An example of this relationship occurs when an ASP offers a one-day credit for an outage that endangered a customer’s main line of business. Many ASPs, especially those with a telecommunications or hardware background, do not recognize the reliance that customers tend to place on any outsourced relationship. These ASPs focus on narrow, engineering-based metrics and remedies, then fail to understand why customers feel dissatisfied with them.
Alternately, ASPs confront a steady drumbeat of "get-this-too" conditions from their customers, usually stoked by experts offering advice and extolling "best practices"--often taken out of context from unique situations. In order to gain attention for themselves, industry pundits repeatedly encourage customers to seek ever more aggressive terms. Subsequently, customers feel increasingly confused about what, exactly, constitutes a "good deal" in this environment. Many customers cease to negotiate contractual remedies for poor performance, instead demanding terms approaching business continuity insurance-- where the ASP guarantees that any failure damaging a customer's business will result in a directly proportionate cash payment.
This article, the last in a series [EDITOR'S NOTE: please see: "What Constitutes a Service Level Agreement?" and "The Forgotten Five" and "The 'Availability Gotcha,' or Why 99.999% Still Equals Nothing"], strives to answer the question "What constitutes an effective remedy?" We begin with how each side views remedies, discuss key points sustaining the principle of effective remedies and conclude with examples of alternative remedies for the ASP business model.
Different players in the ASP game view remedies in different ways. ASPs view remedies as a method to prove the worthiness and surety of their SLA. Customers view remedies as a way to punish the ASP for any failure to deliver as well as to "get whole" after such a negative episode. While both of these perspectives prove understandable, they differ from the professional negotiator's view of an effective remedy. This view considers only those terms that gently encourage top performance by a vendor, while ensuring that the customer also delivers their end of the deal.
If a remedy that looked good during negotiations translates too severely in a real situation, the ASP loses any incentive to perform or--worse yet--is driven out of business. If a remedy is too light, then the ASP might pay the remedy instead of devoting the time and money to fix a problem. Striking the appropriate balance between these two extremes makes negotiating remedies the single most delicate phase of the IT deal.
In the IT industry, many companies offer "fantastic" SLAs with no remedies. Another common trick is the presentation of a "fantastic" SLA with "fantastic" remedies that mask a dozen "gotchas" that invalidate the remedies. Make no mistake, both of these tactics frequently occur in the ASP industry. ASP vendors that hide behind these "phantom" agreements will close a few good deals, but their reputations will always overtake them. Most ASPs, however, want to present a balanced SLA that answers realistic customer concerns, protects customer data and operations affected by the ASP, which also protect the ASP against unreasonable customer demands or expectations.
|
In general, responsible ASPs face two critical problems in offering effective remedies. First, they must be careful about undercutting their viability by presenting a more expensive, less profitable service guarantee than their immediate competitors. Effective remedies can be costly! Small companies, to compensate for their diminutive size or newness, tend to offer overly generous remedies. Though admirable, this tactic can easily drive the ASP out of business. Second, ASPs must be careful not to customize remedies for every customer. A single ASP with 300 clients cannot afford to keep track of 300 different service levels with concurrent remedies. In the heat of negotiation, the administrative cost of performance measurement and compensation is often overlooked. The core competency of an ASP lies in delivering its services, not in negotiating SLAs.
While some ASPs do not include remedies in their basic SLA, they do offer them if the customer will pay extra. What provides the inducement to do so? Many customers with non-critical services do not want to pay for the redundant systems and other protections necessary to measure and implement service level guarantees and remedies. ASPs offering remedies at a higher level of service--and at a higher cost--give customers the option of buying the apparent security a remedy offers. This coverage can, however, significantly alter the economics of the average ASP deal. Customers must decide whether they want this protection before opening negotiations.
Customers, as do their ASPs, come in all varieties. A key point of differentiation concerns what a customer expects a remedy to do. Four broad categories define this area:
The best remedies encourage good performance but remain the hardest to negotiate. This difficulty typically drives customers to the first three categories. Punishing the ASP feels great to an aggrieved customer. The ASP did a bad thing. Consequently, the customer gets to whack them in return. Generally, once the thrill of getting satisfaction passes, the customer may eventually realize that service has become slower, the ASP interprets all requests literally and the overall relationship has inexorably deteriorated. Considering the level of close cooperation required to operate successfully in the ASP model, this attitude jeopardizes the entire ASP project. Customers who insist on punishing their ASP will find that the ASP actively seeks the first opportunity to escape from the project, without being concerned about collateral damage to the customer.
The "big stick" approach is great if all the parties love to negotiate. Some customers believe that a stiff remedy gives them impressive leverage to use in new negotiations following a failure. They understand that the remedy must fit the situation, but want every fault to turn into a "plus" for their side. Procurement professionals and IT business managers usually adopt this view, finding job security in endless negotiations and re-negotiations. This may be useful on enormous deals, but in the new economy, few people have time for lengthy compensation discussions. Most customers want the ASP performing, not institutionally sitting across a conference table. ASPs, therefore, realize that the customer's "big stick" stays put in a cloakroom and is rarely used. This realization totally undermines the original purpose for the remedy and usually proves to be a waste of time to negotiate.
The dollar for dollar school sounds great--for insurance--not for IT performance. The third major type of customer expects the ASP to compensate business losses caused by failures. This is not a remedy; it is insurance. It is unrealistic to expect that if, for example, an ASP-hosted sales force automation application crashes causing the customer to lose a million-dollar deal, then the ASP owes the customer a million dollars. If the customer wants that level of remedy, it is available, but the customer is no longer buying a technology service but rather a form of expensive insurance. If the customer insists--and the ASP accepts--this responsibility, then from day one, the ASP will be hyper-conservative, minimizing risk at every turn and constantly looking for ways to mitigate, offset or ultimately eliminate their risk. While large, well-funded ASPs will consistently reject the insurer role, some under-funded, inexperienced providers may decide to take the risk to secure business.
In well-negotiated SLAs, remedies exist to encourage performance, period. No revenge, no "big stick" and certainly no demonstrations designed to convince customer executives that their negotiators are tough as nails. Customers who negotiate effective remedies almost never need to invoke them. They start by building a firm relationship with the ASP and cultivate it with daily attention. This is not easy and may require discussions with several ASPs before finding a suitable match of styles. Many customers are unsophisticated or short on time and ignore this critical element of the outsourcing relationship. Relying on remedies to build a relationship rarely proves effective; it would be the equivalent of relying on the threat of litigation to build a management team.
ASPs that identify a problem, fix it and then propose a remedy for the fault exemplify a good partner to have in a relationship. Customers that identify a problem, communicate it to the ASP and enthusiastically cooperate in its resolution echo this principle. When both sides remain truly committed to the relationship, it will work. If only one party is required to be committed through the imposition of remedies, the chances of success shrink. ASP executives, especially in smaller firms, usually feel willing to "make it right" when at fault. However, the last part of that sentence, "when at fault" proves key.
The best way to torpedo a good relationship is for the ASP to be uncommunicative, or the customer to be unreasonable during a crisis. Most customers are familiar with the standard ASP dodge, "The fault must be in your network." This infuriating, uncommunicative, response can be accepted after honest troubleshooting by the ASP, but if used consistently as the first response from help-desk staff, then a problem exists with customer service that precipitously threatens the relationship.
Customers need to realize, however, that their ASP deal only goes so far and it is inappropriate to blame the ASP for faults outside its control. Let us examine telecommunications providers (telcos) as an example. Nearly every deal relies on third-party telcos, which are known for generally providing abysmal customer service. In reality, if a telco fails an ASP, customers who respond to every problem by screaming at their ASP endanger the relationship. The ASP will usually be far more responsive than the telco. Customers who resist the temptation to yell and instead ask the ASP for help or clarification in addressing the issues positively, will usually resolve the situation much more productively than the screamers.
Seven key principles define the most effective package of ASP remedies: objectivity, visibility, necessity, proportionality, continuity, creativity, and balance. Adopting these will induce customers and ASPs to enjoy better relationships, faster trouble recovery and more mutually beneficial projects.
| Objectivity | Objectivity means basing all measurements and remedies on facts, not on
opinions. Perception-based service measurements, such as surveys and interviews,
are trouble from the start. While they can be valuable tools as an informal
gauge of performance, they usually criticize the vendor for circumstances beyond
their control, as in the telco example, above. The other extreme, excessive
detail-based measurement, has a far more common failing. SLAs that measure
dozens or hundreds of miniscule indicators, but never connect them to actual
business performance, also miss the point. Let us consider the example of automated measuring systems. These may be described as all the current IT "rage," but ASPs and customers must consider the costs and additional expertise necessary not only to run such a system, but also to interpret the results. If the metrics prove too detailed and/or too complex, they become meaningless as tools to encourage, much less quantify, an ASP's genuine performance. As with most other areas of SLA negotiations, effective remedies must achieve a balance: just enough detail to be objective, but not so much that the underlying business purpose for the measurement becomes obscured. Objective, well thought-out, easy-to-understand metrics and remedies remain the most important elements required to build an effective SLA.
|
| Visibility | A visible remedy will be effective because it attracts the attention of
project leaders from all sides. If a failure proves sufficiently serious, this
will get the attention of executive management. The current trend towards automated measurement and remedy application systems can obscure the cause and effect relationship between failures and remedies. Effective remedies address important or constant failures that adversely affect the ASP customer. Remedies do not encourage performance if, somewhere deep within the relationship's background, they are totally automated, handled by a measurement system and then passed to accounting. True, the customer's monthly bill may be lower than expected after a failure, but many customers will not understand why. This process, while very efficient, results in the customer accepting poor performance as the ASP slowly loses any margin it had on the project. Even where automated systems handle faults and remedies, project managers and executives from all sides should openly discuss any significant event that triggers a remedy. Spend time on making things better, not documenting how bad things are.
|
| Necessity | As a document, the most complex SLAs start with scads of measurements and
then lash together those groups of measurements into performance indicators .
The ASPs that write them understand that problems which cannot be measured
qualify as opinions, not problems. In reality, customers generally just do not
care about these elegant numbers because they have little direct relation to
customer concerns. Customers just want the system to work as advertised, period,
without fore-or afterthought. This brings us to the necessity test for remedies.
A remedy that the customer does not recognize, appreciate and demand is not
effective; in fact, it often becomes an irritant to customers though it appeared
through their own insouciance. Effective remedies connect visibly to measurable failures that have a business impact important to the customer. Administration of this type of remedy proves very difficult since business needs change, as do their prescribed remedies. The effort, however, will be worthwhile if it makes a project more successful and keeps a customer from abandoning the ASP during the inevitable crises.
|
| Proportionality | Effective remedies fit the severity of the fault that triggers them.
Currently, in order to employ "one-size-fits-all" solutions, many ASPs
offer a simple "time for time" remedy: one hour of credit for every
hour down. This logic fallaciously assumes that, without the ASPs services, the
customer simply returns to conducting business in the manner they did pre-ASP.
This calls the need for the ASP into question, as it ignores the fact that the
customer now relies upon its services. "If I don’t do the work, you
don’t pay me" is not a remedy, it is a basic fact of business. To make a
remedy effective, the ASP must do better.
|
| Continuity | Remedies must encourage the business relationship to continue after whatever
crises have passed. ASPs must exercise vigilance in avoiding the pressure to
offer remedies that customers will find more attractive than actual performance
standards. If a customer CFO likes an ongoing 25% under run in the budget for
ASP services, he or she will be unhappy when the problem is solved and billing
returns to 100% of the contracted rate.
In the transparent outsourcing model, the ASP sets its goal to act as an invisible force enhancing the customer’s IT infrastructure. This makes developing business relationships and presenting the value of the services offered very difficult. If remedies are paid from a contract that nobody has ever heard of, the ASP will not get the credit for offering an adequate remedy. If nobody understands what value the ASP adds, they will want less performance at the lower price. This is not a good way for ASPs to earn business.
|
| Creativity | Remedies do not have to be time-for-time or cash-based payments. The ASP
model depends on the idea that remedies exist as infrequent responses to special
circumstances. Keeping this principle in mind, ideally, the remedy should be
equally creative. Effective remedies start with "If I don’t do the work,
you don’t pay me" and then add a creative remedy on top of that. Note: ASPs need to be careful that creative remedies do not cause more harm than good. While a creative remedy for an outage may involve a personal call from the ASP's CEO to the customer CEO, this will be effective only if it happens once every couple of years. It becomes an irritant if it happens every few months. Effective remedies reflect the concerns and personality of the customer, not a "gee-whiz" marketing stunt. Some inexperienced ASPs ignore this fact, aggressively attempting to turn negatives--failures--into positives--marketing points--to the potential bemusement and certain annoyance of their customers.
|
| Balance | Experienced IT vendor negotiators often seek to equalize remedies with
incentives. Their position is, “If a task is critical enough to warrant a
remedy for failure, shouldn’t it offer a bonus for outstanding performance as
well?” This is an effective tactic and usually annuls the media and
consultant-influenced "get-this-too" remedy hype. Balance involves asking both, “What remedy is appropriate for a specific fault?” and "What is so important that the customer will pay extra for sterling performance?” Some examples include performance speed guarantees, consulting or troubleshooting services above and beyond those called for in the SLA and time windows during which the ASP guarantees 100% uptime.
|
 |
|
As mentioned above, some remedies are so automated that they simply result in a slightly lower bill for substandard performance. This rarely encourages either SLA creativity or better ASP performance. Less visible, automated remedies also backfire when the ASP discovers that the account is not profitable, or when the customer detects a steady erosion of service.
Monetary remedies definitely have a role. In a nascent market, however, small ASPs need to look for remedies that keep cash flow positive and predictable. Customers want recognition for failures, but understand that the best remedy in the world may prove worthless if it drives a critical vendor into default.
In conclusion, here are ten ideas to encourage good performance without exchanging a dime:
Apologize
A unique idea in America today. When something goes wrong, try saying, I am sorry. If you are the customer and you pin a failure on the ASP that your staff or vendors caused, try apologizing. If you are the ASP and you are at fault, you may only be responsible for a small cash remedy, but include an apology as well. Apologies for infrequent outages can mean as much as a large cash payment--if the customer stays committed to building a durable relationship. Warning: most American lawyers will use any attempt at civility to prove culpability in court, so check with counsel to find ways to apologize without endangering your company.
Escalate
Escalation is a process by which progressively higher ranks of customer and ASP management automatically become involved in resolving faults after an agreed period of time. Effective escalation processes involve senior executives for serious outages putting an enormous amount of pressure on junior managers to solve problems before their bosses become personally involved. Again, beware of mechanization: if the escalation proves repetitive or tedious, the pressure factor becomes lost.
Escalation is free, builds the relationship and can remove the element of emotion from failures. Consider this option by investigating Cisco's excellent vendor-side escalation system. Do not stop there, however! Cisco is a hardware vendor; much room remains available for creative escalation in service contracting.
Note: Customers should offer formal escalation at corresponding management levels, in order to avoid an ASP CEO apologizing to a 19-year old data center operator.
Mutual Involvement
Involve the other party in your decisions, worries and opportunities. ASPs should over-communicate with customers, offer data center tours and give free seminars on the ASP model. Customers, in turn, also need to open doors to the ASP, offering more business as performance warrants.
Flexible customers also work a marketing deal with their ASP, receiving a small fee for recommending the ASP to their allies or peers. This puts the customer’s reputation on the line right beside the ASP. Expanding the relationship in this way will only be useful, however, if it becomes a key part of the ASP selection process. It remains difficult to graft a marketing alliance on to an existing, traditional IT contract.
Cooperate
Technology succeeds only in collaborative environments. When cooperation stops, problems start. Customer IT departments may feel threatened by ASP vendors, viewing them as the first step towards total outsourcing. This means that customer and ASP executives must find ways to build confidence between customer and ASP staff. In this environment, it can be counter-productive to allow customer IT managers to impose remedies. The perception of the ASP can be that IT managers have a vested interest in making them look bad and the remedy takes on far more significance than the customer negotiator intended. Where sensitivity of existing IT staff is an issue, customers should enforce remedies through senior management, procurement, or legal departments.
Trumpet Good Performance
ASPs need to infuse effort in overcoming their biggest selling point, transparent outsourcing. Transparent outsourcing is central to the ASP model, but it can be a very difficult point upon which to build a sound relationship. An ASP must not hesitate to blow its own horn. For example, smart ASPs distribute newsletters emphasizing interesting information that gets beyond standard marketing jargon. The book Permission Marketing by Seth Godin, provides a great starting point for inaugurating this concept. While an incumbent ASP should visit or telephone customers regularly, especially when things are going well, they must also be careful not to become pests. If you are an ASP, your goal must be to let customers know who you are and that you are a dependable partner when needed.
Reward
Customers, if things go well, say “Thank you.” If your ASP goes a whole year without any problems, have your CIO send their CEO a thank you note. Remember, though, to run it by the attorneys--see above--but do it. Another good idea is to send their help desk staff shirts, hats or mugs with your company logo. It is hard to ignore a customer when you are wearing their clothes.
Bolster the Relationship
Both sides to any ASP deal need to look for ways to build a positive, durable relationship between companies. Relationship building does not replace remedies and performance metrics. Rather, it enhances their constructive use. When failures happen, pick up the phone with an attitude that here is a chance to build confidence and make the relationship better.
Innovate
One of the first things that customers and ASPs should sign is a confidentiality agreement. Once in place, work together on exciting projects. Look for better ways to do things, and give credit where credit is due. ASPs must be willing to reduce prices if technology and ideas proposed by customers result in dramatically increased margins.
Anticipate
Both sides should constantly try to think about what the other will need in the future. Sellers usually do this, but buyers are terrible at it. Why? Because a key principle of sales is to anticipate needs and objections, then find answers. Contracts this with the principle of procurement--raising objections and waiting for the other side to answer them. The seller has an advantage in anticipation, but there is no reason why the buyer cannot think along the same lines. Customers can reduce the need for corrective tools, such as remedies, by working to align customer processes to the needs of the ASP whenever practical. Even if this does not stop problems, it helps both sides solve them faster and with less emotion.
Team Up
In any multi-year contract, the buyer and seller co-exist in a team relationship, whether they elect to realize this or not. Apply all of the lessons from internal teambuilding to increase communications and reduce conflicts. Every outsourcing relationship benefits from extensive work on teambuilding. In the ASP model, where customer and vendor may not be on the same continent, teambuilding is more difficult and far more important.
|