Selling SaaS B2B What you need to know

I’ve broken this down into the following sections.

1. The SaaS sales process
2. Good Contracts Closed Quickly
3. What the buyer wants to know
4. The SLAs: uptime, response time, support levels
5. Handing contract complexity
6. The Sales-side Set Up
7. Avoiding duff clauses
8. APIs and revenue models
9. Selling SaaS to regulated companies

 Check your SaaS sales process

 The key understanding for any B2B SaaS seller is that getting to signed contract is a process, and it’s a process that starts a long time before you ask the buyer to commit. Unfortunately, most organisations have a sales-contracting flow which has evolved over time without coherent planning which, as a result, means that they have higher costs, close less contracts, and generate more friction.

 So, check your sales-contracting process and ask yourself this key question.

Is it really easy for the customer to agree and sign our contract?

That’s the key question, and it breaks down into these sub-questions:

1. Does our process answer all the customer’s concerns before we ask them to commit?
2. Does our process give the customer the right amount of information, but not so much information that they are scared off?
3. When the customer looks at the contract, do they find it easy to understand?
4. When the customer looks at the contract, will they find it fair?
5. Does our process distinguish between low value contracts (ideally, no human intervention) and higher value contracts (human intervention may be appropriate)?

Unless you can answer Yes to all these questions, your sales-contracting process is broken.

Good Contracts Closed Quickly (GCCQ)

To be designed effectively, a process must have an overall objective. The overall objective of any sales-contracting process is Good Contracts Closed Quickly (GCCQ).

In other words, the end point is an agreed contract which contains all the elements and protections you need (= good for the seller), which contains all the elements and protections that the customer is looking for (= good for the buyer), which is signed in the minimum elapsed time (absolute time, as well as person/hours consumed), and which generates the minimum of friction (= quickly, which won’t happen unless also = good for the buyer).

Why does this matter? Because the more time you spend closing the contract, the greater your costs, the longer it takes to get to the money, the greater the friction and – worst of all – the greater chance that your buyer will get lured away by a competitor.

What the buyer wants to know

So, GCCQ is a great idea, but how do you get there?

Here’s the starting point.  Before a SaaS buyer commits, there are eight (nine if the buyer is a regulated company) key questions to which the buyer wants to hear good answers (other than price, obviously)

The 8 key questions should be clearly answered in the contract, but they should also already have been explained to the customer through written, audio or video materials.

By the time the buyer is asked to commit, he or she should know how your business answers those 8 key questions and, to the extent that the buyer looks at the contract, they should just find confirmation of the positions that you have already outlined.

Here are the 8 key questions that buyers are concerned about. Not every buyer will be concerned by all of these, but all buyers will be concerned – and ask questions about – some of these. Answer these questions well, and you have taken a significant step closer to winning the contract.

Buyer Question 1

How much will I pay, and when?

Buyer Question 2

What do I get for my money? Am I getting value for my money? (What services? What SLAs and uptime/response time?).

Buyer Question 3

How long will the contract last? (How long am I committed for?).

Buyer Question 4

How easily can I get out? (Am I locked in? Can I terminate for convenience?).

Buyer Question 5

Can I get my data out? (Am I locked in? Is it my data or the supplier’s?).

Buyer Question 6

What if I don’t get what I paid for (support, service credits, exit for breach)?.

Buyer Question 7

What limitations of liability do I get? (Does the supplier have skin in the game? Will I look like a fool to my boss if it all goes horribly wrong?)

Buyer Question 8

Am I covered for GDPR? (Is the supplier’s infosec any good? Will I look like a fool to my boss if there’s a breach?).

Buyer Question 9 (if regulated)

Does the contract allow me to easily comply with regulation (Can I demonstrate to the FCA that I still have managerial control of the service? Does the contract allow me to comply with the requirement for operation resilience?).

The SLAs: uptime, response time, support levels.

The SLAs that you offer, and whether you should offer any at all, depends directly on the service you are selling and the nature of your customers.

If you are selling a service which is not time critical and where the buyers are not sophisticated or have little negotiating power, then you can get away with offering none at all. However, if you are selling to sophisticated buyers or those with negotiating power (eg. companies with procurement departments) then you are going to have to offer something.

The key is to offer something which, if challenged, you can justify. Remember GCCQ (= Good Contracts Closed Quickly)?  You don’t want to give away the shop, but you should aim to offer something that doesn’t turn into a negotiating issue in its own right and ends up burning time, cost, and goodwill.

Service levels break down into three main types.

Uptime is the primary one, and this can vary 99% to 99.99% depending on the criticality and time-sensitivity of the service.

The more sophisticated buyers (depending on the criticality of the service) will ask for a system response time SLA – ie. how fast does your SaaS platform respond to my query or keystroke? This is usually measured by a speed metric and a percentage (ie. percentage of API calls meeting the speed metric).

Some buyers (usually at the heavy end) will also ask for an SLA on support desk response times (eg. X% of calls to the support desk answered in Y seconds), as well as service credits on failure to hit response times.

Handing contract complexity

One of the difficulties of SaaS contracts where subscribers sign up online is that there is often a lot of price-related optionality behind the different functions and this, if described to the level of detail required for legal purposes, generates a lot of documentation.

The question then becomes – how do I disclose all this information in a way that meets the legal requirements for a contract, but doesn’t turn off the buyer by swamping them in documentation?

The answer is layering. You make an initial layer of information available to everyone (for example, the functions that come with that price plan), but then provide further information in additional clickable layers. It’s a kind of information self-service: buyers that don’t like too much documentation will stick to the top layer; those that like the full monty will go through to the lowest layer.

What’s the right number of layers? Three layers is best for most SaaS businesses. Hubspot is a good example of this.

The Sales-side Set Up

The ideal for the Sales-Contracting Process is to get the contract signed with zero human intervention. However, at the heavy end (think SaaS payroll, SaaS banking technology and similar), this isn’t possible. The buyers will still want to sign an old-school standalone contract and, invariably, will want to negotiate its terms.

As a seller, how do you make sure that in the negotiation the buyer doesn’t drive a coach and horses through your carefully planned legal terms?

That’s where the Sales-Side Set-Up comes in. When you send out a price proposal, you make two things clear.

First, that the price you have proposed is linked to a number of key assumptions, including the key parts of your contract.

Second, that while you are willing to contemplate changes in your legal terms, there will be a corresponding impact on the pricing. In other words, you link the whole thing together as a holistic package – any change in one part will have a knock-on effect on the rest. This won’t (usually) be enough to get you out of the negotiation woods altogether, but it gives you a firm basis from which to negotiate.

This applies equally well (better in some respects) to contract issues that are considered legal. Take limitations of liability, often a fertile ground for lots of to-ing and fro-ing between lawyers. Let’s say that you have proposed a limitation of liability of 1x fees in the year: the customer is not happy and wants 2x. You can play out the usual to-ing and fro-ing (much fun to be had by everyone) or you can say: “As set out in our proposal, our pricing is based on our key terms, and one of those is the limitations of liability that we have proposed. Of course, if you are prepared to increase the price, then we can increase our limitation of liability. How much more do you want to pay?” (stylised for emphasis, obviously).

The great thing about this approach is that it takes a legal issue and turns it into a commercial one. By doing that, you move the dialogue from the other side’s lawyer to their commercial person with whom, generally, you will get a much more sensible discussion.

Avoid duff clauses

SaaS contracts are the descendants of earlier software contracts.  The earliest software contracts gave the original lawyers a real dilemma. Yikes! they said, our software has got bugs, and a bug is a defect, and that means we are selling a product which contains defects.

To those early (American) lawyers, a defect was an invitation to litigation, and as a result they developed all sorts of devices and language to protect suppliers from liability. The world has moved on since then, but a lot of contracts still contain these old-school, and nowadays totally inappropriate, legal provisions.

So make sure your standard SaaS contract doesn’t contain this kind of stuff. Here’s an example of what I mean: this clause is still in use in a sector-leading SaaS contract and is a great example of how to inject negativity just when you want the customer to sign.

“The Customer acknowledges that access to our solution may be subject to limitations, delays and other problems inherent in the use of communications facilities. We (a) shall not be responsible for any delays, delivery failures, or any other loss or damage resulting from the transfer of data over communications networks or facilities, including the internet; and (b) do not warrant that our Solution, Services or Products will be error-free or that operation of our Solution, Services and Products will be secure or uninterrupted.”

Here’s what this clause is really saying:

• internet speed is variable and the internet is not 100% reliable. Yes: thanks for sharing.
• The product is not error-free. Ie. there may be bugs. Eek! Shock! Horror! Why not turn this into a positive? eg. any bugs will be addressed by our amazing support team.
• It may be interrupted. Ok, so what are you going to do about it? Do you have any skin in the game at all?
• It is not secure. Really? What kind of SaaS supplier does not commit to security and, what’s more, tries to sneak this in at the end of the clause? Avoid.

APIs and revenue models

A lot of B2B SaaS revenue models reflect the on-prem world: pricing is based on the number of authorised users. But one of the advantages of SaaS is that there is a much greater number of parameters around which pricing and revenue can be built, and also that you can monitor them in real time. The combination of these two elements has resulted in a whole new discipline of SaaS pricing of which the leading exponents (imo) are ProfitWell (profitwell.com, recently acquired by Paddle). ProfitWell has a great free pdf “The Anatomy of SaaS Pricing” which you can (or used to be able to) download from their website.

A few other things to think about in relation to pricing.

If you are exposing your API and it allows machine to machine integration, how will that impact your authorised user pricing? Will it cannibalise that revenue stream?

Is “authorised user” the right pricing metric for you? Is there another variable that is more aligned to what the customer values? After all, you want your SaaS platform to become pervasive in your customers, so that they literally can’t live without it. If you price by user, you are limiting pervasive-ness.

If you are selling to the US, is your pricing too cheap? Patrick Campbell, CEO of ProfitWell, recently suggested the pricing of most European companies is too cheap for the US market, and as a result their SaaS offerings lack credibility.  He recommended that European SaaS companies increase pricing by 30%: you will sell more, and make more per sale.

Selling SaaS to regulated companies

The FCA, and other financial regulators, are increasingly concerned about the reliance of regulated companies on technology companies – which increasingly means SaaS companies – which are not regulated.

In the on-prem world, regulated companies controlled their own technology so, effectively, their technology infrastructure came under the regulator’s purview. In a cloud world this is no longer the case, and the regulators are having to address the risk by (in addition to the previous rules on material outsourcing) introducing new rules on operational resilience.

What does this mean for a SaaS company selling to a regulated firm? Essentially, it’s a sales opportunity. If you can demonstrate how your SaaS offering allows your regulated customer to comply with regulation (assuming you know how regulation impacts your customer) the easier it is to win, and retain, the customer.

There’s a number of ways you can do this: here’s two suggestions.

Availability of management information (MI). The regulators are explicit that outsourcing does not mean abdication of management responsibility: if a regulated company outsources to the cloud (or otherwise), it still has to retain management control. If the regulated company does not have a contractual right to good quality MI, then it can’t claim to have retained management control. As a SaaS vendor, you can draw attention to this issue and demonstrate how your contract gives an enforceable right to high quality MI.

SaaS escrow. The failure of a number of suppliers has highlighted the supply chain risk that regulated companies face. As a SaaS supplier you can mitigate this risk by making SaaS escrow available to your customers. Unlike old-school source code escrow, SaaS escrow is more about keeping the lights on if you go bust: it enables the customer to step in and pay AWS (or Google or Azure) so that their instance remains up and running whilst the customer figures out the next step (look out for a forthcoming article from me on SaaS escrow).