Procurement Can't Negotiate on an Unverified Demand Signal

What procurement usually receives, a spend total, a contract and a date, set against the verified pack it needs before a sourcing event: verified quantity, a named decision owner, usage confidence, a dependency map and alternatives

When a software sourcing event starts, procurement receives a request that sounds simple: get us a better price. The input is usually a spend total, a contract and a date. What it rarely includes is any assurance that the quantity is right, that someone owns the decision, or that the product is being used the way the contract assumes. Procurement is then expected to negotiate hard on a number that nobody has verified, against a vendor who often knows the customer's deployment better than the customer does.

This post argues that the commercial problem starts upstream of pricing. The demand signal, the statement of what the organization needs, is often unverified, and no amount of negotiating skill recovers what a wrong signal gives away. It then sets out what procurement should ask SAM and IT for before the sourcing event, and how to recognize which spend has leverage.

The demand signal is usually weaker than it looks

A renewal request normally carries a quantity: last year's seats, cores or subscriptions, perhaps with a growth margin. That quantity is treated as demand. In practice it is often a historical purchase, and it may be wrong in either direction.

  • Too high. Seats assigned to people who left or changed roles, licenses for projects that ended, capacity bought for a peak that did not come.
  • Too low. Installations nobody counted, a new business unit, a platform migration that changes the metric. The shortfall surfaces later as a true-up or an audit finding.
  • Mis-specified. The right product at the wrong edition, or a metric that no longer fits how the software is deployed.

If the quantity is unverified, the best discount in the world is applied to the wrong base. A team that negotiates fifteen percent off a quantity that is one third higher than needed has been outmaneuvered before the first meeting. The work described in auditing software intelligence before renewal exists to prevent exactly this.

Spend totals hide the leverage

Procurement tools are built around spend: by vendor, by category, by business unit. Totals tell you where the money goes. They do not tell you where you can negotiate. Leverage sits in four things that spend data does not carry.

FactorThe question to answerWhy it moves leverage
DependencyWhat business process breaks if we do not have this?High dependency narrows your options and shortens your time
AlternativesWhat could replace it, at what cost and in what time?A credible alternative is the only real basis for a walk-away position
Usage confidenceHow sure are we that we use what we pay for?Confirmed low usage supports reducing quantity; unknown usage supports nothing
OwnershipWho decides, and who can commit the business?Without a decision owner, the vendor negotiates with procurement and sells to someone else

Two contracts of equal annual value can have opposite leverage. A team renewing Oracle, Microsoft and Salesforce in the same quarter might hold strong leverage on the Salesforce contract, because seat usage is measured, a reduction is supported by data and a competing product was evaluated last year. The Oracle renewal, tied to a core platform with an unreconciled position, has almost none, however the totals compare. Treating them with the same sourcing playbook wastes the first and exposes the second.

What procurement should ask SAM and IT for

Before a sourcing event begins, procurement should be able to ask for a short, consistent pack. It is a request for verification, not a larger report, and it should have an owner and a date. The questions below are the ones that change what procurement can do.

  1. Verified quantity. What is the current entitlement, what is deployed, what is used, and when was each last checked against a source? Gaps between the three should be explained.
  2. A named decision owner. Which business and technical leaders will stand behind the quantity and the product choice, and can they commit?
  3. Usage confidence. Is the usage measured or estimated, and how old is the data? Mark it high, medium or low.
  4. Dependency map. What processes, applications and users rely on the product, and what is the impact of a gap in coverage?
  5. Alternatives. What has been evaluated, what would switching cost, and how long would it take? If nothing, say so.
  6. Known unknowns. What does the team not know that could change the quantity, the metric or the exposure, with owners and dates for closing each. This is the register described in a register of unknowns beats a falsely complete inventory.
  7. Contract facts. Notice dates, renewal terms, price protections and audit clauses, in one place.

The pack should fit on a few pages. Its purpose is to replace the quiet assumptions in a sourcing brief with stated facts and stated gaps.

It helps to agree the pack with procurement once, as a standard, rather than negotiating its contents every time. Finance can then rely on the same fields across vendors, and SAM and IT know what they are expected to produce and how far ahead. A sourcing event starts with a standing expectation, not a scramble for exports in the final month, and the people who own the facts are asked for them while there is still time to verify.

Sourcing strategy follows from the signal

Once the signal is verified, software sourcing strategy becomes a practical choice. High dependency with few alternatives points to securing terms, such as price protection and a longer commitment, and to preparing the position early. Measured low usage points to right-sizing before renewal, which is leverage by itself. Strong alternatives point to a competitive process. A pack that shows uncertainty on a critical product points to delaying the commercial conversation until the uncertainty is resolved, which is not a failure of procurement but the most valuable thing it can ask for.

Software spend analysis improves for the same reason. Spend by vendor becomes spend by decision: how much of it is verified, how much is dependent, how much is owned. Software rationalization is the practice of acting on that view, cutting what is redundant and right-sizing what remains, and License Contract Manager keeps the contract facts, dates and positions that procurement needs in one record. The executive side of the same discipline is in what executives actually need from SAM during renewal negotiations.

A readiness check before any sourcing event

Use this as a gate. If the answer to any of the first four is no, the event is premature for that product.

  • The quantity is verified against deployment and usage, with the date of the last check.
  • A named owner can commit the business to the decision.
  • Usage confidence is stated, not assumed.
  • Dependencies are mapped well enough to say what a walk-away would cost.
  • At least one credible alternative has been assessed, or the absence of one is acknowledged.
  • The known unknowns are listed, owned and dated.
  • Contract notice dates are confirmed, so the timeline is real.

This does not slow procurement down. It moves the hard work to the point where it is cheapest, before the vendor is in the room. A team that arrives with a verified signal negotiates on facts. A team that arrives with a total negotiates on hope, and the vendor is usually better informed.

Alex Cojocaru

Alex Cojocaru

Alex has been active in the software world since he started his career as an Analyst in 2011. He had various roles in software asset management, data analytics, and software development. He walked in the shoes of an analyst, auditor, advisor, and software engineer, being involved in building SAM tools, amongst other data-focused projects. In 2020, Alex co-founded LICENSEWARE and is currently leading the company as CEO.