The environment around the offer
Decision Context
An offer is never evaluated in isolation.
The offer is the design object. Decision Context tells you what that offer has to beat, fit through, satisfy, avoid, or change in order to be accepted. You want a transaction on terms worth having; the other side's decision is the constraint on that objective. Model it, then design against it.
Decision Context defines the problem your offer has to solve.
The question is not whether your offer is good. It is whether it is better than what the other side will do instead, for the people who must approve it, under the constraints they actually face.
Those three clauses do most of the work. Each one can defeat an offer on its own, and each one calls for a different response. An offer that loses to the status quo needs something other than an offer that loses to a rival proposal, which in turn needs something other than an offer that everybody wants and nobody can approve.
Collapsing them is expensive. When every failure is read as evidence about the offer, the reflex is to improve the offer — usually by conceding price — and the actual obstacle survives untouched while the economics get worse.
Position
This is not a seventh lens.
The six lenses ask what the offer structurally does: what it creates, what each side keeps, what work it imposes, what can go wrong, what choice it forecloses, and when everything happens. Decision Context asks something else entirely — what environment that structure has to survive. It surrounds the offer rather than sitting inside it, and it is a property of the other side and the moment, not of the deal.
Every offer is measured against a reference alternative.
The other side is not choosing between your offer and nothing. They are choosing between your offer and whatever they expect to do instead. That expectation is the benchmark you actually have to beat, and it is frequently invisible because it has no proposal document.
Another proposal
A competing vendor or counterparty already in the conversation.
The status quo
Keep the current arrangement, which already works well enough and requires no decision.
Build internally
Absorb the problem with existing people, on a budget line that feels already paid.
Delay
Revisit next quarter, after the reorganisation, or once something else lands.
Solve part of it
A narrower tool, a manual workaround, or fixing only the piece that hurts.
An adjacent category
A service, a process change, headcount, insurance, or simply carrying the exposure.
Transact with someone else
The same objective pursued through a different counterparty entirely.
Keep the asset
Retain the technology, rights or capacity rather than licensing or selling it.
A different use of the same resources
Capital, rights, capacity or attention spent on another initiative altogether.
The relevant alternative is not the objectively best option, and it is not the competitor you would prefer to be compared with. It is what they actually expect to do if they do not accept. It can be worse than options they never seriously considered, and it usually holds two advantages nothing new can match: its burden has already been absorbed, and its results are observed rather than promised.
A deal can beat every competitor and still lose to the status quo, to delay, to an internal build, or to simply keeping the asset.
Different stakeholders often hold different alternatives at the same time. Finance is comparing this against another initiative, operations against carrying on as they are, the sponsor against doing nothing visible this year. One offer, several benchmarks.
The alternative is a design input, not a competitor report.
Identifying the benchmark is only useful if you then design against it. Once you know what you are being measured against, four questions follow, and each of them points at a change you can make to the offer.
- 01Where does the alternative genuinely outperform us, on the terms they care about?
- 02Where is it weaker — in outcome, burden, risk, timing, rights or certainty?
- 03Which costs and risks of moving away from it are real, and which are habit?
- 04What can we change — scope, timing, proof, commitment, economics, implementation, rights, sequence, or the promise itself — so the comparison turns in our favour?
Comparability decides what gets negotiated.
If your offer is structurally interchangeable with the alternatives, the other side can reduce the decision to a narrow common denominator — almost always price. A materially different configuration can change what is being compared, but only if the difference matters to them and is real in the exchange rather than in the language. There are four honest ways to move.
Outperformance
Win on the dimension the alternatives already compete on: faster, more reliable, broader rights, lower burden, better economics. It requires no re-education, which is its advantage. Its cost is that the margin must be large enough to survive both their scepticism and the work of switching — a lead that only shows up in a comparison table is usually below the threshold at which anyone changes course.
Differentiation
Change one or more meaningful attributes so the offer stops being interchangeable: different rights, different risk allocation, different sequence, different obligations on your side. The test is whether a well-informed person on the other side would say the options are no longer substitutes for each other.
Reframing
Establish that the comparison they are running is not the economically or strategically relevant one — that the real benchmark is the cost of continuing as they are, or that the metric that decides the outcome is total cost rather than unit price. This has to be grounded in facts and structure. A reframe the other side finds strained is worse than none, because it signals you are managing the comparison instead of answering it. The reliable ones feel like a correction they recognise.
Comprehensiveness
Combine elements so the offer solves more of the actual job, or removes a handoff or dependency the alternatives leave in place. That genuinely alters comparability. Adding unrelated extras does not — it just gives procurement more line items to discount.
These are not four theories. They are four ways of designing relative to a known alternative, and most live deals use more than one.
They are comparing mechanisms, not just promises.
Two offers can promise the same outcome and reach it by entirely different routes, with different burden, risk, timing, control, dependencies and credibility. The mechanism itself is often what is being accepted or rejected, and it is often where the objection actually lives.
In a technology deal, buying the asset outright, taking an exclusive licence, taking a non-exclusive licence, forming a joint venture, agreeing a revenue share, or building a distribution partnership are all mechanisms for reaching the same strategic objective. They differ enormously in what each side surrenders and when. If the mechanism is wrong for their situation, no adjustment to the number will fix it.
The other side is rarely a single mind.
A decision that looks like one judgment is usually several local ones running at once, each with its own upside, its own work, its own downside, its own reference alternative and its own approval right. The list below is a prompt, not a role model to be filled in.
Economic buyer
Accountable for the result, and comparing this against every other claim on the same money.
Users and operations
Compare the new way of working against what they already do every day.
Finance
Cares about period, cash profile and whether the money exists on a usable line.
Procurement
Measured on price, terms and process compliance, often against category benchmarks.
Legal
Compares the proposed allocation of liability and commitment against internal policy.
Security and compliance
Compares introduced exposure against a default posture of adding nothing.
Technical and implementation
Bears the integration work, and knows what else is already booked.
Executive sponsor
Spends political capital, and remembers the last initiative that went badly.
Board or investment committee
Sees a paper, not a relationship, and decides on a fixed calendar.
Owners, licensors, engineers
In an asset deal, the people whose knowledge, control or future upside is at stake.
A deal that is attractive to the organisation can fail because one necessary approver carries the downside and almost none of the upside.
That is not obstruction. It is a rational local judgment, and it is a design problem: either the burden or exposure on that person has to come down, or the benefit to them has to become real, or someone with a different balance has to own the decision.
Separate constraints from preferences.
A preference can usually be traded around: it has a price, and something else can be offered against it. A true constraint cannot. It has to be designed around or removed, and trading against it wastes concessions on a wall that does not move.
The complication is that stated constraints are often shorthand. "Policy requires a one-year term" may be policy, or it may be an inability to bind next year's budget, or unresolved doubt about whether this will work. Diagnose before you accept anything as fixed — and before you spend real economics buying your way past something that was never load-bearing.
Map the approval path, not just the relationship.
Most deals that die slowly die in a process nobody described to you. Legal is not the problem; an unmapped path is. These questions are worth answering explicitly, early, while there is still time to design for the answers.
- Who can actually say yes, and to what size of deal?
- Who can say no unilaterally, and on what grounds?
- Who must be consulted before anyone else can move?
- Which thresholds move the decision to a higher level?
- What information does each gate require, in what form?
- In what sequence do the approvals have to occur?
- Which gates consume calendar rather than persuasion?
- Where has a deal like this stalled inside this organisation before?
Thresholds, security review and procurement policy exist for reasons. The objective is to present a structure those controls can actually process — pre-built documentation, standard terms, a scope that sits below the level requiring a committee that meets twice a year — not to find a path around them.
Ask what changes if they wait.
Urgency belongs to the context unless it is embodied in the actual economics or timing of the deal. So the useful question is never how to create pressure. It is what the economics of waiting genuinely are, for them.
Sometimes delay costs them almost nothing: no deadline, no losses accruing, no window closing. Then delay is a strong reference alternative and your offer has a hard job — which is worth knowing before you spend three months on it. Sometimes waiting destroys value: a market window passes, a risk stays open, an operating cost continues, an incumbent arrangement lapses, a compliance date arrives. Then the work is to make that arithmetic visible and verifiable, not to manufacture a deadline of your own.
Budget is not the same thing as value.
An offer worth a million to them can be impossible against a five hundred thousand authority ceiling. Nothing about the value judgment is in dispute; the money simply does not exist in that period, on that line, under that signature. Discounting into a budget constraint sacrifices real economics to solve a problem the price was never causing.
A question that separates the two cleanly: if the price were half, would this happen this quarter? A no establishes that the number is not the obstacle.
What does work: phasing, a narrower initial scope, different payment timing, a different decision owner whose budget the benefit lands in, separate workstreams, or simply waiting for the cycle with the reason recorded. All of these are subject to genuine procurement and anti-circumvention rules. Splitting a deal to dodge a threshold is not a design move; it is a governance failure you would be creating for someone else.
Objections are evidence about the decision.
An objection is an observation about the context. It is not an instruction about what to change, and taking it literally is how good economics get given away for nothing.
"The price is too high"
Could mean: the value is not there for them; the money is in the wrong year; the number crosses an approval threshold; they do not believe the promise; a reference alternative is genuinely stronger; the problem is not urgent; the commitment attached to the price is what is objectionable. Or the price really is too high. Seven of those eight are not solved by a discount.
"We need termination rights"
Could mean: an unresolved risk they cannot name comfortably; a policy against multi-year lock-in; an inability to bind a future budget; a previous supplier failure still being remembered; or a genuine desire for optionality they are willing to pay for. Each points at a different structure.
Do not change the variable named in the objection until you understand the variable causing it.
And do not redesign the offer around the objection until you understand the decision underneath it.
Sometimes the context itself can change.
Fitting the offer to the environment is the usual move. It is not the only one. Some parts of the environment are facts you can genuinely alter — who is in the room, what is known, what has been demonstrated, whose budget the benefit lands in, which mechanism is on the table.
Bring in a different stakeholder
The person who owns the problem may not be the person you have been talking to.
Generate evidence
A reference, a data run on their own numbers, a diligence result — new facts, not new adjectives.
Run a pilot
Converts an argument about the future into an observation about the present.
Change the mechanism
A licence rather than a sale, a partnership rather than a purchase, a phase rather than a programme.
Surface the cost of waiting
Where delay genuinely destroys value, make that arithmetic visible rather than asserted.
Change scope so a different budget owns it
A narrower initial phase can sit with the person who benefits most and can approve fastest.
Solve a blocker's burden
Do the security pack, the integration work, the migration — remove the reason to say no.
Propose a workable approval path
Present a structure the controls can actually process, rather than one that must be excused.
The line to hold is clear enough. Changing facts, information, structure, or who genuinely owns the problem is deal design. Changing perceptions that the underlying facts do not support is not, and it fails on contact with delivery in any case.
Example · Enterprise software
"You're twenty percent too expensive."
One sentence, four entirely different decisions underneath it. The automatic discount is not a concession; it is a diagnosis, and usually the wrong one.
A · A competitor benchmark
They hold a real quote from a real rival. The move is outperformance or differentiation: win on something they weigh, or change the configuration so the two are no longer substitutes — different scope, different risk allocation, different obligations. Matching the number leaves you interchangeable and cheaper.
B · An annual budget cap
The value is accepted; the money is not available in this period at that size. The move is timing and phasing: a smaller first phase, ramped payments, expansion in the next cycle. Nominal economics can stay largely intact. A discount here destroys margin to solve a calendar problem.
C · Implementation doubt
"Too expensive" means "too expensive if it does not work." The move is proof: a paid pilot, acceptance criteria, milestone-linked payment, a reference on their own data. You are buying belief, not shaving price — and a discount quietly confirms the doubt.
D · The status quo looks free
They are comparing against a process whose burden was absorbed years ago. The move is to make the real cost, risk and burden of continuing visible, and to reduce the burden of switching away from it — migration, integration, parallel running. Price is not the axis in play.
Same words, four contexts, four different offers. The only version where a discount is the right answer is the one nobody bothered to check for.
Example · Technology licence
The owner will not sell, at any sensible price.
The valuation is fair, the terms are clean, and the answer is still no. More money has already been tried and made no difference — a reliable sign that the objection is not about the number.
Their reference alternative is keeping the technology. That alternative carries future upside they believe in, strategic control they do not want to surrender, a fear of selling too early into a market that may reprice it, and possibly a commercialisation route of their own. Against that benchmark, a clean cash sale is the one structure that removes everything they value.
The mechanism is what has to change, not the consideration. A field-limited licence that leaves other applications with them. A royalty that keeps them exposed to the upside they are betting on. A staged option that converts to broader rights once the technology is validated. Milestone payments tied to development progress. Retained rights in their own markets, with reversion if you do not commercialise. A joint venture where control is shared rather than transferred.
Every one of those can be worth more to you than a sale you cannot obtain, and several cost you less. The obstacle was never the price of the asset; it was the shape of the transaction.
Decision context map
Run this before you change a single term.
- 01What is the other side actually trying to accomplish?
- 02What will they genuinely do if they reject this offer?
- 03Which reference alternative does each important stakeholder use?
- 04Where does that alternative beat our offer, and where do we beat it?
- 05Are we competing on the same mechanism, or could another structure serve their objective better?
- 06Who benefits, who does the work, who bears the downside, who can block, who can approve?
- 07Which constraints are truly fixed, and which are preferences or proxies for another concern?
- 08What approval thresholds, processes and information requirements apply?
- 09What happens if they wait? Is delay costly to them, or comfortable?
- 10What is the objection telling us about the decision, rather than about the term it names?
- 11Can we change the offer to fit the context more cheaply than conceding the named variable?
- 12Can we change the context itself — through evidence, sequence, stakeholders or a different mechanism?
Architectural note
Decision Context sits around the offer, not inside it.
The offer is the object. Promise and Credibility define and support what it claims. The six lenses stress-test its structure. Decision Context models the environment it has to be accepted in. Nothing here produces a score, and none of it is a claim about what deals are made of.
It explains why the same structure is signed in one organisation and declined in another, and it tells you which part of the offer is worth changing — which is a different question from whether the offer is any good.
Next
Once you know why the current offer does or does not fit the decision environment, the next question is what to change.
That is Deal Moves: the specific transformations available to you, and what each one propagates into elsewhere in the structure.