The SaaS Business Model and Some Common Legal Questions

I recently caught up with Cary Platkin. Cary is an attorney and more specifically was the in house attorney assigned to the CRM On Demand  & SMB divisions I ran at Siebel Systems. Cary was instrumental in developing Siebel’s CRM On Demand Service Level Agreement (SLA) and helping me and my organization negotiate many Siebel CRM On Demand contracts. 

I really enjoyed working with Cary because he acted as a member of my management team; he first focused on the business objectives I wanted to accomplish and then applied law to help me accomplish those objectives. He also helped me negotiate through a minefield of sticky issues like Vendor Specific Objective Evidence (VSOE) for revenue recognition and managing SLA issues.

Cary now has his own legal practice, Platkin Law,  and one of his specialities is helping SaaS startups. I asked Cary if he wouldn’t mind addressing a number of common legal issues that SaaS companies are faced with and he was kind enough to oblige.


Bruce:  What key terms should a SaaS Agreement contain?

Cary: SaaS agreements are typically subscription services agreements that address key customer concerns with service levels, security, privacy, and ultimately performance.   

More detailed SaaS-specific issues include: how mid-term add-on user subscriptions are handled; the details of the renewal process; whether support is bundled in or extra; what usage rules apply to your users; and how third party services are made available through your service.

There are many ways to address these issues depending on your particular business, but one thing is clear — SaaS providers need to ensure their hosting and other services vendors are providing “back-to-back” terms for the terms being offered to customers. 

If you use outside vendors to provision your service, it is critical that you secure the same or better terms from your hosting vendors than your customers will seek from you.   If your vendor doesn’t back you up on the commitments you’ll need to make, you’re really out on a limb.  On one hand, you might choose to manage your risk tightly by seeking a one-off exception from the hosting vendor, but this can slow the sales cycle.  On the other hand, you might choose to accept the risk, close your sale quickly, and make contract commitments that your hosting vendor cannot or will not back up.

Sometimes the risk is merely a matter of numbers that you can easily analyze.  For example, say your SLA is 99.9% with one day of credit for each one hour of downtime.  Your vendor has agreed to provide you the same basic SLA and credit, so you feel comfortable with that arrangement.  But what if a good handful of customers demand 99.99% and two days of credit for each one hour of downtime?  Your risk is merely the delta between the coverage you have from your vendor and the commitment your customers want you to make. 

Crunch the numbers and cross your fingers.

Sometimes the risk is more cut and dry.  For example, say your customer insists it must be permitted physical access to the hosting facilities and full access to the detailed SAS 70 Type II security audit reports on the hosting facilities.  If your hosting vendor limits physical access to its facilities and restricts your right to distribute the revealing audit reports (both common security measures), then promising these things to your customer is simply not possible without an exception from the hosting vendor.

So as you develop your contract terms early on, anticipate your customers’ demands, think through the details, and insist that your vendors get on board with your business and your customers’ needs.


Bruce: Speaking of SLAs, should a SaaS company offer a Service Level Agreement, and if so, what are the key terms they should spell out in the SLA?

Cary: Whether to provide an SLA or not is a business decision based on customer demands and competitive landscape.  Obviously, if you can avoid making a commitment, most lawyers will tell you that’s a good thing.

However,  I think SLAs are a critical element to successfully market a SaaS offering, and more and more, SLAs are required to adequately compete with both on-demand and on-premise alternatives.  If your SLA is world-class and you can make your current performance metrics constantly available to customers, your customers will appreciate it, even if your system goes down from time to time.

There are many types of SLAs, so the first question is what are you going to measure and commit to?  Support levels (response times for support tickets) and system availability are minimum requirements for today’s SaaS offerings.  You might also offer SLAs around reliability — number of outages or time between outages — or response time for your system’s ability to turn around input and output.  Beyond that, I think it can be a bit difficult to offer accessibility, performance or scalability SLAs because there are so many factors that contribute to these issues. 

In any event, most customers want the availability SLA and the performance warranty to run in parallel, so if the system is down for an extended period of time, the customer can max out its SLA credits, and still terminate the contract for breach of warranty if you are ultimately unable to fix the system.

When drafting your SLA, describe in great detail:

  • the definition of metric being measured (availability, reliability, etc.); 
  • how the SLA percentage is calculated;
  • the permitted exclusions to performance, including scheduled maintenance, customer-caused problems, and other issues outside of your control; and
  • how credits (or refunds) are calculated and applied to customer accounts.

One tip about credits:  don’t over-do it.  The biggest and best SaaS providers experience downtime events on a regular basis.  No one expects dial-tone availability, and you probably only marginally better than the customers’ own internal IT staff.  You don’t want one or two events to wipe out your business.  One day of credit for each hour of downtime is typical, but only after the system has already fallen below your target availability level and only for use with renewal terms.


Bruce: What terms do you feel should never be in SaaS Agreements?

Cary: I have been encouraging my clients to hold the line on accepting unlimited liability for confidentiality breaches. 

While security of the system and privacy of the customer data are critical customer concerns, you are not Fort Knox.  You can and should use the same type of security measures that other vendors in the industry use.  But if a hacker gets in despite these measures, is it really fair to hold you fully responsible for the damages?  If you said “yes,” then you agree that your monthly subscription fee is adequate to cover not only software and hosting services, but unlimited insurance against this common business risk.  Assuming you were able to buy insurance for this risk, how much do you think unlimited coverage would cost you?   Some multiplier of fees paid, up to a comfortable cap in the high 6 or low 7 figures, is probably adequate to close most transactions — why accept more and put your entire business at risk for something no one can absolutely guarantee?

You might be surprised to learn that other terms that might not be necessary in your SaaS subscription agreement are traditional software license terms.  If your offering is a pure multi-tenant hosted offering without any local client for the customer to use, then you are merely providing access and use of a service.  You are not licensing software in the manner most customers are accustomed to.  This is a subtle but important distinction for your template subscription agreement — SaaS is easier to sell when you continually reinforce the notion that this is not a software license plus associated hosting and managed services.  Rather, it’s a subscription service that is offered the same way to every subscriber.  There’s no delivery of software, no need for source code escrow, and most importantly for the multi-tenant solution, no custom hosting services terms often found in ASP or managed services agreements.  

Bruce: How should a SaaS company set up its Agreements from the beginning so it can avoid revenue recognition problems downstream?

Cary: I am not an accountant so I can only speak to the kinds of terms clients have told me are important to them.  First, SaaS providers know that revenue recognition is one of the great barriers-to-entry for publicly-traded enterprise software companies.  This is because subscription services revenue is recognized ratably over the life of the agreement as the services are performed, which runs contrary to the up-front revenue recognition model of traditional  software license deals.

Pure play SaaS providers build stable annual revenue streams that end up being more predictable.  So, the key to success with subscription agreements is to do all you can to keep the revenue flowing and renewing.    

Although revenue is recognized differently, accountants tend to care about the same issues that arise with standard software and services:  

  • Acceptance terms should be avoided (the free 30-day trial and smaller up-front start-up costs have made this easier for customers to bear);
  • Payment terms should not be extended too far into the future;
  • SLAs should be achievable and warranties should be “documentation” based; 
  • remedies for breach of these commitments should be credits on future services only, no refunds of fees paid;
  • termination for any reason should result in refund of unused prepaid fees only, not fees for services rendered prior to the date of termination.
  • future product commitments should be avoided. 


Bruce: What about multi-year Agreements? Should companies execute multi-year Agreements? If so, for how long?

Cary: Multi-year agreements are great for business — I haven’t met a person selling SaaS yet who preferred short-term subscriptions.  Multi-year contracts are typically procured through the use of higher discounts on fee that are paid annually in advance (or for unconvinced customers, quarterly in advance for the first year and annually thereafter). 

Customers being customers, they love discounts, but hate commitments.  So, I usually recommend terms that require the customer to pay the delta between the discounted multi-year rate and the higher short-term rate in the event it terminates the subscription mid-term or at the end of the shorter term.  SaaS providers with better leverage might even suggest some percentage of terminated subscription fees (up to 20%) as an early termination fee.

Bruce: If a SaaS company is planning to handle customers/data from the U.K./Europe/Asia, will they need make any special provisions?

Cary: This is a very complicated question that depends on many factors including where your company is incorporated, where your data centers and support staff are, where your customer is, where their end users are, what kind of customers they are, what kind of data they are uploading to your system, etc.

The easy answer is if you are a US company that has been selling to US customers, and you are suddenly selling into international markets, you should probably seek knowledgeable US or local counsel to work with your finance team to iron out required terms.

The most common issue that US SaaS providers face early on is Safe Harbor certification.  Many EU customers will not do business with a US company holding personally identifiable information unless it warrants that it complies with the UE-EU Safe Harbor framework.  Participation in this program requires annual self-certification that your company complies with security and privacy standards set forth by the US Department of Commerce at  I do caution clients not to over-commit to the customer here — EU customers have their own requirements to comply with privacy regulations.  When you are holding and processing data on behalf of your EU customer, you can only really commit to security terms, but issues related to the direct relationship between your customer and its individual end customers can only be managed by your customer.  A simple example:  if privacy regulations provide that the individual should have the ability to “opt out” of marketing programs that use their personal information, only your customer can manage this obligation, so it is not likely that you are in a position to help or hurt their compliance with this regulation.


Bruce: Are there simple things  a SaaS company can do develop a easy, scalable contracting process?

Cary: Perfecting the contracting process is often overlooked, but it can have such an important impact on close rates, cash flow, and customer satisfaction.  From a legal perspective, the easiest thing you can do to close contracts quickly is to use fair, industry standard terms that meet or exceed your customers’ expectations.  For each term in your subscription agreement, you should know not only the industry standard and your customers’ expectations, but also how much risk you are willing to tolerate.  Your law firm’s standard software or services agreement probably won’t do here.  You really need to think through each of the issues, or you’ll learn the hard way as customers begin to question certain provisions with each new deal.

 From an operational perspective, you’ll want to use an automated contract management system that integrates with all of your company’s workflows.  As such, you should solicit input from all of the company functions that touch this important process:  sales, sales operations, finance, legal, provisioning, and support.

If the offering is marketed to the low-end of the SMB market, then an online transaction system with a posted click-to-accept subscription agreement is ideal for an easy, scalable solution.  However, this is rarely sufficient for my clients — even if they can use an ecommerce system, there are always clients who want to negotiate terms or even use their own agreements.  So there has to be an exception process, and an 80-20 goal (or better) of closing as many deals as possible without business or legal exceptions.

I find that the best contracting structure for most SaaS companies is a simple page or two order form generated out of a sales order processing system.  The order form should contain all the applicable customer information, products and pricing being purchased, and a space for one-off terms applicable to the deal (future discount provisions, early termination rights, etc.).  And most importantly from a legal perspective, it should state that acceptance of the order form (by signing the form, emailing acceptance, or issuing a PO) constitutes acceptance of your posted subscription agreement (including the URL).  The posted subscription agreement can in turn reference other posted policies such as support policy, SLA, security policy, etc.  You should have a Word version of the subscription agreement and the related policies available for prospects that request the ability to redline.

Finally, your lawyer can help you minimize legal fees for negotiations by helping you prepare tools that empower non-lawyers to close deals with standard exceptions.  These tools may include:

  • a list of regularly-used alternative business and legal terms,
  • a “playbook” that describes the purpose of the various clauses in your contracts and provides alternatives,
  • an approval matrix to ensure that the right people around the company are approving exceptions to standard terms.

* * *

Legal Disclaimer.  The materials available at this web site are for informational purposes only and not for the purpose of providing legal advice. You should contact your attorney to obtain advice with respect to any particular issue or problem. Use of and access to this Web site or any of the e-mail links contained within the site do not create an attorney-client relationship between Platkin Law Offices and the user or browser.