SaaS Customer Life cycle - Contract

This is part of a series of posts focused on the life cycle of a SaaS customer. The first post is here, and the previous post about pre-sales can be found here.

This post will focus on SaaS contracts. I feel like I have covered this ground in previous posts but in the effort to cover the entire life cycle of a client I will spend a little time on this topic again.

In the best case scenario any topics of discussion or concern will have been addressed during the pre-sales process so that contracts become a formality. In reality it seldom works this way. As this blog is focused on SaaS for the enterprise we should keep in mind that the notion of an adhesion contract that a client will just sign doesn't apply. There will be some level of negotiation for every contract, at least in my experience. The negotiation can sometimes start with which parties standard contract language gets used.

No matter what boilerplate contract gets used there are a few things that should be spelled out clearly.

• How upgrades / migrations are handled.
  
• Who owns what data
  
• Pricing model, including any custom requests if such thing even applies
  
• Scope of work, as much as possible without getting bogged down into specifics
  
• Clearly spell out any / all SLAs and how reporting on those SLAs will be handled
  
• What browsers, technology your application will support. Avoid specifics like IE 7 is also advisable. The language could be something more generic like "the latest stable release of IE" or "the most common 3 browsers on Windows".
  

Here is a short list of things that I would suggest NOT putting into contract language.

• Any specifics of the technical solution. I have found that many large firms like adding this language, it provides some sort of comfort to lawyers in some way. The truth of the matter is that adding the specifics (think what DB server, or presentation layer technology, etc) in a contract can lead to potential issues if/when those technologies change. My advice, just leave it out if possible
  
• Code escrow agreements. I have written on this in the past (see post here) and the honest answer is that even if a company goes out of business having source code is useless to the client. If a customer insists on such a term then clearly spell out it is the responsibility of the client to bear those costs and agree to a specific calendar time that the code will be updated.
  

There is obviously much more to contracts. I am not a lawyer and so I won't even bother trying to cover all the other stuff (liability, etc etc etc) as it lies beyond my subject matter expertise.

The most important thing is that the contract language matches the information what has been delivered during the sales process. The next team to follow shouldn't be hindered by contract language. Contracts are another tool to help set expectations with clients.