I promised to give some practical advice about how to approach SaaS contracts. As you will probably find out, it’s just the same advice I would give about how to approach any contract that passes by your desk.
A contract is contract
My first piece of practical advice: a contract is a contract is a contract.
If you have a contract that describes what you are providing/buying well, that defines the roles/responsibilities, and then has reasonable boilerplate, you have a great contract—in any context. And that includes SaaS/cloud computing contracts. So if you are confronted with a SaaS contract, don’t go crying to expensive outside counsel who will tell you things that may be untrue—okay go ahead, do that. But in the end, what you need to do is put your common sense thinking back on and go back to the basic principles around contracts.
Know what you’re buying
Understand what you’re buying. Are you purchasing a new cloud based CRM system where your sales and account management teams will store leads, contact information, and support information? Are you purchasing subscription billing and marketing solutions like my company offers? Are you buying wads of network (“cloud”) storage from a large web services vendor? None of these are the same, and I believe their contracts should look different too. Sure, some terms will be similar, but these can be very different products.
More than knowing what you’re buying, make sure you are working off paper that is appropriate for what you’re buying. One thing that bothers me to no end is that I have to negotiate a contract for my company’s services on the buyer’s paper, which has nothing to do with any sort of SaaS or cloud vendor. Instead, it is either generic professional services agreement (which says that our products and services are work-for-hire—sorry, that’s not happening) or some sort of IT procurement/enterprise agreement with massive amounts of licensing terms. If it is a SaaS contract, use SaaS paper.
Case in point, I was negotiating a purchase for a SaaS web conferencing product as a buyer. The paper from the vendor, a large enterprise that had acquired this smaller SaaS company, was the enterprise IT paper that included Subscription and Support maintenance fees. This had nothing to do with what we were buying. I sent that paper back and said give us something that makes sense. (Thankfully, they were smart enough to dig up a pre-acquisition contract and just use it, to the chagrin of the enterprise legal department)
Whose paper? Doesn’t matter that much if you know what you’re doing (sort of…)
Tie these two concepts together and you get this: understand what you’re buying and then approach whatever paper that crosses your desk like it’s just a normal contract. Let’s say you get that nasty enterprise hardware contract for a simple SaaS service. If you know what you’re buying or selling, you’ll see unrelated provisions and just delete. For example, if anyone tries to insert a source code escrow provision into our form contract, I won’t even engage in that discussion: it’s simply deleted.
That being said, if there is good paper, you should use it. I’ve heard people say that it needs to be on their paper and I end up basically rewriting my contract into their format. That’s a waste of time. If there is a good, applicable, and relevant contract from the other side, just use it and edit away.
