A pump OEM may configure the casing, motor, seal, controls and standard test package from approved options. The same quote moves into ETO when the buyer asks for a duty point outside the validated range, a new baseplate geometry or a certification the product family has never carried. The standard portion can continue through rules while engineers work the exceptions.
This distinction changes who makes the decision, how the team estimates cost and delivery, what must exist before the quote can be released, and which records move into production. It also tells the business where CPQ helps, where PLM or ERP takes over and where an application has to coordinate people across those systems.
Use the approved product model as the boundary
A CTO product model contains the characteristics a buyer can choose, the allowed values, compatibility rules, calculations and the outputs those choices produce. It also has owners, revisions and tests. Sales can complete an order inside that boundary because engineering has already approved the choices and their effect.
IFS describes its sales configurator as a rules engine that presents compatible values and can automatically attach or remove options. Its configuration structures use back-office rules to select components and support cost and production lead-time calculations. That is CTO in operational terms: a maintained set of choices can produce a manufacturable order.
ETO starts when the team cannot answer the request from those approved rules. An engineer may create a new component, change an order BOM, modify a routing, calculate an unproven duty, resolve a new interface or qualify a new standard. Prior jobs can inform the answer. A qualified engineer still has to decide whether that earlier work applies to this customer, product state and operating condition.
| Boundary test | CTO | ETO |
|---|---|---|
| Requirement coverage | The maintained model contains the characteristic and allowed value | The requirement is absent, out of range or conflicts with a maintained rule |
| Technical authority | The approved product rules make the decision | A qualified engineer makes and records a new decision |
| Product definition | The configuration resolves an existing structure | Engineering creates or changes order-specific product data |
| Validation | Existing rule and product tests cover the result | The team defines the analysis, review or test needed for this order |
| Reuse | The option is available to every authorized order | The decision remains order-specific until product governance promotes it |
Follow the different work each path creates
IFS groups CTO and ETO with other pull-based production approaches in Dynamic Order Processing. It also calls out the need to check both materials and capacity before confirming delivery. CTO does not mean build-to-stock, and ETO does not mean that every part is new. Both can start from a customer order and reuse common components. The difference is the amount of product-definition work the order still needs.
| Process question | Configure-to-order | Engineer-to-order |
|---|---|---|
| What starts the work? | Customer selects values for a known product family | Customer asks for a requirement outside the approved model |
| Who prepares the answer? | Sales or a customer uses maintained rules | Sales frames the request; engineering resolves the exception |
| How is feasibility checked? | Constraints, calculations and availability rules | Engineering analysis, design review, supplier input and order-specific validation |
| How is cost built? | Configured components, routing, rates and option prices | Preliminary design, order BOM, new routing, supplier quotes and explicit risk |
| How is delivery set? | Lead-time rules plus material and capacity checks | Engineering duration plus material, capacity, validation and approval time |
| What is released? | Approved configuration, BOM, routing, price and documents | Approved order-specific product definition with its assumptions and validation plan |
| What changes after the sale? | The accepted configuration passes into the order | Engineering may complete or release the final design before production starts |
Understand what CTO has to produce
A sales configurator is only the front end. The accepted characteristics have to resolve into the records that costing, planning, purchasing and manufacturing use. That may include a configured BOM, routing, drawing package, inspection requirements, supplier selections, price, lead time and proposal text.
IFS lets a won quotation carry the configuration into the customer order and supports an interim order for inspection and estimated cost roll-up. SAP’s make-to-order variant configuration example uses product characteristics and dependencies to select components, calculate sales price and pass the configured order into MRP and production. These are useful acceptance tests for CTO software: the choices should produce the same product in sales and operations.
The product model also needs effectivity. A configuration quoted under today’s rules must remain explainable after engineering changes an option, supplier or constraint. Store the model revision, selected values, rule results and generated outputs with the quote. Re-running the same answers against a newer model is not a substitute for the baseline the customer accepted.
Understand what ETO has to produce
ETO begins with a controlled engineering problem. The request should name the customer requirement, the closest approved configuration, the rule or limit it exceeds, affected interfaces, requested date and commercial context. Engineering can then define the minimum work needed to support the quote and the work that remains after award.
SAP’s current ETO process for product variants gives a concrete example. When the standard configuration cannot meet the order, engineering creates an order-specific BOM, changes components and hands the result back to sales. The standard process continues after sales accepts the engineering changes.
The quote-stage output may be a complete design for a small exception or a controlled preliminary basis for a larger project. In either case, state what has been proven, what remains to be engineered, which assumptions support price and delivery, and how a later customer change will affect the order. Hiding unfinished engineering inside a configured line gives production a false release.
Classify the request line by line
Do not label an entire customer or product family ETO because one line needs engineering. Split the request into decisions. Known options and approved calculations stay in CTO. New geometry, unproven performance, customer-specific code requirements and conflicts leave the model through an engineering exception. Unaffected work can continue while that exception is open.
A configurator’s “other” field only captures text. It does not validate the request. Turn the entry into an exception with the source requirement, closest standard choice, affected interfaces, due date and owner. The quote should show which configuration is valid, which assumptions remain open and which price or delivery lines depend on the engineering answer.
| Request element | Treatment | Example |
|---|---|---|
| Known option | Apply the maintained compatibility rule | Choose an approved 460 V motor for the standard frame |
| Approved calculation | Run the governed sizing or performance method | Select the impeller from a validated duty range |
| Prior order-specific design | Engineer confirms whether it can be reused | Earlier baseplate geometry for a different site load |
| Out-of-range value | Open a scoped engineering task | Required flow exceeds the validated pump curve |
| New interface | Define, analyze and approve the interface | Customer nozzle orientation conflicts with the standard casing |
| New compliance demand | Assign qualification and evidence work | Customer requires a certification the family does not hold |
Worked example: one pump package uses both paths
A customer asks for three pump skids. The pump casing, standard motor, seal system, instruments and control-panel options all sit inside the approved model. Sales configures those items, and the rules produce the base BOM, standard routing, performance calculation and option price.
The customer also needs the discharge nozzle rotated 30 degrees to clear site steelwork and wants a seismic load the current baseplate has not been checked against. Those two requirements become ETO tasks. Mechanical engineering checks the casing and piping interface. Structural engineering analyzes the baseplate and anchor loads. Estimating adds the changed fabrication, engineering hours and risk. Planning adds the analysis and approval duration.
The proposal states the valid configured scope and the engineered deviations. After award, the accepted configuration becomes the starting order structure. The approved nozzle and baseplate changes update the order BOM, drawings, routing, inspection plan and as-built record. Treating the whole package as CTO would hide the two unproven requirements. Treating it all as ETO would send known motor and instrument choices back through engineering.
Connect the accepted promise to production
Before order release, reconcile the accepted proposal, configured product, engineering exceptions and customer PO. The selected options and engineered changes must produce one BOM, routing, drawing set, cost basis, inspection plan and delivery promise. If sales, PLM and ERP each hold a different product state, the ETO/CTO classification has failed its most important test.
Siemens Teamcenter product configuration uses a common definition of variability across product planning, engineering, manufacturing and service. PTC’s product configuration guidance also treats ETO as order-specific engineering built from an ATO or CTO starting point. The customer choice and the engineering change must survive into the product that gets built and serviced.
| Release record | CTO contribution | ETO contribution |
|---|---|---|
| Requirements | Selected characteristics and rule results | Approved order-specific requirements and assumptions |
| Product definition | Configured part structure and standard drawings | Changed BOM, drawing, model or interface definition |
| Manufacturing | Resolved standard routing and work instructions | New or changed operations, tooling and inspection |
| Commercial | Option prices, standard terms and lead-time rules | Engineering cost, supplier input, risk, deviation and schedule effect |
| Service record | Standard serialized configuration | Order-specific design and validation history |
Decide what happens to the engineering result
After engineering approves an exception, classify the result. It may remain unique to the order. It may become a controlled customer variant used for one account. Or it may reveal repeat demand that belongs in the standard product model. Product governance makes that call after the order.
Promote repeatable work only after engineering defines the permitted range, constraints, calculations, outputs, validation evidence, owner and change process. Copying an old drawing into the next quote is reuse without governance. It can carry an old customer condition, obsolete component or untested interface into a new order.
Track how often the same exception returns. Repeated engineering hours, repeated customer demand and stable validation evidence can justify turning ETO into CTO. Rare, risky or highly site-specific work may remain ETO even when the team has seen it before.
Give each system a clear job
CTO and ETO often cross CPQ, PLM, ERP, CRM and engineering tools. Define which system owns the customer request, product rules, released product definition, price, order and task. Then use a working application to bring those records together for the decision. Do not duplicate every master in a new “single source of truth.”
Siemens separates the definition of product variability from engineering content while linking the two in Teamcenter Product Configurator. That separation is useful beyond one vendor: configuration experts can maintain valid choices while engineering disciplines control the product data those choices resolve.
| System or application | Primary job in the process |
|---|---|
| CRM | Own the account, opportunity, contacts and commercial activity |
| CPQ or configurator | Guide approved choices, run constraints and produce the valid configuration |
| PLM | Own released product structures, drawings, models, changes and engineering effectivity |
| ERP | Own item and supplier masters, cost records, customer order, planning, purchasing and production execution |
| Engineering tools | Perform calculations, analysis, CAD work and product validation |
| Bourne application | Assemble the request, coordinate exceptions, show evidence and carry approved results between the owning systems |
Measure how the boundary performs
A faster quote can still hand production an invalid configuration. Measure how well the process uses rules, isolates engineering work and carries the accepted product into the order. Segment the measures by product family and exception type so one difficult project does not hide the health of the repeatable business.
| Measure | What it shows |
|---|---|
| Straight-through configuration rate | Share of quote lines completed inside the approved model with no engineering exception |
| Exception response time | Time from a request leaving the model to an approved engineering basis |
| Exception reuse rate | Share of engineering work that can use a reviewed prior decision or controlled variant |
| Configuration-to-order defects | Accepted choices that fail during BOM, routing, purchasing or production release |
| Engineering rework after award | Quote assumptions or preliminary decisions that must be redone before manufacture |
| Repeated exception count | Demand that may justify a new rule, option or product platform change |
| Quoted-to-delivered margin variance | Whether CTO rules and ETO risk allowances predict the work that the order consumed |
How Bourne handles mixed CTO and ETO work
Bourne can guide sales through the approved product model, retrieve the customer requirements and isolate every choice that needs engineering. The application shows which configuration lines are valid, which assumptions remain open, who owns each exception and which cost or delivery items depend on the answer.
Bourne works with the CPQ, PLM and ERP records that already own product rules, released engineering data and the order. After engineering approves an exception, Bourne updates the affected costing and proposal work and sends the accepted result to the owning system. The product configuration workflow shows this path in the product.
Buğra Gündüz
Buğra Gündüz is the co-founder and CEO of Bourne and co-founder of HockeyStack. He built HockeyStack into an eight-figure AI business. At Bourne, he works with entrepreneurs and established companies to create AI products and services.