Contact Us
Who We AreWhat We DoOur ClientsNews & EventsCenter of Excellence

Consultant's Corner

Previous Next
5

What to Include in a SaaS Contract?

Posted by Mike Brennan Apr 22, 2008 12:27:48 AM

 

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:

 

  1. Faster time-to-value through configurable applications.

  2. Mitigated risk through minimal upfront costs and pay-as-you-go procurement.

  3. Less reliance on support from internal IT departments that are too busy to help.

  4. 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:

 

  1. 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.

  2. 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.

  3. Security. Typically these requirements (e.g., intrusion tests, SAS 70 Type 2 Certificate) are covered pre-contract during the evaluation period.

  4. Data back-up and recovery. Similar to security bullet above.

  5. 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.

  6. 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.

  7. Integration non-SaaS systems. Requirements related to frequency, data mapping, and file format are the biggest gotchas.

  8. Growth. Include and define provisions (i.e., milestones) for growth that will allow you to lower your average cost-per-user.

  9. 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.

 

 



Add a comment Leave a comment on this blog post.
Apr 22, 2008 12:53 AM Reply Click to view Jason Averbook's profile Jason Averbook

Quick comment Mike - how often data is available for download and what subset of data. In a recent negotiation, it was revealed that only once a week and a small subset was included, everything else was additional cost. It is important to get in writing what is included and what isn't.

Apr 22, 2008 1:51 AM Reply Click to view Andy Gebavi's profile Andy Gebavi in response to: Jason Averbook

I concur with all above points listed. As a follow on to Jason's point, I think it's most important to fully understand the standard service agreements the vendors provide. Given the characteristics of the SaaS model (multi-tenant, single code base, standardized platform), it would be very difficult for vendors to maintain custom SLA's for their hundreds (sometimes thousands) of customers. Most of the SaaS vendors have developed varying levels of premium service (for additional cost) for customers that require service above and beyond the standard service levels.

 

So, the most important advice I could give a client is to try to anticipate your organization's service level needs, understand what the vendors provide within their varying levels of service, and choose accordingly. Because chances are you won't be able to negotiate a custom SLA the way we used to for ASP or HRO deals.

Apr 28, 2008 2:44 AM Reply Click to view Jason Averbook's profile Jason Averbook

Interesting article below from CIO Magazine

 

http://www.cio.com.au/index.php?id=302117702&rid=-154

 

Some helpful tips..

May 27, 2008 8:30 PM Reply Click to view Phil Deys's profile Phil Deys

This is a nit, but it came up recently for me so I thought I'd comment...

 

All vendors will put up-time parameters in their SLA. It's important to define what, exactly, up-time means. Does it mean the little green light on the front of the server is blinking? CPU and memory are not spiked for more than a few seconds? The server can be pinged?

 

What I've seen happen is that insufficient monitoring is in place and the vendor isn't even aware that a client's site is down. There needs to be a monitor that logs in to the site and navigates to a few screens to make sure the site is actually up. This is a question to ask during due diligence and also an item for the SLA.

Jun 10, 2008 10:48 PM Reply Click to view Jason Averbook's profile Jason Averbook in response to: Phil Deys

Thanks for the post Phil. What do you recommend related to this item? Have you included this?