Engineer-to-order (ETO) exceptions are customer requirements that fall outside a manufacturer’s standard product model. In a manufacturing CPQ process, the objective is not to force every unusual request into a predefined option list. The objective is to identify what can be configured safely, isolate what requires engineering judgment, collect the information needed for review, and transfer an approved design into quoting and production systems without losing traceability.
This is different from generic sales CPQ, where an exception may simply require a manager’s pricing approval. In manufacturing, an exception can affect structural integrity, motor selection, materials, safety compliance, manufacturing methods, the bill of materials (BOM), computer-aided design (CAD) files, lead time and warranty obligations. CPQ must therefore manage the boundary between rules-based configuration and engineering work.
A practical ETO exception workflow uses the product model to validate standard requirements, an exception object or engineering request to capture the deviation, workflow rules to route it to the right reviewer, and controlled outputs to update the quote, BOM, CAD data and enterprise systems after approval. The exception should remain visible throughout the manufacturing workflow, rather than disappearing into email or free-text quote notes.
What is an engineer-to-order exception?
An engineer-to-order exception is a customer or project requirement that cannot be fulfilled entirely by the current standard configuration model and therefore requires additional engineering analysis, design work, approval or production planning.
Examples include a pump requiring a non-standard wetted material, a conveyor needing an unusual length and support arrangement, an air-handling unit requiring a casing dimension outside the standard range, or a mobile machine requiring a mounting interface that has not been modeled previously.
An exception does not always mean that the entire product becomes a one-off design. Many ETO products contain a standard core with a limited custom portion. CPQ should preserve the standard elements and identify only the affected assemblies, calculations, drawings, parts and commercial assumptions.
Common categories of ETO exception
| Exception type | Manufacturing example | Likely review |
|---|---|---|
| Parameter outside range | A pressure vessel diameter exceeds the modeled standard range | Mechanical engineering and compliance |
| New combination | A motor, gearbox and impeller combination has not been validated | Application engineering and testing |
| New component | A customer requests an unlisted alloy or sensor | Engineering, purchasing and quality |
| Interface change | A skid requires a customer-specific pipe or mounting connection | Mechanical and manufacturing engineering |
| Performance requirement | A fan must meet an unusual airflow, noise or temperature condition | Engineering calculation and validation |
| Compliance exception | A machine must satisfy a regional electrical or hazardous-area requirement | Compliance and technical authority |
| Process exception | A welded assembly requires a non-standard fabrication sequence | Manufacturing engineering and quality |
Why ETO exceptions need controlled handling
Uncontrolled exceptions create a gap between the sales promise and the engineered product. A salesperson may record “special stainless construction” in a quote, while engineering later discovers that the requested material changes shaft tolerances, seals, welding procedures, cost and delivery time.
The risks are interconnected:
- Configuration risk: the proposed combination may violate a technical dependency that is not visible to sales.
- Cost risk: engineering hours, prototypes, special tooling, testing and low-volume components may be omitted from the price.
- Schedule risk: review, design, procurement and approval activities may extend the promised delivery date.
- Data risk: an approved custom design may not be reflected in the BOM, CAD files, ERP item structure or manufacturing instructions.
- Governance risk: a one-time workaround may later be reused without the original engineering assumptions.
CPQ does not eliminate these risks by itself. It provides a controlled place to capture the requirement, apply known rules and manage the handoff. The product model, engineering systems and approval processes still need clear ownership.
The boundary between configuration and engineering
A maintainable CPQ implementation distinguishes three outcomes instead of treating every request as either valid or invalid.
| Outcome | Meaning | Typical CPQ action |
|---|---|---|
| Valid standard configuration | The request is inside approved product rules and parameter ranges | Allow configuration and generate normal commercial and manufacturing outputs |
| Conditional configuration | The request is known but requires a calculation, document, approval or additional input | Allow provisional configuration and create a review task |
| Unmodeled ETO exception | The requirement is outside the current product model or creates a new design problem | Capture an exception request, restrict commitments and route to engineering |
This distinction is more useful than a simple “configuration failed” message. A failed configuration may be technically correct but operationally incomplete. For example, a 7.5 kW motor may be valid for a standard pump range, while a 15 kW motor may be possible only after checking the shaft, coupling, baseplate and power supply. The latter should become a conditional or ETO case, not an unstructured override.
Manufacturers should document this boundary in the product configuration model. Rules that are stable and reusable belong in the model. Decisions that require case-specific engineering evidence belong in a controlled exception workflow.
Product-model logic for ETO exceptions
Rules-based configuration
Rules-based configuration uses explicit conditions such as “if option A is selected, option B is required” or “if frame size is X, only motors from list Y are permitted.” These rules are suitable for known relationships, exclusions, defaults and permitted ranges.
For an industrial pump, rules might require a particular seal family for a corrosive fluid, prevent a small motor from being paired with a large impeller, or restrict a casing material to specified temperature ranges.
Constraint-based configuration
Constraint-based configuration represents technical limits and relationships that may involve dimensions, capacities, loads, temperatures, materials or calculations. A constraint could compare required flow and head with an operating envelope, verify that a frame can support a selected motor, or check that a platform length remains within transport limits.
Constraints are useful for detecting whether a request is inside the modeled design space. They do not automatically solve every design problem. If the requested value is outside the design space, CPQ should explain the constraint and offer an ETO path where appropriate.
Guided selling
Guided selling asks users questions in a business-friendly sequence and recommends suitable products or options. It is useful for helping a distributor or sales engineer collect application information, but it should not be confused with engineering validation. A guided question such as “What fluid will the pump handle?” may select a material family; it does not replace a materials review for an unusual chemical or temperature.
Exception-aware model behavior
A mature product model can define an explicit response for an out-of-model request. That response may include:
- the reason the standard configuration cannot be confirmed;
- the technical data that must be supplied;
- the type of engineering review required;
- the options that remain provisional;
- the estimated engineering effort or commercial allowance;
- the approval level needed before a quote can become firm;
- the downstream outputs that will be blocked until approval.
For example, a CPQ system may permit a non-standard conveyor width to be entered, but mark the conveyor frame, guards, drive selection and drawing as pending engineering review. It should not silently generate a production-ready BOM as though the design were already approved.
Data captured in an ETO exception
An exception record should contain more than a description such as “customer needs custom design.” It should provide enough structured information for engineering to assess feasibility and for commercial teams to understand the consequences.
| Data group | Examples |
|---|---|
| Commercial context | Opportunity, customer, quote revision, requested delivery date and sales owner |
| Application requirements | Capacity, duty cycle, fluid, temperature, pressure, environment, load and operating conditions |
| Requested deviation | Dimension, material, interface, performance target, component or compliance requirement |
| Configuration context | Selected model, options, quantities, affected assemblies and standard alternatives considered |
| Engineering evidence | Calculations, customer drawings, specifications, photographs, test requirements and assumptions |
| Commercial impact | Engineering hours, special components, tooling, testing, risk allowance, lead-time impact and provisional price |
| Governance | Owner, reviewer, status, decision date, revision, reason code and links to approved design records |
Structured fields should be used for information that affects rules, routing, pricing or reporting. Documents and free text remain useful for context, but they should not be the only place where a critical requirement is stored.
Workflow: from exception request to approved order
1. Capture the requirement
The salesperson, distributor or application engineer records the customer requirement through the CPQ interface. The system should identify the affected product, configuration revision and quote line. If the request originated in a customer drawing or specification, that document should be attached or referenced.
2. Run standard validation
CPQ evaluates all known product rules and constraints before creating the exception. This prevents engineering from spending time on a request that is already invalid because of a basic incompatibility. The system should distinguish a hard failure from a review condition.
3. Classify the exception
Classification can be based on the affected discipline, technical risk, novelty, compliance implications or expected commercial impact. A low-risk non-standard finish may need product engineering approval, while a pressure boundary change may require a formal design review and compliance sign-off.
4. Estimate commercial and schedule impact
CPQ can apply provisional engineering charges, special material costs, risk allowances or lead-time rules. These are estimates until engineering completes the review. The quote should clearly label assumptions and conditions rather than presenting an uncertain value as a final commitment.
5. Route the review
Workflow rules send the request to the appropriate engineering owner. Routing may depend on product family, material, country, compliance category, plant or exception type. Approval should be role-based and traceable. An email notification alone is not a sufficient system of record.
6. Record the engineering decision
The reviewer should be able to approve, reject, request more information, propose a standard alternative or convert the request into a reusable product feature. The decision should state assumptions, limits and required downstream actions.
7. Update outputs and quote status
After approval, the system may update the configurable BOM, item selections, price, cost, lead time and quote documents. Where supported, it may also trigger CAD or calculation automation. Until the relevant review is complete, production-facing outputs should remain provisional or blocked.
8. Handoff the approved order
The final order package may include the approved configuration, exception decision, engineering documents, BOM references, drawings, calculations, customer approvals and commercial assumptions. Integration with enterprise resource planning (ERP), product lifecycle management (PLM), product data management (PDM), manufacturing execution systems (MES) or CAD tools depends on the organization’s architecture and the capabilities of the selected CPQ platform.
How exceptions affect BOM, CAD, pricing and quoting
Configurable BOM, EBOM and MBOM
A configurable BOM represents the selectable structure before all choices are resolved. An engineering BOM (EBOM) describes the product from a design perspective, while a manufacturing BOM (MBOM) represents the structure and operations needed to build it. An ETO exception may change both structures, but not necessarily in the same way.
For example, a custom enclosure may require a new EBOM component and drawing, while the MBOM also needs a special bending operation, inspection step and purchased fasteners. CPQ should not claim to generate a complete MBOM unless that capability and integration are actually implemented. In some architectures, CPQ produces a provisional configuration and ERP or PLM creates the controlled engineering and manufacturing structures.
More detail on these relationships is available in the guide to BOM generation, pricing and quote automation.
CAD and engineering automation
Some manufacturing CPQ platforms can pass approved parameters to CAD automation tools to create models, drawings or calculation inputs. Others only record the requirements and link to external CAD or PLM processes. The distinction matters for ETO exceptions.
A custom dimension may be safe to pass to a parametric CAD template if the template covers that range. A new structural arrangement may require a designer to create and review a new model. The CPQ workflow should identify which outputs are automated, which are manual and which require formal release.
See CAD and engineering automation in manufacturing CPQ for the relationship between configuration parameters, calculations, models and drawings.
Cost and price
Exception pricing should account for more than material cost. Potential elements include design hours, analysis, prototyping, testing, special tooling, supplier minimums, expedited procurement, additional inspection and manufacturing inefficiency. Some of these may be calculated in CPQ; others may require an engineering or project estimate.
Pricing and engineering approval should be coordinated. Approving technical feasibility without updating cost can create an unprofitable order. Conversely, adding a large contingency without documenting its basis can make a technically suitable proposal commercially uncompetitive.
Exception statuses and controls
A simple status model helps users understand whether a quote can be issued, accepted or released. A possible model is:
- Draft: the requirement is being collected.
- Validation required: standard CPQ rules have not yet completed.
- Engineering review: the request is assigned to an engineering owner.
- More information required: required data or documents are missing.
- Conditionally approved: the design is acceptable subject to stated assumptions or tests.
- Approved for quote: commercial values and scope can be presented under defined conditions.
- Approved for order: the required technical and commercial approvals are complete.
- Rejected: the request cannot be supported or is not commercially viable.
- Converted to standard feature: the approved solution is being modeled for future reuse.
Permissions should reflect these states. A sales user may create an exception, but only an authorized engineering role may approve a pressure boundary change. A quote may be sent with a clearly stated engineering contingency, while order release remains blocked until required documents are approved.
Designing maintainable exception logic
Do not turn every exception into a permanent option
If each customer-specific variation is added directly to the product model, the model can become difficult to test and understand. The result is often a large number of conditional rules, duplicate options and exceptions that conflict with one another.
Use a decision framework:
- Model a variation as a standard option when it is repeatedly sold, technically understood and operationally supported.
- Use a conditional rule when the variation is known but requires a defined calculation or approval.
- Keep it as an ETO exception when the design is genuinely novel, infrequent or dependent on case-specific engineering.
- Retire or redesign the process when repeated exceptions reveal a missing product family or poorly defined standard range.
Separate reusable rules from case decisions
A reusable rule might state that a certain seal material is required above a temperature threshold. A case decision might approve a particular seal arrangement for one unusual chemical after reviewing supplier data. The first belongs in governed product logic; the second belongs in the exception record unless it is later validated for general use.
Version the model and the exception
Quotes can remain open while product rules change. Store the product-model version, rule version, configuration revision and exception revision with the quote. Otherwise, an engineer reviewing a later revision may not know which constraints applied when the original commercial commitment was made.
Test negative and boundary cases
Testing should cover valid configurations, invalid combinations, borderline values, missing data, rejected exceptions, approval reversals and changes after approval. A model that works for a standard pump may still fail when a material change affects price, BOM selection and CAD parameters simultaneously.
Integration architecture
Exception handling commonly crosses several systems, but each system should have a defined responsibility.
| System | Typical responsibility |
|---|---|
| CRM (customer relationship management) | Opportunity, account, contacts and commercial pipeline context |
| CPQ | Configuration, rules, quote context, exception capture, pricing and approval workflow |
| CAD | Models, drawings and design geometry where automation or manual design is required |
| PLM | Product revisions, engineering change control, release status and lifecycle governance |
| PDM (product data management) | Controlled storage and relationships for design files and technical documents |
| ERP (enterprise resource planning) | Items, purchasing, inventory, production orders, costing and order execution |
| MES (manufacturing execution system) | Shop-floor instructions, execution records and production feedback |
These systems are not interchangeable. A CPQ exception record may initiate a PLM review, reference a CAD drawing and send approved item data to ERP. The exact flow depends on the manufacturer’s data ownership and the documented capabilities of the platforms involved. See the CPQ integration guide for integration patterns and boundary decisions.
Implementation approach
- Map current exceptions: review recent quotes, engineering requests and order corrections. Classify the reasons, affected data and outcomes.
- Identify high-value boundaries: start with exception types that cause recurring delays, margin leakage, rework or order errors.
- Define the standard model: document options, ranges, dependencies, calculations and approved alternatives before designing the exception workflow.
- Define ownership: assign responsibility for product rules, engineering decisions, pricing assumptions, CAD outputs, BOM release and system integration.
- Build structured exception forms: require the application data and documents needed for a real review.
- Set approval gates: define when a quote can be issued, when an order can be accepted and when production data can be released.
- Integrate selectively: automate stable data exchanges first. Do not create a complex CAD or PLM integration before the exception process and data definitions are stable.
- Measure and improve: review exception volume, turnaround time, rework, approval outcomes, margin variance and conversion into standard features.
Implementation planning should include data migration, testing, deployment, adoption and long-term governance. The manufacturing CPQ implementation guide covers these activities in more detail.
Benefits and limitations
Potential benefits
- Earlier visibility of technical risk during quoting.
- Less reliance on email, spreadsheets and unstructured quote notes.
- Better separation between standard configuration and genuine engineering work.
- More accurate estimates for engineering effort, special materials and lead time.
- Traceable approval decisions and assumptions.
- Improved continuity between the quote, approved design, BOM and order.
- Reusable knowledge when recurring exceptions are converted into governed product features.
Important limitations
- CPQ cannot replace engineering judgment for novel designs, testing or regulatory decisions.
- A workflow cannot compensate for inaccurate product data or unclear ownership.
- Exception pricing is difficult when engineering effort and manufacturing risk are not estimated consistently.
- Automated CAD, BOM or ERP outputs require compatible data models and integrations; they are not universal CPQ features.
- Allowing unrestricted overrides can undermine configuration governance and create unsafe or unmanufacturable orders.
- Over-modeling every possible custom request can make the product model expensive to maintain.
Practical example: custom pump skid
Consider a pump skid configured for a chemical-processing application. The standard CPQ model validates flow, head, pump size, motor, base frame, valves and instrumentation. A customer then requests a non-standard alloy, a different nozzle orientation and a compact footprint.
CPQ can first check whether the alloy is an approved material for the fluid and temperature. It can identify that the nozzle orientation is outside the standard CAD template and that the compact footprint may reduce maintenance clearance. The request is classified as an ETO exception and routed to mechanical, materials and application engineering.
The provisional quote includes the standard pump package, an engineering allowance, special material cost and a conditional lead time. Engineering confirms the material, redesigns the base, verifies access clearances and approves the nozzle arrangement. The final record references the approved drawing revision, updated EBOM, manufacturing requirements and commercial changes. ERP receives the released item and order data only after the required technical gate is complete.
This is a controlled CPQ order process: the customer receives a usable commercial response before every design detail is complete, but the manufacturer does not confuse a provisional configuration with a production-ready design.
FAQ
What is an ETO exception in CPQ?
It is a customer requirement outside the approved standard product model that requires engineering analysis, design, approval or special manufacturing planning.
Should CPQ reject every configuration outside the standard range?
No. CPQ should distinguish between an impossible request, a known conditional request and a genuinely new ETO requirement. Conditional requests can be routed for review instead of being silently rejected.
Can CPQ replace an engineer for ETO products?
No. CPQ can apply known rules, collect requirements, calculate supported values and route work, but engineers remain responsible for novel designs, technical judgments, testing and formal approval.
How should a non-standard dimension be handled?
Validate it against modeled limits first. If it is outside those limits but potentially feasible, capture it as an exception with affected assemblies, engineering inputs, cost impact and approval requirements.
What is the difference between a configuration error and an ETO exception?
A configuration error violates a known rule or technical constraint. An ETO exception is outside the current model and may be feasible after engineering review.
Should ETO exceptions be stored as free-text notes?
No. Use structured fields for requirements, affected components, status, owner, cost, lead time and approvals. Attachments and notes can provide supporting context.
How does exception handling affect CPQ pricing?
It can add engineering labor, special materials, testing, tooling, procurement risk, manufacturing effort and schedule allowances. These values should be labeled as estimates until the technical review is complete.
Can an exception generate a BOM before approval?
It may generate a provisional or configurable BOM, depending on the platform. A released production BOM should normally wait for the required engineering and manufacturing approvals.
What is the role of CAD in ETO exception handling?
CAD may validate or generate product-specific models and drawings. Some CPQ platforms automate this through templates, while others only pass requirements to CAD, PDM or PLM systems.
When should an exception become a standard product option?
Consider conversion when the variation is repeatedly requested, technically validated, commercially supported and maintainable within the product model.
How can manufacturers prevent too many product-model exceptions?
Review exception history, improve option definitions and ranges, standardize recurring designs and use governance to decide which deviations belong in the core model.
What approval levels are useful for ETO requests?
Approval levels can reflect technical risk, compliance impact, commercial exposure, engineering effort and production consequences. A minor finish change should not follow the same path as a pressure-boundary redesign.
How should CPQ handle missing engineering information?
Set the exception to a “more information required” status, identify the missing fields or documents and prevent final approval until the required information is supplied.
Can CPQ manage customer-specific designs?
It can manage the commercial and configuration context and link to controlled design records. The actual customer-specific CAD and lifecycle control may belong in CAD, PDM or PLM.
How do ETO exceptions affect configure-to-order?
They create a boundary between configure-to-order (CTO), where predefined choices determine the product, and ETO, where engineering must create or approve new design work. The order should follow the appropriate path rather than being mislabeled as CTO.
What is the difference between ETO and make-to-order?
Make-to-order (MTO) generally means production begins after an order but uses an established design. ETO requires new or customer-specific engineering work in addition to order-triggered production.
Which metrics help evaluate exception handling?
Useful measures include exception volume by type, engineering review time, percentage requiring more information, quote revision count, approval cycle time, rework, margin variance, order corrections and conversion of recurring exceptions into standard features.
Semantic map
The article connects the following manufacturing CPQ entities and relationships:
- CPQ manages the boundary between standard configuration and ETO engineering.
- Product models define options, parameters, dependencies and approved ranges.
- Configuration rules prevent known invalid combinations.
- Constraints identify values that require review when they exceed modeled limits.
- ETO exceptions capture requirements outside the standard product model.
- Engineering reviews determine technical feasibility and design responsibility.
- Approved exceptions can update configurable BOMs, EBOMs and MBOMs.
- CAD automation can generate product-specific models and drawings when templates support the design.
- Pricing logic estimates engineering effort, special materials, testing and manufacturing risk.
- Workflow approvals control quote release, order acceptance and production release.
- PLM and PDM manage controlled product and design records.
- ERP manages items, purchasing, production, costing and order execution.
- Recurring exceptions can become governed standard product features.
For broader context, see the guide to manufacturing CPQ and the related material on CTO, ETO, MTO and order-to-production workflows.