Enterprises are increasingly willing to rely on data storage in the cloud and software as a service (“SaaS”) solutions. These are significant changes from the traditional software model where you store your data locally and your enterprise licenses the software it uses. This article will discuss some unique contract considerations in SaaS deals and how SaaS deals differ from traditional software licenses.
Some Definitions
Before the non-techie readers zone out, this article will turn to some fundamental definitions. They are neither mysterious nor complex.
It all starts with what is cloud computing and where is the cloud? You need to understand this as a prerequisite to understanding SaaS. Cloud computing for the purposes of this article is simply the delivery of computing and storage services over the Internet. If you have ever stored your music collection with Apple using iTunes or your photos with Flickr, you have personally used the cloud. Of course, enterprises use the cloud too.
The cloud physically lives in data centers around the world. Amazon is a well-known example of a cloud services provider since it sells access and use of its data centers to other enterprises for their business needs. So to visualize the cloud, do not look to the sky. Instead, you should think more mundanely of racks of computers gorging on the power grid in a cool room with lots of ventilation so that they do not fry. That is the cloud.
SaaS is the delivery of software from the cloud to your computer. If you use Gmail or Yahoo mail, you have used a SaaS solution. Gmail is run by complex email software, but you have do not have the software installed on your computer. Rather, you access this complex software using your browser. This is as compared to the traditional software licensing model that has email software like Outlook installed on your PC’s hard drive.
Negotiating Agreements
Your company’s ability to negotiate an agreement for SaaS and cloud computing services is no different from its ability to negotiate any other type of tech deal. While service providers may argue that they cannot agree to custom agreements with individual customers because of the shared infrastructure inherent in cloud and SaaS solutions, this writer’s experience says that while the refrain is common, it is simply not true.
What is true is that your company’s ability to negotiate the poorly written form agreements service providers foist upon you as non-negotiable PDF’s is directly proportional to things like the size of your spend, the length of the agreement, and your company’s size. If this sounds no different from the calculus of your negotiating power in almost any other type of deal, that is because it is not.
SaaS is not a License
The starting point in negotiating any SaaS deal is for you to understand that SaaS is not a software licensing deal. It is a complete paradigm shift from licensing software to providing it as a service. Thus, if the service provider sends you a form agreement with licensing language like “Buyer hereby licenses the software installed on Seller’s server,” you have already learned that the service provider’s lawyers are living proof that even the bottom of the law school class can find a job too.
On a more serious note, I will not try to redline a SaaS agreement that feels like a license. The document is simply a throwaway and I am quick to tell the other side the bad news. If I can, I will use this as an opportunity to send them my SaaS agreement, which has a tilt toward my client. (He who drafts sets the agenda.) Sometimes service providers will buy into this because of their hope (as cynically interpreted by this writer) that they can use my agreement as the starting point for the future redo of their form.
Smarter service providers will not let me get away with my form as the starting point for the discussion, but of course, the smarter ones do not send SaaS agreements that read like licenses. Either way, this conversation about the agreement being completely inappropriate creates some interesting discussion. If there is any good news here, it is that over time this writer is seeing fewer licenses purporting to be SaaS agreements.
A correctly written SaaS agreement is a service agreement without a license to use anything.1 By analogy, think of the plain old telephone service (“Pots”) your company buys for landlines from Verizon, AT&T, or whomever. Your company gets a dial tone that you instinctually know has lots of software behind it. Nonetheless, your company does not license any software as a part of the Pots deal. All your company is buying is a service. What the telephone company does, and the technology it uses to provide the dial tone is their problem.
With SaaS, it is the same thing. Your company does not license the software underlying the service. It simply buys a service that may happen to have software behind the curtains to make the service work. Everything about your agreement with your service provider must reflect this reality underlying SaaS.
Some Key Contract Considerations
In all SaaS contracts, you will have the negotiations regarding the usual provisions like limitations of liability and exclusions from the limits, indemnity, and all the other usual suspects. However, this article will focus on a few examples of considerations and provisions that are unique to SaaS deals.
Service Level Agreements
Probably the most important part of any SaaS deal is the negotiation of the Service Level Agreement (“SLA”). Since your service provider runs and delivers the service to your enterprise in a SaaS arrangement, it is essential that you have clear and objective provisions regarding things like uptime requirements, speed, responsiveness, and the like. Typically, SLAs will provide for credits against the next month’s fees if your service provider does not meet the requirements of one of more of the specific services levels. Also typical are provisions that limit the total of all credits to between 10% and 20% of the fee in any given month.
While it is tempting to write a long SLA with many specific metrics, this writer finds it more effective to push my own client to focus on the metrics that are truly important to it and focus the negotiation to just those. Otherwise, it is easy to get lost in minutia.
Moreover, do not – I repeat – do not get lost in demanding service levels beyond what your company needs. Some downtime and occasionally deficient service are often reasonable risks depending on what the service does and the enterprise cost associated with problems.
You may have heard terms bandied about like “five nines” and “four nines” uptime. In English, this translates to 99.999% uptime and 99.99% uptime respectively. With a 99.999% (five nines) uptime SLA, the service provider promises that the system will be down no more than about six seconds per week. With 99.99% (four nines), the promise is downtime not to exceed about one minute per week. If the system uptime does not meet the standard required by the SLA, the contract would typically award a credit that would be applied to the next month’s bill.
The point of this numbers exercise is to make the point that four and five nines are rigorous standards that come with a cost. If your enterprise wants and needs five nines, your service provider may have to throw lots of redundancy at the promise and that redundancy comes at a cost to the buyer. For example, five nines might require using two different data centers that are geographically remote from one another to help accomplish the SLA’s requirements just in case of a power or weather related problem in one particular geographic area. This type of redundancy is not free.
So, if your operation is tolerant enough to accept 99% uptime (two nines in the lingo) or about 7.2 hours per month of downtime, go for the lower price that probably comes with that lesser SLA.
You may remember all the controversy about cloud and SaaS services that followed storm related outages at companies like Netflix and Salesforce.com in June 2012. Many of the articles at the time spoke about the reliability issues inherent with cloud and SaaS services. Ridiculous.
Even if your own IT department ran its own data center, no sane CIO would ever promise 100% uptime. Even an attempt at five nines uptime would require your CIO to demand increased funding for redundant hardware and a redundant location. This does not come cheaply.
And this brings you back full-circle to the importance of SLAs. If you need a certain level of service, your agreement should reflect that. Careful and thoughtful contracting can help your company accomplish what it needs in the cloud with SaaS. Moreover, since SaaS fees are usually in the nature of monthly recurring service charges, your company could avoid the large capital expenditures required to run its own data center and local software installations.
Chronic Downtime
An area of legitimate concern with SaaS deals is the mediocre service provider whose failures never quite reach the level of a breach of contract, but rather are more in the nature of every month it misses one or more service level in ways that are annoying and disruptive. This is a problem your agreement could address using what some commentators refer to as a “chronics provision.”
With this type of provision, you might say something like a failure to meet the SLA required metric on three or more individual items in three consecutive months or four of any consecutive six months would be considered a material breach of the agreement.
The buyer of the service would want a provision that says that the credits provided by the SLA for failures would not be the exclusive remedy for “chronics” and that the buyer could seek all damages permitted by law. Obviously, the service provider would want “damages” capped by the credits permitted by the SLA. Many factors would determine how this plays out including the relative negotiating power of the parties and the cost of the service.
Ownership of Data and Risk of Loss
Since your company’s SaaS provider will often store data as a part of a SaaS deal, it is important to have express provisions that appropriately deal with the issues of data ownership and risk of loss if data is lost, damaged, or compromised.
Data ownership is the easier one. The contract must have an express statement that the customer owns its data and then continue with appropriate authorizations for the service provider to use the data solely for the purposes of providing the services pursuant to the SaaS agreement. No ambiguity should ever be acceptable in this area.
Lost, damaged, or compromised data is the tougher one to negotiate if for no other reason that it is like any negotiation over risk of loss. The SaaS provider’s rhetoric includes things like, “We are not charging you enough to bear this risk” and “We are not an insurance company.”
The customer’s pushbacks typically include, “You must bear responsibility for you actions” and “Your reticence to accept responsibility is causing us to wonder about your own confidence in your own abilities.”
Norms are Lacking
People are often in search of the ever-elusive norms in the industry. Using the example of risk of loss provisions, this writer must conclude from his extensive experience in doing these deals that there are few “norms” and that every deal stands on its own relative merits.
If there is a norm, it is that sophisticated enterprise level SaaS deals are complex exercises in negotiation and contracting and that they usually require many weeks of discussions before the parties can conclude a deal. The examples of important provisions discussed in this article and basic negotiation tactics like pushing back hard, asking for more than you really need, and not buying into the vendor’s form are the foundational concepts to effectively negotiating a SaaS deal.
1 Sometimes a SaaS solution requires special software and not just any browser to access the software being delivered as a service. In that case, there may be a license limited to that special software that may be installed on each PC or handheld device that accesses the services. However, the generalization that SaaS is not a licensing arrangement remains true.
