I talk with a lot of founders of early-stage SaaS companies. They know that they need to have a contract in place with their customers, but they often get lost in the alphabet soup of NDAs, SLAs, DPAs, etc. They are focused on whatever it takes to close their first customers, and they are wary of creating potential issues down the road when they go to raise money or sell the company. So, what’s a founder to do?
The biggest determining factor on which contracts a SaaS company uses is their go-to-market (GTM) model, specifically whether they are product-led (also known as self-serve or PLG) or sales-led. So as you’re thinking about which contract to put in place, consider whether your users’ journey starts by signing up for your product or with a conversation with a member of your team.
The stage of the company and industry-specific regulations are the other big determinants of which SaaS contracts are needed. As a company grows, expands into new verticals, or updates its GTM, it’s likely that something will need to change with its contracts.
The visualization below shows different stages of the customer lifecycle and the contracts that are most commonly used at each one.
Sales-Led Contracts
A sales-led go-to-market does not necessarily mean that you already have a sales team. Most SaaS companies start with one or more founders selling the product. Even if your product does not yet exist and you’re working on getting your first design partner on board, that’s sales. Sales in this context means 1:1 conversations with your prospective customers, and that necessitates 1:1 contracts (rather than the 1:many contracts that are common in PLG).
There can be significant differences in the types of contracts between early and late-stage companies.
Contracts Pre Launch
Before their product is launched, SaaS companies often use a Letter of Intent (LOI) or a Design Partner Agreement to bring their earliest customers on board. Some companies do this for their first 2 – 10 customers, and others start signing sales agreements from the beginning.
Letter of Intent (LOI)
LOIs can be very simple and short, which is the main reason that early stage companies use them. However, one of the key things to understand about LOIs is that they are non-binding and not actually contracts at all. This leaves the ownership of intellectual property ambiguous. While IP ownership may not be top of mind while you’re trying to close your first customer, it can create an issue down the road during due diligence for fundraising or M&A.
A common diligence question is phrased along the lines of, “Does the company have agreements that assign ownership of intellectual property, including all contributions to the product, to the company?”
Early customers who provide a lot of feedback are contributing to the product, but an LOI, by definition, cannot assign ownership of that feedback to the company because it is nonbinding. In that case, you’ll have to disclose this gap to the investor/acquirer. Sometimes they’ll be OK with it, and other times they’ll ask you to go back to the early customer and get them to sign something to fill that gap. This can be particularly challenging if your point of contact is no longer there. Either way, it introduces delay and uncertainty when you least want it.
Design Partner Agreement
A Design Partner Agreement is an alternative to the LOI that solves these intellectual property ownership issues upfront. It also provides a framework for commitments that the vendor and customer make to each other. These may include:
From the customer:
- Regular feedback calls
- Serving as a reference
- Payment
From the vendor:
- Discounts or free use of the product
- Roadmap influence or promises to build certain features
The Design Partner Agreement is not quite as short as an LOI, but it’s set up to be as short and lightweight as practical while providing some base level protections. Our blog post on how to work with design partners gives more context on these relationships.
At this early stage, it’s common to only have one agreement in place with customers. The customer might ask to put a Nondisclosure Agreement (NDA) in place at the beginning of their conversations as well, but this, and many other contracts, are more common as SaaS companies mature.
Contracts Post Launch
After the product is launched, SaaS vendors move into a more traditional vendor-customer relationship rather than a design partnership. That relationship evolves over time, and can broadly be split up into five stages, each of which impacts the relevant contracts:
- Opportunity
- Pilot
- New customer
- Upsell/renewal/downsell
- Churn
Opportunity
An opportunity is a prospect who meets a set of minimum qualifying criteria that indicates they have a real possibility of becoming a paying customer. One commonly used framework is BANT, which stands for budget, authority, need, and timeline. There are a variety of other frameworks, but the key thing is that it’s worthwhile for a vendor to invest time and energy in an opportunity.
The most common contract to sign with an opportunity is a Mutual NDA. This can advance the sales cycle by allowing both sides to share information that will help them evaluate whether a deal will make sense.
A customer might need to share confidential information about their business in order for the vendor to give a price quote. The vendor might need to share information about their security and compliance posture, like a SOC 2 audit report or the results of a penetration test, in order to help the customer decide if they can trust this SaaS vendor with their data. This information would be very useful if it got into the hands of a competitor or potential hacker, so vendors often want anyone they share it with to sign an NDA.
This information is typically shared well before a sale happens, so NDAs get signed even if the ultimate agreement that the vendor and customer will sign (Design Partner Agreement, Cloud Service Agreement, or otherwise) also includes a confidentiality provision.
Pilot
Some vendors provide customers with limited use of the product before they make their purchasing decision. This is referred to as a pilot or trial. These can be handled by a dedicated section of the ultimate sales contract or a separate agreement.
Either way, a pilot typically differs from the ultimate vendor-customer relationship with some or all of the following:
- Shorter duration
- Either no fees or prorated fees
- Fewer legal protections for the customer
- Use of the product is limited in terms of data, integrations, or functionality
New Customer
If the sales process ends with a deal, the vendor signs a sales contract with the customer. The most common name for these has historically been a Master Services Agreement, but that name can be and is used for anything from software to catering. Since these agreements can be used for wide ranging activities, they often have clauses and obligations that are fundamentally incompatible with the business activity at hand (e.g., a requirement that a SaaS vendor conform to the customer’s hard hat policy).
More specific names for these contracts include the Cloud Service Agreement (CSA) for SaaS and Professional Services Agreement for, you guessed it, providing professional services. For most SaaS companies, the keystone contract for their business is the CSA.
This SaaS subscription agreement typically has an order form at the beginning that outlines the business terms of the deal like pricing, entitlements, and payment terms. The rest of the contract covers the legal terms, like indemnification and limitation of liability. Vendors create a SaaS agreement template and hope to keep all of their customers as close to that as practical, but negotiations often mean that different customers have varying the business and/or legal terms.
Connected Contracts
The CSA can be supplemented by other contracts depending on industry specific regulations. If the customer is a covered entity under HIPAA (US healthcare law), they may need to sign a Business Associate Agreement (BAA). Similarly, if the data of EU residents or citizens is involved, then under GDPR (EU data privacy law) a Data Processing Agreement (DPA) is required.
There is often a Service Level Agreement (SLA) attached to a CSA as well. This provides guarantees about performance and specifies remedies, often in the form of partial refunds or early termination, if the vendor doesn’t live up to its promises.
Upsell, Downsell, and Renewal
After the initial CSA is signed, changes to the relationship will show up in additional contracts. The customer might need additional capacity or features, in which case an amendment is signed that references the original contract and updates the price and entitlements. The reverse can also happen, where the customer gets a lower price in exchange for reduced capacity.
Depending on the original CSA, when the term is up, the contract may or may not automatically renew. If it does not automatically renew, then the renewal is often accomplished with a new order form that references the old contract for its legal terms. This order form renewal process allows both parties to continue or change the products provided while maintaining the same relationship via the contract’s legal terms.
Churn
When a vendor-customer relationship ends, it typically falls into one of three categories.
- If it has automatic renewal, the vendor or customer sends a notice of nonrenewal.
- If the contract does not automatically renew, the relationship ends if no new contract or order form is signed.
- The contract is terminated before the term is up. This is most common when the performance guarantees of the SLA have not been met.
Of course, vendors try to keep this churn category as small as possible. It’s useful to keep on top of renewal timelines to proactively improve tenuous relationships before it’s too late.
PLG Contracts
Product led growth (PLG), or self-serve, describes a go-to-market strategy where the customer’s journey starts by using the product rather than with a sales conversation.
In a PLG model, every customer typically starts with the same legal terms and pricing plan. These legal terms are called the Terms of Service (TOS), which are posted on the vendor’s website. The TOS references a public pricing page, also posted on the vendor’s site, which allows the vendor to update their pricing without changing their contract. Vendors also post their privacy policy, which describes the data they collect and how it’s used.
Customers typically signal their agreement to the TOS when they sign up for the product by checking a box next to the signup form along the lines of “I accept the Terms of Service.”
When a PLG user converts to a paying customer, or when they upgrade, downgrade, or cancel, it all happens under the TOS they agreed to when they first signed up. There are no additional contracts involved.
Product-Led Sales
However, product-led does not necessarily mean zero sales. It’s common for sales to get involved with PLG users in order to upsell them. When that happens, the process looks like the new customer step in the sales led section above, with a negotiated CSA and potentially other connected contracts.
Ideally, the TOS and CSA are built on a common foundation, so that customers can be easily transitioned from one to another. This also enables hybrid models, where you sign an order form with custom business terms that reference the legal terms in your TOS posted online.
Figuring out the “what” and “when” of SaaS contracts is hard enough, not to mention actually getting them in place at your company. If you’re just getting started, try out the SaaS Agreemeent Toolkit with step-by-step guides to customizing contracts and a benchmark report on the most commonly used terms.