Configurix
Demo buchen

Buyer checklist · RFP template

3D product configurator requirements checklist.

Define what your configurator must do, what evidence a vendor must show and how your team will accept the result. Prioritize twelve requirement areas and copy a practical RFP starting point based on your launch scope.

Build your requirements Open the demo test pack
12requirement areas
10vendor demo tests
18buyer FAQs

Interactive requirements builder

Decide what belongs in the first release.

Mark each area as must-have, should-have or later phase. The requirement and acceptance language stay specific; only the delivery priority changes. Review the result with product, sales, operations, IT and the people who will maintain the catalogue.

Requirement 01

Catalogue and product model

Families, option groups, components, dimensions, defaults, lifecycle and stable IDs.

Requirement language

The configurator shall represent the supplied product families, structures, components, dimensions, option groups, default values and market availability using stable identifiers that remain separate from customer-facing labels.

Acceptance evidence

One normal product, one minimum, one maximum and one retired or unavailable option produce the agreed visible choice set and structured product record.

Inputs and procurement warning

Inputs: Catalogue export, product hierarchy, option list, component IDs, dimensional ranges, market availability and lifecycle ownership.

Watch for: A visual list of colours is not a product model if the final selection cannot be saved, identified and reproduced.

Requirement 02

Rules, constraints and validation

Dependencies, exclusions, required choices, limits, warnings and recovery paths.

Requirement language

The configurator shall prevent or explain invalid combinations and shall apply the supplied dependencies, exclusions, required selections, minimums, maximums, increments and conditional review rules.

Acceptance evidence

The vendor runs the agreed invalid and boundary cases. Each case produces the expected allowed state, message, automatic change or hard stop without corrupting the saved configuration.

Inputs and procurement warning

Inputs: Rule matrix, engineering limits, sales exceptions, known invalid combinations, warning copy and decision owners.

Watch for: A disabled button proves little unless the team can explain the rule, the saved state and how the user recovers.

Requirement 03

Real-time 3D and visual accuracy

Geometry, materials, configurable states, camera, animation and device budgets.

Requirement language

The 3D scene shall respond to every visual field named in the configuration data dictionary and shall show approved geometry, materials, visibility states and motion on the agreed browsers and devices.

Acceptance evidence

Approved camera views for representative and boundary configurations match the accepted references. Parts do not intersect, float, disappear or show the wrong material when options change.

Inputs and procurement warning

Inputs: CAD or models, drawings, scale, material references, configurable-part map, approved views, animations and target-device list.

Watch for: A beautiful generic render is not evidence that the visual model is driven by the same product state used for price and output.

Requirement 04

Pricing and commercial logic

Price lists, formulas, quantities, accounts, markets, tax, currency and approvals.

Requirement language

The system shall calculate the supplied price cases from the agreed sources, formulas, quantities, account and market context, discounts, tax, currency, rounding and validity rules.

Acceptance evidence

Every line and total in the known-price test pack reconciles to the approved result, including thresholds, dimensional quantities, discount permissions, tax and rounding.

Inputs and procurement warning

Inputs: Price lists, formulas, sample calculations, quantity basis, currencies, tax rules, customer groups, discounts and approval policy.

Watch for: The phrase ‘dynamic pricing’ is not a requirement. A reconciled calculation with named inputs and an expected result is.

Requirement 05

Users, roles and sales journeys

Customer, salesperson, dealer, administrator, approver and operational roles.

Requirement language

The configurator shall apply the agreed catalogue, price, brand, language, account and action permissions for each user role and shall preserve the correct project owner and next action.

Acceptance evidence

The same test project is opened by the named roles. Each sees only the permitted data and actions, and the handoff reaches the expected person or queue.

Inputs and procurement warning

Inputs: User journeys, roles, accounts, permission matrix, login rules, price visibility, ownership and completion events.

Watch for: A public product customizer, assisted-sales tool and dealer CPQ may share an engine but should not expose the same decisions or commercial data.

Requirement 06

Responsive, accessible customer experience

Guidance, keyboard operation, touch, status, error recovery and responsive completion.

Requirement language

The important product-selection, validation, save and completion actions shall work on the agreed viewport sizes and input methods, with labels, focus, status and error handling defined for the target accessibility level.

Acceptance evidence

A user completes the representative journey by keyboard and on the named phone and tablet without horizontal overflow, blocked controls, missing status or reliance on camera dragging for essential choices.

Inputs and procurement warning

Inputs: Supported browsers, devices, viewport sizes, accessibility target, input methods, content hierarchy, error states and test users.

Watch for: Responsive screenshots do not prove that selection controls, validation, saved state and completion remain usable on a real device.

Requirement 07

Quotes, documents and approvals

Saved projects, revisions, branded output, signatures and approval state.

Requirement language

An accepted configuration shall create the agreed estimate, quote or proposal with the correct customer, product, options, visuals, price, terms and revision relationship.

Acceptance evidence

Create a quote, revise a price-changing field and issue a new version. The current and previous documents remain traceable to the correct configuration and approval state.

Inputs and procurement warning

Inputs: Document templates, required fields, legal text, visuals, price detail, approval flow, signature behavior, numbering and revision policy.

Watch for: A PDF export is not enough if a changed configuration silently updates an already issued commercial document.

Requirement 08

CRM, ERP, ecommerce and API integrations

Sources, destinations, triggers, fields, identifiers, failures, retries and reconciliation.

Requirement language

Each named integration shall send or receive the agreed fields using stable identifiers, authentication and triggers, and shall expose delivery, rejection, retry and duplicate status to the responsible operator.

Acceptance evidence

Accepted payloads create the expected destination record exactly once. Rejected and unavailable destinations produce an actionable visible state and a controlled recovery path.

Inputs and procurement warning

Inputs: System owners, API documentation, sample payloads, field mapping, identifiers, environments, credentials, rate limits and failure ownership.

Watch for: ‘Integrates with ERP’ is not testable until the exact event, payload, destination result and failed-delivery behavior are named.

Requirement 09

BOM, order and production handoff

Components, quantities, dimensions, drawings, files and downstream order data.

Requirement language

Where included in scope, the approved configuration shall generate the agreed bill of materials, configured order, production fields, technical files or installation data from the same accepted product revision.

Acceptance evidence

A representative product and boundary case produce the expected components, quantities, dimensions, option codes and files, and operational owners approve the downstream result.

Inputs and procurement warning

Inputs: BOM examples, component logic, units, tolerances, drawings, file formats, ERP or production fields and technical approval rules.

Watch for: A customer-facing specification should not be described as production-ready unless operations has accepted the exact output and revision behavior.

Requirement 10

Brand, language and market configuration

White-label delivery, translations, currencies, regional catalogues and domains.

Requirement language

The system shall apply the agreed brand, domain, language, terminology, catalogue, price, currency, tax, document and contact behavior for each market and channel.

Acceptance evidence

The same project is opened in every launch language and market. Labels, values, units, price context, documents, email and fallback behavior match the approved market pack.

Inputs and procurement warning

Inputs: Brand system, domains, languages, translation ownership, terminology, locale formats, market catalogues, price lists and legal content.

Watch for: Translating interface labels is not a multilingual implementation if product data, documents, messages and market rules remain in one locale.

Requirement 11

Security, privacy and data ownership

Authentication, authorization, personal data, retention, export, deletion and incident ownership.

Requirement language

The solution shall document authentication, authorization, data fields, storage regions, subprocessors, retention, export, deletion, logging, backups, vulnerability handling and incident responsibilities for the agreed deployment.

Acceptance evidence

Role and object-level access tests pass; personal and commercial data follows the approved lifecycle; exports and deletion requests produce the expected result; security responsibilities are assigned.

Inputs and procurement warning

Inputs: Data-flow diagram, role matrix, privacy review, retention schedule, hosting information, subprocessors, security contacts and recovery requirements.

Watch for: A generic compliance badge does not replace a deployment-specific data flow, access test and contractual responsibility matrix.

Requirement 12

Performance, analytics and maintenance

Budgets, events, environments, publishing, support, change control and regression testing.

Requirement language

The project shall define performance and availability budgets, meaningful analytics events, release environments, publishing permissions, support paths and regression tests for catalogue, pricing, asset and integration changes.

Acceptance evidence

The representative journey meets the agreed test profile; analytics events contain the expected context; an option and price update follow the documented review, publication and rollback process.

Inputs and procurement warning

Inputs: Performance profile, analytics plan, environments, release owner, support service, change calendar, regression pack and saved-project policy.

Watch for: The first launch is not the whole cost. Ask who changes a product next month and how existing projects remain reproducible afterward.

From feature list to acceptance

Write behavior you can observe.

“3D, pricing and ERP integration” describes topics. It does not say which product changes, which calculation is correct, which record is created or what happens when the destination fails. A strong requirement combines four parts: source input, observable behavior, expected result and accepted evidence.

Source input

Attach the product data, rule, price case, document, payload or policy the system must use.

Observable behavior

Name the user action, system trigger, role, market and state that cause the requirement to run.

Expected result

Describe the visible, calculated, saved, generated or transferred result precisely enough to compare.

Accepted evidence

State the environment, case, reviewer and artifact that prove the result and close the requirement.

Vendor demo test pack

Test the same product with every vendor.

Send the cases before the demonstration. Let the vendor state which result is live, configured for your product, planned, custom work or outside scope. Score evidence, not presentation quality.

Test 01

Representative product

Configure the product your team sells most often from entry point to the required customer and business output. Record every manual workaround.

Test 02

Minimum and maximum

Use the lowest and highest accepted dimensions, module counts and option quantities. Confirm visual geometry, validation, price and output.

Test 03

Invalid combination

Select two incompatible choices, remove a required component and trigger a conditional option. Inspect the explanation and saved state.

Test 04

Known price

Run a supplied calculation containing dimensions, quantities, accessories, tax and discount permissions, then reconcile every line.

Test 05

Quote revision

Issue a quote, change a price-driving field and create a revision. Confirm which product and document versions remain valid.

Test 06

Role and market

Open one project as a customer, salesperson, dealer and administrator in each launch market. Check access, branding and price visibility.

Test 07

Real mobile journey

Complete selection, validation, save and the primary conversion action on the named phone and network profile—not only a desktop emulator.

Test 08

Integration failure

Send an accepted project to the destination system, then reject a payload and disable the endpoint. Check status, retry and duplicates.

Test 09

Post-launch change

Add an option, change a price, publish a translation and retire a component. Measure ownership, testing and saved-project behavior.

Test 10

Export and exit

Request the agreed catalogue, configuration, customer, quote and asset exports. Confirm format, completeness, ownership and timing.

RFP writing sequence

A shortlist is stronger when the inputs are ready.

Vendors cannot prove a product rule, price or output without representative source data. Prepare one useful scope before asking for broad platform promises.

  1. 01Name the user, product, channel and completion event.
  2. 02Attach source data and representative normal, boundary and invalid cases.
  3. 03Separate must-have launch scope from useful later phases.
  4. 04Write each requirement as observable system behavior.
  5. 05Add the input, expected result, environment and evidence required for acceptance.
  6. 06Assign business and technical owners for data, review and decision timing.
  7. 07Normalize implementation, recurring cost, internal effort and future catalogue change.

Vendor evidence ladder

Not every “yes” carries the same evidence.

Record the evidence level beside every important requirement. A generic demonstration can be useful, but it should not be scored like an accepted scenario using your product, data and required output.

1Discovery only

Feature claim

A website, slide or salesperson says the capability exists. Useful for a longlist, but not evidence for your catalogue or workflow.

2Platform pattern

Generic demonstration

A prepared example shows the feature. This proves a reusable pattern, but not your rules, prices, data or ownership model.

3Useful evidence

Configured prototype

A representative part of your own product and journey runs with agreed inputs. Boundary and output behavior can be inspected.

4Strong evidence

Accepted working scenario

Named cases pass using approved source data, expected results and the environment included in the agreement.

Primary technical references

Turn standards into project-specific tests.

Standards and guidance help define vocabulary and risk. Your RFP still needs a named product, device, user, environment and expected result. Use these primary sources with the exact technical and contractual scope agreed for your implementation.

Khronos glTF

The open standard for efficient delivery and loading of 3D scenes and models.

W3C WCAG 2.2

The W3C recommendation for accessible web content and interaction requirements.

OWASP API Security Top 10

A primary reference for common API authorization, resource and data-exposure risks.

Google Core Web Vitals

Google's current user-experience metrics and measurement guidance for web pages.

Procurement FAQ

Questions to settle before vendor selection.

Use these answers to turn broad product-configurator language into decisions your product, commercial, operations and technical owners can verify.

Continue the buying process

Use the checklist with the complete buyer guides.

Product data model guide

Specify product families, characteristics, stable IDs, configuration revisions, source ownership and downstream mappings.

Open guide

Product pricing engine guide

Specify calculation methods, price ownership, account and market context, revisions, approvals and price-regression evidence.

Open guide

Configurator BOM generation guide

Specify component identity, quantity logic, hierarchy, revisions, substitutions, ERP delivery and production acceptance evidence.

Open guide

Configurator security and privacy guide

Specify data classification, identities, object access, tenant isolation, APIs, logs, retention, recovery and security acceptance evidence.

Open guide

3D asset pipeline guide

Specify source ownership, glTF or GLB delivery, product-data bindings, PBR materials, target-device performance and asset acceptance evidence.

Open guide

3D configurator performance guide

Specify Core Web Vitals, first useful product view, staged runtime budgets, mobile GPU limits and long-session acceptance evidence.

Open guide

Configurator testing and QA guide

Turn each requirement into versioned fixtures, cross-domain assertions, release evidence and permanent regression coverage.

Open guide

Product configurator UX guide

Specify the complete user task across guidance, controls, feedback, validation, pricing, mobile, accessibility and completion.

Open guide

Accessible 3D configurator guide

Specify WCAG scope, semantic controls, canvas alternatives, keyboard operation, complete processes and acceptance evidence.

Open guide

Product configurator glossary

Align product, 3D, CPQ, pricing, BOM, integration and implementation terminology before writing requirements.

Open guide

Product rules engine guide

Specify dependencies, exclusions, dimensional constraints, derived values, execution order and regression evidence.

Open guide

Compare configurator software

Use a weighted scorecard, common test pack and evidence ladder across vendors.

Open guide

Configurator RFP and vendor scorecard

Package accepted requirements into comparable responses, scripted demonstrations, evidence scores, commercial assumptions and contract gates.

Open guide

Implementation guide

Turn accepted requirements into owners, phases, inputs, tests and a controlled launch.

Open guide

Maintenance and governance guide

Specify catalogue ownership, publishing permissions, change impact, regression evidence and saved-project behavior after launch.

Open guide

Integration guide

Specify API, CRM, ERP, ecommerce, document and order connections precisely.

Open guide

Headless configurator and API guide

Specify canonical state, allowed transitions, channel contracts, authorization, idempotency, versions and recovery evidence.

Open guide

Cost and ROI calculator

Normalize implementation scope, total cost and payback using your own baseline.

Open guide

Your product. Your requirements.

Turn the checklist into a working product scope.

Bring one representative product, its important rules, price examples and the output your team needs. Configurix can map the first accepted configuration journey with you.

Review your requirements