Product configurator architecture
Integrated product configurator vs standalone tools.
Compare one connected configuration record with a stack of separate 3D, spreadsheet, quote, CRM and production tools—without assuming that either architecture is automatically right.
Updated 19 August 2026 · 12-minute guide
Short answer
Choose continuity where it matters.
Separate applications are not a problem by themselves. The problem begins when the selected product loses its identity between visualization, price, quote and order. Every re-keyed dimension, copied option and untracked revision becomes another place where the customer-facing design and business output can diverge.
An integrated product configurator keeps the governed specification at the centre. The 3D model, commercial calculation, proposal and downstream handoff either use the same record or exchange it through explicit identifiers and interfaces. CRM and ERP can still remain separate systems of record.
The standalone stack
Several capable tools. Several handoffs to govern.
Many teams already own every necessary function. The architecture question is how the exact product moves between them and who is responsible when one record changes.
3D or visual tool
Shows the product and may let a buyer change visible attributes.
Rules or selection guide
Explains permitted dimensions, dependencies and compatible options.
Spreadsheet and quote template
Calculates price and recreates the selected product in a commercial document.
CRM, ERP and operations
Store the customer, opportunity, order, bill of materials or project status.
Side-by-side comparison
Compare the workflow, not the feature checklist.
| Decision area | Standalone tool stack | Integrated configurator |
|---|---|---|
| Product definition | May be split across the 3D asset, price sheet, option guide and individual knowledge. | A governed configuration record expresses the selected dimensions, components and options. |
| Compatibility rules | Checked by the buyer, salesperson or a later technical review unless a separate rules engine is connected. | Required, excluded, dependent and review-only choices can be applied during configuration. |
| Price calculation | Selections are copied into a spreadsheet, calculator or quoting application. | The same fields that define the product can drive price lists, formulas, quantities and permissions. |
| Quote revision | A changed design may require another calculation, document and manual version check. | A saved configuration can create a new commercial revision while retaining project history. |
| Customer context | The CRM may store a link, screenshot or written summary of what the buyer selected. | A project can reference the configuration ID, selections, price, documents and customer action. |
| Operational handoff | Someone translates the approved quote into item, BOM, order, drawing or installation information. | Approved selections can become defined structured output for ERP, ecommerce, scheduling or production. |
| Catalogue change | The same option or price may need updating in several files and applications. | Ownership and publishing can be governed, with each connected output retested when logic changes. |
| Best fit | Simple products, low volume or workflows where each tool already has a reliable owner and interface. | Made-to-measure, modular or option-rich products where design, price and handoff must remain traceable. |
The revision test exposes the architecture.
Configure a product, calculate its price and issue a quote. Then change one input that affects geometry, price and downstream components—for example width, module count, material or an accessory with dependent hardware.
Inspect what updates automatically, what must be re-entered, which document is now valid and whether the final order still points to the approved revision. This single test is more informative than asking whether each application has an integration or export button.
Decision signals
Use the simplest architecture that preserves the product.
Standalone tools may be enough when
- The product is selected from fixed SKUs or a small number of independent attributes.
- A visual is for presentation and does not need to create a structured specification.
- Prices rarely change and can be checked without complex dimensions or dependencies.
- Quote volume is low enough that manual review is deliberate rather than a bottleneck.
- Existing integrations already preserve identifiers, revisions and data ownership reliably.
An integrated configurator is worth testing when
- Dimensions, components and accessories depend on one another.
- Salespeople repeat the same product checks or price calculations for every enquiry.
- The customer sees one product while the quote or order is rebuilt in another tool.
- Dealer, market, currency, margin or approval rules affect the commercial result.
- The approved configuration must continue to BOM, ERP, ecommerce or installation data.
A six-test evaluation pack.
Run the same cases in every shortlisted architecture. Count the manual steps and inspect the resulting records—not only the customer-facing screen.
Configure a representative product
Use the product your team sells most often. Include the actual dimensions, options, materials and customer information required for a complete proposal.
Trigger boundaries and invalid choices
Test minimums, maximums, increments, required components and incompatible combinations. Record where a person must interpret or correct the result.
Reconcile a known price
Supply a price example containing quantities, dimensions, accessories, labour, installation, tax and permitted discount. Confirm every line and rounding rule.
Create and revise a quote
Issue a customer proposal, change one important selection and create a revision. Check which version is valid and how the change is communicated.
Send the approved project downstream
Create the CRM, ERP, order, BOM or scheduling output required by the team. Compare identifiers and fields with the approved configuration.
Change the catalogue
Add an option, adjust a price and retire a component. Measure how many places must change, who can publish and how existing projects remain reproducible.
What integration should mean
One platform does not mean one system owns everything.
A credible integrated architecture names a source of truth for each data domain. The configurator may own the selected product and its revision. CRM may own the account and opportunity. ERP may own item masters, price sources, orders or production status. Ecommerce may own checkout and payment.
The important work is defining identifiers, fields, direction, timing, failure behavior and responsibility. A logo in an integrations list does not prove that the configured product, commercial result and downstream record remain aligned.
Migration path
Connect the highest-risk handoff first.
A team does not need to replace every application at once. Start with one product family and the handoff that creates the most re-entry or ambiguity. Preserve the existing CRM or ERP when it already performs its job well, then connect only the fields needed for the accepted scenario.
- 1.Choose one representative product and known price case.
- 2.Define the configuration record and stable identifiers.
- 3.Model the product rules and customer-facing journey.
- 4.Connect price, quote and the first required destination.
- 5.Test boundaries, revisions, failures and catalogue changes.
- 6.Expand by product family, market or downstream workflow.
FAQ
Integrated configurator questions.
What is an integrated product configurator?+
An integrated product configurator keeps a governed product specification connected to the visual model, price, quote, customer project and defined downstream outputs. Integration does not require every function to live in one database; it requires stable identifiers, agreed ownership and traceable data movement between the systems involved.
Is a 3D product viewer the same as a configurator?+
No. A 3D viewer presents a prepared model for rotation, zoom or inspection. A rule-driven configurator creates a permitted product variant from dimensions, components, materials and dependencies, then saves structured data representing that exact selection.
When are standalone sales tools a good choice?+
Separate tools can be appropriate when the product has few independent options, pricing is simple, quote volume is low, the visual does not need to drive structured data, or a team already has reliable integrations and clear ownership for each handoff.
What is the main risk of connecting tools manually?+
The main risk is not the number of applications; it is losing the relationship between the selected product and its commercial or operational output. Re-keyed dimensions, copied option names, untracked quote revisions and ambiguous identifiers create avoidable review work and make the final order harder to reproduce.
Does an integrated configurator replace CRM or ERP?+
Not necessarily. CRM can remain the owner of accounts and opportunities, while ERP can remain the owner of items, orders or production. The configurator should own or reference the configured product record and pass the agreed fields, identifiers and status to each destination.
How should a company compare the two approaches?+
Use the same representative product and test normal, boundary and invalid cases. Create a price, issue a quote, revise the configuration, send the approved data downstream and change one catalogue rule. Record every manual step, reconciliation point, failure mode and ownership decision.