Engineer-to-order or configure-to-order: does every enquiry need an engineer?

Comparison criteria

Criteria are stated explicitly and neither option is declared a winner: which one fits depends on the constraint that binds hardest in your operation.

The migration from one to the other is a product decision, not a systems project

Companies that want to configure rather than engineer usually start by buying configuration software, and stall. The blocking work is upstream: deciding what your product actually is, drawing the boundary between what varies and what never does, fixing the interfaces so a module can change without disturbing its neighbours, and rationalising the accumulated special versions into a defensible option list. That work is contentious because every historic special has a customer attached to it. Until it is done, a configurator simply automates the confusion, producing valid-looking combinations that the shop floor cannot build and that nobody has ever costed.

Estimating risk is the price of bespoke work

In project work the quotation is issued against a design that does not yet exist, which means the estimator's judgement, not the shop's efficiency, often determines whether a job earns anything. Two disciplines make this bearable. The first is a costing feedback loop: recording actual hours and material by job, and comparing them with the estimate in a form the estimator sees, so patterns of underestimation become visible. The second is a written scope, because the majority of overruns arrive as customer expectations that were understood differently by two parties who both believed themselves reasonable. Neither discipline removes the risk; both make it accountable.

As-built records are what you sell after delivery

Aftermarket revenue depends on knowing what you actually shipped, which is not always what the drawings say. Substitutions made under time pressure, a fitter's adjustment, a customer-requested tweak agreed on site — each of these separates the record from the machine, and the gap only shows up when a spare is ordered years later. Bespoke work makes this acute because no other unit can be used as a reference. The remedy is unglamorous: a serialised record per unit, a rule that deviations are logged before they are made rather than after, and a handover pack the service team can actually retrieve without asking the original engineer.

Frequently asked questions

Can a business run both models at once?

Frequently, and the usual shape is a configured core range alongside a project stream for work that falls outside it. The discipline that makes it work is a clear entry rule stating what disqualifies an enquiry from the standard range, applied by someone with authority to say no. Without it, project work leaks into the configured line, and the special items break the very interchangeability that made the standard range cheap to build and easy to support.

What data does a configurator actually need before it earns anything?

A released and maintained option list, rules covering which options may and may not be combined, a way to generate a bill of materials and routing from a valid selection, and costing data attached to the modules rather than to whole finished units. Missing any one of these turns the tool into a quoting front end that produces orders manufacturing cannot fulfil. The data maintenance burden is ongoing, so someone must own it once the implementation team has moved on.

How do I stop a configured range drifting back into bespoke work?

Track how many orders leave the option space and why, and treat that number as a product signal rather than a sales inconvenience. A recurring exception is telling you the architecture is missing something customers genuinely want, and the answer is to add it as a controlled option after the usual design and costing work. A one-off exception is a commercial decision about a single order. The failure mode is granting exceptions individually until the standard range exists only on paper.