Matrix Pricing & Rule Authoring
Last updated 12 Oct 2026
At a glance
Matrix pricing sets a price across several dimensions at once (product, segment, volume, term and region), so one offering can carry many legitimate prices. The power is real, and so is the cost: every dimension multiplies the price points someone has to define, test and later explain.
The picture
Four rules match one deal and all set the per-site monthly price. One price reaches the quote.
1 · Deal context
- Offering
- Managed SD-WAN 100
- Segment
- Enterprise
- Volume
- 40 sites
- Term
- 36 months
- Region
- UK
2 · Gather matching rules
- Matrix cell: Enterprise × ≥25 sites × 36 mo£310
- Enterprise segment price book£360
- Default list price (TMF620)£400
- 2024 launch promotion£299
Promotion excluded: its validity period has ended
3 · Rank by specificity
- 13 matched dimensions£310
- 21 matched dimension£360
- 30 matched dimensions£400
A tie here is a modelling defect, broken by a documented priority order
4 · Price line
£310
per site per month
Set by the matrix cell, and only by it
How it works
Not every price comes from the same mechanism
"It’s a pricing rule" hides very different levels of complexity and risk. The models below differ in how the price is determined and where that logic is usually authored.
Pricing models compared
| Pricing model | How price is set | Typically authored in |
|---|---|---|
| List price | One fixed price per Product Offering Price, with no conditions | Product Catalog |
| Matrix / dimensional price | Looked up across two or more dimensions at once: product, segment, term, region | Pricing engine / rate tables |
| Volume-tier price | Price or discount steps as a quantity threshold is crossed | Pricing engine or CPQ rule set |
| Term / commitment price | Price varies with contract length or committed spend | Pricing engine or CPQ rule set |
| Negotiated override | A deal-specific price outside any standing rule, approved case by case | CPQ, at quote or approval time |
Which rule wins
Matrix pricing only works if "which rule wins" has one deterministic answer. An enterprise customer ordering above a volume threshold, on a three-year term, in a region with its own price book can match four or five rules at once. If precedence is not explicit, the same configuration resolves to different prices depending on the order the rules happen to be evaluated in. That is a bug nobody has noticed yet.
How conflicting rules resolve
Gather applicable rules
Every rule whose conditions match the configuration, customer and deal, and whose validity period covers today.
Rank by specificity
Rules that match more of the deal (a named account, a segment-volume-term cell) rank above general ones (the default list price).
Apply priority order
PricingWhere specificity does not decide, an explicit priority order, owned by pricing governance, breaks the tie.
Resolve deterministically
The same inputs always produce the same winner. A genuine tie is a modelling defect to fix, not a runtime coin flip.
Produce the price line
CPQThe winning rule, and only that rule, sets the price that reaches the quote.
Where TM Forum stops
TMF620 models price through ProductOfferingPrice, with recurring, one-time and usage price types and price alterations for conditional discounts. It standardises the shape of a price on an offering. The engine that does multi-dimensional lookup and precedence resolution sits outside TMF scope, as vendor- or platform-specific logic. That gap is deliberate, not a modelling failure.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Product Offering Price (list price) | Product Catalog | CPQ | Billing | TMF620 ProductOfferingPrice. |
| Pricing rules and matrix tables | Pricing engine (or the CPQ rule set where there is no engine) | Pricing administration | — | Usually outside the product catalog, which does not see them. |
| Quote price line | CPQ | Sales / partner portal | COM | Fixed when the quote is accepted. |
| Negotiated override | CPQ (with its approval record) | Deal desk | Billing | The approval reference must travel with the price into billing. |
In practice
CPQ platforms usually ship their own rule engine, billing platforms hold rating tariffs, and the product catalog holds list prices. Large estates often end up with all three holding part of the price logic: a CPQ rule layer on top of a pricing engine on top of a catalog price book, each with a partial view of precedence and none with authority over the whole.
What breaks first under scale is untested rule interaction. Combinations grow far faster than anyone tests them, so a stale promotion still matches, or a new segment rule collides with an old term rule. Under partial migration, when only some products move to rule-based pricing, sellers and systems have to track which mechanism prices which line. That tracking becomes a manual rule with no owner.
The trade-off
What it solves
A given segment, volume and term resolves to the same price every time, whichever seller or channel quotes it. Pricing owners can change one dimension, such as a new volume tier, once, instead of editing every offering.
What it does not solve
- Intent. A rule says what price applies, not why it was set or what assumption it depended on.
- Documentation. Hundreds of conditional entries have no built-in narrative.
- Strategy. A rule set can resolve deterministically and still produce pricing that makes no commercial sense.
What it adds
- Each added dimension multiplies the price points to define, test and explain.
- Precedence must be specified, owned and tested, or results depend on evaluation order.
- Rule interactions grow faster than the rule count and faster than anyone tests them.
Architecture decision
Where should a new pricing condition live?
Catalog price (TMF620)
Choose when the price is a standing property of the offering and every channel must quote it identically.
Pricing engine rule
Choose when the price depends on several deal dimensions at once and is reused across offerings.
Negotiated override in CPQ
Choose when the price is a one-off for a specific deal and needs an approval trail.
Breaks if the same condition is encoded in more than one layer, so no single layer can say which one won.
Takeaways
Key Takeaways
- Matrix pricing sets price across several dimensions at once
- Precedence must be explicit: specificity first, then an owned priority order
- Rules encode decisions, not intent; undocumented intent leaves with the author
- What breaks first is trust in the price, not the pricing engine
- TMF620 models ProductOfferingPrice; the resolution engine sits outside TMF scope
Check yourself
A 40-site enterprise deal on a 36-month term matches a segment price, a volume tier and a term discount, all setting the per-site price. What decides which applies?Show answerHide
Explicit precedence. Specificity first: the rule matching more of the deal’s dimensions wins. Then a documented priority order owned by pricing governance. If two rules still tie, that is a modelling defect, not something to settle at runtime.
Does TMF620 standardise the matrix pricing engine?Show answerHide
No. It standardises the shape of price on an offering (ProductOfferingPrice, including price alterations). Multi-dimensional lookup and precedence resolution live in vendor- or platform-specific logic.
Nobody can explain why a renewal priced at £310 a site. What has broken?Show answerHide
Trust in the number. The engine is doing what the rules say; the intent behind the rules was never recorded, and their interactions were never tested.