Custom configurators and business software
Configure-to-order software for complex products.
We specialize in complex products. Configurix builds configure-to-order software and 3D configurators around your permitted product rules, prices and accepted revisions—connecting sales to material lists, orders and the factory handoff your team can approve.
Map your configure-to-order workflow
Permitted product choices
Accepted commercial revision
Defined order handoff
A valid design. An order your team can accept.
Define the repeatable solution space
Model permitted dimensions, modules, options and dependencies before customers configure. Route exceptions to the appropriate review instead of treating an unrestricted design as an order.
Accept the exact product revision
Keep configuration, price and customer approval tied to the same saved state. Define how later changes affect the quote, components and operational release.
Name the next system's responsibility
Agree order lines, component data, identifiers and acceptance checks. Keep engineering release, inventory and factory execution with the systems and teams named in your implementation.
Custom software for manufacturers
A configurator up front. Your business connected behind it.
We specialize in complex products. Configurix builds configure-to-order software and 3D configurators around your permitted product rules, prices and accepted revisions—connecting sales to material lists, orders and the factory handoff your team can approve.
Qualified projects and CRM
Capture the requested product, dimensions, options and review requirements with the opportunity. Assign ownership and keep technical exceptions visible before committing to a customer offer.
New enquiry
Accepted product configuration
Product fitQualified
Accepted product configuration
RequirementsProposal
Accepted product configuration
Next actionReviews and production appointments
Link saved revisions to consultations, engineering reviews, surveys or agreed production appointments. Define availability and calendar connections around the teams that approve each stage.
- 09:00Project review
- 11:30Technical review
- 14:00Production planning
Configured BOM and material structure
Map accepted choices to assemblies, components, quantities and units. Define the output contract, revision ownership and checks separately from purchasing, manufacturing planning and execution.
| Component | Quantity |
|---|---|
| FRM-01Accepted assemblies | 1 |
| PNL-02Components and materials | 1 |
| KIT-03Defined operations | 1 |
Mapped to your product codes
Prices, quotations and acceptance
Calculate the permitted product and preserve the commercial revision. Define discounts, technical approvals, customer acceptance and how a later product or price change reopens the decision.
Quote revision
Order acceptance and assigned jobs
Pass accepted data to the agreed order or factory workflow. Keep identifiers, release status, documents and exceptions so a new draft cannot silently overwrite a released manufacturing instruction.
- Accepted quote01
- Configured order02
- Production job03
- Installation04
Accepted orders and invoicing
Connect order acceptance and agreed milestones to deposits, invoice drafts and accounting references. Define the issuing system and how a revision or cancellation changes the commercial record.
Accepted product configuration
Built for your website. Connected to your systems.
Launch a branded configurator in your existing website or a custom sales portal. Connect CRM, ERP, PIM, ecommerce, calendars and accounting through available APIs, webhooks or agreed imports. We define the data, permissions and responsibilities for each connection with your team.
- 01Your website
- 02Configurator
- 03CRM & calendar
- 04ERP & accounting
Choose the workflows your implementation needs. We build and validate them against your products, documents and target systems.
Plan your manufacturing configuratorFrom permitted choices to an accepted factory handoff.
Bring one configurable product, its rules and a known order output. We will map the custom configurator, price and revision approvals, material data and downstream acceptance your team requires.
Questions before your implementation.
Implementation details and acceptance checks
Direct definition
What configure to order means.
Configure to order (CTO) is the process of defining a customer-specific product from a prepared model, option classes and permitted choices when the order is created. The product is not designed from nothing: the business has already established the reusable solution space and the rules that govern it.
Configure-to-order software makes that solution space usable. It guides the user, validates the product, preserves a structured configuration and connects the result to the commercial and operational process. A visual CTO experience can also update a 2D or 3D product while dimensions, components and finishes change.
Configurix governs the customer and sales configuration layer, scoped pricing, proposals, projects and integration contracts. It does not silently claim ownership of engineering release, inventory, production planning or shop-floor execution. Those responsibilities remain with the systems and teams named in the implementation.
Fulfillment language
CTO, ATO, MTO and ETO describe different responsibilities.
The terms are useful only when the business defines when the customer chooses, what is stocked, what is made, what needs engineering and which system authorizes the next step.
Make to stock (MTS)
A finished item is produced before the customer order.
Forecast finished-item demand, stock availability and standard ordering.
A selector or ecommerce catalogue may be sufficient when the sellable variants already exist.
Assemble to order (ATO)
Stocked components or subassemblies are combined after the order.
Choose a permitted combination and confirm component availability and assembly capacity.
The configuration must resolve the components and identifiers the order system expects.
Configure to order (CTO)
A customer-specific product is defined from an approved model, options and rules at order time.
Validate the product, commercial result and configuration record before fulfillment begins.
Configurix can govern the buying and sales experience and pass the accepted configuration downstream.
Make to order (MTO)
Production begins after the customer specifies the product or project.
Preserve the exact dimensions, materials, quantities and approved customer state.
A configurator can capture the specification; ERP, planning or production systems still own execution.
Engineer to order (ETO)
The order requires customer-specific engineering beyond a fully predefined solution space.
Separate reusable configuration from engineering review, design and release.
Configurix can qualify and structure the request, but should not present uncompleted engineering as approved.
Connected CTO architecture
Eight layers make a configured order usable.
A polished viewer is not a CTO system by itself. The visual product, commercial result and downstream record must resolve from governed data and named authority.
Commercial product model
Define product families, models, characteristics, option groups, dimensions, services and market availability with stable identities.
Configuration rules
Apply defaults, required choices, dependencies, exclusions, ranges, increments, derived values, warnings and review states.
Visual and dimensional state
Bind governed choices to 2D or 3D geometry, materials, components, measurements and customer-facing views.
Commercial calculation
Calculate from approved price sources, formulas, quantities, account context, services, discounts, tax and approval authority.
Quote and acceptance
Generate the proposal from the same product and price revision, then preserve which revision was issued, changed or accepted.
Configured order contract
Translate the accepted project into the product, customer, commercial and service fields required by the next system.
Optional BOM mapping
Resolve approved components, quantities, variable dimensions and provenance when a configured BOM is an accepted deliverable.
Operational execution
Keep production planning, inventory, procurement, routing, work orders and shop-floor control with their named authoritative systems.
From demand to execution
One configuration. Eight controlled transitions.
Each transition should have an owner, an accepted input, a visible state and a machine-readable result. The order is not ready because a button was clicked.
Demand
Start with buyer and project context
Capture customer, account, channel, country, language, site conditions, target use, timing and the role performing the configuration.
Model
Select the governed product family
Begin from an approved system instead of a blank drawing. Assign the catalogue and revision that define available characteristics and options.
Configure
Create a valid product state
Guide dimensions, components, materials and accessories through rules. Distinguish valid, incomplete, invalid and review-required states.
Visualize
Show the same structured product
Update the 3D scene, specification and measurements from the configuration record so the visual does not become a disconnected mock-up.
Price
Calculate the permitted commercial result
Apply quantities, formulas, price lists, account terms, services, discounts, tax and approvals using the documented source of authority.
Quote
Issue one traceable revision
Create a customer document or digital proposal that references the exact product, visual and price state presented for acceptance.
Order
Translate acceptance into structured data
Map stable identifiers, characteristics, quantities, services, dates, addresses, attachments and revision references for the next system.
Execute
Let operational systems fulfill the order
ERP, PLM, MES, planning, procurement or field-service systems validate and execute the responsibilities assigned to them, with visible exceptions.
Configured order data contract
Define the record before choosing the connector.
An API name does not define what an accepted configuration means. Agree the identity, fields, versions, authority, validation and delivery behavior first.
Identity
Configuration ID and revision, quote or cart ID, order correlation ID, catalogue and rule versions
Customer context
Account, contact, seller, dealer, market, language, addresses, site and tax context
Configured product
Family, model, characteristics, option IDs, dimensions, derived values, components and services
Validity
Complete, valid, review-required or approved state plus warnings, exceptions and responsible reviewer
Commercial state
Currency, price list, quantities, unit and total values, discounts, tax, approvals and price validity
Customer evidence
Accepted quote revision, product snapshot, specification, drawings, terms and customer action timestamp
Operational mapping
ERP materials, configured item references, optional BOM lines, routing inputs, survey or installation fields
Delivery control
Destination, schema version, idempotency key, delivery state, acknowledgement, error and retry history
Minimal traceability chain
Customer acceptance must point to an exact product state.
Configuration
Price
Quote
Order
System ownership
One field, one authority, visible synchronization.
PIM or product master
Stable sellable identities, descriptions, classifications and market availability
Which product attributes and lifecycle states are authoritative there?
PLM or engineering
Approved engineering structure, drawings, effectivity and technical change
What can sales configure without renewed engineering?
Configurix
Guided product state, rules, 3D experience, scoped price logic, quote and project revision
Which rules and results are accepted in the working implementation?
CRM
Account, opportunity, activity, owner, stage and relationship history
Which identifier reconciles the configured project with the opportunity?
ERP or order management
Order creation, authoritative materials, commercial posting, inventory and fulfillment state
What exact structure must an accepted configuration become?
MES, planning or field operations
Production, capacity, work execution, quality, delivery or installation
What release conditions and operational data are required?
Implementation blueprint
Build the business contract before the interface.
Start with one end-to-end product and prove the accepted transition. More catalogues and channels can reuse the pattern after its responsibilities are clear.
Outcome
Name the business transition
Define whether the implemented journey ends at a qualified lead, technically reviewed quote, accepted project, cart, sales order or production-ready handoff.
Representative product
Choose a complete test case
Select one product containing meaningful dimensions, dependencies, exclusions, derived quantities, pricing and at least one exception path.
Sources
Assign authoritative systems
Map ownership for catalogue, rules, geometry, prices, customer data, tax, documents, BOM, inventory, lead time, order and production state.
Rules
Model the permitted solution space
Convert product knowledge into explicit allowed values, constraints, formulas, review states and testable expected results.
Experience
Design the role-specific journey
Decide what customers, salespeople, dealers, approvers and administrators can see, change, price, approve and continue.
Contract
Define the configured order payload
Document identifiers, required fields, enumerations, units, versions, null behavior, validation, authentication and error responses.
Acceptance
Test product and handoff together
Verify normal and boundary configurations, visuals, prices, documents, revisions, roles and downstream acknowledgement using approved examples.
Operations
Govern change after launch
Assign catalogue owners, release controls, regression tests, monitoring, recovery, historical project behavior and the route for new products or rules.
CTO measurement model
Measure the transition, not the animation.
Establish the baseline, denominator, exclusions and data owner before launch. A faster 3D experience is useful, but CTO performance is proven by valid, accepted and usable records.
Valid-first-time rate
Configurations reaching the agreed valid state without avoidable product correction
Time to order-ready state
Elapsed time from qualified project start to the defined accepted handoff
Manual re-entry rate
Accepted projects that require avoidable retyping before the next system can continue
Exception rate
Projects entering technical, price, availability or operational review, separated by reason
Order rejection rate
Handoffs rejected because required identity, structure, value or authority is missing
Configuration-to-order match
Orders reconciled to the accepted configuration and quote revision through stable identifiers
Post-order change rate
Accepted configurations changed after order creation, classified by cause and approval impact
Catalogue change lead time
Time required to publish and accept a controlled product, rule, price or mapping update
Working acceptance checklist
Prove the configured order with one difficult product.
Give each vendor the same catalogue inputs, expected configurations, price examples, user roles and destination contract. Require evidence from the working flow.
A representative product is created from governed characteristics and option identities rather than a free-text description.
Required, default, dependency, exclusion, minimum, maximum, increment and derived-value rules match approved examples.
Incomplete, invalid, technically reviewable and order-permitted states are visibly different and machine-readable.
The 3D product, measurements, specification, price and quote reference the same configuration revision.
Normal, boundary, account, currency, service, discount, tax and rounding price examples reproduce approved values.
Public, customer, sales, dealer, approver and administrator roles expose only permitted catalogues, data and actions.
A change after quote issue or acceptance creates the required new configuration, price, document and approval state.
The order payload contains the agreed stable IDs, units, values, versions, customer context and operational mappings.
Unknown, obsolete or invalid product and option identifiers are rejected with a useful error instead of silently substituted.
Repeated delivery with the same idempotency key does not create duplicate opportunities, quotes, carts or orders.
A downstream rejection or timeout is visible to the responsible role and can be retried without losing the project.
The destination acknowledges the accepted record and can be reconciled to the originating configuration and quote revision.
Primary references
Ground CTO decisions in operational definitions and testable contracts.
Oracle: Overview of Configure-to-Order
Primary product documentation describing configured items, option classes, runtime choice and order fulfillment for configure-to-order.
Oracle: Configured item work orders
Primary documentation showing how configured item attributes and model work definitions continue into a work-order flow.
SAP: Configure-to-Order scenario
Primary documentation connecting configurable product models, variant formulas, BOM and process data, sales configuration and routing.
SAP: Order BOMs for variant configuration
Primary documentation explaining customer-order-specific BOM handling and the boundary between configuration and engineering changes.
JSON Schema
Primary specification for describing and validating structured configuration, quote, order and integration payloads.
OpenAPI Specification
Standard format for documenting HTTP APIs, authentication, request and response shapes and integration behavior.