Parametric CPQ is a product configuration approach where values are computed by formula, conditions are enforced by rules, and the product is defined by a set of parameters (such as width, capacity or fabric) rather than by a list of pre-built variants.
It differs from a standard product configurator, which relies on discrete, independently selected options, because it can handle dimensions that are continuous, specifications that are derived from other inputs, and combinations whose validity depends on conditional logic.
The word “CPQ” gets stretched to cover almost anything. People use it for a simple product-options dropdown and for a fully rule-driven engineering configurator in the same breath.
Parametric CPQ in Odoo refers specifically to the second kind: a configuration model where values are computed, conditions are enforced, and the product itself is effectively defined by a set of parameters rather than by pre-built variants.
Here is what that distinction means in practice.
What is standard product configuration, and where does it stop working?
Variant-based Product Configuration in Odoo builds a product from discrete attributes and their values, and it works well when a product has a manageable number of independent options.
It stops working the moment options depend on each other, become continuous, or need a value calculated from other inputs.
A standard product configurator is built on discrete attributes and their values.
In Odoo, for example, this is the product.attribute and product.template.attribute.value model. It is the right tool when options are independent and few. A T-shirt in three sizes and five colors is fifteen straightforward variants, and a variant model handles that cleanly.
The model runs out of road in three situations:
- Options are not independent. A handle style that only makes sense for certain finishes.
- Options are not discrete. A continuous window width, rather than a fixed list of sizes.
- A value has to be computed from other inputs. Fabric yardage derived from width and drop.
Forcing any of these into a variant model has one of two outcomes. Either you cap what the customer can actually configure, or you generate an unmanageable explosion of SKUs to approximate it. Neither is acceptable for a genuinely made-to-order product.
Not sure whether your catalog needs parametric CPQ, or whether standard attributes are enough?
Talk it through with our team.
How is Parametric CPQ different from Standard Product Configurator?
Parametric CPQ adds two capabilities a variant model does not have: computed characteristics, which derive a value by formula from other inputs, and conditional rules, which show, hide or disable options based on live conditions elsewhere in the configuration.
Together they let a product be defined by its parameters rather than by a pre-enumerated list. The two pieces are worth naming precisely:
- Computed characteristics: Auto-type fields whose value is derived by formula from other inputs, rather than selected from a list. Total panel area calculated from width and height, for instance.
- Conditional rules: Compatibility rules that show, hide or disable options based on what has been selected elsewhere in the configuration, live, as the product is built.
With these in place, a product is described by its parameters, its width, capacity and fabric, instead of by a fixed list of everything it could possibly be.
The contrast is easiest to see in an example. A parametric wardrobe configurator computes Total Panel Area from Width and Height in real time, so the price and the bill of materials reflect the exact product.
A variant-based one simply lists “Small, Medium, Large” as three separate pre-priced options that only approximate what the customer actually needs.
Parametric CPQ vs. standard product configurator: what is the difference?
| Standard Product Configurator | Parametric CPQ | |
| Underlying model | Discrete attributes and pre-enumerated values | Parameters, computed values and conditional rules |
| How options behave | Independent and discrete | Can be dependent, continuous or derived |
| How values are set | Selected from a list | Selected, or computed by formula |
| How combinations are handled | Every valid combination is a pre-built variant or SKU | Product is defined by parameters, not enumerated |
| Best fit | A few independent options, such as a T-shirt in sizes and colors | Continuous dimensions, derived specs, conditional validity |
| Where it breaks | Options that interact, are continuous, or need calculation | Designed for exactly those cases |
When do you actually need Parametric CPQ in Odoo?
You need parametric CPQ when at least one of three things is true: dimensions are continuous rather than a fixed list, a derived specification depends on multiple inputs, or valid combinations depend on conditions that would otherwise require a human to remember.
If your options are genuinely independent and discrete, standard attributes are the simpler and faster choice.
Not every configurable product needs this level of machinery, and it is a mistake to reach for it by default. Parametric CPQ earns its added complexity only when the product genuinely demands calculation or conditional logic.
When it does, it replaces the two things that quietly cost configurable-product businesses the most: capped customization, and a person who has to remember which combinations are valid.
Frequently asked questions
Is parametric CPQ only relevant for manufacturers?
It is most common in manufacturing and made-to-order businesses, but any business selling a product whose valid specification depends on calculation or conditional logic can benefit, distributors included.
Can standard attributes and parametric characteristics coexist on the same product?
Yes. Aktiv CPQ deliberately keeps both systems available on the same template, so you can use standard attributes for simple options and custom characteristics where conditional or computed logic is needed.
Does parametric CPQ require custom development?
No. Aktiv’s CPQ addon exposes characteristics, compute expressions and rules as configuration rather than code, so most parametric behavior can be set up by a functional consultant rather than a developer.
What is the difference between CPQ and a product configurator?
A product configurator lets a buyer assemble a product from options. CPQ (configure, price, quote) adds pricing and quoting to that configuration. Parametric CPQ goes further again, defining the product by computed parameters and enforced rules rather than by a fixed list of variants.
Want to see parametric CPQ on your own product? See Odoo CPQ in action, or talk to our team about whether standard attributes or parametric characteristics fit your catalog.
