The ASP model of software delivery is riding on a strong second wind. Pure online application service providers, especially in the CRM space, are doing very well. And a growing number of software vendors — Onyx, Blue Martini, Pivotal and Microsoft, to name just a few — are hosting their products through third parties.
Despite the growing popularity of ASPs, the service-level agreements that traditionally accompany them have yet to be standardized. SLAs are the contracts users and ASPs sign to define who is responsible for what — as well as when, at what cost and in what circumstance.
In many respects, the terms and conditions are fairly routine. For example, language regarding termination of the agreement in the event the ASP should become insolvent rarely deviates from one contract to another. But other terms and conditions can vary significantly, depending on the service provider.
Most of the variables focus on performance criteria, according to Denis Pombriant, vice president and managing director of Aberdeen Group’s CRM practice. “That is why it is valuable for the buying organization to understand, for example, ‘uptime,’ not simply from a percentage basis but in terms of hours, minutes and days,” he told CRM Buyer Magazine.
The Meaning of ASP
Not that the industry has ignored the need to create some standardization in service levels and language. “The problem is that there are so many companies out there that tie themselves to the moniker of ASP,” Gartner research director Chris Ambrose told CRM Buyer. “Some of these vendors started out as product companies that decided to get on the ASP bandwagon, so they haven’t built all of [their] competencies around delivering services — such as [an] SLA.”
Of course, much depends on how critical an application is to a business. “This is what will drive the performance agreement that the enterprise will want out of the ASP,” Ambrose said. “It may be that the application plays a minor role in the business — in which case, the company should do a cost-benefit analysis to see if it pays to negotiate a stringent SLA. You don’t want to overpay for a high level of service unless you need it.”
Assuming, though, that an application is indeed mission-critical — and most enterprises view CRM in that light — there are a few essential points that should be addressed when negotiating service contracts.
When an SLA Is Not an SLA
Standard boilerplate clauses in most SLAs include availability of the application, which ranges from 99 percent (considered low availability) to 99.97 (considered a high level of availability), with the majority settling around the 99.5 percent range, according to Ambrose.
Other issues important to enterprises are user support and incident response time. Most ASPs tend to offer tiered levels of support. Incident response time is based not only on the severity of the incident, but also on the level of support the customer purchased.
However, no matter how diligently the customer has worked to incorporate the best levels of availability and service into an SLA, Ambrose pointed out that there is no actual SLA without penalties for failure to meet the prescribed terms.
Such an agreement is not easy to achieve — ask any company that has tried to negotiate a benefits- and penalty-based contract with a systems integrator. However, Ambrose said that because ASPs include such a broad class of businesses — some of which are more mature than others — there are a variety of approaches to this issue.
“Many might have some kind of performance credit in the contract. It may not be a monetary penalty but instead provides some relief on an upcoming monthly invoice or some percentage of that invoice,” he said. In some cases, one sees very complicated calculations used to establish those conditions.
Termination for Cause
A related issue is the matter of termination because the ASP did not meet the specified service levels. Some people feel that this is implied in a contract, but others do not. Thus, it is important for a company to spell out the terms under which it would want to terminate the agreement for failure to meet its requirements.
“If the only recourse the enterprise has are financial penalties — which may be minor compared to the overall value of the contract — the service provider can continue to miss metrics month after month,” Ambrose said, “but the enterprise cannot terminate the contract for cause because it wasn’t tied to missing performance metrics.”
Another tricky matter is the use of averages in determining availability. “Some vendors like to calculate this based on the average uptime in a given month,” Ambrose said. “We don’t advocate this.”
It is possible, he said, that a system could be down for an entire day in a monthly period, and the service provider could still meet its promise of availability. Ambrose recommends negotiating for a shorter time period on which to base the calculation, such as a week.
Fortunately, given the quality of service providers in this space, these clauses should rarely kick in. However, should a company find a mission-critical system down for an entire day, at least it would not have to endure insult on top of injury by having the vendor insist that it had met its monthly availability metric.