Configure-to-Order, CPQ
Stefan Jungen
27. July 2026
Many machine and plant manufacturers have worked in an engineer-to-order model for decades: every customer project starts from scratch, sales and engineering develop the solution together, and the result ends up as an individual drawing on the table. The problem becomes visible as soon as order volumes and variant diversity increase at the same time: engineering capacity turns into a bottleneck, quotes take weeks instead of days, and experienced engineers spend a growing share of their time on repetition rather than real innovation.
This is exactly the point at which many companies begin to ask how to move from ETO to CTO — from engineer-to-order to configure-to-order. The transition succeeds when it is not treated as a one-time transformation effort, but as a gradual process: analyze existing variants, transfer the most common cases into a rule set, and deliberately leave true special cases as exceptions. Any company that tries to standardize its entire product portfolio in one step will overwhelm both engineering and sales — and risks seeing the project fail because of exactly the complexity it was supposed to reduce.
This article explains the difference between ETO and CTO, outlines the typical triggers for transformation, describes a realistic approach for turning individual customer projects into configurable products, and shows the role that sizing, calculation, and a modular CPQ approach play in this transition.
In the engineer-to-order model, technical sizing begins only once a specific customer order exists: sales and engineering develop a solution together that did not exist in this form before. In the configure-to-order model, by contrast, the product already exists as a modular system of predefined components, options, and rules — the customer selects within that framework instead of triggering a completely new development.
The following overview summarizes the most important differences:
One important point should be kept in mind: CTO rarely replaces ETO completely. Most companies in mechanical and plant engineering operate on a continuum, covering a growing share of their orders through CTO while keeping true custom projects in the ETO process.
The shift is worthwhile wherever a significant share of customer inquiries appears individual, but can technically be traced back to recurring patterns. These are exactly the cases that consume unnecessary engineering capacity in an ETO model — capacity that is then missing for genuinely new challenges.
In practice, three triggers occur particularly often:
Structured product configuration for selling complex products addresses exactly this point: it transfers recurring sizing and configuration knowledge into a rule set that sales teams and customers can use independently, without having to involve engineering again for every single request.
The most reliable way to make the transition is in clearly defined steps — not as a one-time large-scale project, but as an iterative process that starts where the leverage is greatest.
A realistic approach typically includes:
Experience shows that companies that start with the most frequent 70 to 80 percent of inquiries — instead of trying to model every historical special case from the very beginning — reach a usable result much faster. The remaining share of true custom projects is not displaced, but becomes more clearly visible and can be handled more deliberately, because engineering is no longer overloaded with repetitive tasks.
Sizing and calculation are the step that comes before configuration itself — and in many ETO companies, they are the most underestimated part of the transformation. Before a customer can select a variant, it must already be clear which technical requirements a component has to meet in the specific application: load, dimensions, environmental conditions.
If this sizing step is not also translated into rules, it remains a manual engineering bottleneck even after a configurator has been introduced. Sales may be able to select options, but will still require technical approval from engineering. Structured sizing and calculation for complex products therefore often form the real foundation on which a CTO model becomes viable in the first place: sizing logic and configuration rules work together so that only technically valid combinations are offered automatically.
The ETO share can be reduced most effectively when CTO and ETO are deliberately allowed to coexist, rather than treating CTO as a replacement for the previous model. The goal is not to completely eliminate individual projects, but to clearly distinguish between cases that a rule set can reliably cover and cases that genuinely require new development.
The shift from ETO to CTO is not a one-time project with a fixed end date, but a gradual rebalancing in which standardizable inquiries increasingly replace pure custom development. It works best where companies begin by analyzing their existing variants, clearly define a configurable core product, translate sizing knowledge into rules, and deliberately keep real special cases in the ETO model instead of forcing full standardization. A CPQ and configuration solution delivers the most value when sizing, rule logic, and the sales process are treated as one connected system from the start.
The shift from ETO to CTO means that a company transfers a growing share of its previously individually engineered customer projects into a rule set of predefined modules and options. Instead of engineering each request from scratch, the customer selects within a framework that has already been designed and validated in advance.
No. Most companies in mechanical and plant engineering run both models in parallel: frequently recurring inquiries are handled through CTO, while genuine special projects remain in the ETO process. The goal is a meaningful shift in the balance, not a complete replacement.
That depends heavily on the number of variants, the quality of the existing sizing documentation, and the chosen scope of the first pilot, so it cannot be defined in general terms. A gradual approach that starts with a single product family usually leads to a usable result much faster than trying to standardize the entire portfolio in one step.
Products or product lines with a high share of recurring inquiries are best suited — in other words, cases that appear individual at first glance, but on closer analysis can be traced back to a small number of technical parameters. An analysis of past projects usually shows very reliably which product family is best suited for a first pilot.
True custom projects remain in the ETO process even after the shift. The move to CTO only reduces the share of inquiries that were previously treated as special cases even though they could actually be traced back to recurring patterns. This frees up more engineering capacity for genuinely new challenges.
CIBELE CASTRO
Managing Partner 4PACE Swiss AG
This might also interest you
