Negotiation Strategy and Tactics Questions

Direct answer

Leverage is the ability to make the other side prefer your terms over their alternative. The main sources are: a strong alternative, the other side's need and deadline, information, legitimacy, relationships, and what you can offer that is valuable to them. You build leverage you lack by improving your alternatives, reducing their power over you, and increasing what they stand to lose or gain from the deal.

Main sources of leverage

In a typical technology deal, two or three of these usually matter most: a credible alternative, their deadline, and the information you hold. The rest support those. Leverage is always relative to the specific deal. Large companies are not always powerful: a small supplier whose product you cannot replace for 18 months holds more power in that deal.

Building leverage you do not have

1. Create alternatives. Run a qualified second source on a small slice of volume. Even 10% of traffic on another provider makes "we can move" credible. To make it visible without bluffing, state only true facts: "We have run 10% of production traffic on another provider for two months and the results are comparable. We would like to stay with you, so we want the renewal to reflect that we have a real option."
2. Reduce their leverage over you. Remove lock-in (being stuck with one vendor because switching is costly): use open standards, keep data exportable, shorten dependencies.
3. Aggregate demand. Combine purchases (buy as one larger customer instead of several small ones) across teams or business units so you are a larger customer.
4. Manage time. Start early. The side with the later deadline wins concessions. Do not reveal that your deadline is hard.
5. Build information. Collect usage, price benchmarks and their cost drivers before the meeting.
6. Increase what you can give. Offer a longer term, a reference, faster payment or a forecast. These cost you little and matter to them.
7. Find allies. An executive or user group on their side who wants the deal closed.

Worked example (assumed numbers)

A platform team pays a vendor $400,000 per year, with all workloads on that vendor. It builds a proof of concept on a second provider that handles 15% of workloads at 20% lower cost. Annual savings on that slice are 0.15 x $400,000 x 0.20 = $12,000, which is small, but the real value is the credible threat that the remaining 85% could follow. At renewal, the vendor's offer moves because their risk is not $12,000 but a trend.

Pitfalls

• Bluffing leverage you do not have; it damages credibility for the whole relationship.
• Using leverage so hard that you destroy goodwill with a supplier you will still need.

Direct answer

I would first make the number concrete, because 99.999 percent sounds like a label but means about 26 seconds of downtime per 30-day month. Then I would be honest that no provider can commit to that on dependencies it does not control, show what each availability level costs, and propose a structure that meets the real business need: a tiered commitment by service component, a measurement and credit regime with a cap, and a path to a higher level if the customer funds it. The commitment I sign has to be one I can keep: an SLA (service-level agreement, the contractual availability promise with remedies) I will probably breach is neither honest nor commercially workable.

Step 1: make the number concrete

MIN_PER_MONTH = 30 * 24 * 60  # 43,200 minutes in a 30-day month

for target in (99.9, 99.95, 99.99, 99.999):
    allowed = MIN_PER_MONTH * (1 - target / 100)
    print(f"{target}% -> {allowed:.2f} min ({allowed*60:.0f} s) of allowed downtime per 30-day month")

# Components in series: a request needs every one of them up at the same moment, so availabilities multiply.
print("three 99.99% services in series:", round(0.9999 ** 3 * 100, 4), "%")

# A service credit is a discount on the next invoice, paid when measured availability misses the promise.
# Tiers: below 99.95% earns 10%, below 99.9% earns 25%, below 99.0% earns 50% of the monthly fee.
def credit_pct(measured):
    if measured < 99.0:  return 50
    if measured < 99.9:  return 25
    if measured < 99.95: return 10
    return 0

fee = 50_000
for measured in (99.97, 99.93, 99.6, 98.5):
    print(f"measured {measured}% -> credit {credit_pct(measured)}% = {fee*credit_pct(measured)/100:,.0f} of a {fee:,} monthly fee")

Output:

99.9% -> 43.20 min (2592 s) of allowed downtime per 30-day month
99.95% -> 21.60 min (1296 s) of allowed downtime per 30-day month
99.99% -> 4.32 min (259 s) of allowed downtime per 30-day month
99.999% -> 0.43 min (26 s) of allowed downtime per 30-day month
three 99.99% services in series: 99.97 %
measured 99.97% -> credit 0% = 0 of a 50,000 monthly fee
measured 99.93% -> credit 10% = 5,000 of a 50,000 monthly fee
measured 99.6% -> credit 25% = 12,500 of a 50,000 monthly fee
measured 98.5% -> credit 50% = 25,000 of a 50,000 monthly fee

The 99.999% line is 26 seconds a month. The same output shows why: "in series" means a customer request passes through every service in turn and fails if any one is down, so the chance that all three are up is 0.9999 x 0.9999 x 0.9999, about 99.97%, lower than any single one. A promise higher than the product of the dependencies you rely on is a promise you cannot keep, so my cloud provider's own SLA and my own architecture set the ceiling.

Step 2: find out what the customer actually needs

I ask what an hour of downtime costs them and which functions must not fail (payments, ordering) versus those that can (reports, back office). Often the real requirement is "the transaction path must not fail during trading hours", not "every feature, every minute".

Step 3: offer alternative structures

• Tier by component: 99.99 percent (about 4.3 minutes a month) for the critical transaction path; 99.9 percent (about 43 minutes) for supporting services. The 99.99 percent tier is only honest if the critical path really can reach it. If it needs three services at 99.99 percent in a chain, the arithmetic above gives 99.97 percent, so I either shorten the chain on that path, or duplicate the weak links so one can fail while a second serves (independent copies in parallel: both down together is 0.0001 x 0.0001, a far smaller chance, though failures that share a cause make the real figure lower), or offer 99.95 percent instead. The platform's own 99.99 percent is the ceiling for anything built wholly on it.
• Measurement rules that are honest: a clear definition of "available", measured at an agreed point (for example at the customer-facing API, not inside my own network), with planned maintenance windows (announced periods when the service may be down) and customer-caused faults excluded.
• Credits instead of unlimited penalties: a service credit is a discount on a later invoice; I use tiers like those in the code (10 percent below 99.95, 25 percent below 99.9, 50 percent below 99.0) with an overall cap, for example 50 percent of the monthly fee, so the penalty exposure is bounded and priced.
• Termination right for chronic failure (for example missing the SLA in three months of any six), which gives the customer a real remedy without open-ended penalties.
• Architecture options at a stated price: multi-region active-active (running the service live in two or more geographic regions at once, so losing one region does not cause an outage) as a paid add-on, so the customer can see what higher availability costs.

Step 4: handle the budget and uncertainty

Because the demand would triple my infrastructure and operating cost, I would phase it: start at 99.9 percent, with a contractual path to 99.95 and then 99.99 as usage and budget grow, each step tied to a stated price. If their usage is uncertain, a committed baseline plus pay-as-you-go above it avoids paying for capacity that is not used. I trade: a longer term or larger commitment from them in exchange for the higher tier from me.

Step 5: show the constraint, do not just assert it

To reduce the demanded uptime I show evidence: the dependency chain (the services a request passes through, one after another) with each component's own SLA, the architecture options with costs, and incident history. "We cannot sign 99.999 percent" is an assertion; "the platform we run on commits to 99.99 percent, so anything above that in a single region would be a promise we cannot keep, and a second region is the priced route to go higher" is a constraint they can check.

In the room I would say: "I can commit to 99.99 percent, about four minutes a month, on the payment path, which is the part that costs you money when it stops, and 99.9 percent on reporting and back office. If we miss 99.99 percent, you receive credits of 10, 25 or 50 percent of that month's fee depending on how far we fall short (for the payment path I start the tiers at the 99.99 promise itself, for example 10 percent below 99.99, 25 percent below 99.95 and 50 percent below 99.9; the tiers in the code above are the ones for a 99.95 promise), and you can terminate if we miss three months in any six. If you need more than 99.99 percent on payments, I can price a second region as an option, and you can see what it costs."

Trade-offs and pitfalls

• Signing the number to win the deal: the penalty exposure and the credibility damage cost more than the contract is worth.
• Credits that exceed the fee: at some point the penalty is a bet against my own platform.
• Walk-away: if procurement insists on uncapped penalties for a figure I cannot deliver, I decline that term and offer the tiered structure; I would rather lose the deal than win one I must breach.

Direct answer

With three or more parties the main differences from a two-party negotiation are that coalitions form, that a deal needs every necessary party, and that one party can block. So I prepare by mapping each party's interests, alternatives and power, find which combinations could make a deal, and manage the process: who talks to whom, in what order, and with what proposals. I look for trades that cost one party little and are worth a lot to another, because that is the only way partly conflicting interests are reconciled.

Prepare

1. Map the parties. For each: what they want (interests, not positions), their best alternative to a negotiated agreement (BATNA), what they can concede, and who can veto.
2. Find the ZOPA, the zone of possible agreement, which is the range where a deal would beat every party's alternative. In a multi-party case, check each party in turn: does the draft package beat that party's alternative? If yes for everyone, a zone exists for all; if one party's alternative is better than any package I can afford, the zone exists only for a subset and I build around that party (see the example below).
3. Differences in value. Look for items valued differently by different parties (timing, risk, brand, volume). Those are the tradeable items.
4. My own position. My alternative, my priorities, and what I give for what.

Worked example (illustrative)

A software upsell (selling more to an existing customer) where three groups at the customer want different things: procurement (the buying department that negotiates price and contract terms) wants a lower price, the power users want more features and training, and the chief information officer (CIO) wants security and a single vendor. A single "price" negotiation will fail because the price is only procurement's concern.

Package: a 3-year term and price cap (procurement), included training and early access to the features users want (power users), and a security addendum plus a consolidation plan (CIO). Each party gets its main concern, and what I give costs me less than a price cut would. With assumed numbers: a three-year base of $300,000 ($100,000 a year) and a 10% unit price cut costs me $30,000. Instead, a 3% yearly cap against my normal 7% rise costs me $321,490 - $309,090 = $12,400, training is 20 hours at $120 loaded cost = $2,400, and the security addendum and plan is 40 hours at $150 = $6,000. The package costs about $20,800, roughly $9,200 less than the price cut, and it meets three different needs. For a like-for-like basis: the cap is costed against a normal 7% yearly rise, so the price cut should be too. A 10% cut on the $321,490 I would otherwise have billed is $32,149, so the package is about $11,349 cheaper on that basis, and the ranking does not change. ZOPA test for procurement: their alternative is a rival quote of $310,000 over three years, and our capped total of $309,090 is below it, so the deal is inside their zone. If the CIO's alternative were stronger than anything I could offer (they would rather stay with a rival), the zone would exist only for procurement and the power users, and I would build the deal around those two and bring the CIO in on better terms.

Manage the process

• Sequence. Meet the parties separately first (to learn real interests), then bring the shared proposal together. Start with the party that can block most and cares least about price: here the CIO, who holds a budget veto and cares about security, not price.
• Avoid sides. Do not let two parties lock into a coalition (an alliance of two against the third); keep proposals whole, so nobody can cherry-pick (take the parts they like and drop the parts that were the price of them).
• Shuttle and test. Shuttle means carrying proposals between parties one at a time instead of meeting all together. Test a proposal privately ("if the CIO's needs were met, would you support this?") before the joint session.
• Concession order. Concede early on items that cost me little and that unlock someone's support; hold the item that costs most until the end, and trade it only for a commitment.
• Keep a visible record of what is agreed so a party cannot reopen it.

Trade-offs and pitfalls

• Each side-conversation can create the suspicion of secret deals; be transparent about the process even if not about positions.
• A deal that satisfies everybody superficially but leaves one party unconvinced will fail in implementation. Check support (will they actively help make it work?), not just consent (will they not object?).
• What would change my call: when one party's alternative is very strong, I may build a deal with the other two first and add the third on better terms.

Direct answer

The best low-cost, high-perceived-value concessions are things that cost me little to deliver but that the other side genuinely values: flexibility on timing, extra visibility, small amounts of expert time, access, and recognition. I make sure each is traded by attaching it to an explicit condition ("if you can sign by the 30th, I can include...") and by never offering it unprompted. A concession given without a get teaches the other side that asking works.

The ranking logic: value per unit of cost

A concession is anything I give up or add. Perceived value is what the buyer thinks it is worth, which may differ from my cost. I want a high ratio of their perceived value to my real cost (for example, a give that costs me $300 and is worth $3,000 to them is a 10x ratio, while a 5% discount on a $100,000 deal costs me $5,000 and is worth $5,000 to them, a 1x ratio), and I also want to protect gross margin (revenue minus the direct cost of delivering, as a share of revenue). Discounts hit margin directly; the items below mostly do not.

Ranking worked example (assumed numbers): the architecture workshop costs me about 4 hours at $150 = $600 and the buyer would otherwise pay roughly $5,000 for outside consulting, so the ratio is about 8x. The executive call costs one hour at $300 = $300 and is worth about $3,000 to their internal case, 10x. Flexible billing on a $50,000 invoice delayed 60 days costs me about 50,000 x 8% x 60/365 = $660 of financing, and may be worth far more to a buyer stuck in a budget cycle. I rank the gives by that ratio, offer the highest first, and keep the discount, at 1x, for last.

How I keep each one traded

1. Know my list before I walk in. I write each give, its cost to me and the get I want, so I am never inventing a trade under pressure.
2. Say "if... then" every time. "If we can lock the end date this week, then I can include the architecture workshop." The sentence structure is the control.
3. Trade small for small, and step down. Large asks get large conditions; I never give the last concession for free.
4. Hold gives in reserve. I introduce them one at a time, so I always have something to move with.
5. Keep a ledger. After each call I note what was given and received, which stops quiet drift into free gives. A ledger row looks like: "12 Mar | gave: 2-week pilot extension (cost about 10 engineer hours) | got: written success criteria signed by their VP | open: reference call still owed."

Applying it: a price-sensitive partner on a 90-day plan

A common variation of this situation is a reseller or integration partner who pushes hard on price when my pricing is fixed. A partner here is another company that resells or builds on my product. In that case I cannot cut price, so I pitch a bundle of gives that cost me time, not margin. Example pitch: "I cannot move the price, but I can offer a joint onboarding plan with a named engineer for the first 90 days, a quarterly business review (QBR, a scheduled meeting where we review results and plans), and a co-branded case study (a customer story published under both our names), in return for a 12-month commitment." Resources I need: roughly one engineer-day per week for 90 days and a manager hour per month. Success in 90 days, measured: onboarding finished by day 30, partner live in production by day 60, and one referenceable outcome (a result they allow me to quote publicly) by day 90 (for instance a measured reduction in their ticket volume). All of it is conditional: if the 30-day milestone slips because of the partner, the later gives pause.

Trade-offs and pitfalls

• Low cost to me is not zero cost. If three customers each get an engineer, my capacity is gone. I cap each give (hours, duration) in the offer.
• A give with no deadline becomes an entitlement. I time-box every one.
• If the counterparty values something I mis-estimated, I check with a question ("which of these would matter most to your team?") rather than guessing.
• What would change the list: for a deal where the buyer is really negotiating on price, non-price gives will not satisfy them, and I need to talk about scope or terms instead.

Direct answer

I would run a structured review that separates what happened from my interpretation of it, using the counterparty's own words and actions as evidence, and then change specific habits in how I listen and question. In many cultures where direct disagreement is rare (often called high-context communication, where meaning is carried by context and relationship more than by explicit words), a polite phrase like "we will consider it" or "this may be difficult" can mean a firm no, and silence or a change of subject can mean disagreement. My failure, most likely, was reading politeness as agreement. I would also avoid replacing one stereotype with another, and treat culture as a hypothesis to test with the specific people involved.

How I would review it

1. Reconstruct the timeline from notes, emails and calendar entries: each of my claims and each of their responses, in order.
2. Mark every signal I treated as agreement ("yes", nodding, "we will study it", "interesting") and list the evidence for each reading. Ask: was there ever a specific commitment (a date, a named person, a number, a next step)? Where was there none?
3. Mark every signal I missed: delayed replies, a new person joining at a late stage, a change of topic when price came up, a request to "send more material" without a decision date, a decision-maker who never spoke.
4. Check the structure, not only the conversation: were decisions made by consensus in a group or by a senior person not in the meeting? Did the meeting format (large group, hierarchy, a translator) prevent open disagreement?
5. Get outside perspective: ask a colleague from that region, a local partner or an interpreter to read the transcript and tell me what they would have heard. Ask the counterparty, through a trusted intermediary, for feedback if the relationship allows.
6. Write down the root causes (for example, I assumed yes meant commitment; I asked only yes-or-no questions in a group setting; I pressed for a decision in the room).

What I would change in how I listen and question

Worked example (illustrative)

In a meeting I proposed a 90-day pilot and the regional director said "this is a very interesting proposal, we will study it carefully." I recorded this as positive. Two weeks later the response was a request for 12 more pages of material and no date. In the review I see that there was no owner, no date, and no budget conversation, and the person who spoke was not the one who signs. Next time I would ask afterwards: "Who else would need to see this, and what would they want to know first?" and then offer to meet that person with the director's introduction.

Pitfalls

Do not conclude "they are indirect" as a general rule: individuals vary, and company culture, seniority and age differ within one country. Do not blame the counterparty either. The disciplined conclusion is about my process: I relied on one reading of ambiguous evidence. I would share the lessons with the team, and add a rule to the deal plan that every pilot or next step needs an owner and a date on both sides.