For the renewal conversation
Negotiating from the price list
An AWS Enterprise Discount Program agreement is quoted as a percentage off on-demand. An Azure commitment is quoted against pay-as-you-go. A Google commit is quoted against published rates. A SaaS renewal is quoted against list, or against last year's price with an uplift. In every one of those conversations the discount is a percentage and the thing it is a percentage of is a published price list.
The vendor has a complete dated copy of that list. They know what they published last April, what they publish today, and which way it moved in between. The customer, almost always, does not — because no vendor publishes what a price used to be, and nobody thinks to save the page. That asymmetry is the whole reason this site exists, and it is at its most expensive in the six weeks before a renewal.
What a price archive can actually tell you
Four things, and it is worth being precise about them, because a great deal of what gets sold as negotiation intelligence is somebody's opinion about your leverage rather than a fact about your prices.
What has the list done since my rate was set?
What is committing worth on its own?
How often does this vendor raise prices?
How much of our increase is price, not usage?
If you already speak FinOps
The FinOps Foundation's Rate Optimization capability sets out what a buyer needs before negotiating: a consumption baseline, a view of current and planned usage, and a way to measure what the commitments returned. It is careful and it is widely adopted. It also names no public source for the list-price half of that, because until recently there was not one.
| The measure | Where it is here |
|---|---|
| Effective savings rate — spend against what the same usage would cost at on-demand list | The discount off list figure. With an on-demand baseline these are the same measure. Ours is the ceiling: it assumes every committed unit is used, because nothing here can see utilisation. |
| Commitment coverage — how much of the footprint sits on a committed rate | Partially. The stack table reports how many of your lines have a committed twin published at all, which bounds coverage from above. Your actual coverage is a fact about your account, and your billing data is where it lives. |
| Rate versus usage variance — which half of a bill's movement is which | The rate half, isolated by holding quantities constant. The usage half is not computed and not guessed at. |
| A dated rate card for the list layer of a forecast | The rate card CSV, exported from the variance page for whichever meters your model is built on, with the effective date and a citable URL on every row. |
About benchmarks
Advisory firms publish ranges for what enterprises achieve — figures in the region of five to thirty percent for AWS EDP agreements are widely quoted, scaling with commitment size and term, and Google and Microsoft publish their own standard committed-use rates outright. Those numbers are useful for calibration and we do not reproduce them as a gauge anywhere in the product, deliberately.
The reason is simple: they are other people's measurements of contracts we have never seen, and they cannot be checked. Every other number on this site can be — you can open the vendor's own page and verify it. Putting an unverifiable benchmark beside a verifiable price, in the same typeface, would make the two indistinguishable and quietly convert an archive into an opinion. If you want peer benchmarks, buy them from someone who has actually seen the contracts, and hold them to the same standard of provenance you hold us to.
What we can give you instead is the thing your vendor already has and you do not: a dated, checkable record of the list price your percentage is struck against.
On timing
The consistent finding across every published account of enterprise software and cloud negotiation is that the useful window opens roughly a year before renewal and has largely closed by thirty days out. That is not because vendors soften early; it is because a case takes time to assemble and an alternative takes time to price, and an incumbent who knows you have run out of time is negotiating against a deadline rather than against a position.
Which is a mundane conclusion with a mundane remedy: put the renewal dates in your stack and let the record accumulate against them. The page will tell you which stage each one is at and what that stage is for. A quiet year is evidence too — a vendor whose published price has not moved has no list-price argument for raising yours.
What this cannot tell you
- What you actually pay. Everything here is published list price. Your invoice reflects discounts, credits, support plans and an agreement we are not party to, all of which push the real figure down.
- What is in scope of your agreement. Real contracts carve services out, and newer managed services routinely sit outside a commitment for a year or more. The archive prices meters; it cannot read your contract.
- Whether you will use what you commit to. Unused commitment is the usual gap between a modelled saving and a realised one. That is a utilisation question and your billing data owns it.
- What a good outcome looks like for you. The pages here report what your position is, against what, and how it has moved. They never score it, and they will tell you when the numbers are unflattering.
Start with what you run
Ten or twenty meters is usually enough to make the shape of a deal visible. Your quantities, your discount and your renewal dates stay in the page's address bar — they are never sent to us and never stored, which is the only version of “tell us about your cloud spend” we are willing to offer.