Editors note: In the last issue, Purchasing Magazine looked at areas technology buyers should focus on first when doing deals with ASPs (application service providers). This time, we delve a bit deeper, and provide readers with four areas that require special attention when negotiating with providers.

You're a technical buyer ready to begin contract negotiations with an ASP. Suppose somewhere down the line the ASP goes bankrupt, a scenario not so unusual in this day and age. What are your rights and where would you stand in the queue of people who are collecting these rights?

The key to the relationship is understanding the obligations of both parties, says Ditka Reiner, president of Reiner Associates, San Francisco, Calif., (www.reinerassociates.com). Reiner's firm provides consulting services for IT acquisition professionals involved in negotiating contracts for software and other technology purchases.

An ASP allows a technology buyer to create a contract to lease or license a Web-based application or service which is hosted, deployed or managed from an outside facility, instead of implementing or supporting the application in-house.

While pricing is the first item most companies key in on, Reiner suggests technology buyers pay close attention to these areas: definitions, change control, service-level agreements (SLA's) and termination.

There are issues surrounding definitions used in contracts: Buyers should clearly define terms that they may not normally define.

For instance, when buying application software there is an acceptance period, so a buyer can define the "effective date" clearly. But when a provider customizes an application for a buyer, the term "effective date" is critical because there are more entities involved.

In a one-to-one relationship the meaning of force majeure is clear. But this may not be the case in a relationship with an ASP that uses a third-party host. Most providers try to exclude third-party force majeure events as something they control.

The term "user" is important to include in definitions. If a user is anyone who accesses a database internally, externally, or as an authorized third party, that's clear. Not including this could cost a buyer when he or she wants to add outside users.

"In general, most people don't do a thorough job of putting definitions in their contracts," says Reiner. "The legal department might add their terms, but it's the buyer's responsibility to add user, technical or business definitions. If there's a dispute that goes to court, the first thing the attorneys and the judge are going to look for is whether terms of the contract are clearly defined. Definitions are important because they show intent."

Change control is an update to an application, and can occur on both the hosting and using sides. Change control applies to customer changes, the ASP's changes to its systems, as well as platform or network changes that need to be made at hosting sites. It's clear who the customer is and what is intended "when you are licensing something yourself," says Reiner. "It isn't as clear when you have multiple customers and multiple points where change control occurs." For example, she notes, "Suppose you're using an Oracle application and your provider is updating to the latest version. You'll need information from your provider on notice, preparation for the update, support and how quickly you are expected to upgrade to the new version."

When the ASP is upgrading servers or changing to another hosting company the buyer will need to know: "Do you have to dedicate staff to accommodate these changes? Do you have the right to test the application to ensure it's operating correctly after the change has been made? What is the process? Depending on the change will you need to do benchmarking or systems testing again?"

A buyer may also want to make changes. "Suppose you have an application and want to update your client base. What happens if you want to add new reports or need new formats? Does the provider have staff to accomplish these tasks or do you have to do them?"

All ASPs have standard maintenance hours during which they do their own service and upgrades. "You need to be aware of these if you want to run an extra update or do some testing of your internal functions," says Reiner. "How much notice do they need? How fast can they respond?"

Service level is the performance benchmark the ASP agrees to provide contractually. An organization needs to have a process in place to track a provider's service levels. Says Reiner, "One of the biggest mistakes people make is that they expect a service level from their ASP that their organization can not achieve internally.

"I always tell people that the first step in crafting a Service Level Agreement (SLA) is to poll their internal support. Expecting an ASP to perform to unachievable levels is setting everyone up for failure." She suggests buyers measure critical application uptime on a daily, weekly and monthly basis.

Determining critical service levels depends on the application—there's no need to measure every SLA that could possibly exist. "Take e-mail as an example. You'd want to set service levels for the actual processing, i.e., that your e-mails actually arrive, etc. You should also have an SLA to measure uptime and availability of service.

For each application, there will be different categories, but Reiner tells buyers they should keep categories to a manageable number. For every SLA expectation there has to be a penalty if it isn't met. Standard rule of thumb is that the penalty should not be more than 20% of the monthly fee. An individual should be assigned to track the information and be sure the provider is performing to the agreement.

It's important to specify termination-triggering events—significant or repeated events that automatically trigger penalties or automatic termination. "Before you put a penalty in your SLA be sure you can respond," says Reiner. "Some people have very strict termination events and they end up terminating their provider with nothing to fall back on."

What happens on termination is called an exit strategy. There are many ways a relationship can be terminated and these must be stated in the contract. Termination may occur between the user and the ASP or the ASP and its hosting entity. If the buyer terminates for convenience, it's important to ensure there is a migration assistance plan so service to customers is not degraded.

It's also important to cover what happens if termination is for cause. If the buyer terminates the provider for cause, what kind of migration assistance are they responsible for providing? "You want to make sure that termination for cause is as amicable as possible," says Reiner. "Define the process up front because above all else you don't want to affect your customers."

When terminating for convenience, buyers should understand the penalties involved with early termination. With an ASP, contracts are usually term agreements with penalties for early termination. "You have to make sure you understand the obligations of both parties, even if it's for convenience."

Many ASPs have tried to disavow third-party outages as part of their service levels so if they experience force majeure, the buyer doesn't have a right to terminate the contract. "If you have a critical problem that can't be resolved in the timeframe you need, you want to have an advance agreement on how the event is to be handled," Reiner says.