SaaS Agreement

If you offer a software as a service (SaaS) app, it is likely easier for you to combine all your legal agreements into one: the SaaS agreement.

Many SaaS apps contain a series of agreements including Terms and Conditions (T&C) or Terms of Service (ToS), Privacy Policy, Disclaimers, and additional notices.

What is a SaaS Agreement

A SaaS agreement is a legal contract between a developer of the app and user using the app. The SaaS Agreement is a Terms and Conditions or Terms of Service for SaaS apps.

Like the Terms and Conditions or the Terms of Service, it contains the rules and limitations to how the SaaS app is accessed and used.

Many SaaS apps have this kind of legal agreement but still call it a "Terms and Conditions" or a "Terms of Service."

The name does not matter as much as the content. You just need to be sure the document covers the elements unique to SaaS apps and elements unique to your business.

Many of these agreements integrate elements of the Terms and Conditions, Privacy Policy, and Service Level Agreement (SLA) covering subjects like:

• Warranties
• Restrictions
• Use
• Billing terms

Most SaaS Agreements are more extensive than the basic Terms and Conditions because there are often more rules involved in using SaaS and cloud services.

Users should accept your app's SaaS Agreement the same way they would with others: through clickwrap. You should make the acceptance of the agreement a condition to entering billing information and proceeding to create an account.

What to add in a SaaS Agreement

Termination

Users need to know when service (the SaaS app) availability starts and ends. That includes listing circumstances that could result in immediate termination of user accounts or the service.

Soffront offers online and on-site client relationship management and marketing services. Its termination clause within its SaaS Agreement document is fairly general in that failure to follow the terms outlined in the agreement will lead to termination.

Also, it allows for termination with written notice from a user:

Other companies contain more detailed descriptions of their termination clauses.

Axosoft, a scrum software service, offers language on when services begin and the multiple circumstances of when they end, including non-payment for services. It also indicates that payment for any services performed is due at termination:

mySalesman is another example of a general termination clause. It states that the agreement is terminated when parties decide to do so:

Billing and payments

Payment terms are also important for SaaS Agreements. It is a way to be upfront with users about how much they need to pay, when, and how.

Like termination clauses, these tend to vary in length.

Soffront takes the quick-and-easy route with a quick description of possible payment arrangements and the requirement of a credit card on file. While it included nonpayment as a condition for termination under that section, that is mentioned again in payment terms:

mySalesman is a little longer because it is a subscription service. There are specific terms it makes known including the date of billing and late fees:

Sailpoint offers identity governance services and its payments are accepted through individual invoices and schedules. There are also terms allowing for the company to demand reimbursement for expenses from users and the requirement of tax payments:

This is yet another area where there is extensive customization.

Companies do not have identical billing practices. If the payments you receive from users are automated, you likely require less content in this section since many times, service is programmed to terminate when a payment fails.

Present payment terms clearly so users know what to expect but also be sure to have an out in case payments stop.

Licensing and Restrictions

The user does not own the app like an app where an EULA agreement is involved. SaaS app gives a license to use the service in order to avoid any terms regarding ownership over the app.

For most SaaS apps, you need to draft your agreement so that the license is for the services--not the software.

The problem with allowing a software license is it can allow the user to reverse engineer your product and possibly create a superior one that competes against you in the market.

Also, if your product suffers appreciable downtime, you can be held liable for the loss of the software and the service.

Offering a license for both the software and the hosting service exposes you to legal risks that you may wish to avoid.

Sailpoint licensing takes this approach by making it clear that it offers services and does not deliver software:

Soffront's licensing provision includes the software. However, unlike other examples, it offers both cloud and on-site services.

Under those circumstances, it likely has to license the software so in-house IT departments can make adjustments. For that reason, it assumes the risk:

You likely want to do the same in order to protect the proprietary interest in the software you are developing.

Axosoft takes this approach in a section on "Restrictions of Use". Not only are users not allowed to copy or reverse-engineer the software but they cannot license or sell their interest in the service to anyone else:

Sailpoint includes the same restrictions in its SaaS agreement and makes it clear that it maintains an ownership interest in the software, services, and documentation:

Warranties

If you have any warranties on your SaaS app, include those in the SaaS agreement too. The same is true if you disclaim warranties.

Sailpoint offers a general warranty regarding good services but does not guarantee that it will run the software error-free all the time. It offers some reassurance but does not take responsibility for elements beyond its control:

Soffront offers multiple detailed warranties. It offers the usual service guarantees while also refusing to take responsibility for user misuse of its services:

The trick to warranties is to offer reassurance of good functioning without making too many promises. Taking a general approach and then adding disclaimers is likely your best approach here.

Any additional promises can be set out in a Service Level Agreement.

SLA Terms

A Service Level Agreement (SLA) sets out the specific services provided along with the rules for using them. It generally includes:

• The hosting of SaaS software and customer data
• Support services
• And software maintenance services.

While it can raise expectations with your users, it is also a selling point.

The SLA can also describe what happens when there's downtime. These terms often address the amount of money compensated or measures taken to minimize damage to users.

Your SLA can be a separate document or you can include the terms of your SaaS Agreement.

Axosoft is very specific in its promises. In its SaaS section on service level commitments, it guarantees that its services will remain accessible 99.5 percent of the time during any given month.

However, it also waives liability if network availability decreases due to the actions of a third party:

mySalesman makes a similar promise in that it will make the effort to keep the service available but it also refuses responsibility for downtime during maintenance or if a third party interferes with the product:

Privacy Policy

Privacy terms can also be included in the SaaS agreement.

However, if you are doing business in the U.S., you need to comply with CalOPPA and include the name "privacy" in that agreement. For this reason, your best course is to continue providing a separate Privacy Policy.

It does not mean you leave out privacy altogether in your SaaS Agreement. Sailpoint has a separate Privacy Policy which it references directly in its SaaS Agreement:

Other companies would rather not deal with this issue at all.

Axosoft warns against submitting confidential information and indicates that it is not bound by all privacy laws, including HIPAA in the U.S. However, this is not essential to its services and it also offers a separate Privacy Policy page:

Others will contain privacy terms in their SaaS agreements.

Soffront's section on privacy is fairly extensive and explains that it will practice nondisclosure for two years after service concludes:

Even though Soffront addresses confidential information and protecting it in a SaaS Agreement, it also has a separate Privacy Policy page.

It's not a good idea to rest your entire approach to privacy on the SaaS Agreement -- especially if you do business in the U.S.

Include references to your Privacy Policy in the SaaS Agreement but provide a separate Privacy Policy agreement.

Whether you call the "SaaS Agreement", a "Terms and Conditions" or a "Terms of Service", legal agreements regarding the use of your SaaS app are important.

Be careful to not only define your rules (including payment terms) but to take steps to reduce the possibility of liability.