“Sorry, but we don’t negotiate our SLA. We offer the same terms to all of our customers.”
Ah, the frustrations of a negotiation wall.
How do you take down a negotiation wall? One brick at a time.
SaaS vendors commonly claim that their SLAs are non-negotiable. That is usually not true. If you’re on the receiving end of this all too common phrase, you don’t have to stop there. You have options. You can use a combination of negotiation strategies and subject matter expertise to find the penetrable soft spots and land better contractual terms for your clients. This article will show you how.
“[E]ven if you do accept [that] argument and the SLA’s procedural terms, consider negotiating better SLA legal terms.”
What’s really non-negotiable?
When vendors say the SLA is non-negotiable, they’re usually referring specifically to the procedural SLA terms, e.g., the uptime SLA itself.
For example, in the Amazon Connect Service Level Agreement (last updated March 21, 2019), Amazon promises an uptime of at least 99.99%. If you were expecting a higher uptime SLA, and the vendor said it is non-negotiable, consider focusing your negotiations on the SLA legal terms. See the blue text below for SLA procedural terms and the red text for SLA legal terms.
How to use negotiation strategies to build leverage?
To successfully negotiate a contract as complex as a SaaS agreement, and a component as complex as the SLA, you should apply a dynamic range of negotiation strategies. Consider the urgency of the deal, your starting leverage, and the needs of your stakeholders. Then, start with one of the negotiation strategies listed below to see which bricks are loose enough to grab.
1. Redlines to the max!
When you have the leverage, there’s no better place to start the negotiation than the beginning. If you represent a larger customer with greater leverage, you should redline the entire SLA document to reflect your client’s needs. Remember to leave explanatory comments to justify why you are proposing a certain redline so that the SaaS vendor has that context while reviewing your redlines.
2. Leverage business channels to increase leverage.
The next step is to connect with your internal clients and ask them to work the back channels. Time to play a little good cop, bad cop. If your internal client is IT or Procurement, they will likely have a relationship with the SaaS vendor’s salesperson. No one has a stronger motive to close the deal than that salesperson. That’s why they can be your strongest advocate.
3. Consider modifying commercial terms for a better SLA.
Even so, sometimes, when the SaaS vendor says no, they really mean no. At this point, you should meet with your internal client and review the commercial terms. It may be worthwhile to lengthen the subscription term or upgrade the customer service add-on if it means you’ll be able to land a better SLA. Then again, it might not. At least you had the conversation and are aware of the risk vs. benefit tradeoff.
4. Focus on one main value-add and be persistent.
Suppose you’ve tried all of the above, or already know (based on experience) that you don’t have enough leverage to expect a customized SLA. In that case, your only option is to pick one crucial change that will add value and lower risk for your client, and negotiate for that one point. See the section below for some example SLA legal clauses to consider.
Which SLA legal terms are usually negotiable?
Let’s say you expected a higher uptime SLA but that brick was immovable. What parts of the SLA legal terms can you potentially negotiate to make up for the less-than-ideal SLA procedural terms?
Definition of Uptime SLA & Exclusions
While you may not be able to change the actual uptime SLA, you may be able to negotiate how the uptime SLA is defined. Uptime SLAs are commonly defined in the negative, or what it does not include, e.g., the exclusions. The more or broader the exclusions, the less meaningful the SLA becomes. This defined term is typically a mix of highly technical terms and legal terms. To properly negotiate it, you should have a thorough understanding of the technical and legal aspects of an SLA. Otherwise, partner up with a subject matter expert and work on reviewing and understanding the definition and exclusions together.
Because you wouldn’t necessarily want to terminate a SaaS agreement due to some unwanted downtime, the service credits help offset a temporary or minor failure to perform. Service credits are both a commercial remedy and a legal one. Like the uptime SLA, the procedural aspects of the service credit (e.g., % or $ of service credit due) may be set in stone, but the definition and qualifications for obtaining a service credit can be negotiated.
SLAs may or may not be linked to termination rights. Remember, unless specifically defined as so, an SLA failure is not necessarily a material breach of contract. Because your client did not get the uptime SLA you were hoping for, the risk of being an unhappy customer increases. Your client may want a way out of the contract to mitigate this risk if the uptime SLA is not upheld. In this case, you should negotiate a termination right for A) repeated failures over a short period of time (e.g., 3 failures within a consecutive 3-month period) or B) 1 critical failure (e.g., if the uptime SLA falls below 50% at any given point in time). Amazon’s SLA states that the service credits offered are the “sole and exclusive remedy for any unavailability.”
There are two types of maintenance, planned and emergency. Each one presents an opportunity to negotiate better terms for your client. Planned maintenance is usually an exclusion to the uptime SLA, while emergency maintenance should not be. Amazon’s SLA does not reference maintenance windows or procedures.
* * *
Contracts between vendors and customers should be negotiable to ensure that the common goal – a successful and long-term business relationship – is achieved. Even with “non-negotiable” SLAs, there are opportunities to negotiate. “Sorry, but we don’t negotiate our SLA. We offer the same terms to all of our customers.”
Author: Nada Alnajafi
If your SaaS system is going to be tested in a proof of concept (POC), be sure to put an agreement in place. The POC agreement would ideally restrict access to the SaaS in a test environment, disclaim any warranties and indemnities and require your customer to ensure that no confidential or personal data is processed while in the POC mode. To learn more and join in the discussion, check out my LinkedIn post.