Originally Published on Alentis.com, 12 June 2000

The ‘all-inclusive’ service level agreement (SLA) does not exist. ‘Outs’ always exist for vendors when services provided fall below contractually stipulated levels. Customers, enraged at the fact that their SLA does not protect them against everything, blame providers for poor service and ‘unfair’ SLAs. Customers often forget that the more comprehensive the SLA, the greater its cost.

A ‘balanced SLA’ is just that, balanced between the customer’s need for protection and the risk that the provider takes by providing that protection. Many customer SLA negotiators see their discussions as a zero-sum game, arguing only for maximum protection at minimum cost. ASP SLA negotiators may seek to get the deal at any cost in order to increase market share, but at minimum risk and maximum margin. Seeking a middle ground between these two positions proves crucial. It is the most difficult aspect of the high-tech negotiator’s job.

A ‘balanced SLA’ is just that, balanced between the customer’s need for protection and the risk that the provider takes by providing that protection. Many customer SLA negotiators see their discussions as a zero-sum game, arguing only for maximum protection at minimum cost. ASP SLA negotiators may seek to get the deal at any cost in order to increase market share, but at minimum risk and maximum margin. Seeking a middle ground between these two positions proves crucial. It is the most difficult aspect of the high-tech negotiator’s job.

A ‘balanced SLA’ is just that, balanced between the customer’s need for protection and the risk that the provider takes by providing that protection. Many customer SLA negotiators see their discussions as a zero-sum game, arguing only for maximum protection at minimum cost. ASP SLA negotiators may seek to get the deal at any cost in order to increase market share, but at minimum risk and maximum margin. Seeking a middle ground between these two positions proves crucial. It is the most difficult aspect of the high-tech negotiator’s job.

A ‘balanced SLA’ is just that, balanced between the customer’s need for protection and the risk that the provider takes by providing that protection. Many customer SLA negotiators see their discussions as a zero-sum game, arguing only for maximum protection at minimum cost. ASP SLA negotiators may seek to get the deal at any cost in order to increase market share, but at minimum risk and maximum margin. Seeking a middle ground between these two positions proves crucial. It is the most difficult aspect of the high-tech negotiator’s job.

Most ASP industry SLAs ignore the points presented here. Many customers will try to add these terms to their contracts and SLAs. The intent of this article is to present the points, discuss why they are important and give customers ideas on whether or not they should be critical, must-have points in every negotiation.

The purpose of a balanced SLA is twofold:

· Assure customers of a basic set of expectations that the provider promises to meet

. Assure customers of a basic set of expectations that the provider promises to meet

· Protect the provider by limiting liability, identifying responsibilities and rationally managing expectations

Protect the provider by limiting liability, identifying responsibilities and rationally managing expectations

Customer-written SLAs tend to lean heavily towards the first point. Provider-written SLAs pay lip service to the first point, but focus on the second. Mutually agreed, negotiated SLAs should combine the best of both points but, realistically, tend to favor the party with the most leverage.

Customer-written SLAs tend to lean heavily towards the first point. Provider-written SLAs pay lip service to the first point, but focus on the second. Mutually agreed, negotiated SLAs should combine the best of both points but, realistically, tend to favor the party with the most leverage.

Assure customers of a basic set of expectations that the provider promises to meet protect the provider by limiting liability, identifying responsibilities and rationally managing expectations Customer-written SLAs tend to lean heavily towards the first point. Provider-written SLAs pay lip service to the first point, but focus on the second. Mutually agreed, negotiated SLAs should combine the best of both points but, realistically, tend to favor the party with the most leverage.

Assure customers of a basic set of expectations that the provider promises to meet Protect the provider by limiting liability, identifying responsibilities and rationally managing expectations Customer-written SLAs tend to lean heavily towards the first point. Provider-written SLAs pay lip service to the first point, but focus on the second. Mutually agreed, negotiated SLAs should combine the best of both points but, realistically, tend to favor the party with the most leverage.

Leverage is a critical factor during SLA negotiations. Fortune 500 negotiators feel proud of the fantastic terms they extract from ASPs, but this tends to reflect the size of their respective companies in conjunction with the immaturity of the ASP market, as opposed to any negotiating prowess. By the same token, many of the largest players in the technology business are morphing into ASPs. Because of their size and power, they tend to place a ‘standard SLA’ before a Small-to-Medium Enterprise (SME) and refuse to negotiate, maintaining a “take it or leave it” attitude.

Therefore, the prospective ASP customer must first identify who has the leverage in the relationship before negotiations commence. If you are shopping for a 250-user deal and have several ‘must’ SLA terms, then negotiating with the big players will likely prove to be a frustrating experience.

In this situation, your choices are simple:

· Spend weeks negotiating, get a few minor changes, then do a deal out of desperation when your time runs out and you must implement

. Spend weeks negotiating, get a few minor changes, then do a deal out of desperation when your time runs out and you must implement

·  Give up the terms you want in the SLA and sign the big-vendor-offered agreement

Give up the terms you want in the SLA and sign the big-vendor-offered agreement

· Find a smaller Provider who is willing to negotiate and appears capable of staying in business with the terms you want
Since we cannot cover all of the key terms of an SLA in this article, we will focus on five key points that you must consider when reviewing provider SLAs. Remember, most providers suspend their SLAs when these points occur—make sure to deal with these points before spending time negotiating an SLA.

. Find a smaller Provider who is willing to negotiate and appears capable of staying in business with the terms you want Since we cannot cover all of the key terms of an SLA in this article, we will focus on five key points that you must consider when reviewing provider SLAs. Remember, most providers suspend their SLAs when these points occur—make sure to deal with these points before spending time negotiating an SLA.

Spend weeks negotiating, get a few minor changes, then do a deal out of desperation when your time runs out and you must implement Give up the terms you want in the SLA and sign the big-vendor-offered agreement Find a smaller Provider who is willing to negotiate and appears capable of staying in business with the terms you want Since we cannot cover all of the key terms of an SLA in this article, we will focus on five key points that you must consider when reviewing provider SLAs. Remember, most providers suspend their SLAs when these points occur—make sure to deal with these points before spending time negotiating an SLA.

Spend weeks negotiating, get a few minor changes, then do a deal out of desperation when your time runs out and you must implement Give up the terms you want in the SLA and sign the big-vendor-offered agreement Find a smaller Provider who is willing to negotiate and appears capable of staying in business with the terms you want Since we cannot cover all of the key terms of an SLA in this article, we will focus on five key points that you must consider when reviewing provider SLAs. Remember, most providers suspend their SLAs when these points occur—make sure to deal with these points before spending time negotiating an SLA.

ACTIONS BY THIRD PARTIES

A typical ASP deal involves more than the provider and the customer. It involves telecommunications companies, software publishers, integrators, consultants, ASP aggregators, data storage vendors, disaster recovery companies and a few dozen other potential players. Contracts often refer to these players as ‘third parties’ because they have not signed the contract between the provider and the customer.

Two methods exist to deal with third parties in the ASP contract and SLA:

Provider is responsible for the actions of all parties (very high risk cost to provider)

Provider is responsible for the actions of all parties (very high risk cost to provider)

Provider is responsible only for its own actions (minimal risk cost to provider)

Provider is responsible only for its own actions (minimal risk cost to provider)

Naturally, most providers prefer to be responsible only for their own actions. Some will take responsibility for their ‘partners’ but charge a fortune to minimize their risk. This means that if the customer demands full end-to-end responsibility from the provider, the customer should expect to pay a lot of money. This is not new; every properly balanced business agreement seeks to reward risk with money. In the ASP industry, some providers talk about taking risks, charge for it, then put SLAs into play that seek to eliminate the very risks they contractually accepted with the customer. While many providers promise end-to-end solutions (maximum risk), the reality in their SLA remains far from the total responsibility that their marketing implies.

Naturally, most providers prefer to be responsible only for their own actions. Some will take responsibility for their partners but charge a fortune to minimize their risk. This means that if the customer demands full end-to-end responsibility from the provider, the customer should expect to pay a lot of money. This is not new; every properly balanced business agreement seeks to reward risk with money. In the ASP industry, some providers talk about taking risks, charge for it, then put SLAs into play that seek to eliminate the very risks they contractually accepted with the customer. While many providers promise end-to-end solutions (maximum risk), the reality in their SLA remains far from the total responsibility that their marketing implies.

Provider is responsible for the actions of all parties (very high risk cost to provider)Provider is responsible only for its own actions (minimal risk cost to provider) Naturally, most providers prefer to be responsible only for their own actions. Some will take responsibility for their partners but charge a fortune to minimize their risk. This means that if the customer demands full end-to-end responsibility from the provider, the customer should expect to pay a lot of money. This is not new; every properly balanced business agreement seeks to reward risk with money. In the ASP industry, some providers talk about taking risks, charge for it, then put SLAs into play that seek to eliminate the very risks they contractually accepted with the customer. While many providers promise end-to-end solutions (maximum risk), the reality in their SLA remains far from the total responsibility that their marketing implies.

Provider is responsible for the actions of all parties (very high risk cost to provider)Provider is responsible only for its own actions (minimal risk cost to provider) Naturally, most providers prefer to be responsible only for their own actions. Some will take responsibility for their partners but charge a fortune to minimize their risk. This means that if the customer demands full end-to-end responsibility from the provider, the customer should expect to pay a lot of money. This is not new; every properly balanced business agreement seeks to reward risk with money. In the ASP industry, some providers talk about taking risks, charge for it, then put SLAs into play that seek to eliminate the very risks they contractually accepted with the customer. While many providers promise end-to-end solutions (maximum risk), the reality in their SLA remains far from the total responsibility that their marketing implies.

If a customer has an excellent contract management system and professional negotiators, they can save a considerable amount of money by allowing the provider to be responsible only for its own actions. Most customers with this capability, however, tend not to ‘penny pinch’ on their ASP deals. The customers who demand rock-bottom pricing from their providers are often the same customers who refuse to spend the money for contract management. They want the provider to take full responsibility, at the lowest possible price.

A brief aside: in my role as a customer advocate, I seek to place as much responsibility on vendors as their marketing, sales and delivery people are willing to accept. If I am promised a 10ms response time, the contract and SLA will make the vendor provide this service level and provide a remedy if they fail to do so.

Where I differ from many IT negotiators is in the realization that the best contract in the world will not work if both parties are not able to meet its terms. Customers who insist on maximum provider responsibility at rock-bottom prices may get a signed deal, but they will rarely get a successful project. The demand is irrational because of the basic business principle that good contracts reward risk with money. Customers who insist on irrational terms are not negotiating–they are simply issuing demands.

Providers can usually negotiate away this particular demand, taking only responsibility for their own actions and giving the customer the low price they desire. While the provider gets the deal, a dangerous situation develops when customers who have no dedicated contract management staff take extensive responsibility for managing third parties (contract management staff means a dedicated team of contract managers, lawyers and administrators who keep track of the obligations made by the customer and provider).

When a telecommunications line fails, a customer with such a system in place knows to pursue the telecommunications vendor. Customers with bad contract management systems usually cannot even find their telecommunications contract, so they blame the target of first opportunity–the provider.

Many ASP sales pitches imply that once the customer signs the deal, all their IT worries will vanish forever. Should the provider take full responsibility for third party actions, this may prove to be true, although the cost of such a deal is likely to enrage potential customers. Balancing these two positions remains the hardest part of negotiating an ASP deal.

To summarize, both parties must understand the technology and agree where customer responsibility stops and provider responsibility begins. Actions of third parties do not need to be a deal-breaker, if both parties recognize from the outset that the security of a provider taking end-to-end responsibility always comes with a high cost. Since most customers refuse that high cost, they must accept that a truly end-to-end service level agreement does not exist in reality.

THE QUALITY OR RELIABILITY OF CUSTOMER NETWORKS

Most ASP deals do not extend all the way from customer desktop to provider server. Somewhere, there is a hand-off from the customer desktop, to the customer network, to the telecommunications company, to the provider.

Many potential ASP customers consider the model based on desperation. They have outdated internal networks, old desktops, shaky support contracts, poor software compliance and minimal contract management. Providers selling to these customers ignore the problems, focusing on what the ASP deal can do for the customer. They fail to mention that most provider-written SLAs make any failure caused by customer infrastructure a point that suspends the SLA. Most customers also forget to include in their business case the cost of upgrading their infrastructure to interface with the ASP. ASPs would prefer the customer forget this cost, because the high price of late upgrading makes moving to the ASP model far less compelling for late adopters.

If the customer infrastructure causes a failure, the customer cannot access the applications hosted by the provider. I am amazed at how many customers believe that this entitles them to a refund from the provider. They are not, unless the provider agreed to provide service all the way to the desktop. Service to the desktop is rare. To do it, the provider would need to control the customer’s servers and internal network.

The customer may already have an outsourcing arrangement that covers their desktop or network. These deals provide an ideal starting point for exploring the ASP world. Customers can leverage their existing volume of business during the negotiations and reasonably demand a more end-to-end SLA from the outsourcer/provider. Beware, however, of marketing ‘partnerships’ between outsourcers and providers. These arrangements may look seamless, but the contracts are usually nowhere near as cohesive as the salespeople imply.

The customer may already have an outsourcing arrangement that covers their desktop or network. These deals provide an ideal starting point for exploring the ASP world. Customers can leverage their existing volume of business during the negotiations and reasonably demand a more end-to-end SLA from the outsourcer/provider. Beware, however, of marketing ‘partnerships’ between outsourcers and providers. These arrangements may look seamless, but the contracts are usually nowhere near as cohesive as the salespeople imply.

The customer may already have an outsourcing arrangement that covers their desktop or network. These deals provide an ideal starting point for exploring the ASP world. Customers can leverage their existing volume of business during the negotiations and reasonably demand a more end-to-end SLA from the outsourcer/provider. Beware, however, of marketing ‘partnerships’ between outsourcers and providers. These arrangements may look seamless, but the contracts are usually nowhere near as cohesive as the salespeople imply.

The customer may already have an outsourcing arrangement that covers their desktop or network. These deals provide an ideal starting point for exploring the ASP world. Customers can leverage their existing volume of business during the negotiations and reasonably demand a more end-to-end SLA from the outsourcer / provider. Beware, however, of marketing partnerships between outsourcers and providers. These arrangements may look seamless, but the contracts are usually nowhere near as cohesive as the salespeople imply.

CUSTOMIZED COMPONENTS

In the wake of enterprise resource planning (ERP) debacles, the ASP model emerged as a one-size-fits-all solution to endless customization. Customers do not tell Yahoo! how to handle their email and (so the theory went) they won’t tell SAP how to handle accounts payable. Now, however, most providers allow customers to customize their application solution.

These customization’s range from simple interface changes, such as screen colors, to full application development efforts. An ASP-hosted time and billing package, expanded by a customer to include expense tracking, qualifies as an example of a major ASP customization.

In most cases, third-party consultants program these major customization’s for the customer and run them on the provider system. This is a great idea only if the SLA covers the customization’s. Usually, it does not.

Customization’s exist as a key problem for the ASP model, just as in ERP projects. In ERP, customers use third-party integrator’s to customize applications from software publishers, such as SAP, Peoplesoft or Oracle, and then expect that the software publishers would support those customization’s. They were wrong; software publishers usually only support their core applications.

The customers then turn to the third-party integrator’s who wrote the customization’s, only to be told that the integrator is a consultant, not a software company–no support is available, or if it is available, it proves ruinously expensive. Because of this runaround, many ERP projects that looked successful on the surface derailed the first time a custom component needed support. The same thing currently happens with ASP customization’s.

In the ASP model, customers must realize that if they customize anything, they need to be prepared to absorb the cost of supporting the customization. If customers do a basic cost benefit analysis on each desired customization, many of them will be exposed as luxuries.

Most customization’s also derail the SLA, especially if an unscrupulous provider hides behind customization, insisting that the customer prove every fault is not related to the customization before the provider takes any action. A key warning sign is language in the contract or SLA like:

In the event of any Failure, Customer will first determine if the cause of such Failure originates in any Customer custom or proprietary Software. Customer will provide evidence supporting such determination to Provider before Provider will initiate troubleshooting. If Provider reasonably determines that any Failure was caused by Customer custom or proprietary Software, then Provider shall be entitled to bill Customer for time spent on troubleshooting efforts at then applicable list prices. To summarize, customization can be a nightmare in any IT project. If the folks in Accounting want a blue background because their old mainframe application had a blue background, customers need to consider such a cost before customizing the ASP application.

INFRINGEMENT

What if the software or process your provider uses on your contract does not belong to them? Software licenses typically include a provision that requires the publisher to defend the customer if it transpires that the publisher stole a third party’s work for use in their program. This protection, called infringement indemnification, exists as a critical part of every professional software license, typically understood and appreciated only by attorneys specializing in this field.

Most customer-negotiated licenses go farther. In addition to defending the customer and paying any damages due to the third party, customers require that the publisher replace the infringing software immediately with and acceptable, non-infinging substitute. This is a huge expense, which should be borne by the publisher.

So, what happens to SLA commitments if it turns out that the software running on a provider system infringes on somebody else’s patent? Worse, what if the U.S. Patent Office grants a patent on a key component of ASP technology to a small company nobody ever heard of? If Amazon.com can get a patent on one-click ordering, imagine what could be coming next. The answer is, nobody really knows. There are precedents for distributed and remote computing, but the industry evolves so quickly that the courts are finding it difficult to keep up.

This is not strictly an SLA problem; basic ASP contracts should address the issue with pass-through protection, that is, indemnification from the publisher through the ASP to every customer of the ASP. Most ASP contracts, however, do not mention this protection. When pressed, providers may insist that the software license and any protections are between the publisher and the ASP, or between the publisher and the customer.

This snarl will take years for the courts to untangle and is a bit complex for this overview. However, for now, ensure that:

• Contracts and SLAs take into account the unique relationship between provider, publisher and customer

• Software accessed through the provider guarantees patent infringement protection for the provider’s customers

• Software accessed through the provider is licensed to the customer

• Contracts contain a provision requiring the provider to pay any royalty or licensing charges associated with existing or future patents On large, or mission-critical deals, pay a qualified intellectual property lawyer to review to contract and suggest language that addresses this issue

TRANSITION AND CHANGE

In high technology, change is constant and relentless. Most ASP agreements, however, do not include provisions allowing for change over time. They establish a three-year deal, with leveled pricing and services across all three years. Few contain any provision for the provider doing a better job, or costs going down, or volume going up. This is unfortunate, considering that the ASP model works best in a flexible, high-change environment.

SLAs must evolve over time. This is the reason professional negotiators separate the SLA from the more enduring provisions of a contract. The SLA is a separate article, or document, that contains a flexible change provision. However, beware change provisions that give the provider sole right to change the SLA with little notice to the customer and no recourse.

Of course, if the provider can rewrite the SLA at will, then the SLA is useless as a tool to compel performance. Intentionally, unscrupulous providers may use a balanced SLA during the sales cycle and then dramatically change it six months into the contract. Even scrupulous providers may include this provision in an honest attempt to allow them to improve the SLA without being too specific about the method.

Of course, if the provider can rewrite the SLA at will, then the SLA is useless as a tool to compel performance. Intentionally, unscrupulous providers may use a balanced SLA during the sales cycle and then dramatically change it six months into the contract. Even scrupulous providers may include this provision in an honest attempt to allow them to improve the SLA without being too specific about the method.

Of course, if the provider can rewrite the SLA at will, then the SLA is useless as a tool to compel performance. Intentionally, unscrupulous providers may use a balanced SLA during the sales cycle and then dramatically change it six months into the contract. Even scrupulous providers may include this provision in an honest attempt to allow them to improve the SLA without being too specific about the method.

Of course, if the provider can rewrite the SLA at will, then the SLA is useless as a tool to compel performance. Intentionally, unscrupulous providers may use a balanced SLA during the sales cycle and then dramatically change it six months into the contract. Even scrupulous providers may include this provision in an honest attempt to allow them to improve the SLA without being too specific about the method.

Providers respond to this concern by saying that they can only offer one service level to all customers; otherwise, they will be overwhelmed with contract management duties. They have a good point.

Customers confronted with this provision must, at the very least, insist on the right to review any proposed SLA change, discuss it with the provider before its implementation–perhaps through a user-group review process–and terminate the contract without penalty if they cannot abide by the revisions.

Customers must not let changes in technology management or processes invalidate an SLA. Make the SLA an effective tool by including language that allows customer and provider to change the SLA as technology advances, the market stabilizes and both parties build trust.

CONCLUSION: IF THE PROVIDER DOES NOT SCREAM, WORRY…
If your provider agrees to all of these issues without a fight, worry. It may mean that they are trying to get ahead of the market and make promises they cannot deliver. In this situation, they hope that their market share will expand fast enough to offset the remedies for non-performance. We’ve seen this sort of market-share ponzi scheme in other high tech booms. Customers almost always lose out in the long run.

If your provider agrees to all of these issues without a fight, worry. It may mean that they are trying to get ahead of the market and make promises they cannot deliver. In this situation, they hope that their market share will expand fast enough to offset the remedies for non-performance. We’ve seen this sort of market-share ponzi scheme in other high tech booms. Customers almost always lose out in the long run.

If your provider agrees to all of these issues without a fight, worry. It may mean that they are trying to get ahead of the market and make promises they cannot deliver. In this situation, they hope that their market share will expand fast enough to offset the remedies for non-performance. We’ve seen this sort of market-share ponzi scheme in other high tech booms. Customers almost always lose out in the long run.

If your provider agrees to all of these issues without a fight, worry. It may mean that they are trying to get ahead of the market and make promises they cannot deliver. In this situation, they hope that their market share will expand fast enough to offset the remedies for non-performance. We’ve seen this sort of market-share ponzi scheme in other high tech booms. Customers almost always lose out in the long run.

The best a customer can hope to do in this marketplace is realize that these issues exist and try to balance agreements so that they give both sides adequate protection. Remember, customers who seek one-sided agreements usually get bitter vendors, bare minimum by-the-book performance, and failed projects. Many providers tout ‘industry-leading contract guarantees without considering even these five points.

Your ASP project–and by extension your SLA–will work, if you are realistic about the capabilities and costs, select a good vendor, and cooperate with each ot
her.

ADVICE TO THE POTENTIAL ASP CUSTOMER:

· True end-to-end service level agreements are very rare, very expensive and almost never meet expectations

. True end-to-end service level agreements are very rare, very expensive and almost never meet expectations

· The best SLA terms in the world are worthless if a provider can suspend them

The best SLA terms in the world are worthless if a provider can suspend them

· You get what you pay for. If you demand rock-bottom pricing, do not expect a world-class SLA

. True end-to-end service level agreements are very rare, very expensive and almost never meet expectations The best SLA terms in the world are worthless if a provider can suspend them You get what you pay for. If you demand rock-bottom pricing, do not expect a world-class SLA

· There are always third parties to an ASP deal, make sure the SLA addresses them

. There are always third parties to an ASP deal, make sure the SLA addresses them

· If you are considering ASP because of faults in your infrastructure, realize that failures due to customer infrastructure are usually an ‘out’ for providers

If you are considering ASP because of faults in your infrastructure, realize that failures due to customer infrastructure are usually an ‘out’ for providers

· Changes in technology or processes can invalidate an SLA overnight; make sure it is written to be flexible and easy to change

. Changes in technology or processes can invalidate an SLA overnight; make sure it is written to be flexible and easy to change

·  If you elect to customize an ASP-hosted application, make sure to consider the cost of supporting and upgrading that customization over time

There are always third parties to an ASP deal, make sure the SLA addresses them, if you are considering ASP because of faults in your infrastructure, realize that failures due to customer infrastructure are usually an ‘out’ for providers, changes in technology or processes can invalidate an SLA overnight; make sure it is written to be flexible and easy to change.

True end-to-end service level agreements are very rare, very expensive and almost never meet expectations The best SLA terms in the world are worthless if a provider can suspend them, you get what you pay for. If you demand rock-bottom pricing, do not expect a world-class SLA There are always third parties to an ASP deal, make sure the SLA addresses them if you are considering ASP because of faults in your infrastructure, realize that failures due to customer infrastructure are usually an ‘out’ for providers. Changes in technology or processes can invalidate an SLA overnight; make sure it is written to be flexible and easy to change.

www.bestitdocuments.com