Saas Terms Drafter

---
name: saas-terms-drafter
description: Drafts SaaS terms of service or a customer agreement — access grant, service levels, data processing position, IP ownership, limitation of liability, and termination and data-return provisions — flagging data protection applicability, consumer-protection requirements for B2C terms, and liability-cap enforceability for verification rather than asserting them. Use this whenever a user needs terms for a SaaS product — including phrasings like "draft our SaaS terms of service", "prepare a customer agreement for our platform", "what should our data processing position say", "draft terms for a B2C subscription product", or "add termination and data-return provisions to our ToS". Fires for any software-as-a-service or platform terms of service, B2B or B2C, in any jurisdiction.
---

# SaaS Terms Drafter

## What this does

Drafts the terms of service or customer agreement for a SaaS product: the access and license grant, service level commitments, a data processing position, IP ownership, limitation of liability, and termination with data return or deletion. It drafts only what is actually instructed — it does not invent a specific SLA figure, assume B2B when the customer base could include consumers, or assert that a liability cap is enforceable without that being confirmed against the governing law.

## Before you start

**The commercial model.** The subscription structure, pricing basis, and a description of what the SaaS product actually does. Blocking — access and license terms cannot be drafted without knowing what is being licensed.

**Whether this is B2B or B2C.** Consumer-facing terms carry protections — cooling-off rights, specific dispute resolution requirements, restrictions on unfair terms — that business-to-business terms do not, in many jurisdictions. Ask; do not assume B2B by default, since getting this wrong misses real, mandatory content.

**Governing law.** Ask, unless stated. This determines what can be drafted with confidence and what has to be flagged — data protection obligations, consumer protection requirements, and liability-cap enforceability are all governing-law dependent.

Not blocking, ask once and proceed on what is confirmed: **whether a separate data processing agreement is needed, or should be incorporated into these terms.** SaaS products routinely process customer data, and this is a common, consequential gap if left unaddressed.

## Method

**1. Confirm B2B or B2C before drafting anything**, since B2C terms carry consumer-protection obligations B2B terms do not. Flag this explicitly if the customer base could plausibly include consumers even where the primary market is business.

**2. Draft the license or access grant precisely tied to the product actually described** — scope of use, permitted users, and restrictions such as no reverse engineering or no reselling.

**3. Draft service level commitments only as actually instructed.** Do not invent an uptime percentage, a support response time, or a service credit mechanism. If none has been given, either ask or state plainly that the agreement is silent on SLA and flag this as a gap the user should decide on.

**4. Address data processing.** At minimum, flag that if personal data is processed, a data processing agreement or equivalent terms covering controller and processor roles, security, and data protection obligations are likely required — and note that whether this is actually required, and what it must contain, depends on the applicable data protection law, which needs to be confirmed rather than assumed satisfied.

**5. Draft IP ownership provisions precisely** — the provider retains IP in the platform, the customer retains IP in their own data and content — and draft any feedback or improvement clause narrowly enough that it does not inadvertently claim rights over customer data beyond what was actually intended.

**6. Draft limitation of liability and indemnity provisions consistent with what is actually agreed, and flag the enforceability of any liability cap or exclusion under the governing law rather than asserting it.** Many jurisdictions restrict excluding liability for gross negligence, data breaches, or in consumer contracts specifically — this needs verification, not assumption.

**7. Draft termination and data-return provisions** — what happens to customer data on termination, export rights, and the deletion timeline.

**8. Draft payment terms and renewal mechanics, flagging that auto-renewal clauses are specifically regulated in some jurisdictions, particularly for consumer contracts**, rather than drafting one without noting this.

## Output

**1. Header.** Product or service described, B2B or B2C, governing law, date.

**2. The terms.** License grant, SLA (or explicitly flagged as absent), data processing position, IP ownership, limitation of liability, termination and data return, payment and renewal.

**3. Drafting notes.** Judgment calls made where instructions were silent.

**4. Open points and placeholders.**

**5. Points requiring verification.** Data protection law applicability, consumer protection requirements if B2C, liability-cap enforceability, and auto-renewal regulation.

## Do not

Do not invent a specific SLA commitment — uptime percentage, response time — that was not instructed.

Do not assume B2B when the customer base could include consumers, without confirming.

Do not assert that a data processing agreement is unnecessary. Flag data protection applicability as a verification point whenever personal data is processed.

Do not assert that a liability cap or exclusion is enforceable under the governing law.

Do not draft an auto-renewal clause without flagging that such clauses are specifically regulated in some jurisdictions.