Phase 1: Product Configurator Discovery, Requirements and Acceptance Criteria

A successful 3D product configurator starts before anyone models a product or designs a screen. The first phase is discovery: deciding what the configurator must sell, who will use it, which decisions it must control and what evidence will prove that the first release works.

This is phase 1 of the Configurix product configurator implementation series. It is written for manufacturers, brands, dealers, distributors, retailers, installers and sales teams that sell configurable or made-to-measure products.

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 product configurator discovery means

Product configurator discovery is the structured work used to convert commercial ambition into an implementable scope. It identifies the target product family, users, channels, product decisions, price behavior, required outputs, source systems, owners and acceptance cases.

The objective is not to document everything the business knows. It is to define one complete, valuable journey that can be built and verified. A clear first journey might be:

1. a homeowner configures a made-to-measure pergola on a website;
2. the system allows only accepted dimensions and compatible options;
3. the visible design and live price stay synchronized;
4. the buyer submits the saved configuration;
5. the sales team receives the product, dimensions, selected options and customer details;
6. a representative reopens the same project and creates a branded quote.

That is a testable workflow. “We need an innovative 3D experience” is not.

Start with the business decision, not the feature list

Configurator projects often begin with a long list: 3D, augmented reality, artificial intelligence, CRM, ERP, e-commerce, bill of materials and analytics. A list does not reveal which decision the software must improve.

Start with the user and completion event.

Question	Useful discovery answer
Who starts the configuration?	Website visitor, showroom adviser, dealer or internal salesperson
What are they trying to decide?	Product family, dimensions, layout, finish, accessories and budget
What may they change?	Only options available for their product, market and account
What must the system prevent?	Invalid sizes, incompatible combinations, unavailable components and unauthorized prices
What completes the journey?	Structured enquiry, saved design, quote, cart, dealer order or approved project
Who continues the work?	Sales, technical review, operations, dealer, order desk or production

This framing prevents a public self-service configurator from becoming an internal engineering form. It also prevents an assisted-sales CPQ tool from being reduced to a colour visualizer.

Choose the first product carefully

The best pilot is representative enough to prove the platform but contained enough to launch. It should exercise the important logic without importing every exceptional process into the first release.

A strong first product usually has:

• clear commercial value and regular enquiry volume;
• an identifiable product owner;
• drawings, catalogues, prices and examples that can be supplied;
• a manageable set of dimensions and option groups;
• rules that can be explained by subject-matter experts;
• a real completion action such as a quote or structured lead;
• reviewers who can answer questions and approve examples.

Avoid selecting a product only because it looks impressive in 3D. The pilot must prove that the product can be configured and carried into a useful business result.

Configurix supports product categories including pergolas, verandas, awnings, doors, fences and gates, garden rooms, carports, outdoor kitchens, HVAC and other configurable products. The exact product scope is defined from the accepted catalogue; Configurix is not a generic library that silently decides what a business sells.

Map the current sales and delivery workflow

Document the current path from enquiry to order. Interview the people who do the work, not only managers who receive the final report.

Capture:

• where product information is found;
• how dimensions and options are recorded;
• who checks technical validity;
• where prices, discounts and installation charges come from;
• how revisions are named and compared;
• how quotes are produced and approved;
• which details are re-entered into CRM, ERP, order or production systems;
• where delays, ambiguity and correction work occur;
• which documents or payloads downstream teams trust.

The purpose is not to automate every existing step. It is to understand which steps represent genuine controls and which exist because the current tools are disconnected.

Define the configuration boundary

A product configurator should be explicit about what it can decide and what still requires review. This matters especially for made-to-measure structures, engineered equipment, installation conditions and regulated products.

For example, a pergola configurator may validate catalogue dimensions, roof modules, screens, glazing and commercial options. A structural engineer or site survey may still need to confirm foundations, wind or snow loads, drainage, access and local requirements. An HVAC configurator may select accepted equipment combinations while a qualified professional remains responsible for final load calculations and installation design.

Discovery should label outputs accurately:

• customer estimate is not automatically a binding quote;
• option summary is not automatically a production BOM;
• catalogue validation is not automatically engineering approval;
• AR preview is not a site survey;
• CRM handoff is not an accepted ERP order.

Clear boundaries increase trust because every team knows what the result means.

Inventory the source material

Create a source register before implementation. Typical inputs include:

• current catalogues and option tables;
• product codes and family identifiers;
• dimension ranges and formula sheets;
• compatibility, dependency and exclusion rules;
• approved price lists, taxes, discounts and labour charges;
• CAD, 3D, drawings, photographs and material references;
• example quotes, orders, BOMs and installation packs;
• language, currency, unit and market requirements;
• website, CRM, ERP, PIM and e-commerce field definitions;
• privacy, access and retention requirements.

Each source needs an owner, version and status. If two spreadsheets disagree, the configurator team should not guess which one is correct.

The 3D product configurator requirements checklist provides a more detailed input inventory, while the configurator RFP and scorecard helps compare vendors using the same representative cases.

Turn requirements into acceptance criteria

Acceptance criteria describe observable behavior. They should cover normal, boundary and rejected cases.

Product acceptance examples

• A 4.0 × 3.5 m product accepts the specified roof and screen combination.
• A width below the catalogue minimum is rejected with a useful explanation.
• Selecting a dependent accessory adds the required component.
• Changing market or account changes only the permitted catalogue and commercial context.

Pricing acceptance examples

• A known configuration matches the approved expected total and itemization.
• A dimension boundary selects the correct price band.
• A discount above the user’s limit requires approval.
• Tax, delivery and installation rules use the accepted market context.

Workflow acceptance examples

• Saving and reopening a project preserves product identity, dimensions, options and revision.
• The quote references the same configuration shown in 3D.
• The CRM receives the agreed customer and project fields once.
• A failed destination request is visible and can be reconciled without creating duplicates.

These tests become the shared language between product experts, designers, developers and reviewers.

Assign owners and decision rights

Discovery is incomplete when every decision belongs to “the team.” Name accountable owners for:

• product catalogue and technical rules;
• pricing and commercial permissions;
• brand, content and documents;
• 3D appearance and product references;
• website and customer journey;
• CRM, ERP, PIM, e-commerce or production integrations;
• privacy, security and access;
• testing, launch and post-launch support.

One business owner should resolve conflicts across those areas. Configurix can structure and implement the accepted model, but it should not invent commercial policy or replace the manufacturer’s authority over product truth.

How Configurix approaches phase 1

Configurix is white-label 3D product configurator and configure-price-quote software. It connects browser-based 3D, catalogue options, compatibility rules, dimensions, live pricing, branded quotes, structured lead capture and optional downstream outputs in one scoped workflow.

During discovery, Configurix translates the selected product and journey into concrete implementation inputs:

• the product families and variants included in the release;
• the user roles and channels supported;
• the dimensions, options and rules that must work;
• the price behavior and permissions required;
• the visual states and source assets needed;
• the quote, lead, project, cart, order or BOM result;
• the integrations and field contracts in scope;
• the examples that will be used for acceptance.

An eligible focused first product with complete inputs and responsive reviewers can use the Configurix Fast Launch path, which can usually target around seven days. A broader white-label implementation with multiple products, deeper integrations and additional outputs can take up to about 30 days depending on scope. The signed plan, available data and agreed acceptance criteria determine the real commitment—not the headline duration alone.

Read the complete product configurator implementation guide or review the Configurix Fast Launch program.

Discovery deliverables

Phase 1 should end with a small, usable set of artifacts:

1. scope statement — product, users, channels, completion event and exclusions;
2. journey map — the accepted path from entry to business result;
3. source register — files, systems, owners, versions and gaps;
4. decision model outline — dimensions, option groups, dependencies and boundaries;
5. pricing outline — authorities, formulas, matrices, taxes, discounts and permissions;
6. output map — quote, lead, project, order, BOM or integration result;
7. acceptance pack — normal, boundary, rejected and failure examples;
8. ownership plan — reviewers, approvers and post-launch owners;
9. release plan — phases, dependencies, review cadence and target dates.

If those deliverables are ambiguous, starting development does not make the ambiguity disappear. It makes it more expensive.

Common discovery mistakes

Copying a competitor interface

A competitor’s screens do not contain your product model, pricing authority or operating process. Use market research to understand expectations, then design around your own catalogue and users.

Treating every request as phase-one scope

Multi-product, multi-market and multi-system programmes benefit from sequencing. Prove one complete lifecycle before opening every integration and exceptional rule.

Approving by appearance alone

A visually attractive model can still permit invalid products, misprice dimensions or lose revision data. Acceptance must cover structured state and downstream consequences.

Leaving maintenance until launch

Products, prices, translations and systems change. Discovery should define who may request, approve, implement, test and publish those changes.

Phase 1 completion checklist

Phase 1 is complete when the team can answer yes to these questions:

• Is the first product and channel named?
• Is the start-to-finish user journey documented?
• Are product, price, document and integration authorities identified?
• Are technical and commercial boundaries explicit?
• Are normal, boundary and rejected examples approved?
• Is each required output defined by fields and meaning?
• Are reviewers and owners available?
• Can the release be described without relying on vague feature language?

The next step is to turn those accepted requirements into a governed product model. Continue with Phase 2: Building the Product Data, Rules and Pricing Model.

Frequently asked questions

How long should product configurator discovery take?

It depends on product complexity, source quality, number of owners and decision speed. A focused product with accepted catalogues and prices can move quickly. Conflicting data, unclear ownership or several integrations require more preparation. Discovery should be long enough to remove material ambiguity, not extended to document every future possibility.

Can Configurix start without perfect 3D files?

Yes. CAD, drawings, catalogues, photos and physical samples can all help define the product. Their suitability for browser 3D is evaluated in phase 3. Missing product truth is more serious than missing presentation-ready assets.

Should the first release include ERP integration?

Only when it is required for the first valuable lifecycle and the receiving contract can be tested. A structured lead and quote may be the right first result; another business may need an accepted order or BOM. Scope the integration around a real trigger, fields, owner and failure path.

Is discovery only for manufacturers?

No. Configurix also works with dealers, installers, distributors, retailers, showrooms and sales teams. The discovery questions change by channel, but every implementation needs an accepted catalogue, user journey, commercial result and owner.