Configure-to-order vs engineer-to-order
Draw the product boundary before you automate the order.
Configure-to-order turns approved product knowledge into repeatable customer choices. Engineer-to-order begins where a customer requirement still needs design, calculation or technical release. Configurix can connect the governed core, the exception and the accepted commercial project without pretending they are the same process.
One customer requirement
Three controlled outcomes
Rules prove the product
Valid, priced and order-permitted
Rules identify an exception
Review, reconcile and continue
Engineering creates the answer
Design, approve and release
The boundary belongs in the product model, workflow state and handoff contract—not in a salesperson's memory or a note added after the quote.
Operating-model definition
Complexity does not decide CTO or ETO. Reusable product knowledge does.
Configure-to-order
A customer, dealer or salesperson creates a specific product from a released model. The accepted choices, ranges, constraints and mappings exist before the order. The result may still be made after acceptance, but normal product validity does not require new engineering on every project.
Engineer-to-order
The customer requirement cannot be completed from a fully accepted solution space. Engineering must design, calculate, adapt or release technical content for the individual order. Configuration can structure the request and reuse standard subsystems, but it cannot truthfully approve the unfinished engineering result.
Interactive order-boundary classifier
Classify the work before choosing the software path.
Select the closest operating conditions. The result is a scoping prompt for a representative-order workshop—not a substitute for product, engineering or production acceptance.
Side-by-side comparison
Compare responsibilities—not acronyms.
| Decision area | Configure-to-order | Engineer-to-order |
|---|---|---|
| Product knowledge | Released model, characteristics, modules and constraints | Order-specific requirements and engineering decisions |
| Solution space | Defined before the order and testable with representative fixtures | Not completely enumerable before the customer requirement is known |
| Sales role | Selects and prices within a governed product boundary | Captures requirements and coordinates technical feasibility |
| Engineering role | Models and maintains reusable rules and approved structures | Designs, calculates, reviews or releases the individual order |
| Validity | Rules can prove accepted normal and boundary cases | Validity depends on new order-specific engineering evidence |
| 3D experience | Shows a structured product state tied to accepted choices | May begin as concept or requirement visualization before final release |
| Pricing | Can use approved formulas, components, services and account context | May require estimates, risk allowances and revision after engineering |
| BOM or routing | Can resolve from approved rules, mappings or ERP variant logic | May be copied and changed, or created specifically for the order |
| Quote status | Can be order-permitted when commercial and technical conditions pass | Should distinguish budgetary, technically reviewed and released states |
| Change control | Catalogue, rules and effectivity govern repeatable change | Order-specific engineering change and renewed acceptance govern the project |
| Lead time | Driven by configured scope, availability, capacity and services | Includes engineering effort, review and release before execution |
| Best automation target | High-frequency product decisions with reusable knowledge | Requirement capture, reuse, exception routing and controlled handoff |
Product boundary map
Eight boundaries that decide when rules must hand over to engineering.
Product identity
Rules can continue
An approved family or model exists and remains the order identity.
Review must begin
The requested product cannot be represented by a released model or permitted extension.
Geometry and dimensions
Rules can continue
Ranges, increments, formulas, module counts and derived dimensions cover the result.
Review must begin
Novel geometry, interfaces, loads, tolerances or site conditions need calculation or design.
Rules and compatibility
Rules can continue
Dependencies, exclusions, required selections and valid combinations are accepted in advance.
Review must begin
The requirement falls outside tested constraints or introduces a new dependency.
Components and materials
Rules can continue
Selections map to approved components, quantities, units and effectivity.
Review must begin
A new part, material substitution, custom fabrication or unapproved supplier is required.
Commercial result
Rules can continue
Price, service, discount, tax and approval logic can reproduce accepted fixtures.
Review must begin
Cost depends on unfinished design, uncertain scope or order-specific procurement.
Evidence and compliance
Rules can continue
Approved product data supports the promised description within a defined market and use.
Review must begin
Performance, structural, electrical, safety or regulatory evidence must be created or assessed.
Operational release
Rules can continue
The configuration maps into an accepted order, BOM, routing or production-review contract.
Review must begin
Engineering must change or release order-specific BOM, drawings, routing or work instructions.
Change after acceptance
Rules can continue
A change creates a new governed configuration, price and document revision.
Review must begin
A change invalidates engineering evidence and requires rework, reapproval or re-release.
Hybrid CTO–ETO workflow
Keep the exception connected to the configuration.
A hybrid workflow is not a dead-end “contact us” message. It is a versioned path from reusable product knowledge into a named technical decision and back into the quote, customer approval and operational record.
Qualify
Capture application, site, account, market, target outcome and known technical conditions.
Configure
Use the released catalogue and rules to complete everything that is safely reusable.
Classify
Mark the project valid, incomplete, invalid or review-required with reason codes.
Estimate
Separate accepted price lines from allowances, estimates and pending engineering scope.
Review
Give engineering the configuration, exception, evidence, customer context and required decision.
Release
Attach the accepted technical result, responsible reviewer and released revision.
Reconcile
Update price, quote, configured order and customer acceptance after the technical decision.
Learn
Decide whether a repeated exception should become governed catalogue knowledge or remain ETO.
Shared project contract
The handoff must carry meaning, not screenshots.
Sales, engineering and operations need one traceable record. Stable identifiers and explicit states let every system understand what was selected, what remains uncertain, which technical result was accepted and which revision the customer approved.
Stable core, versioned decisions
Never make a translated label, drawing filename or rendered image the only identity connecting a customer configuration to engineering and fulfillment.
Configuration identityStable configuration ID and revision linked to the customer, opportunity and quote
Product contextFamily, model, catalogue revision, market, account and channel
Selected stateCharacteristics, option IDs, dimensions, derived values, quantities and services
ClassificationCTO, hybrid or ETO path plus rule, reason code and classification timestamp
ValidityComplete, invalid, review-required, technically accepted or order-permitted
Commercial statePrice source, currency, lines, allowances, tax, discount, approval and validity date
Exception recordRequested deviation, affected subsystem, evidence, owner, priority and due date
Engineering resultDecision, assumptions, calculations, attachments, released revision and approver
Operational mappingConfigured item, component, BOM, routing, drawing, survey or work-package references
Change historyWho changed what, previous and new state, impact, reapproval and downstream acknowledgement
Implementation blueprint
Productize the repeatable work. Preserve the engineering boundary.
Choose representative orders
Use frequent standard work, boundary cases, accepted exceptions and truly novel projects from the same product family.
Map the current decision chain
Document who decides product fit, price, technical feasibility, quote status, BOM, release and change today.
Define the governed solution space
Name released models, characteristics, ranges, modules, constraints, components and reusable calculations.
Create exception reason codes
Replace free-text escalation with specific triggers such as size, load, interface, material, compliance or unsupported component.
Assign system authority
Separate catalogue, rule, price, customer, order, engineering, BOM, routing and production ownership.
Design the hybrid state model
Make incomplete, invalid, review-required, approved and released states visible to users and integrations.
Build and reconcile outputs
Connect visual state, price, quote, review packet and configured-order data to the same revision.
Accept and improve
Test normal and exception paths, observe rework and promote only stable repeated knowledge into governed CTO rules.
Measurement model
Measure coverage and rework from your own baseline.
The goal is not a universal percentage of automation. Measure whether frequent work follows the correct path, whether engineering receives complete context and whether accepted orders reach execution with fewer preventable clarifications.
CTO coverage
Share of representative demand completed inside the accepted solution space
First-pass classification
Projects routed correctly without later CTO-to-ETO or ETO-to-CTO correction
Engineering touch rate
Orders requiring technical work, segmented by exception reason and product family
Review cycle time
Time from review-required state to accepted decision, excluding clearly named waiting time
Quote revision rate
Quotes changed because technical scope, component mapping or price assumptions changed
Order clarification rate
Accepted orders returned for missing, ambiguous or inconsistent information
Rule reuse
Frequency with which released rules and components resolve repeatable customer demand
Exception promotion
Repeated reviewed conditions intentionally converted into governed product knowledge
Working acceptance matrix
Twelve tests for the standard path and the exception path.
A standard order inside the approved solution space completes without engineering intervention and reproduces accepted product, price and output fixtures.
Minimum, maximum, increment, dependency, exclusion and derived-value boundary cases behave exactly as the approved product model specifies.
A request outside the solution space cannot be represented as a valid or production-ready CTO result by changing free text or hidden fields.
Every review-required state includes a structured reason, affected product area, responsible role and the evidence needed for a decision.
The visual, dimensions, specification, price, quote, review packet and configured order reference the same configuration revision.
Accepted price lines, estimates, allowances and technically pending values are distinguishable in the interface, document and integration payload.
Engineering can accept, reject or revise the request without overwriting the customer state or losing the original exception.
A technical decision that changes product or price creates the agreed new revision and requires the appropriate commercial and customer reapproval.
A released result records the responsible approver, timestamp, evidence and engineering or operational revision used for fulfillment.
Unknown and retired product, component, rule and engineering references are rejected rather than silently mapped to a convenient substitute.
Repeated submission or retry does not create duplicate reviews, quotes, configured items or sales orders.
A downstream rejection remains visible, retains the full project and can be corrected and reconciled to the originating configuration.
Failure patterns
Where CTO–ETO projects create false confidence.
Everything custom is called ETO
Reusable product knowledge remains inside individual engineers' projects, so sales cannot automate frequent decisions.
Everything is forced into CTO
Unmodeled technical uncertainty is hidden behind a valid-looking interface, price or render.
A warning replaces a workflow
The configurator displays “contact us” but creates no owner, reason, evidence packet, due date or return path.
The quote outruns engineering
A precise-looking total and delivery promise are issued before unresolved design and procurement scope is known.
The picture becomes the specification
A convincing 3D scene is treated as proof of component, structural, compliance or production validity.
Engineering changes a separate copy
The customer configuration, technical design, quote and order diverge because revisions cannot be reconciled.
Every exception becomes a rule
Rare or poorly understood cases make the product model fragile, untestable and difficult to maintain.
No exception ever becomes a rule
The same engineering decision is repeated order after order without becoming reusable governed knowledge.
Primary technical references
Ground the boundary in documented operating models.
SAP · Production process for configurable materials
Primary documentation distinguishing configure-to-order with variant configuration from engineer-to-order production models.
Open primary sourceSAP · Engineer-to-order production models
Primary documentation for order-specific BOM and routing changes when standard configuration does not cover the customer need.
Open primary sourceSAP · Process: Order BOM
Primary process guidance for switching from configurable product choices into engineering and returning the result to sales acceptance.
Open primary sourceSAP · Light engineer-to-order
Primary documentation showing a split between sales-level configuration and engineering-level completion.
Open primary sourceOracle · Configured item work definitions
Primary documentation describing how selected options and transactional attributes can create a configured manufacturing definition.
Open primary sourceJSON Schema · Specification
Primary specification for validating structured configuration, review, quote and handoff contracts.
Open primary sourceCTO and ETO FAQ
Detailed answers for product, sales, engineering and operations teams.
Bring one standard order and one exception
Map what Configurix can govern and what engineering must still decide.
We can test the product rules, technical triggers, pricing status, review handoff, quote revision and configured-order contract against your real workflow.