fbpx

SAAS CONTRACTS – A PLAIN LANGUAGE EXPLANATION OF WHAT THEY ARE AND WHAT THEY DO

Software-as-a-Service (or SaaS) products have been a buzzword in the tech space for a few years now. Many entrepreneurs are developing wonderful new SaaS products with great utility, but understandably find themselves out at sea when it comes to the practical roll-out and B2B (business-to-business) or B2C (business-to-consumer) contracting stage.

It’s okay to feel a bit stuck at this point – don’t let this deter you! Knowledge is power, and knowing some high-level aspects of what needs to be in your SaaS contract with your customers will position you well to seek out sound legal advice, and ask the right questions.

Let’s start at the start: A SaaS product is a software which is hosted by a central provider, and offered to customers through the internet. Instead of being an installable or downloadable program on the user’s hardware, users access SaaS products simply through a web browser. Usually developers will develop the product, and then arrange for a central provider such as Amazon Web Services to host it. Reported benefits of SaaS arrangements include:

  • Hardware failures don’t cause significant data loss;
  • Physical data-hosting machines and complex system configurations don’t need to be expensively maintained by professionals;
  • Continuous updates and new iterations can be applied in real-time using an agile methodology; and
  • Economies of scale can be easily adopted.

It’s worth saying that SaaS contracts need to be tailored to the characteristics of the SaaS product, the functionality that it offers, and who its target market it, so a cookie cutter agreement might leave you exposed.

Below are some big-ticket items which are basic elements of a SaaS Contract, to start off your thinking.

1. ACCESS Timeframe

Think about how long the user will be able to access the program for. This could be for a fixed term, yearly subscription, or a month-to-month arrangement.

2. Payment model

2.1 How are you going to charge the customer for their usage of the product? Your pricing structure will usually be a big drawcard for attracting users, and will need to work in tandem with the contract timeframe.

2.2 There is no right or wrong way to price your product – whether it’s an up-front payment, subscription model, pay-per-user or per quantity of data uploaded, tiered pricing (eg a customizable scale-up / scale-down model based on customer needs), or a combination of these, it’s up to you to decide what will work best for your product and to structure your pricing accordingly.

3. Specify other costs PAYABLE BY THE CUSTOMER in addition to the usage fee

Being clear and direct about this will help you to avoid a dispute with customers regarding undisclosed or unexpected costs. Some common additional costs include:

3.1 Customer onboarding costs – such as the labour required for you to upload the customer’s initial tranche of data (if this is not the responsibility of the customer);

3.2 Costs incurred by the customer exceeding thresholds – for example if the customer uploads excess data than the threshold included as part of the ordinary usage fees; and

3.3 Any customisations you make to the product to cater to customer nuances or requests.

4. Description of what the SaaS product does

4.1 This is as much about managing customer expectations as it is about complying with the law. Customers want to know what they will be provided with (and what they will not be provided with), in exchange for parting with their money.

4.2 Many organisations choose to describe the product in a visually appealing and user-friendly way on their website, and simply refer the reader of the contract to the website for this description, rather than re-hashing it in the SaaS contract. If you do this, you’ll need to take into account that any amendment to that webpage needs to cater to the fact that the page forms part of a binding legal contract.

5. Description of what the Saas product does not do

5.1 Following on from the last point, it’s important to note that the product won’t be “all things to all people”. This is why it’s important to be clear and direct about what the product won’t do.

5.2 A main thing to think about in this respect, is industry regulation. Many of your customers will operate in industries which are subject to independent laws and regulations (eg. medical, gambling, B2C businesses) and will be using the software in the operation of their business. Unless the product is designed to cater to a specific industry, a disclaimer should be included in the contract that the software doesn’t purport to comply with industry laws and regulations, and that the customer is responsible for making their own independent investigations to ensure that the product complies with the laws and regulations specific to their industry.

6. Minimum Quality and Service Levels

6.1 It will be important for you to define a minimum yardstick that the product’s performance will meet and be measured against. If presented correctly, this can be another drawcard to incentivize potential users to sign up to use your product.

6.2 Minimum levels could be:

6.2.1 The percentage of time that the product will be available and usable (e.g. 98% of each week);

6.2.2 Response time of the product (e.g. how long the product will take to process a certain amount of data);

6.2.3 Capabilities of the product to undertake certain actions in a certain timeframe.

6.3 Be careful not to over-promise or over-commit here. You’ll also need to include exclusions for breaches of these minimum standards caused by third party actions or failures which are out of your control (for example, if the central provider host’s platform crashes), or communication failures etc.

7. Maintenance AND UPDATES

7.1 A SaaS product will go through multiple iterations during its lifecycle, and will almost certainly need updates, tweaks and potentially, add-ons. This will likely involve updates which require product downtime – you should include these times, if they are known or can be designated, in your contract so that users can plan this into their operational timetables.

7.2 Similarly with routine maintenance – consider executing planned maintenance, and running all routine maintenance checks requiring product downtime, during a specific monthly or quarterly (or other) window which is carved out in the SaaS contract. Even if you don’t use that window every time, it’s reassuring for you to know that it’s available if you do need it.

7.3 You’ll also be required to fix bugs or errors that arise in the program, and do so in a timely manner. The level of urgency will of course depend on the effect that the bug or error is having on the useability of the product, and how large the problem is.

8. SUPPORT

8.1 The Contract will need to set out whether you will provide routine support, or whether a user must seek that elsewhere. Most SaaS products will come with some level of routine support, given the nature of the SaaS model going through iterations and updates on a relatively regular basis. High-touch SaaS products will almost certainly require a greater amount of support.

8.2 If you’re providing support, be specific about what support you will provide and where the support “limit” is. For example, you should be excluding support that relates to the user’s hardware, or to the communication between the product and any add-ons that the user has developed to work in conjunction with the product.

9. TREATMENT OF CUSTOMER DATA

9.1 Ownership of data: Your customers will want to retain ownership of all data uploaded to the program. They will of course be required to take sole responsibility for integrity and legality of that data.

9.2 Licence to process and use data: The data will be uploaded to the program for use by the program, whether that be for processing, analysis or insertion into a software solution. Because the program will be using and retaining the data, you will need:

9.2.1 a non-exclusive non-assignable licence from the customer to process and use their data; and

9.2.2 a warranty from the customer that the data does not infringe another’s IP rights and is not otherwise in breach of the law, and an indemnity if this turns out to be untrue.

9.3 Data security / backups: You’ll be collecting data for your customers, and sometimes that data will contain personal or sensitive information, such as names, addresses, dates of birth, payment details, and perhaps medical details. Regardless of what is in the data, it’s important to implement measures to protect that data and the product from unauthorized use, breach, damage and unintended loss/disclosure of data.

9.4 In saying that, because you’ll probably be hosting the program through a third-party provider like Amazon Web Services – you probably won’t be actually collecting and holding that data and you won’t be able to promise airtight security (more on this soon). Therefore, it is a good idea to oblige your users to keep backups of all of the data that they upload to your product.

10. Host considerations

10.1 Third party hosts, will host through the cloud. It’s important to know exactly where the cloud is located; is it in your country, overseas, or a combination of countries? This is important to data integrity and data protection, because for example the laws of some countries allow their government to access data which is hosted on servers operated by their country’s nationals.

10.2 You should also consider the contents of your own contracts with hosts, to determine the rights and obligations that lie with you, vs the rights and obligations that you pass on to the host.

11. IP RIGHTS

11.1 The retention of intellectual property rights are of paramount importance whenever talking about any kind of software development. The value that you have created is in the intellectual property that you’ve invested into the software service, so you need to retain all right and ownership over that IP.

11.2 There are a couple of sleepers which also need to be covered. You need to ensure that the retention of IP rights extends to all modifications, updates, improvements, add-ons and troubleshooting that you provide during the term of the agreement.

11.3 You also need to prohibit users from copying, modifying or reverse-engineering the software, or enabling, assisting or causing a third party to do so.

12. LIMITATION OF LIABILITY

12.1 As always, you should limit your liability to the extent permitted by law.

12.2 Third party limitation: As pointed out before, because your service will probably be hosted by a third party on their own server, you can’t ensure absolute protection of user data. Therefore, you need to point this out and limit liability in the event of a loss of data or data breach caused directly or indirectly by the third party.

12.3 Type of loss: Following on from this, SaaS agreements commonly limit or exclude liability for indirect, consequential and economic losses caused by a fault or outage of the service or a loss of data. This is important, and you’ll be glad that you’ve included these types of clauses when you have unexpected hiccups, such as an internet outage.

12.4 Consumer protection: It’s not enough to pick and choose the liability that you wish to opt out of. Consumer protection laws provide consumers with statutory protections that you can’t contract out of, even if your agreement purports to do so – however this will only be relevant in B2C contracts where the service is being provided to an end user/consumer, as B2B arrangements have no such rights.

13. GOVERNING LAW

13.1 This is the part of a Contract which is usually placed at the end, and gets glossed over after readers have tried to process the complexities of the “meatier” parts of the contract.

13.2 Given that your SaaS product will probably be hosted on the cloud and be available to users in many different jurisdictions, it’s important to consider what jurisdiction is going to govern the terms of the agreement. You should designate a jurisdiction that you are based in or that you are otherwise familiar with, otherwise you might find yourself dealing with a dispute that’s subject to the laws of a country that is difficult to navigate and is completely foreign to you.

Now that you know what a SaaS contract is and some basics of what you should expect to see in one, the legal minefield around development of your product should seem a little less intimidating. If you’d like to talk to one of our professionals about your contract or product, please get in touch.

 

Like this article?

Share on facebook
Share on Facebook
Share on twitter
Share on Twitter
Share on linkedin
Share on Linkdin
Share on email
Email it to your friend