4 exercises — negotiating SaaS pricing increases, raising SLA breach claims, pushing back on contract terms, and making the case for product customisation.
0 / 4 completed
Vendor negotiation language
Pricing: Name the internal constraint + usage data + offer multiple compromise paths ("multi-year / seat reduction / feature tier")
SLA breach: Quantify the breach vs. contracted allowance → ask for root cause → structure three remedy paths
Contract terms: Isolate one term → explain business impact in the vendor's language → propose two alternative solutions
Customisation: Acknowledge the policy reason → make each request maximally specific → ask for feasibility assessment not commitment
Always frame the goal as mutual — delays and disputes cost both sides
1 / 4
You are renewing a SaaS tool licence. The vendor has proposed a 40% price increase. How do you open the pricing negotiation?
Option C opens a vendor price negotiation effectively:
1. Acknowledges the proposal without hostility: "Thank you for sending" — professional tone 2. Names a concrete internal constraint as leverage: "above budget approval threshold → CFO escalation → 4–6 weeks" — turns "we don't want to pay more" into "a delay that costs both parties time" 3. Demonstrates usage value to anchor the relationship: "18/22 users, 73% feature utilisation" — signals you're a good customer who deserves fair pricing 4. Offers multiple compromise paths: "multi-year, seat reduction, feature tier" — shows flexibility without naming your actual ceiling first 5. Frames the goal as mutual: "avoid a procurement delay on both sides" — vendor also loses by dragging this out
Why A fails: Threat without specifics is rarely believed and damages the relationship
Why B fails: "Can you give us a discount" has no leverage and is easy to say no to
Why D fails: Stating "our budget is fixed" as fact is often untrue and easy for vendors to call bluff on
2 / 4
Your cloud vendor SLA guarantees 99.9% uptime, but you have experienced 6 outages in the last quarter totalling 12 hours of downtime — well above the 99.9% SLA. How do you open the SLA breach conversation?
Option C is a professional SLA breach escalation because:
1. It opens formally: "formally raise an SLA performance concern" — signals this is documented, not casual 2. It quantifies the breach precisely: "12 hours actual vs. 2.2 hours contracted = 5× threshold" — no vagueness, no exaggeration 3. It asks for the vendor's root cause analysis before demanding remedies: "individual failures or systemic pattern?" — signals you understand operations and are open to explanation 4. It structures three distinct remedy paths: service credits (contractual right), infrastructure fix (prevention), SLA amendment (if current level is unachievable) — organized, not emotional 5. It proposes a concrete next step: "call with account AND infrastructure teams this week" — ensures the right people are in the room
Why A fails: "You breached the SLA, we want compensation" — accurate but not structured; doesn't invite dialogue or demonstrate understanding of the severity
Why D fails: Threatened departure without substance — often backfires if the vendor calls the bluff
3 / 4
A vendor is offering a new contract renewal with terms that would shorten the notice period for price changes from 90 to 30 days. How do you push back on this contract term?
Option C successfully pushes back on a contract term by:
1. Isolating one specific term: "I want to flag one specific term" — makes clear the rest of the contract is acceptable, reducing adversarial tension 2. Explaining the business impact in the vendor's language: "budget cycle is annual → 30 days creates an emergency amendment process" — not just "it's inconvenient" but a real operational consequence 3. Proposing two alternative solutions: (1) revert to 90 days, (2) add a price-change cap clause — gives the vendor a face-saving path if 30 days is a hard internal requirement 4. Framing it as mutual: "predictability for both sides" — caps also benefit the vendor by removing unpredictability from renewal conversations
Why D fails: "Please revert to 90" is a demand without reasoning — gives the vendor no reason to say yes
Why B fails: "We need to check with legal" — often perceived as delaying tactics; doesn't advance the negotiation
4 / 4
You are negotiating a new contract with a software vendor. They have a standard "no customisation" policy, but you need two specific workflow integrations. How do you make the case for customisation?
Option C negotiates past a "no customisation" policy by:
1. Acknowledging the policy reason first: "maintaining a clean product slate has real engineering value" — shows you understand the vendor's perspective, which lowers defensiveness 2. Making the request maximally specific: Each integration is described at a technical level — webhook read-only, build our endpoint ourselves, SSO using existing IdP — reducing the perceived scope dramatically 3. Reframing customisation as standard API tier: "Could live in API tier rather than formal customisation" — potentially sidesteps the policy by classifying it differently 4. Aligning with vendor roadmap: "likely in your roadmap given your SOC 2 posture" — positions SSO as something they were going to do anyway 5. Asking for feasibility assessment, not a commitment: "would your integrations team assess the engineering cost?" — low-stakes ask, easy yes 6. Leaving them a graceful exit: "If it's a significant lift, I'd understand" — signals good faith
Why A fails: "We need you to customise" — the answer to this is the policy
Why B fails: Citing competitors often triggers defensiveness rather than cooperation