Cloud services providers often say they can’t negotiate their SLAs. All customers get the same SLA, so customizing terms for one customer would require changing procedures used for everyone. That’s often true, but customers should test the limits of SLA flexibility. Not all SLA revisions require that the provider change its procedures. Terms addressing “legal” issues generally don’t.
This post provides advice for customers. But providers should find it useful too, particularly when they negotiate with sophisticated, assertive customers.
SLA Procedural Terms – Often Nonnegotiable
If the SLA applies to all customers, the provider often has no practical way to change certain terms. Many SLAs require that the provider respond to errors within fixed periods, for instance. A Level 1 Error might require acknowledgement within one hour and a repair (or a reasonable effort) within four hours. If the provider staff sends one acknowledgement to all customers, and if the repair would apply to all customers, the provider probably can’t customize those terms for one customer.
Error definitions usually don’t offer room to negotiate either. “Level 1 Error means any failure of the Critical Function during Business Hours.” The provider can’t customize a definition like that because its staff responds to errors in the same way for each customer.
Still, why not ask the provider about its procedures? You never know.
SLA Legal Terms – Much Better Odds
Often, the provider can customize less procedural terms: “legal” terms.
Below are terms the providers often can change for an individual customer, without disrupting its broader SLA procedures. None is guaranteed because each provider has its own processes. But they’re all worth exploring.
Higher Credits: Money isn’t really a procedure. So often the provider can accept higher-than-normal SLA credits during contract negotiations. Yes, it’s possible the provider has software that calculates each customer’s SLA credits, and it may have no setting for customized amounts. But ask. And even if so, you may find some other way to track higher credits. If you agree on 1.5x the provider’s usual credit, for instance, the provider’s billing department could just multiply any credit by 150%. Or the customer could do that multiplication job, since the credit only matters when the customer pays the bill. Or you might find some other way to track and enforce higher credits.
Reasonable Efforts to Achieve Service Levels: Many SLAs give the customer credits for service level failures, but they don’t require that the provider try to achieve those levels. Requiring “reasonable efforts” to hit service levels can’t possibly require a change in the provider’s SLA procedures. And it gives the customer an extra remedy — a claim of breach — if the provider does a bad job.
Accurate Reports of SLA Failures:Often, the customer relies on the provider to tell it when the service started to fail and when it started working again. If the provider doesn’t report regularly and accurately, the customer might not know it’s earned a credit or other remedy. A reporting requirement sounds like a procedural change, but most providers already generate some sort of service level report. So accuracy terms just require that the provider share the report — and they give the customer remedies if the reports turn out wrong.
Warranty of Functionality:Contracts with SLAs often offer no warranty related to technology performance. But warranties give customers legal rights without altering SLA procedures. So customers should look for a warranty that technology will function according to its specifications, at least for some period. That warranty would usually appear in the contract’s main body, not the SLA. But make sure the SLA doesn’t take away any warranty remedies. SLAs often provide that the customer has no remedy for service level failures other than credits. Add the following to the end of that sentence: “in addition to such rights as Customer may have pursuant to Section __ (Warranty Remedies), if applicable.”
Termination Rights: Termination rights don’t require that the provider change its procedures. The customer can always add a clause saying more than 3 or 5 or 10 SLA failures in a given month authorizes termination for breach. And the customer can add termination rights for other SLA targets. Also, the customer should always preserve its typical, separate right to terminate for material breach. As noted in the prior bullet, SLAs often say credits provide the customer’s sole remedy. Add the following to the end of that sentence: “in addition to Customer’s right to terminate this Agreement for breach pursuant to Section __ (Termination for Cause), if applicable.”
Other: Think through the terms in your SLA — and ask questions. Don’t assume your provider representatives even know what SLA terms they can change. Ask, pry, and negotiate.
Join Tech Contracts Academy’s two remaining live webinars this spring: April 16 – The Indeminar: Indemnities in Contracts about Software, the Cloud, and AI May 21 – IP
Tech Contracts Academy and David Tollen have partnered with Adam Stofsky and Briefly Inc. to create a series of short, concise videos, covering contract basics. The videos are
I think it’s a mistake to indemnify against claims resulting from indemnitor negligence or other wrongdoing. Indemnities against 3rd party claims usually specify the claims
David Tollen’s Tech Contracts Academy just released a new, updated version of our popular training: AI Contracts – Drafting and Negotiating. With 1 year’s access, you can use it for training and as a reference.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.