What to Include in a SaaS Contract?

mike.brennan — Tue, 22 Apr 2008 00:27:48 GMT

Software as a Service (SaaS) is a distribution model in which applications are hosted by a vendor and made available to customers over a network. Both hardware and software are owned by the provider and maintained at its datacenter. In a true SaaS model, both are also shared by all clients, although user data is divided. In addition, all customers are on the same version and instance of the application. The software is typically leased, although it is sometimes licensed as if it was being bought.

Over the past few years, a critical mass of adopters, better usability, enhancements to GUIs have all driven organizations both large and small to adopt the SaaS model. Coincidentally, a number of large, well-established enterprise application giants have built up substantial SaaS businesses in recent years to compete with younger upstarts.

The four greatest value propositions driving SaaS adoption amongst HR technology buyers are:

Faster time-to-value through configurable applications.
Mitigated risk through minimal upfront costs and pay-as-you-go procurement.
Less reliance on support from internal IT departments that are too busy to help.
Economies of scale like any outsourcing model.

However, in order to realize these, you must first contractually agree with your SaaS providers on the particulars of how these opportunities will be realized. I have learned from working with many clients that there are things to watch out for when engaging a SaaS provider. Moreover, many have told me that they include written stipulations in their contracts to protect their interests such as:

Application Support. Most companies get service level agreements (SLAs) on support related to the application running properly as well its availability, including response times, and notifications of outages and how soon after a failure you must be notified.
Agreement on what an active user is. This is not unlike contracts related to behind-the-firewall implementations. However, reports should be generated more efficiently given that this is how the SaaS provider runs its business.
Security. Typically these requirements (e.g., intrusion tests, SAS 70 Type 2 Certificate) are covered pre-contract during the evaluation period.
Data back-up and recovery. Similar to security bullet above.
Data ownership. Ensure that your provider will enable you to easily migrate your data should you decide to move to a competitor or bring the solution in-question in-house. SLAs related to data migration in such events are not uncommon.
Ownership of source code. This may be covered through an escrow account. Even financially sound companies get shut down from time-to-time. And you never know when someone is going to win a patent infringement suit against your SaaS provider.
Integration non-SaaS systems. Requirements related to frequency, data mapping, and file format are the biggest gotchas.
Growth. Include and define provisions (i.e., milestones) for growth that will allow you to lower your average cost-per-user.
Training and Certification of Support Staff. While ‘major release' is not a term often uttered by a SaaS provider, some are more significant than others. We have seen clients require that all support personnel assigned to them be trained and certified on the latest version.

I have learned about these points through lessons learned by clients and service providers. However, I know this list isn't exhaustive. I'm curious as to what pearls of wisdom my KI colleagues can share based on their experience. And I'm even more curious to hear from those of you who have been involved in a constructing or negotiating SaaS contract. KI does not provide consulting related to either of these areas.

Consultant's Corner

What to Include in a SaaS Contract?