Notes / International contracts
SaaS contracts: what to agree with business customers
Subscription scope, support, data and exit. How to align the contract with what your product and team can actually deliver.
You sell access to an existing service. But the customer's contract may promise new features, a fix for every problem within an hour and support for all their integrations. Before signing, separate the subscription from additional work and agree what happens when the service fails, the product changes or the relationship ends.
1. What exactly are you selling?
With SaaS, the customer usually gets access to software you run. They do not buy the software itself. But “access to the service” is not enough: specify the features, users, storage and other limits that determine the price. Separately clarify whether other companies in the group and the customer's own customers may use the subscription.
Subscription
The existing product
Agreed features, users and limits. The access period and support terms.
Setup
Getting the customer started
Initial data migration, training and connections to agreed systems. Separate deliverables and deadlines.
New work
Features not yet built
Scope, price and acceptance under a separate specification. Check that promises in the sales presentation match the contract.
An example of how a deal can be structured. Not every service includes all three parts.
If the customer says “we need a CRM integration”, find out what they mean: access to your API, an existing connector or a new development. Each involves a different amount of work. State who is responsible for changes to the customer's system and for supporting the connection after launch.
Bring the documents together: the main agreement, an order with the plan and term, support rules, the SLA and data terms. Record their versions and which takes priority if they conflict. For example, data terms might take priority only on processing matters, while an agreed order changes only the commercial terms it expressly identifies.
Implementation and subscription payments can be separated, as in the recurring services example. Rights in new development are covered in the article on customer-funded improvements.
2. The SLA: uptime and what happens when it falls short
An SLA describes the agreed level of service. Distinguish three things: availability, support response time and restoration time. A promise to respond within an hour does not mean the service will be working again within that hour. For example, the Google Workspace support guidelines give target times only for the first reply and say Google may be unable to resolve every request.
The parties can agree a reduction in the next payment after an outage, often called a service credit. Set out its amount and the process for claiming it in the contract.
Example: a 30-day month, a monthly fee of $2,000 and a 99.9% availability commitment. All four hours count as downtime, with no other outages or exclusions. Amounts are in US dollars.
Agreed credit: 10% of the monthly fee
$200off the next invoice
This is not a calculation of the customer’s losses or an automatic refund.
The 10% credit is only a term of this example. It is not a statutory rate or a standard amount of compensation.
First, define what counts as unavailability. The software opens, but payments fail: is the service considered to be working? Which functions count, where do measurements come from, and how are scheduled maintenance and external dependencies treated? Excluding every cloud infrastructure failure could make the commitment of little value to the customer.
The Atlassian SLA, for example, covers specified actions and applies credits to future payments. Its terms also make the credit the exclusive remedy for failing to meet the availability commitment. This is one contract's approach, not a rule for all services. Under English law, a clause like this in a supplier's standard terms may have to pass the UCTA reasonableness test.
If the credit is to replace other remedies for the same outage, say so expressly. Triple Point v PTT [2021] UKSC 29, paragraphs 108–110, explains the general English-law approach to clear wording that limits ordinary remedies. The case did not concern SaaS service credits. Separately agree when repeated outages give the customer a right to terminate.
What to agree with the customer
- Which outages count and how to document them.
- When and how to request a service credit.
- What happens after repeated serious outages.
- How the SLA interacts with damages and the liability cap.
What to check with your team
- Who responds at night and over weekends.
- Whether you can promise a fix by a deadline or only a time to start work.
- What help you need from the customer's technical team.
- How and when you will update the customer on recovery.
3. Customer data: what the service may do with it
“The data belongs to the customer” does not answer the main question: what may you do with it? Separate use to run the service, technical analytics and AI model training. If your product does not use data for one of these purposes, do not add broad permission just in case. Under the UK GDPR, a processor that uses customer personal data for its own purposes becomes a controller for that processing and needs its own lawful basis (Article 28(10)).
The contract should reflect how the product works: what data you receive, who can access it, where it is stored, what connected services do and how you report an incident. Under the UK GDPR, a processor must tell the customer about a personal data breach without undue delay after becoming aware of it (Article 33(2)). The customer acting as controller must notify the regulator without undue delay and, where feasible, within 72 hours of becoming aware of the breach, unless a risk to people’s rights and freedoms is unlikely (Article 33(1)). This can explain a shorter contractual deadline for your notice. Agree any such promise with the team that detects and investigates problems.
Do not promise to delete every copy immediately if backups follow a separate retention cycle. Describe that cycle, access restrictions and any mandatory retention. Check the timing and process against the applicable law.
4. The product changes. What happens to the subscription?
You need to develop the service, while the customer needs to know that a purchased feature will not disappear halfway through a prepaid year. You could agree that routine updates need no separate approval, while a material reduction in key functionality triggers notice, a transition period and a right to leave with an agreed refund of prepaid fees. If you contract on your standard terms, a right to provide a substantially different service may also have to pass the UCTA reasonableness test (section 3(2)(b)).
- 60 days before renewalLast day to give notice of non-renewal
- 30 days before renewalThe customer learns next year's price
- Renewal dateThe new price applies only if the contract allows a change by notice
The deadlines do not work together: the decision comes before the price is known.
One option for negotiation: give 90 days' notice of the new price and keep the non-renewal deadline at 60 days. Another: allow the customer a separate period to opt out after notice of an increase.
These periods are examples, not mandatory rules.
Also check changes to limits, switching plans, reducing user numbers and charges for exceeding allowances. Linked terms should not quietly change the agreed order.
Suspending access needs its own process. For late payment, you can agree notice and time to pay; a security threat may require immediate action. Specify the grounds, scope of suspension, restoration and access to data. Do not extend an emergency rule to every invoice dispute. Under English law, suspending without an express right can itself be a breach; see the article on payment terms.
5. The subscription ends. How does the customer get their data?
An “Export” button does not necessarily let the customer carry on in another system. A contact list might export without attachments, relationships, history or settings. Agree what the export includes and test it with sample data before signing a large deal.
Before the subscription ends
Prepare the move
Agree the data, format, timing and responsibilities. Check that the export is usable.
After it ends
Receive the agreed export
Set the period and method in advance, along with read-only access, assistance and permitted charges.
Then
Delete the data
Follow the agreed, lawful process, including backups and mandatory retention.
Ending the contract should not accidentally prevent the customer from obtaining their data. These steps need to work together in both the contract and the product.
State that export, read-only access and deletion terms survive termination. If you process personal data on the customer’s behalf under the UK GDPR, the customer chooses return or deletion when the relevant services end. Remaining copies must also be deleted unless the law requires their retention (Article 28(3)(g)).
Clarify who performs the move: do you provide files, help with the import or commit to migrating the entire system? These tasks have different costs and depend to different degrees on the other service. HubSpot's export guide illustrates why different types of content need different export methods.
What to check before sending the contract
- The plan and features match what your team can actually provide.
- Support, availability and new development are described separately.
- The consequences of an outage and recurring problems are clear.
- Data use and security commitments have been checked with the technical team.
- The customer learns the new terms before losing the chance to decline renewal.
- Export is possible before deletion, with its contents, timing and assistance agreed.
If the customer sends their own form, start with the general contract review, then check these terms against your product. A large cloud service's terms are useful for comparison, but may not suit your business model or negotiations.
Has a customer sent a contract for your SaaS?
I can check the commitments it creates for your team, prepare changes to subscription, support, data and exit terms, and help negotiate them in English or Russian.
Sources
- Atlassian Service Level Agreement, sections 1–4, Appendices A–B and Calculation: SLA scope, availability calculations and credits towards future payments.
- Google Workspace Technical Support Services Guidelines, sections 1.3, 1.4 and 4.4: handling requests and target times for the first reply.
- ICO: Contracts: processor contracts under the UK GDPR. The guidance is marked as under review following the Data (Use and Access) Act 2025.
- UK GDPR, Article 28 and Article 33: processor contracts and breach notification.
- ICO: International transfers: transfers outside the UK.
- Unfair Contract Terms Act 1977, section 3: standard terms and the reasonableness test.
- Triple Point Technology v PTT [2021] UKSC 29, paragraphs 108–110: the general approach to interpreting limits on ordinary remedies, not a decision about SaaS service credits.
- HubSpot: Export your content and data: export contents and methods.
- European Commission: Data Act explained, Chapter VI; Regulation (EU) 2023/2854, Articles 1(3)(f), 2(36), 23, 25, 29 and 31: switching services and the scope of the rules.
This article concerns SaaS deals between businesses. Contract points follow the law of England and Wales unless the text says otherwise; consumer sales and other legal systems need a separate assessment. The examples do not set mandatory deadlines or compensation amounts.