Short answer: a little of both, but mostly trust. The lesson from Salesforce is that there is no SaaS SLA in its subscription agreement. The availability, security, and privacy story lives on a public “trust site” instead, which takes the longest fight out of the contract and builds more confidence than a buried SLA ever could.
Years ago I read the Salesforce.com subscription agreement looking for the SLA and could not find one. I assumed I had missed it. I had not. That changed how I think about SaaS and PaaS agreements, and after a couple thousand deals on the vendor side I am more convinced of it now than I was then: you are selling trust first and software second. Salesforce figured that out early and moved the proof out of the contract and onto a public trust site.
What Is a Trust Site?
A trust site is a public page where you publish the things a buyer would otherwise interrogate you about in redlines. It is not a marketing page. It is an operational transparency resource aimed at the security and compliance people vetting your product, and the useful ones carry:
- Uptime and incident history. Current numbers plus the archive, usually through a live status feed so customers see incidents as they happen.
- A security practices summary. In plain language, not in the form of a 40-page policy nobody reads.
- Your compliance certifications. SOC 2, ISO 27001, HIPAA where relevant.
- Your subprocessor list, DPA, and privacy policy. The documents procurement asks for every single time.
- A path to the gated material. How to request your SOC 2 report, security overview, or penetration test summary, and who to contact.
The concept is simple. Making it public is what makes it work. A number you publish to everyone reads as a commitment; the same number negotiated into one customer’s contract reads as a concession you had to be pushed into. It is the operational, customer-facing companion to building privacy and security in from the start (see Privacy by Design), and it is the same instinct behind the standardized security questionnaire work of the Vendor Security Alliance: prove it once, publicly, instead of a hundred times in a hundred deals.
What Salesforce Actually Does.
Worth being precise here, because the details have moved since I first wrote about this. The current Salesforce Main Services Agreement commits only to “commercially reasonable efforts to make the online Purchased Services available 24 hours a day, 7 days a week,” subject to planned downtime and events outside its control. That is it. No uptime percentage. No measurement methodology. No service credits. The words “service level agreement” and “uptime” do not appear.
Two things to keep straight. Trust.salesforce.com is a live status board, not a contract, so it publishes what is happening rather than a committed percentage. And some products in the family do carry a real SaaS SLA as a separate document (MuleSoft commits to 99.95% with a tiered credit schedule). So the accurate statement is not “Salesforce has no SLA.” It is that Salesforce keeps the uptime number out of its master agreement and lets the public trust story carry the weight.
Why This Shortens Your Sales Cycle.
What I heard, years ago, was that Salesforce was burning enormous time negotiating the SLA: how uptime gets measured, what counts as downtime, how credits get calculated and claimed. All of that was extending the sales cycle without changing the deal economics much. So the question became what the customer is actually trying to find out. In my experience it comes down to three things:
- That you know when the service has a problem.
- That you are working on it.
- That someone tells them when it is fixed.
None of those needs to live in a signed contract. A trust site with a status feed answers all three, in public, before legal review even starts. That is how buyers actually experience reliability (nobody has ever felt reassured by a credit formula), so that is where you should put your effort.
You Do Not Have to Build It Yourself.
This is the part vendors overestimate. You do not need to engineer a trust site from scratch. Statuspage and Status.io are well-established, and for something in the range of a hundred dollars a month you can publish a credible status and incident history page. Hang the security artifacts off it and you have answered most of a standard procurement questionnaire on your own schedule instead of in a deal crunch.
Two practical points. Tier it: the status page and a basic security overview should be fully public, while the SOC 2 report and penetration test details go out under NDA on request. And do not wait for perfect. A trust site that honestly shows a roadmap (“SOC 2 Type II underway, expected Q3”) is far more credible than no trust site at all.
Three Drafting Moves for Your SaaS SLA.
Moving your operational commitments to a trust site does not mean the agreement goes silent on service levels. It means the contract points at the published page instead of carrying every metric itself. Three moves make that work for the vendor:
- Reference, do not duplicate. Point the agreement at your published availability target and support response times rather than restating them. When you improve the service you update one page, not every signed contract. The same logic applies to your security schedule and your DPA: link to the trust site for current practices rather than hardcoding technical commitments that go stale the moment you change a subprocessor.
- Keep the remedy lean and exclusive. Service credits should be the customer’s sole and exclusive remedy for a missed target, they should be capped, and they should count against your liability cap rather than sitting outside it. A missed uptime number is a service-quality problem, not a license to reach past the cap.
- Reserve the right to update the page. The whole point of a trust site is that it stays current, so say you can change it on notice. Then give one thing back: promise not to reduce the target during the customer’s current term. That single sentence closes the objection this move otherwise invites.
Language You Can Use.
Here is a short version you can adapt. Keep it this size. Every sentence you add is a sentence someone will redline:
Service Levels. We will use commercially reasonable efforts to meet the availability target published at [trust site URL]. If we miss it in a calendar month, you may request a service credit as described on that page. Service credits are your only remedy for missing the target, and credits in any month will not exceed [X]% of that month’s fees. Missing the target is not a material breach of this agreement. We may update the published target and credit schedule on 30 days’ notice, but we will not reduce the availability target during your current subscription term.
The “not a material breach” sentence does more work than it looks like. Without it, a buyer will argue that three missed months is a material breach and terminate for cause, which hands them the termination right you thought you had capped at a few percent of fees.
What to Watch For.
The pushback on a SaaS SLA is predictable and it comes in one of two shapes. Either the customer wants a termination right stapled to repeated misses, or they want SLA failures carved out of the limitation of liability so they can chase actual damages for downtime. Resist both. The trust site exists precisely so you do not have to over-promise in the contract: publish generously, commit carefully, and keep the money exposure inside the cap you negotiated.
If you need to give something, the reasonable middle is a termination right after a defined number of consecutive months below target, with termination and a pro-rata refund as the only remedy. That is a bounded exit, not an open-ended damages claim.
All of this pairs with keeping changeable operational detail in a policy rather than the signed contract, and with the trust signals that move the emotional side of a SaaS negotiation. Your agreement is a bad place to explain things (see why SaaS agreements are not good communication vehicles). A trust site is a good one.
Frequently Asked Questions.
Can I really leave the SLA out of my SaaS agreement? You can move the uptime metrics and the credit mechanics to a public trust site and keep the contract’s service level section to a few sentences. Salesforce does essentially this in its master agreement. Decide deliberately what stays contractual (the credit remedy and its cap) and what gets published.
Do service credits count against my liability cap? They should, and you should say so. Credits that sit outside the cap are extra exposure you did not price for.
Do we need a SOC 2 report before building a trust site? No. Build it now and show what is in progress. An honest roadmap beats an empty page.
Should the trust site be public or behind a login? The status page and basic security overview should be fully public. Detailed artifacts like the SOC 2 report normally go out under NDA on request. Public summary plus NDA-gated detail is the industry norm.
Does publishing an incident log make us look worse? The opposite, in my experience. A public incident history reads as operational maturity. Buyers who can see how you handle problems trust you more, not less.
Does a trust site really speed up deals? Usually. Most SLA negotiation is a buyer trying to verify trust the slow way. Publishing the numbers answers the question before legal review starts, so there is less left to argue about.
Does this work for a PaaS agreement too? Yes, and arguably more so. PaaS buyers are building on top of you, so availability and change notice matter more to them than to a typical SaaS buyer. Same structure, and you may want deprecation and API change policy published alongside uptime.
So are you selling trust or SaaS? A little of both. In this market a customer is unlikely to buy if they do not trust you, so get the trust part right and the SaaS part gets a lot easier. I hope this helps.
Resources:
- Sometimes You Have to Go Back to SaaS School
- Contract or Policy: Which One Does a Software Company Need, and When?
- Limitation of Liability Clause: The One Word That Cost a Vendor $1.88 Million
- The Vendor Security Alliance: Why SaaS Companies Should Care
- Privacy by Design: A Framework for SaaS and Software Vendors
Sample trust sites:
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.