Phase 2: Building the Product Data, Rules and Pricing Model

Phase 2 turns approved requirements into the model a product configurator can execute. This is where catalogues, dimensions, product codes, dependencies, exclusions, formulas, price lists and permissions become structured data rather than knowledge spread across spreadsheets and experienced employees.

This is not simply a database exercise. The product model defines what the configurator may sell, how it explains choices and which structured result continues into quoting, CRM, e-commerce, ordering or production.

Implementation series: Phase 1 — discovery and requirements · Phase 2 — product data, rules and pricing · Phase 3 — 3D assets and UX · Phase 4 — integrations and testing · Phase 5 — launch and optimization

What a product configurator data model contains

A configurator data model represents the identities, attributes, relationships, constraints and commercial context required to create a valid product configuration.

At minimum, it normally needs:

• product families and models;
• stable product, option and component identifiers;
• dimensions, units, ranges and increments;
• option groups and selection cardinality;
• required, compatible and excluded combinations;
• derived values and calculated quantities;
• market, channel, account and role context;
• price sources, formulas, matrices and adjustments;
• visual states and material references;
• quote, order, BOM and integration mappings;
• configuration and revision identifiers.

The visible interface may show “Anthracite” or “Side screen.” Downstream systems may need a finish code, screen family, width, height, motor, fabric and quantity. The model connects the customer-friendly decision to the accepted operational meaning.

For a detailed architecture, see the product configurator data model guide.

Establish stable identity first

Every reusable entity needs an identifier that remains stable when display names, translations or screen positions change. Examples include:

• product family ID;
• model or system ID;
• option and option-value ID;
• material and finish ID;
• component or SKU ID;
• price-list and rule-set ID;
• market, dealer and customer-account ID;
• saved configuration and revision ID.

Names are content. IDs are contracts. If “Traffic white” becomes “White RAL 9016,” a saved project should not silently become a different finish.

Where standard product identifiers such as GTINs exist, they should be used according to the organization’s product-master policy rather than invented for configurator convenience. Google’s product-data guidance likewise warns publishers not to invent or reuse GTINs and recommends exact product identification when identifiers exist (Google Search Central).

Normalize the catalogue without flattening it

Normalization does not mean forcing every product into the same structure. It means separating reusable concepts so they can be governed consistently.

A made-to-measure product might be represented as:

• family: bioclimatic pergola;
• system: freestanding single-zone model;
• parameters: width, projection and height;
• modules: posts, beams, roof zones and drainage;
• closures: screens, glazing or slatted walls;
• comfort options: lighting and heating;
• finish: accepted frame and component colours;
• commercial context: market, dealer, price list, tax and installation zone.

A door configurator will use different concepts: frame, panel, opening direction, glazing, sidelights, hardware, threshold and security package. A pump configurator may use duty point, medium, material, seal, motor and control options. The model must follow the product’s real decision structure.

Model dimensions as governed parameters

Dimensions are more than input fields. Each parameter needs:

• unit and precision;
• minimum and maximum;
• permitted increments;
• default value;
• dependency on model or market;
• display and operational meaning;
• effect on geometry, price, quantity and output;
• boundary tests.

Do not assume that a number shown to a customer is the same number required by production. An opening size, outside frame size and manufacturing size may differ. If transformations are required, name and test them.

Parametric configuration is useful when geometry and outputs derive from variables rather than a finite list of static variants. The parametric product configurator guide explains the distinction in more detail.

Convert expert knowledge into rules

Product rules define the solution space. Common rule types include:

Inclusion rules

Selecting one option requires another. A motorized screen may require a compatible control unit.

Exclusion rules

Two options cannot coexist. A certain door panel may not accept a particular glazing layout.

Range rules

A system or component is valid only inside specified dimensional limits.

Cardinality rules

The user must choose exactly one roof type, may choose several accessories or must select at least one module.

Derived rules

Quantities, posts, modules, motors or fixings are calculated from dimensions and layout.

Context rules

Catalogue, options or permissions change by country, dealer, customer, role or date.

A rule should have an ID, purpose, owner, priority, inputs, output and test examples. A prose note such as “check large sizes” is not executable product logic.

The configurator rules engine guide covers dependencies, exclusions, constraints, explanations and rule governance.

Design rules for explanation, not only enforcement

Users should understand why an option is unavailable. Hiding every invalid choice may make the interface clean but can also make the catalogue feel incomplete. Disabling a choice without explanation creates frustration.

The right behavior depends on context:

• hide irrelevant options before they become meaningful;
• disable recognizable options when explaining the reason helps;
• suggest the change that would make an option available;
• preserve earlier choices when a new selection creates a conflict, then ask the user to resolve it;
• distinguish technical invalidity from commercial unavailability.

Rule explanations are part of the product experience and should be reviewed alongside the logic.

Build one pricing authority

Live pricing is accurate only when its source and policy are clear. A total can depend on:

• base model or system;
• dimensions, area, perimeter, volume or quantity;
• material and finish groups;
• component and accessory prices;
• price matrices and breakpoints;
• labour, survey, delivery and installation zones;
• dealer, customer and account price lists;
• margins, discounts and approval limits;
• currency, tax and rounding;
• effective dates and revisions.

Decide which system owns each part. The configurator may execute accepted formulas, call a pricing service or receive prices from ERP or another governed source. What matters is that the result is traceable and tested.

Separate price calculation from price presentation

The calculated commercial result and the amount shown to a user may differ by role or channel.

A public website might show:

• an exact consumer price;
• a budget range;
• a “from” price with clear conditions;
• no price, while still calculating an internal estimate.

A dealer portal might show account price, recommended retail price and margin. An internal salesperson may apply a permitted discount. The model should calculate from accepted policy, while presentation follows authorization and commercial strategy.

Configurix can support live prices, price lists, formulas, taxes, installation charges and role-specific commercial flows when they are included in the scope. The exact administration and approval controls are defined during implementation.

Read the product configurator pricing engine guide for formulas, matrices, price lists and testing methods.

Use worked examples to build and verify prices

Collect representative price cases before implementation:

Case	Why it matters
Standard product	Proves the basic model and default options
Minimum dimension	Tests lower bounds and first price band
Maximum dimension	Tests upper bounds, structure and surcharges
Boundary value	Confirms the correct side of a matrix breakpoint
High-option project	Exercises dependencies and option totals
Dealer account	Confirms account price and permissions
Different market	Confirms currency, tax, catalogue and installation context
Invalid combination	Proves the system blocks rather than prices an impossible product

Each example needs an expected result approved by the commercial owner. “It looks close” is not an acceptance criterion.

Connect product, visual and operational mappings

The product model must connect three views without confusing them:

1. customer view — understandable names, images and guided choices;
2. commercial view — price lines, discounts, quote language and project status;
3. operational view — identifiers, quantities, dimensions, units and downstream mappings.

One choice may affect all three. Selecting an anthracite frame changes the material in 3D, the line description in the quote and the finish identifier in an order or BOM. The mapping should be explicit, not inferred from screen text.

How Configurix approaches phase 2

Configurix builds the configuration experience around the customer’s accepted catalogue rather than forcing the product into a fixed demo library. Depending on the implementation, the governed model can connect:

• product families, dimensions and option groups;
• compatibility, dependency and exclusion rules;
• parametric or modular 3D states;
• live price calculations and commercial context;
• branded quote descriptions and imagery;
• structured lead and project data;
• optional CRM, ERP, PIM, e-commerce, order or BOM mappings.

Configurix supports ongoing customization. Products, options, prices, languages, documents and workflows can be extended after launch, subject to the agreed administration model, permissions, support scope and regression testing. A change should preserve stable identity and saved-project behavior rather than being treated as a visual edit only.

Governance for product and price changes

Define a change workflow before the first release:

1. request identifies the affected product, rule, price or output;
2. owner approves the intended commercial meaning;
3. impact review identifies visual, price, quote, BOM and integration consequences;
4. implementation occurs in a non-production environment;
5. regression examples are run;
6. reviewer approves the accepted behavior;
7. release is published with a version and rollback plan.

Saved configurations need an explicit policy. Some projects should remain on the historical product and price revision; others may be migrated. That decision depends on quotation validity, contract status and business rules.

Common phase-2 mistakes

Using display labels as identifiers

Translations and marketing names change. Stable IDs should not.

Encoding rules only in the interface

Disabling a button is not a reliable rule if APIs, saved projects or other channels can bypass it. Validate accepted state at the appropriate authority.

Combining technical and commercial rules without ownership

Maximum span and dealer discount are different policies with different owners, even when both affect the final offer.

Treating a spreadsheet as self-explanatory

Formulas need units, rounding, precedence, effective dates and worked examples.

Generating a BOM from visual names

A production or order output needs accepted component identities, quantities, units, revisions and mappings. It is not automatically created because a component is visible in 3D.

Phase 2 completion checklist

Phase 2 is complete when:

• product families and option values have stable IDs;
• dimensions have units, ranges, increments and tests;
• dependencies, exclusions and derived rules are documented and executable;
• normal, boundary and invalid configurations behave as expected;
• the price authority and calculation trace are accepted;
• market, account, role, currency and tax behavior is defined;
• customer, commercial and operational mappings are explicit;
• saved configuration and revision policy is agreed;
• product and price changes have owners and a release workflow.

The next step is to make the model visible and usable without losing its meaning. Continue with Phase 3: 3D Asset Pipeline and Configurator UX for the Web.

Frequently asked questions

Can Configurix calculate live and accurate prices?

Yes, when the accepted price logic and source data are implemented and tested. Configurix can calculate from dimensions, options, formulas, matrices, price lists, taxes, installation charges and commercial context. Accuracy must be proven against approved examples and maintained when policy changes.

Can our team add or change options later?

Yes. Configurix can be customized after launch. The exact method—administration tools, managed support or a combination—depends on the implementation. Every change should be assessed for rules, 3D, price, documents and downstream mappings.

Does Configurix replace our ERP or PIM?

Not automatically. Configurix can own or execute the customer-facing configuration and CPQ layer while connecting to accepted product, price and operational authorities. The system-of-record boundary is defined for each implementation.

Is an automatic BOM included in every project?

No. BOM generation is optional and requires component identities, mappings, quantities, dimensions, revisions and acceptance tests. A sales option summary, configured order and manufacturing BOM are different outputs and should be scoped accurately.