Most organisations buying software for their business uses will be looking at Software as a Service (SaaS) solutions. SaaS solutions have a number of advantages, not the least being that they typically avoid having to spend large amounts of money to buy a new version of the software every few years, allowing customers the ability to spread cost as opex over a number of years.
But as anyone involved in reviewing SaaS terms from a customer perspective will tell you, it’s a disheartening process where you are often faced with very one sided supplier terms that seem to pose a lot of risk. Given that you don't often have a lot of leverage to negotiate changes, the obvious question is what should an organisation focus on seeking to achieve when reviewing and proposing changes?
Is the solution you're purchasing a one-to-many solution?
Our first tip in reviewing SaaS terms is to identify whether you're purchasing a solution sold on a truly one-to-many basis and the impact that will have on the supplier's ability to provide different terms. For example:
- If a solution is truly one-to-many, the supplier may not be able to offer you better service levels, security protections or functional elements without effectively providing them to all of its customers (without payment). The supplier will also typically want maximum control over developing its solution and its roadmap for the benefit of all its customers without being beholden to one customer. Asking for specific protections in those areas, over and above what is offered as standard, is often a relatively fruitless task
- If a solution is one-to-many, and even where there are different instances of the solution for different customers, the supplier will typically want to own all new IP – even IP they develop specifically for one customer – which they can then roll out to other customers. While it may feel uncomfortable or counter intuitive to agree that something you've effectively paid for will then be given to others for free, this is often the nature of SaaS solutions, and the flip side is that in theory you should also get the benefits of this when changes are made for other customers.
Understanding the extent to which a solution is truly one-to-many (or, at the other end of the spectrum, a customer specific solution hosted on third party infrastructure), will help you determine how much is sensible to push for.
It’s also important to be aware of some of the provisions in your typical contracts that may just not work – for example traditional software escrow. Other traditional provisions may not make a lot of sense – for example, there may not be much point in having a post acceptance warranty period if you are paying for all ongoing fixes as part of an ongoing subscription fee.
The one-to-many model also provides some practical, rather than legal, protection. If you suffer a problem, it is highly likely all other customers are suffering the same problem. The supplier is likely to be highly incentivised to fix the issue, as it will be under commercial pressure from all of its customers (and potential customers). That may be more powerful than a single customer having a problem and having to rely on contractual remedies to seek a solution, particularly where such remedies are too expensive to realistically use.
What to watch for when reviewing standard terms
Of course, the nature of SaaS software subscriptions does not necessarily justify all the positions taken by SaaS suppliers in their standard terms and nor should customers simply roll over and accept standard terms without question.
In our view, there are a few key areas worth focussing on:
- Roadmaps and updates: Most SaaS suppliers are unlikely to promise how frequently they will release new software or that they will introduce particular functionality within fixed timeframes. They also typically won't want (and may not even be able to technically accommodate) customers being on multiple versions of the software which means when the software is updated, each customer will have to use the new version (as opposed to in traditional licences where customers could often choose to remain on older versions for a period of time). That doesn't mean a customer should have no control. If possible, it is ideal to have an obligation on the supplier to maintain a product roadmap and share it at a regular frequency. It is also often possible to obtain a commitment from the supplier to give the customer opportunities to feed into and be consulted on the roadmap. Some suppliers will agree to commit that each new version/update will only improve (and not decrease) performance, functionality and/or security. Finally, for some SaaS solutions a customer may be able to achieve a commitment from the supplier that they will provide a minimum period of notice of major updates which may give the customer a chance to test these (for example, to ensure that integrations with other systems will continue to work) and prepare for more significant updates with appropriate user training.
- Restrictions on raising fees: Many SaaS contracts will contain provisions allowing suppliers to unilaterally increase fees. Customers wanting to push back on these could seek to lock fees in for a specified term and to limit future increases, at least for a period, to some sort of index or fixed percentage.
- Easy termination and disengagement: One of the advantages suppliers often seek to push when marketing their products is the ease of moving from product to product. Of course, this doesn't work if the customer is committed for a long period without a right to terminate for convenience without significant termination fees. A right to terminate for convenience will be even more important to the customer if the supplier has rights to change/update the product or increase fees in a manner that may be unfavourable. Customers also need to think carefully about how they would disengage from a supplier and its SaaS solution on termination for any reason – in particular, it's critical to be clear about how and when the customer can access its data and what it will need to pay the supplier if it needs help to migrate its data to a new solution.
- Data protection: We still see many SaaS contracts which are very light on detail when it comes to terms regarding security and data protection, including breach notification obligations. This will often need to be a key area of focus when reviewing SaaS contracts. It's particularly important if the relevant solution will store or process personal information, and especially when the supplier and solution are based offshore. Even if the supplier will just be using personal data provided by the customer for the sole purpose of providing the SaaS solution, it's important to remember that for the purposes of the Privacy Act 2020 they will be acting as the customer's agent and the customer will be responsible for breaches of the Act if the solution does not have a reasonable level of security.
- Service levels and service credits: Service levels in SaaS subscription terms should ideally cover both the availability of the solution and promises regarding how quickly the supplier's helpdesk will respond to issues/problems as they arise (and ideally resolve or provide workarounds – even if only on a best endeavours basis). Suppliers are often very reluctant to provide service credits (or if they do provide them only doing so on the basis that the customer cannot take any action for further losses). Given they are often very low value it can be tempting to simply give up. However, in practice, it may be very difficult (or at least extremely costly) to pursue a SaaS supplier for damages – particularly if they are based offshore. In that context, service credits may provide some worthwhile comfort that if service levels are poor, the supplier will feel some pain (and the customer receive some compensation) that will incentivise the supplier to improve performance. If service credits are expressed to be a sole remedy for a service level breach, the customer may seek an exception to that where it terminates for breach of contract (so that it can recover its losses – less any credits paid – up the value of any liability cap). Of course, credits are only worthwhile if the service levels are well drafted, capable of measurement and will be reported against so that the customer can identify if they are not being met.
- Liability, governance and dispute resolution: It's all very well and good having a high liability cap (and often the caps offered by SaaS suppliers are pretty low), but if the SaaS solution has failed in a way which affects the supplier's entire customer base, chances are there may not be enough money to cover all customers' losses. Furthermore, if your supplier is offshore and the contract is governed by another jurisdiction's laws and courts, taking any sort of legal action to recover losses is likely to be cost prohibitive. If that's true of the solution you are purchasing, it's probably better to focus your efforts on the provisions that can stop matters ever getting to that stage – regular reporting and governance/meeting obligations, early stage dispute resolution/issue escalation regimes and ideally obligations on suppliers to produce and implement service improvement plans if service is poor.
- Implementation protections: Finally, it is worth considering what protections are required around implementation of the SaaS solution. Clearly not all SaaS solutions are the same. Some will be highly configurable, take considerable time and cost to implement, and involve complex integrations with other systems (and potentially even some bespoke code development – although that is often in everyone's interest to avoid that). In those circumstances, the customer will often want to engage an implementer to run the implementation project or require that the supplier undertakes the implementation work. The issue that customers often come up against is that implementation partners often don't like taking responsibility for ensuring that the SaaS solution is implemented to meet the customer's requirements (even if they've promised it will do so in response to an RFP process). On the other hand, SaaS suppliers involved in implementation will often seek to do so on terms that largely just deal with subscription to the solution and lack any detailed protections for implementation (eg provisions dealing with delay, acceptance testing or warranties regarding configurations meeting customer requirements). If your project does involve a significant implementation project, it is often wise to seek some legal advice on how to achieve some protection against the risk of a poor implementation project in your contractual terms.
This article was written by Amy Ryburn (Partner).
