Many software companies build products that live on the web and don’t install on local computers at all. Enterprise-focused companies call this SaaS; everyone else just calls them web-based or hosted services.
Either way, developers of these products sometimes look for customers among big companies. It is really common then that the customer’s contracts manager doesn’t quite get the nuances and sends over some kind of Master Services Agreement to document the deal. Those agreements are generally based on the idea that the vendor is providing a specific, custom deliverable and don’t fit the situation very well. I have been through this drill a lot and have a few observations about some of the important differences between a custom services and a SaaS deal.
1) Work for hire language. A Master Services Agreement will almost always say that the customer owns all technology and works created by the SaaS vendor during the course of performance. This would be true if the vendor was writing custom software, but is the opposite of what the vendor wants in a SaaS situation. This should be replaced with something that says the vendor owns all the software and anything developed during the term of the contract, and that the customer has a license to use all of it (subject to payment of all fees).
2) Service levels. The Master Services Agreement may not have any service level terms, such as an uptime guarantee or detailed procedures for responding to service errors. This can work out well for the vendor since it allows more flexibility and avoids difficult conversations about discounts if the service goes down.
3) Source code escrow. Some companies feel strongly that if an important vendor goes out of business they should be able to take over the source code to preserve continuity. With SaaS products these terms are especially inappropriate because the service is hosted- a customer would have to take over the entire service rather than just getting the source code to maintain an installation at its own facility.
4) On-site services. Master Services Agreements can use a lot of ink on issues like vendor behavior on the customer’s premises and the customer’s ability to replace vendor personnel. This comes out of the idea that vendor personnel will be in the customer’s data center regularly, which is not correct in a SaaS relationship. I watch out for language that is really egregious here, but mostly try to leave this stuff alone since it just doesn’t apply very often.
The point of this post is that a Master Services Agreement is the wrong tool for the job in a SaaS deal. From the vendor’s side, some terms definitely need to be changed, while others are not applicable but can be left mostly alone. I always try to make the minimum set of changes that will let everyone sign the deal and get the relationship underway, while making sure there is nothing in the agreement that can come back to bite my clients later.