Software-as-a-Service (or “SaaS”) is a term that gets bandied about a lot these days. Lawyers and techy people might like to get into the nitty gritty of whether or not something is SaaS, PaaS, or IaaS, but at the end of the day the customer at the end of it usually just wants to have some certainty over some common concerns. So, if you have built a SaaS or similar solution, you should try to think about how you meet your customer’s needs and expectations (or how to manage them at least).

As a technology lawyer who has worked with many start-up SaaS businesses over the years, I often see technology solutions that have been built at pace working toward developer-led objectives. This can often mean that more customer-focused elements are not considered until the end of a project, and very often after that!

Most one-to-many SaaS providers will not want to have to negotiate different terms with each customer. Either the cost of negotiating the contract can be disproportionate to the profit margin for the service, or the infrastructure (and security layer wrapping around that) has to take a certain form because of the nature of the service. That means it is crucial to take a step back and consider how you can arrive at a position that will satisfy the majority of your customers’ needs whilst not exposing you to too much risk in the process.

With effective early engagement with legal advisors and other stakeholders, you can prepare your services and terms to cope with most customer requirements in advance, thereby reducing the time to revenue and helping you scale with certainty.

There are a number of very common concerns that SaaS customers have. Sometimes a customer might have had a bad experience of SaaS with a previous supplier and that can focus their attention on that specific issue. Whilst it should be a relatively easy thing to explain away such concerns, that assumes you manage to get to the stage of having a conversation, bear in mind that negotiations can quickly become costly where many terms have to be negotiated.

Regardless of what has happened previously, it is never a bad idea to be prepared to deal with common customer queries, as failing to have an answer can potentially be worse than presenting the wrong one!

These are a few of the most common concerns I see raised by SaaS customers, and top tips for dealing with them.

Price

Whilst the price is up to you and market reality, the customer will want some sort of control over how you can increase your prices or charge for additional services (as customers rarely object to price reductions).

Agreeing 30-day payment terms isn’t likely to be the source of any an issue for most people, though it is common in SaaS for there to be annual terms (by which I mean the length of the contract, not 365-day payment terms!) linked to either a lump sum payment or a series of payments towards that annual cost. Clarifying how those costs become payable over time is something to think about in advance.

This means that the customer will usually want some information or contractual guarantees to address the following issues:

1. How long is the price fixed for? When could it be increased?

It is common practice with SaaS providers to agree to a fixed initial term, anywhere from 3 months up to many years, and usually the price will be fixed during this period but not always.

A fixed-term might revert to another fixed-term, or it might switch to a rolling monthly contract, like with many modern subscription services.

2. How much can the price increase? How is this calculated?

If you don’t specify what the price is going to be in the future, it could be anything at all (within reason). For that reason, many customers will request a price increase cap mechanism. This might refer to some sort of inflation measure such as the Retail Prices Index and will usually place a cap on any price increase by limiting that to the level of RPI plus a certain percentage. It can also be as simple as capping any price increase to no more than 10% per year, but that’s less ideal where inflation rises closer to that mark.

Sometimes licenses are granted to an enterprise as a whole and not just to a single organisation, so it would then be important to make sure that any changes to the scope or scale of the customer’s organisation can be taken into account to adjust pricing at regular intervals (if not on a live basis). It is generally wise to avoid providing open-ended licenses to anything to third parties who you can’t identify, and losing track if that can frustrate efforts to protect your intellectual property, among other things.

If there are usage-based pricing metrics that could increase the price, these will also need to be set out somewhere and can’t just be wedged in later – see below for more detail. 

3. Are there any add-on or additional costs? Does higher usage increase the price?

There can often be usage-based metrics for pricing which can be confusing for some customers, who would prefer to have as much transparency and visibility over their spending at all times. Considering a fixed cost and allowing for a certain level of usage can be a wise move.

Having a clear pricing table with proper definitions cannot be underestimated, and yet this is often one of the last things to be considered. Taking into account the technical infrastructure needed to track levels of usage, this is something that should be considered well in advance of any conversation with a customer.

4. Updates and new versions – an all-inclusive roadmap?

Two things you will want to be clear on are:

1. What the customer is getting under the current agreement; and
2. What the customer is not getting – i.e. what the supplier might want to hold back and offer under a separate agreement later.

Some customers may rightly or wrongly expect that all future developments, features, versions, modules, and add-ons of any kind that you make available alongside your core product should always form part of their SaaS subscription at no additional cost to them.

Whilst an offer like this can be attractive as a marketing tool, it can restrict your ability to seek investment against a roadmap if you don’t have any ability to charge for that future release. Some models take this into account in their subscription fees, and so it’s important to assess whether your margins make this a wise idea or not. Playing it safe and managing customer expectations surrounding what, if any, development effort they might acquire the benefit of later is rarely going to be a bad idea. Initially setting out clear functional criteria in a specification can help you clarify expectations in this regard.

Your options here can vary, and it will almost always be a commercial decision for you to take in each case, though you will want to keep an eye on what your competitors offer to make sure you don’t diverge too much from the norm.

DISCLAIMER: The information and opinions expressed in this article does not address individual requirements and is for informational purposes only. It does not constitute any form of legal advice and should not be relied on or treated as a substitute for specific advice relevant to your particular circumstances.