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.

SaaS Customer Life cycle - Pre-sales

Let me start by saying sales is certainly not my area of expertise. I couldn't do what sales does. I couldn't convert a lead to a prospect if my job depended on it, and I am certainly not the person who is going to come in and make sure a deal is closed.

I have spent plenty of time doing pre-sales support, and that is what I will focus on in this post.

I am going to state what seems like it should be obvious:

The sales team should understand what SaaS means. The sales team should be able to not only understand what it means but also how to communicate the value proposition to prospective clients, at least at a high level.

The technical sales support is crucial. Enterprise clients are becoming increasingly familiar with SaaS. This increase in familiarity is both good and bad. The good news is that as the SaaS delivery method matures prospects are not in the situation of needing to be convinced SaaS is valuable or viable. The bad news is that the types of questions that you are likely to face seem to be more focused.

Any technical pre-sales support should be ready to explain basic architecture (both network and application) as well as security and privacy issues. It would be helpful to be able to explain how the upgrade or migration process works once a client is up and running. This may go hand in hand with questions about product road map and the methodology your organization uses to develop and share that road map.

A mature SaaS organization can use the pre-sales period to distance themselves from less mature competition. This can be a significant differentiation point. An important part of Software as a Service is the service part. If an organization has an advantage in that area it should be something that prospects understand.

This period is also the time to set expectations with a prospect. This can make all the difference for the relationship and the teams that follow after signature.

Things to be clear about during the sales cycle should include implementations (how long, what is required from client, cost, etc) as well as how migrations or upgrades will work moving forward.

Any ambiguities about implementation and/or future upgrades will likely lead to incorrect expectations. This can damage a relationship right from the start if there are significant relationship challenges around deployment.

If both of these issues can be clearly communicated and expectations set correctly then the relationship has a much better chance of turning into a positive long term relationship.