Best practices for negotiating a SaaS SLA

Ensure adequate uptime and support

Uptime is one of the most important aspects of a SaaS SLA, since even a small amount of downtime can negatively impact a business. Many of today's leading SaaS vendors offer 99.5% to 99.9% uptime -- with some caveats around scheduled maintenance in specified time windows. Some buyers feel these levels are too low, though the actual percentage often comes in higher than what was promised.

"Many top SaaS vendors, like Salesforce, publish their uptime on a public site or in a status dashboard in the app and consistently achieve far better uptime than the promise," said Liz Herbert, analyst at Forrester.

Enterprises should be realistic about SaaS SLAs and "not waste time hammering on things that are highly unlikely, if not impossible," Herbert said.

Review the support options and escalation path

SaaS is designed to be multi-tenant and standardized -- a concept that extends to its SLAs, too. Most vendors offer multiple tiers of support, with basic support included in the subscription. There also are premium options, but those tiers may not be as essential as they would be with a private, on-premises offering that requires more individual support. For example, if a SaaS tool stops working properly, it typically does so for all users. The vendor will be aware of the issue and work to fix it systemwide, so customers don't necessarily have to alert their vendor the same way they would with a private service, Herbert said.

However, if there are issues that go beyond the typical help desk ticket, an escalation clause can open up communication lines between the customer and the vendor. A clear procedure ensures an incident is routed to the appropriate support person. Typically, the clause will include a contact person in the case of a specific problem. Service request prioritization rules ensure the vendor responds and fixes the problem in an orderly and timely manner. For example, there may be multiple levels of impact, from critical to normal, and each level comes with specific response time expectations.

Define unavailability penalties

If something does go wrong, it's usually slow performance rather than unavailability. In that case, enterprises need to be able to prove it's the service provider's fault, not their own end users' internet connection. In practice, a one-second outage can be serious if it terminates in-progress customer sessions and causes data loss, no matter how little. If there is a violation, providers may have to pay penalties or provide service credits.

Once these penalties are defined, look out for exclusions that will protect the provider from risk. A five-second delay with perfect recovery may be only a minor annoyance and not an official SLA violation.

"It's a common mistake for procurement [teams] to treat SaaS like infrastructure hosting and argue about SLAs and penalties," said Duncan Jones, vice president and principal analyst at Forrester. But the SaaS vendor agreement doesn't involve the actual delivery, so enterprises shouldn't expect to receive a service credit or refunds if their availability expectations aren't met for reasons that fall outside the vendors' purview.

Think about customization options

Many enterprises question whether or not to customize SaaS offerings or how much customization to perform. SaaS products are typically designed to fit most use cases, and enterprises can deploy them right out of the box with little configuration. In some cases, enterprises can choose to tier SaaS products. For example, an educational institution may provide students with a basic version of Gmail but give faculty and researchers the same product with more capabilities, said Greg Schulz, senior advisory analyst at StorageIO.

It's a common mistake for procurement [teams] to treat SaaS like infrastructure hosting and argue about SLAs and penalties.

When you look at a SaaS product, you need to consider what best practices it includes, as well as configuration options, Jones said. If you decide to add customizations -- if the offering enables it -- the SaaS product will require more configurations, and those must be applied to future updates.

"A fundamental [aspect] of SaaS configuration is that all such changes must carry over from version to version, unlike on-premises customization, which you have to redo every time you upgrade," he said.

Additionally, SaaS vendors now offer platforms that are both flexible and extensible. For example, SAP provided advanced customization capabilities for SuccessFactors, its HR management service, through its SAP Cloud Platform. Enterprises should evaluate such platform options and weigh the costs, language support and customization abilities against a single SaaS offering. However, many of these choices often aren't included as part of a SaaS SLA.

Prioritize security, compliance and reporting

Depending on your industry or specific enterprise requirements, you need to be careful about what data resides in a SaaS application. These requirements need to be part of the SLA, said Ed Featherston, technologist at Cloud Technology Partners, a consulting organization.

Enterprises should include audit and reporting requirements as well to validate that the SaaS app meets security and compliance standards. For example, if the data that resides in the SaaS app needs to meet Health Insurance Portability and Accountability Act compliance regulations, it is the enterprise, not the service provider, that is responsible for violations. Enterprises are always responsible for their own data.