By November 1, 2000 Read More →

Contracting With ASP’s What’s the Customer to Do? | Article

Hand Signing ContractThe headaches are familiar. Pay lots of money for up-to-date software. Then pay consultants for implementation. Hope the IT gurus can make it work, and pay still more money for new computers, peripherals and telecommunications circuits. Then repeat the exercise every couple of years for major upgrades.

Application service providers (“ASP’s”) promise to make all this go away. Rather than pay large license fees and hire swarms of consultants, companies may “rent” the software, or buy applications “by the drink,” paying so much per user, per month. Applications will be delivered to the desktop, over the Internet. Just pay the money, and someone else will buy, install, connect and configure everything. The allure is plain, and has aroused interest in the marketplace, and from service providers, including well-financed startups, as well as such stalwarts as Intel and Oracle. The appeal is especially strong to new and smaller companies, who can adopt standard functions from popular packages more easily than larger, long-established organizations.

Most ASP’s offer supposedly “standard” terms, but in an immature, competitive market, few real standards exist, and the form agreements vary in both sophistication and substance. Since ASP’s offer standard service, with few variations, and their own success depends upon economies of scale, the reasons for simple, standard agreements are obvious. Moreover, time and cost constraints preclude the elaborate, heavily negotiated contracts used for mammoth outsourcing engagements.

What should a customer do? Much as the ASP’s like standard terms, they are eager to build market share in a crowded, volatile arena, and thus motivated sellers. In practice, ASP’s may prove willing to negotiate, and to amend or supplement their contract documents. Thoughtful and sophisticated customers can obtain important protections and improvements by careful negotiation.

The customer’s leverage is greatest before he signs, while other alternatives are freely available. Disengagement may be disruptive and expensive. What are the customer’s risks?

  • The contract might prove too expensive, if the customer’s requirements change, or market prices change. A la carte is not always the best deal, and payments often do not count toward acquisition of a long-term, transferable license — any more than rent payments build equity in a home.
  • Signing a long term service contract relinquishes future flexibility, especially when purchasing a standard service. Future changes in or variations upon standard service offerings may be costly or, worse, unavailable. Many service offerings echo Henry Ford’s axiom that the customer could have any color he liked, as long as it’s black.

  • Entrusting critical applications to a contractor involves what the word suggests: trust. Poor service can jeopardize operations.

Customers may protect themselves in many of the same ways that have proved effective in larger outsourcing contracts. The ASP’s service offerings and economics differ, but many of business and contract issues are essentially similar.

  • Scope. To assure success, both parties need a crisp, clear description of the service to be delivered, so that both parties know what’s included and excluded. Clarity now avoids uncertainty and tension later. Many ASP contracts describe the service offering with astonishing brevity. Succinctness is good. Uncertainty and vagueness are not. Customers should be sure that the contract documents accurately describe everything they’ve bargained for. Anything extra will cost more, if available.
  • Changes. When purchasing standard services, there may be less scope for changes than in a conventional outsourcing or systems integration contract. Nonetheless, change may occur, and it is prudent to provide for written change control procedures, and metrics for pricing changes — since the relationship is difficult to break, and the supplier has corresponding leverage. Generally, customers should request the best price that the supplier then offers other customers for future upgrades, options and other changes in service.
  • Software Licenses. Often the customer’s users are licensed under the ASP’s umbrella license, so when the service contract lapses or terminates, the customer will have to renew, find another provider or buy a new license — perhaps at considerable cost. Where the customer already has a license, it may be worth asking on what terms the license could be reinstated. Sometimes, the customer either retains or purchases a license, and in those cases, the customer should insist that the license be transferable to another provider when the ASP contract expires or terminates.
  • Service Levels. CSC, EDS, IBM and other big outsourcers routinely make service level commitments, and risk paying credits to the customers if service levels are missed. Customers should expect no less from an ASP, and may well find the ASP’s, like the outsourcers, are willing to commit to excellent levels of availability, prompt responses following service incidents, and other common measures of performance. At a minimum, customers should thoroughly investigate the ASP’s capabilities, check references, and insist upon some minimum service levels that, if missed, would provide the basis for default termination.
  • Disaster Recovery. Most ASP’s presumably have this, at their own facilities, or the facilities of those with whom they contract for operations. Many are reluctant to commit themselves to maintenance and execution of plans, regular testing and other customary precautions of the kind that give customers (and their auditors) comfort, and help assure prompt resumption of service after an earthquake or hurricane.
  • Termination Rights. Customers may wish to terminate for a variety of reasons, ranging from poor service to changes in business strategy. Generally, customers should expect (and insist upon) rights to terminate contracts (i) for default, after notice and a reasonable time to cure, if service is poor, and (ii) without cause, for their convenience, by giving notice and paying a reasonable fee. ASP’s sometimes demand large termination fees, citing economic arrangements with software vendors and long term obligations for facilities, equipment and the like. Large termination charges naturally tend to deter termination, which is part of their purpose. From the customer’s standpoint, the lower the termination charge, the better (although a larger payment might be tolerable if it applied toward a permanent, transferable license for the application). Whether the contract expires or terminates, and whatever the circumstances, the contract should describe what service the supplier will provide to assure a smooth transition (and what charges, if any, must be paid). The customer may want more than mere delivery of a tape.
  • Remedies. ASP’s, like other suppliers of IT services, attempt to limit their liability by contract — barring recovery of lost profits and other consequential damages, and limiting recovery of actual damages to a fixed sum, sometimes calculated based on total charges for a period of months. Customers are well advised to propose that the ASP’s (i) have unlimited liability for certain kinds of unlikely but serious claims (such as intentional misconduct) and (ii) be at risk for consequential damages (at least up to a limit) for such claims as deliberate misappropriation or infringement of the customer’s proprietary rights (where the only damages may be consequential).

When dealing with ASP’s, as with other providers of critical services, customers should look past the “standard form” boilerplate and attempt to negotiate real protection against foreseeable risks of these relationships.

George Kimball is a partner in the Los Angeles office of Arnold & Porter, an international law firm whose practice includes outsourcing, technology and intellectual property.


Post a Comment

Your email address will not be published.

( required )

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>