Commitment Floor
also called Minimum Spend Obligation, Contracted Spend Floor
The minimum spend a contract obliges you to pay regardless of usage, which makes efficiency gains unrealisable until the term ends and therefore sets the pace of cost programmes and migrations.
An engineering team spends a quarter removing 40% of its telemetry volume. The work is real, the data proves it, and the invoice does not move. A year later a platform team lands a rightsizing programme worth a reported £400000 and finance reports no change. In both cases the spend sat under a minimum annual commitment, and below the floor you pay the floor.
A commitment floor appears in committed-spend cloud agreements, reserved capacity, enterprise software contracts, observability platforms, content delivery contracts and data platform licences. It is the mechanism that converts a discount into an obligation, and it is the single most common reason a genuine engineering win produces no financial result.
Why it matters
It changes the value of a saving from its headline number to its realisable number, and it changes the date on which any saving starts. A £400000 annual reduction against spend that is 90% committed for another 14 months is worth £40000 this year. That can flip a project from an obvious yes to a marginal no, and the arithmetic is not available to anyone who has not read the contract.
It also sets migration timing. The saving from moving off a vendor begins at the contract boundary, not on the day the engineering finishes, so the correct pace is to land the cut-over one or two months before renewal rather than as fast as possible. Teams that race to finish eight months early pay for both systems for eight months.
Implementation patterns
- Publish a commitment register: for each contract, the floor, the term end, the notice period, and the share of current spend it covers. This is a four-column table and almost no engineering organisation has one.
- Size commitments to the trough, not the average. Only the trough is capacity you are certain to consume across the whole term, especially once planned efficiency work lands.
- Sequence efficiency before commitment. Land the change, let usage settle for a month, then commit against the new floor. Doing the two in the same quarter makes them cancel.
- Prefer the flexible commitment shape when the roadmap is uncertain, accepting a smaller discount as the price of the option. A term reservation tied to one instance family is a bet on an architecture; a spend commitment is a bet only on volume.
- Gate every cost project on one question: what fraction of this spend is under a floor, and when does the term end?
Industry example
Cloud committed-use and reserved-capacity programmes have worked this way since the major providers introduced them around 2009, and the same structure spread into enterprise software, monitoring and content-delivery contracts. The publicly visible effect is the standard advice from every published cost practice from about 2019 onward: buy commitments against the usage floor rather than against the forecast, because the discount on an unused commitment is zero while the obligation is not.
Failure scenarios
- An efficiency programme lands under a fresh commitment, produces no invoice change, and makes the next cost programme harder to fund because the last one "did not work".
- A migration finishes a year before renewal and the organisation pays for two systems for a year, during which the cost line rises and executive support disappears.
- A three-year commitment is bought against a forecast and an architecture change six months later strands most of it.
- Nobody knows the notice period, so a contract auto-renews while the replacement is being built.
- Coverage is reported as a percentage of average usage, which hides the fact that the trough is far below the average on a workload with a daily or seasonal shape.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Deep coverage on a long term | The largest purchasing discount available | Architectural lock-in for the term and stranded commitment if plans change |
| Trough-sized coverage | Discount on capacity you will certainly use | Leaves discount unclaimed on the part of usage above the trough |
| No commitment | Full freedom to change | On-demand rates, frequently a large multiple of committed rates |
When not to use it
A heavy, long commitment is right for a stable workload with a known architecture and no migration planned inside the term, where it is usually the single largest purchasing lever available. Avoid it when a platform migration, a major re-architecture or an efficiency programme is in the next four quarters, when the workload's volume forecast spans a factor of two, or when the commitment is tied to a specific hardware family that the roadmap may abandon. In those cases buy a shorter term or a more flexible shape and treat the smaller discount as the price of reversibility.
Interview question
Q: You have found a change worth £400000 a year in cloud spend. What would stop you starting it on Monday?
What a strong answer covers: asking what share of the spend sits under a commitment and when the term ends; distinguishing headline from realisable saving; pacing the delivery to the contract boundary; the dual-run overlap during which costs rise; and the sequencing rule that efficiency work precedes commitment purchasing rather than following it.
Quick check
Quiz: You cut usage 40% under a minimum annual commitment with 14 months left. What happens to the invoice? Nothing until renewal. Below the floor you pay the floor, and the reduction is realised as headroom you already bought.
Flashcard: Why should a vendor migration be paced rather than rushed? Because the saving starts at the contract boundary, not at cut-over, and finishing early means paying both the vendor floor and the replacement's running costs for the remainder of the term.