Commercial Catalog & Bundling Mechanics

Bundling and configuration mechanics are where commercial intent gets encoded into something a catalog can enforce and a configurator can assemble. The commercial catalog is not marketing collateral — it is the contract between commerce and fulfilment. Every rule it expresses (what can be sold together, what is mandatory, what is mutually exclusive) is a promise that something downstream can actually build. An offering that cannot decompose into something the network can deliver should never have been made sellable in the first place.

Offering vs Specification

The single most important distinction in commercial catalog design is between a Product Offering and a Product Specification. Conflating the two — treating them as one modelling layer — is the root cause of most bundling defects: offerings that cannot be repriced independently, specifications that cannot be reused, and bundles that silently diverge from what was originally sold.

Parent–Child & Bundling Mechanics

Technical Dependency Mapping

A commercial bundle is only real if every offering and configuration option it exposes maps to something that can be ordered and built. That mapping runs through the SID decomposition chain: a Product Offering references one or more Product Specifications, each Product Specification is realised by one or more Customer-Facing Service (CFS) specifications, and each CFS decomposes into one or more Resource-Facing Service (RFS) specifications that ultimately consume physical or logical Resources. Bundling logic that stops at the commercial layer — cardinality rules, discount tiers, promotional eligibility — without a corresponding technical decomposition is not yet an orderable product; it is a priced idea.

What Bundling Solves

Bundling mechanics give sales and CPQ a governed way to express commercial packaging without hand-coding rules per deal. Cardinality and dependency rules centralise what would otherwise be scattered validation logic across quoting tools, order forms, and tribal knowledge. Reusable Product Specifications mean a single technical change — a new access variant, a new managed service tier — can be exposed through many commercial offerings without re-specifying the underlying technology each time. Done well, bundling turns "can we sell this combination" into a catalog lookup rather than a negotiation between sales and engineering for every deal.

What It Does Not Solve

Bundling mechanics are a modelling and validation layer, not a guarantee of deliverability or simplicity. They are frequently asked to solve problems that live elsewhere — in the technical catalog, in the order stack, or in organisational alignment between commercial and network teams.

• Does not fix missing technical decomposition — a bundle can be perfectly valid commercially while referencing a Product Specification with no CFS/RFS mapping behind it, making it unorderable in practice
• Does not remove combinatorial complexity — nested, configurable bundles multiply the number of valid states exponentially, and the catalog does not manage that complexity for you, it only expresses it
• Does not reconcile commercial and network truth on its own — a bundle can be sold, ordered, and even activated while the resource actually provisioned diverges from what the specification described, and bundling logic has no mechanism to detect that drift after the fact

When It Becomes an Anti-Pattern

This anti-pattern is attractive because catalog modelling is visible, demonstrable work that produces a clean-looking artifact reviewers can approve. It becomes dangerous the moment the organisation treats "the catalog is modelled" as equivalent to "the product is orderable." Every offering added to an unconsumed catalog is a liability disguised as an asset: it must eventually be reconciled against whatever the order and provisioning systems actually do, and that reconciliation cost compounds with catalog size rather than staying fixed.

What Breaks First

Under scale, unbounded bundle combinatorics and orphaned specifications break first. As nested, configurable bundles accumulate optional components and cross-product dependencies, the number of theoretically valid configurations grows far faster than anyone modelled or tested — configurations that pass commercial validation in CPQ but have no fulfillable decomposition once they reach an order system. Under legacy or partial adoption, the failure mode is different but related: Product Specifications get created and reused freely at the commercial layer while the corresponding CFS/RFS mapping is deferred "for later," so the catalog silently accumulates offerings that look orderable and are not. Both failure modes are invisible until real order volume hits an untested combination, because a catalog validator checks internal consistency, not deliverability.

TMF / SID Mapping

• TMF620 Product Catalog Management — the API surface for managing Product Offerings, Product Specifications, and their bundling relationships
• SID Product / ProductOffering / ProductSpecification — the logical entities that separate what is sold from what is technically defined
• CFS/RFS decomposition (SID Service / Resource) — the chain that turns a Product Specification into something the network can actually instantiate