Short answer: your SaaS agreement is a legal document, not a product manual. Put the core legal terms in the contract (liability, warranties, disclaimers, indemnity) and move the descriptive “how it works” material into an online FAQ or policy you can update as the product changes.
Some SaaS companies stuff everything into their SaaS agreement, so that when the customer finishes reading it they supposedly understand the entire offering. That kind of makes sense at first blush. But once you work with these agreements regularly, you see it is neither efficient nor effective.
Why SaaS Breaks the “Put It All in the Contract” Habit.
The core problem is that SaaS is not static. It morphs and changes far more often than on-premises software. Most SaaS companies run an Agile methodology built around rapid release cycles, and the customer generally has to accept those ongoing changes to the underlying software (that is one of the main benefits of SaaS in the first place). If you bake all of the descriptive detail into the contract, every product change risks making your contract inaccurate, and changing a signed contract is slow and expensive.
The In-Versus-Out Framework.
The trick is finding the right balance between what must live in the agreement and what is better handled outside it. Core legal concepts belong in the contract because they allocate risk and neither side should be able to change them unilaterally: limitation of liability, warranties, disclaimers, and indemnities. (How those risk terms fit together is the subject of What Does Your SaaS Agreement Liability Model Look Like?.) Descriptive, operational detail is a great candidate for an FAQ or policy you control and can revise.
If a term allocates legal risk, it goes in the contract; if it just describes how the product works, it belongs in a policy or FAQ. That single rule resolves most “should this be in the agreement?” debates. The deeper version of this contract-versus-policy decision is its own topic (see Contract or Policy?), and I wrote a separate post on using FAQs in SaaS negotiations.
Better Addressed Outside the Agreement.
- How to set up and administer user accounts.
- How to upload or export your data and content.
- Support contacts, support process, and severity levels.
- Service level and availability detail.
None of those need to be frozen into a signed contract, and all of them are likely to change. Put them where you can keep them current. The move is to work with your SaaS attorney to sort which issues belong inside the agreement and which belong outside it. Trust me on this one.
For the foundational frame on what a SaaS agreement is actually supposed to do, and the indemnity-versus-breach distinction that drives it, see SaaS Indemnity vs. Breach of Contract: What’s the Difference?
Common Questions About SaaS Agreements and Documentation.
Should you put everything in your SaaS agreement? No. The contract is a legal document, not a product manual. Put risk-allocating terms in the contract and descriptive detail in a policy or FAQ.
What belongs in the contract versus a policy? If a term allocates legal risk (liability, warranties, disclaimers, indemnity), it goes in the contract. If it just describes how the product works, it belongs in a policy or FAQ.
Why does this matter more for SaaS? SaaS changes constantly under Agile release cycles. Baking operational detail into a signed contract makes the contract go stale and is slow and expensive to fix.
Resources:
- How to Use FAQs in SaaS Contract Negotiations
- Contract or Policy? Which One Does a Software Company Need?
- Have SaaS Agreement Templates Become Commoditized?
Disclaimer:
This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.
Discover more from Aber Law Firm
Subscribe to get the latest posts sent to your email.