Catalogue
Products, families, options, components, identifiers, markets and lifecycle.
Planning and implementation guide
How to implement a product configurator—from product knowledge to an accepted system.
A practical guide to catalogue discovery, configuration rules, real-time 3D assets, live pricing, integrations, acceptance, rollout and maintenance. Use it to prepare a Configurix project or evaluate any alternative.
8
implementation phases
10
acceptance tests
18
detailed answers
The implementation boundary
A 3D viewer is one layer. A sellable configuration is the system around it.
Product rules
Dimensions, dependencies, exclusions, defaults, warnings and valid outcomes.
Visual model
Geometry, materials, motion, camera, scene and real-time device performance.
Commercial logic
Prices, quantities, account context, discounts, tax, installation and approvals.
User workflow
Roles, permissions, decision order, validation, save, quote, cart or handoff.
Business output
Documents, CRM, ERP, ecommerce, analytics, order, BOM and project revision.
Interactive readiness assessment
Find the inputs that can slow the build before they become rework.
Select the honest status for each area. This score is a planning aid, not a launch promise. Evidence and reviewer availability matter more than a high self-score.
Readiness score
0/24
Next focus: Product catalogue. Move it to “Ready to review” with the evidence described in that row.
Product catalogue
Can one representative product be described with stable families, options and IDs?
Ready means: A product owner can identify the sellable families, option groups, components, dimensions, defaults, market variants and lifecycle status without relying on one salesperson's memory.
Rules and boundary cases
Are valid, invalid and conditional combinations written down?
Ready means: Normal products, minimum and maximum dimensions, dependencies, exclusions, substitutions, warnings and hard stops are documented with expected results.
3D and material assets
Can the product be represented from source CAD, drawings or approved references?
Ready means: Geometry sources, scale, configurable parts, materials, textures, animations and visual review owners are available for the first product scope.
Pricing and commercial data
Can known configurations be reconciled to approved prices?
Ready means: Price lists, formulas, quantities, account or market context, discounts, tax, rounding, validity and example calculations have named ownership.
Users and journeys
Do you know who configures, what they may see and what action comes next?
Ready means: Customer, salesperson, dealer, administrator and approver roles have a defined entry point, permissions, decision flow and completion action.
Outputs and integrations
Is the required result defined beyond the visual configuration?
Ready means: The project names required quote, cart, CRM, ERP, order, BOM, document, analytics or API outputs, including exact trigger and receiving owner.
Ownership and acceptance
Are reviewers, decisions and observable acceptance criteria assigned?
Ready means: Product, commercial, brand, technical and operational reviewers know what they approve, how quickly they review and what evidence closes each issue.
Launch and operations
Can the organisation publish, support and change the configurator safely?
Ready means: Environments, publication, training, analytics, support, catalogue change, regression testing, access and incident ownership are planned.
Eight delivery phases
Build product truth first, then connect the complete sales journey.
Phases can overlap, but their decisions cannot disappear. Each one should leave evidence another reviewer can inspect instead of depending on project memory.
Phase 1 of 8
Define the business outcome and first journey
One named user, product, channel and completion event.
Decide whether the first release supports website self-service, assisted sales, dealer quoting, ecommerce, project capture or another journey. Define what the user starts with, what they may change, what they must understand and what counts as completion. Separate a visual demonstration from a sellable workflow.
Evidence
A one-page journey, user permissions, success event, excluded scope and accountable business owner.
Typical owner
Business sponsor + product owner
Phase 2 of 8
Select a representative product scope
A first product that exposes the important complexity without importing the entire catalogue.
Choose a family with meaningful options, dimensions, rules and prices. Include at least one common configuration, one boundary case and one commercially important exception. Record markets, currencies, languages and channels included in the first acceptance pack.
Evidence
Approved product family, source documents, sample projects, scope boundary and follow-on catalogue plan.
Typical owner
Product owner + sales operations
Phase 3 of 8
Model catalogue, rules and configuration state
A stable product model that can answer what is allowed and why.
Create stable identifiers for families, option groups, values and components. Define defaults, dependencies, exclusions, quantity and dimensional behavior, messages and revision rules. Keep labels separate from IDs so translations and renamed options do not break saved projects or integrations.
Evidence
Catalogue workbook or source model, rule examples, controlled values, expected messages and revision approach.
Typical owner
Product owner + configuration specialist
Phase 4 of 8
Prepare real-time 3D assets and visual states
A scene that represents every accepted product decision clearly and efficiently.
Review CAD, drawings, photography and existing models. Separate configurable parts, establish scale and pivots, define materials, textures, animations and camera behavior, and optimize for target devices. Decide which differences need geometry, a material swap, visibility state, procedural change or a non-visual data rule.
Evidence
Asset inventory, naming map, visual reference board, device budget, review renders and accepted material or motion states.
Typical owner
3D lead + product engineer + brand reviewer
Phase 5 of 8
Implement decision flow, validation and pricing
A user can reach a valid product and understand the commercial result.
Order choices around the buyer's decision, not database columns. Show defaults, consequences, validation and progress at the right moment. Connect every price-changing input to its source, formula, quantity basis, account or market context, rounding and approval requirement. Preserve an explainable calculation result.
Evidence
Clickable flow, role views, validation states, known-price test pack and line-by-line reconciliation.
Typical owner
UX + product owner + commercial owner
Phase 6 of 8
Connect documents, systems and project outputs
The accepted configuration can continue without manual reconstruction.
Define the required quote, cart, lead, opportunity, order, document, BOM or production output. For every connection name the source, destination, trigger, ownership, identifiers, fields, response, failure, retry and duplicate behavior. Integrate one accepted lifecycle before trying to connect every possible system.
Evidence
Source-of-truth matrix, field contract, representative payload, destination result and failure-recovery test.
Typical owner
Solution owner + destination-system owner
Phase 7 of 8
Run product, commercial and technical acceptance
Observable evidence that normal, boundary and failure cases behave as agreed.
Test product validity, visuals, prices, permissions, documents, integrations, responsive behavior, accessibility, performance, saved revisions and failures. Record input, expected result, actual result, owner and decision. A polished happy-path demonstration is not acceptance for a rule-driven sales system.
Evidence
Signed acceptance pack, unresolved issue register, approved exceptions and release decision.
Typical owner
Named reviewers across product, sales, operations and technology
Phase 8 of 8
Launch, measure and maintain the product model
A controlled operating system rather than a one-time visual project.
Publish through defined environments, train users, monitor meaningful events, support live projects and plan catalogue changes. Version product logic, prices, assets and integration contracts. Run regression cases when a component, formula, translation, template or receiving system changes.
Evidence
Release checklist, owner directory, event contract, support process, change calendar and recurring regression pack.
Typical owner
Operations owner + product owner + technical owner
Product data pack
Give the implementation team decisions, not a folder of unexplained files.
The first data pack does not need every future product. It needs enough approved truth to model, price and accept the representative scope without inventing rules.
Catalogue structure
- Family, model, component and option identifiers
- Market and channel availability
- Default selections and lifecycle status
- Customer-facing names and translations
Geometry and dimensions
- Source CAD, drawings, units and coordinate system
- Minimums, maximums, increments and equations
- Pivots, attachments, clearances and placement rules
- Expected technical views and dimensional outputs
Rules and compatibility
- Required, optional and conditional choices
- Dependencies, exclusions and substitutions
- Warnings, hard stops and engineering review cases
- Saved-project behavior after a catalogue change
Materials and visual states
- Finish codes, colors, texture references and samples
- Transparent, emissive and animated parts
- Lighting and camera references
- Visual acceptance owner and target devices
Pricing and quantities
- Pricebooks, effective dates, currency and market
- Unit, length, area, volume, module and formula prices
- Discount, margin, tax, installation and delivery rules
- Known configurations with expected line and total values
Outputs and identity
- Quote, project, cart, order or BOM fields
- Customer, account, salesperson and channel context
- Document templates, terms and approval states
- CRM, ERP, PIM, ecommerce and analytics identifiers
3D asset implementation
Prepare the model for product decisions, not only for a beautiful render.
A configurator asset is part of the product model. Its nodes, materials, variants, motion and scale need stable relationships to configuration state and acceptable performance on the devices buyers actually use.
Structure
Separate configurable parts deliberately. Keep names and pivots stable enough for material, visibility, motion and attachment rules.
Visual fidelity
Match approved profiles, proportions, finish behavior, transparency and light response. Review every meaningful state, not one hero angle.
Runtime budget
Set target devices and scenes before optimization. Inspect geometry, textures, materials, animation, draw behavior and loading as one budget.
Validation
Use specification validation and asset-audit tools where appropriate, then test the real scene because a valid file can still be too heavy or visually wrong.
Khronos describes glTF as a format designed to reduce asset size and runtime processing, and publishes specifications, validators, an asset auditor, optimization tools and commerce-ready asset guidance. These are useful pipeline references, not substitutes for product, visual and device acceptance in your own configurator.
Implementation ownership
Assign the decision before the review request arrives.
This compact responsibility model is a starting point. Replace role names with people and define who decides when product, commercial, brand and technical needs conflict.
| Domain | Accountable | Contributors | Release input |
|---|---|---|---|
| Product scope | Product owner | Sales, engineering, implementation | Sponsor |
| Catalogue and rules | Product owner | Engineering, configuration specialist | Sales operations |
| 3D assets and materials | 3D lead | Product engineering, brand | Product owner |
| Pricing and discounts | Commercial owner | Finance, sales operations, implementation | Sponsor |
| UX, roles and content | Experience owner | Sales, product, accessibility reviewer | Product owner |
| Integrations and data | Solution owner | CRM, ERP, ecommerce or PIM owners | Technical owner |
| Acceptance and release | Business acceptance owner | All domain reviewers | Sponsor |
| Live operations | Operations owner | Support, product, technology | Business owner |
Product configurator acceptance pack
Ten tests that make “working” observable.
Replace sample values with your actual product and expected results. Run the same pack against Configurix and every competing option so the comparison measures your workflow rather than presentation quality.
Representative configuration
01Build the most common product from a clean start and compare every visible and structured selection with the approved result.
Minimum and maximum dimensions
02Test exact boundaries, one valid increment inside them and one invalid value beyond them, including the expected message or corrective behavior.
Dependency and exclusion
03Select an option that requires another component, then an incompatible combination. Verify automatic changes, warnings and hard stops are intentional.
Known-price reconciliation
04Compare price lines, quantities, formula inputs, discounts, tax and rounding for customer, salesperson and account contexts.
Revision and resume
05Save, reopen, duplicate and revise a project. Confirm product version, price status and issued documents do not become ambiguous.
Role and market access
06Verify that every role sees only the correct catalogue, prices, margin, discounts, markets, accounts and actions.
Document and downstream output
07Generate the required quote, cart, CRM, order or BOM result and compare identifiers, fields, revision and visual snapshot with the source project.
Failure and duplicate submission
08Reject or time out a destination, retry the intended action and double-click it. Preserve the project and avoid duplicate business records.
Mobile, keyboard and responsive flow
09Complete the journey on priority devices and with keyboard controls where applicable. Check focus, labels, validation, reflow and recovery.
Performance and constrained network
10Measure the first useful interaction and option response on agreed devices and networks using the actual representative asset set.
Scope and delivery path
A focused first launch and a full platform build are different projects.
Choose the smallest scope that proves the important product and commercial logic, without pretending optional systems or future catalogues are already accepted.
Eligible focused scope
Fast Launch
A prepared representative product and focused journey can target around seven days when inputs, product decisions and reviewers are ready.
- One agreed product scope
- Prepared source inputs
- Focused customer or sales flow
- Fast review and written acceptance
Broader custom scope
White-label build
A multi-product, branded software build can take up to about 30 days depending on catalogue depth, integrations, outputs, languages and acceptance.
- Multiple products or markets
- Custom roles and interface
- Documents and integrations
- Phased technical acceptance
These ranges explain the delivery model; they are not unconditional guarantees. The accepted scope, source quality, integration access, reviewer availability and signed plan determine the actual timeline.
Implementation risks
Six common failure patterns—and the design decision that prevents each one.
Starting with the entire catalogue
What appears: The team spends months normalizing exceptions before a usable journey exists.
Better response: Choose one representative family and preserve a reusable data model. Prove normal and boundary cases before importing adjacent products.
Treating rules as UI conditions
What appears: Product knowledge is scattered through screens and cannot be reused, audited or tested consistently.
Better response: Model stable product state and authoritative rules separately from presentation. Give every acceptance case an input and expected result.
Optimizing visuals before product truth
What appears: The demo looks strong but permits products, dimensions or combinations the business cannot sell.
Better response: Approve representative structure, dependencies and boundaries early; develop visual quality and configuration validity together.
Mirroring price logic in several tools
What appears: Website, spreadsheet, quote and ERP totals diverge after the first commercial change.
Better response: Name the authoritative calculation for each context, return an explainable revision and keep a known-price regression pack.
Calling a successful request an integration
What appears: A lead or order appears in a demo, but duplicates, rejection, retry, permissions and reconciliation are undefined.
Better response: Specify lifecycle, identity, failure and ownership. Accept the destination result and recovery behavior, not only a 200 response.
No owner after launch
What appears: New prices, options and translations wait for developers or silently bypass regression testing.
Better response: Assign catalogue, commercial, content, asset and technical owners with a publication path and recurring change review.
Post-launch maintenance
Every change needs an owner and the right regression pack.
The configurator becomes operational product infrastructure. Keep the test scope proportional to what changed, while protecting saved projects, issued quotes and downstream orders from silent drift.
| Change domain | Examples | Minimum regression |
|---|---|---|
| Catalogue change | New or retired option, component, market or family | Rule and saved-project regression |
| Price change | Pricebook, formula, tax, discount or effective date | Known-price line and total reconciliation |
| 3D asset change | Geometry, material, texture, lighting or animation | Visual states, device performance and fallback |
| Content change | Label, translation, help, terms or document template | Priority languages, roles and issued-document behavior |
| Integration change | Field, authentication, endpoint, webhook or contract version | Success, rejection, retry, duplicate and reconciliation |
| Platform release | Viewer, browser, device, framework or dependency change | Critical journey, accessibility and performance pack |
Implementation questions
Product configurator implementation FAQ.
Detailed answers about project inputs, 3D assets, rules, pricing, BOM, integrations, accessibility, timelines, acceptance and maintenance.
Primary technical references
Standards and official guidance behind the technical checklist.
These sources support general 3D asset, web accessibility and API-security guidance. They do not prove a particular Configurix scope or replace acceptance against your product and systems.
Khronos: glTF runtime 3D asset delivery
Official glTF overview, specification links, validator, asset auditor, optimization resources and real-time asset creation guidance.
Khronos: Asset Creation Guidelines 2.0
Official guidance for commerce-ready real-time assets, including geometry, materials, textures, inspection and web optimization.
W3C: Web Content Accessibility Guidelines 2.2
The W3C recommendation for accessible web content, including keyboard operation, focus, reflow, status and input requirements.
OWASP: API Security Top 10
A primary industry reference for authorization, resource, business-flow and unsafe-consumption risks in API implementations.
Continue your evaluation
Move from implementation readiness to a tested vendor decision.
Product configurator migration guide
Replace spreadsheets, custom software or another vendor while preserving rules, prices, 3D assets, open quotes, integrations and search continuity.
Product data model guide
Design stable identities, characteristics, revisions, visual mappings, commercial context and downstream product records.
Product pricing engine guide
Prepare price methods, source ownership, account and market context, result records, revisions and permanent acceptance tests.
Configurator BOM generation guide
Prepare component masters, selection logic, variable quantities, effectivity, revisions, substitutions, operational views and BOM acceptance tests.
Configurator security and privacy guide
Map data, identities, roles, tenants, browser exposure, APIs, retention, recovery, evidence and permanent security acceptance tests.
3D asset pipeline guide
Turn CAD and source models into governed glTF or GLB assets with stable bindings, measured performance, validation and acceptance evidence.
Configurator testing and QA guide
Build model, contract, interaction, end-to-end and human-review evidence across rules, 3D, pricing, outputs and release gates.
Product rules engine guide
Model dependencies, exclusions, dimensions, derived values, execution order, review states and rule regression evidence.
No-code product configurator guide
Define the business-team authoring surface, specialist boundary, permissions, approval, publishing and change-safety evidence.
Product configurator glossary
Align the 48 core product, 3D, CPQ, commerce, integration and governance terms used throughout implementation.
3D configurator requirements checklist
Prioritize procurement scope and copy testable RFP language before implementation begins.
CPQ implementation guide
Plan commercial policy, quote revisions, migration, CRM and ERP handoff, adoption and post-launch ownership.
Product configurator software
Understand the complete category: catalogue, rules, 3D, pricing, quote and project data.
3D configurator examples
Review twelve product blueprints with inputs, rules, pricing, outputs and edge cases.
Product configurator integrations
Plan CRM, ERP, ecommerce, PIM, pricing, documents, analytics and BOM contracts.
Headless product configurator
Plan product authority, canonical configuration state, channel APIs, transaction guarantees and contract lifecycle.
Configurator cost guide
Model implementation, asset, integration, operating and multi-year ownership costs.
Compare configurator software
Use a weighted scorecard, acceptance tests and normalized cost model across vendors.
Configurator for websites
Plan embedding, mobile behavior, accessibility, analytics and lead or checkout completion.
Configurator analytics and KPIs
Turn measurement questions into event contracts, funnel definitions, data-quality checks and acceptance evidence.
Maintenance and catalogue governance
Define change ownership, impact assessment, release evidence, regression packs and saved-project versioning after launch.
Ready to scope the first product?