Why CPQ and ERP quoting modules fail for engineered-to-order project bids
CPQ and ERP quoting modules fail for engineered-to-order (ETO) project bids because they are built to price configurable catalogue products from a pre-modeled option list, while an ETO bid is a one-off engineered response assembled from unstructured tender documents. A CPQ engine needs the product, its options and its pricing rules defined in advance; an ETO tender has no product yet, arrives as an RFQ, scope of work, drawings and blank returnable schedules, and must be answered clause-by-clause in the client's own format. That is a different problem: not selecting and pricing a known configuration, but reading documents, deciding compliance, and writing the answer into someone else's template. This is the work Elora Grid is built for: hand it the documents a tender arrives as, and it returns the compliance response and deliverables with every line cited to its source, while pricing and judgment stay with your team.
Why do CPQ and ERP quoting tools fail for engineered-to-order bids?
CPQ and ERP quoting tools fail for engineered-to-order bids because they assume the product already exists as a configurable model, and an ETO bid does not. Configure-price-quote (CPQ) software prices a product by walking a user through pre-defined options, applying option rules, and reading prices from a maintained table. That works when you are selling a catalogue item with a finite set of variants. An engineered-to-order project bid is the opposite: the scope is unique to one tender, the deliverable is engineered specifically to win that job, and the inputs arrive as documents a person has to interpret, not as options a user picks from a menu. The quoting module has nothing to configure, so the team quietly falls back to spreadsheets and the licensed module sits unused for project work.
What is the difference between configured-product quoting and ETO bidding?
The difference between configured-product quoting and ETO bidding is where the product gets defined. In configured-product quoting the product is defined before the order: the standard manufacturing strategy continuum runs from make-to-stock, through assemble- or configure-to-order and make-to-order, to engineered-to-order, and CPQ is designed for the configure-to-order end, where every variant is a combination of known options. Engineered-to-order sits at the far end of that continuum, where the design is created in response to the order itself, so there is no pre-built option model to price against. For a tender, that means each bid is a fresh scope of work, a fresh specification and often a different governing standard, with nothing carried over from the last one except your method. A tool that assumes a stable product model cannot price a deliverable that does not exist until you engineer it.
What does a CPQ engine assume that an ETO tender breaks?
A CPQ engine makes four assumptions, and an ETO tender breaks all four. It assumes the product and its options are modeled in advance, but an ETO tender has no product, only a scope to be engineered. It assumes its inputs are structured data (an item master, a bill of materials, a routing), but an ETO tender's inputs are unstructured documents: an RFQ, a scope of work, drawings and returnable schedules. It assumes the output is its own quote format, but a tender demands the answer inside the client's returnable schedules and compliance matrix. And it assumes the deliverable is a price, but a compliant bid is a cited, clause-by-clause compliance response of which price is only one part. The table below sets each assumption against the reality.
Why can't an ERP quoting module read a tender's documents?
An ERP quoting module cannot read a tender's documents because it operates on structured master data, not on prose. ERP quoting is built around the item master, the bill of materials and routings: you tell it which parts and operations a quote contains, and it costs them. The hard, time-consuming part of an ETO bid happens before any of that exists, when someone has to read the RFQ, the scope of work and the drawings, work out what is actually being asked for, and find the contradictions between documents. ERP has no layer that interprets a clause or a single-line diagram, so the interpretation, the genuinely difficult work, lands back on the estimator and the engineer. The module can hold the numbers once a human has produced them; it cannot produce them from the documents.
Why won't reformatting into the client's returnable schedule work in CPQ?
Reformatting into the client's returnable schedule will not work in CPQ because CPQ outputs a quote in the vendor's own layout, and a tender requires the answer in the client's. Every tender arrives with blank returnable schedules (called submittals, bid forms or exhibits in the US) plus a compliance matrix and often a deliverables list (SDRL) that the bid must be poured into, line for line, in the issuer's structure. CPQ has one output template, its own, and no concept of a compliance position against an external specification, of a clarification or a departure, or of a deliverables register. So even where a CPQ price exists, a person still re-keys it into the client's forms by hand, which is the reformatting cost that eats the bid team's hours on every submission.
What actually fits an engineered-to-order project bid?
What fits an engineered-to-order project bid is a tool that reads the tender documents, cites every value it produces, and writes the answer into the client's format, leaving pricing and judgment to people. The work is document interpretation first and configuration never: extract every requirement, find the conflicts, build the compliance response, and complete the returnable schedules, with each line traced to the source document and page so a human can verify it. This is what Elora Grid does. You hand it the RFQ, scope of work, drawings and blank returnables, and it returns the compliance matrix, the conflict and variation register and the completed returnable schedules, every line cited; it never invents a price, and it surfaces anything it cannot match for review instead of guessing. The estimator and engineer keep the commercial decisions; the tool removes the document-reading and re-keying that CPQ and ERP were never built to do.
Where CPQ fits on the manufacturing strategy continuum, and where ETO falls off it
| Production strategy | What the customer orders | Is the product defined before the order? | Quoting approach that fits |
|---|---|---|---|
| Make-to-stock (MTS) | A standard item from a catalogue | Yes, fully | Price list |
| Configure / assemble-to-order (CTO/ATO) | A product built from pre-defined options | Yes, as a set of known options | CPQ (configure-price-quote) |
| Make-to-order (MTO) | A standard design, made after the order | Yes, the design is fixed | CPQ or a costed bill of materials |
| Engineered-to-order (ETO) | A one-off design created for this tender | No, it is engineered to win the bid | Document-led, cited bidding (not CPQ) |
What CPQ and ERP quoting assume, versus what an ETO project bid actually is
| CPQ / ERP quoting assumes | An ETO project bid actually is |
|---|---|
| The product and its options are modeled in advance | No product exists yet; the scope is engineered to win the tender |
| Inputs are structured data (item master, BOM, routing) | Inputs are unstructured documents: RFQ, scope of work, drawings, returnable schedules |
| Output is the vendor's own quote format | Output must be the client's returnable schedules and compliance matrix |
| The deliverable is a price | The deliverable is a cited, clause-by-clause compliance response; price is one part |
| Each quote reuses one stable product model | Each tender is a different scope, specification and often a different standard |
Four ways teams quote an ETO project bid
| Approach | Reads the tender documents? | Outputs in the client's format? | Pricing source | Where it breaks |
|---|---|---|---|---|
| CPQ / ERP quoting module | No | No, its own layout only | Maintained price tables | No product to configure; cannot read documents or fill returnables |
| Spreadsheets and Word (manual) | A person does | A person re-keys it | Estimator's judgment and history | Slow and error-prone; reformatting eats the bid team's hours |
| Generic LLM (ChatGPT) | Yes | Drafts prose, not structured returnables | Invented (predicts a plausible number) | Hallucinates prices and compliance claims it cannot support |
| Cited, deterministic assistant | Yes | Yes, into the client's schedules | Never invented; flagged for a human | Judgment stays with people by design, not a failure |
- 01Hand it a real tender, not a product list. Give the tool an actual RFQ with its scope of work, drawings and blank returnable schedules. A CPQ or ERP quoting module needs a pre-modeled product and has nothing to do with raw tender documents.
- 02Check it can output in the client's format. Confirm the tool can complete the client's returnable schedules and compliance matrix in the issuer's structure, not just print a quote in its own layout.
- 03Ask where each value came from. A fit-for-tender tool cites every number and compliance statement to a source document and page. If it cannot show its working, you cannot defend the bid.
- 04Confirm it refuses to invent a price. Check the tool flags a missing price for a human rather than filling the cell with a plausible figure. An invented number in a bid costs real money.
- 05Give it a scope it has never seen. Each ETO tender is different, so a tool that only works once a product is configured will stall. A fit tool handles a fresh scope because it reads the documents rather than matching a catalogue.
Common questions
Can you use a CPQ tool for engineered-to-order quoting?
Not for the bid itself. CPQ (configure-price-quote) software prices a configurable product from a pre-modeled list of options, which an engineered-to-order tender does not have: the scope is unique and the design is created to win the job. CPQ can price a productized sub-assembly inside a larger bid, but it cannot read the tender, decide compliance or complete the client's returnable schedules, which is most of the work.
What is the difference between configure-to-order and engineer-to-order?
Configure-to-order (CTO) builds a product from a fixed set of pre-defined options, so the product is fully defined before the order. Engineer-to-order (ETO) creates a new design in response to the order itself, so the product does not exist until you engineer it. CPQ and ERP quoting suit configure-to-order; ETO project bids, which arrive as unstructured tender documents, do not fit that model.
Why doesn't our ERP handle tender bids?
An ERP quoting module works on structured master data: the item master, bills of materials and routings. It can cost parts and operations once a human has defined them. A tender bid's hard work happens earlier, in reading the RFQ, scope of work and drawings, deciding what is required, and finding contradictions between documents. ERP has no layer that interprets those documents, so that work stays manual.
Is a generic LLM like ChatGPT better than CPQ for ETO bids?
A generic LLM can read the documents that CPQ cannot, but it introduces a different risk: it invents plausible prices and compliance claims because it predicts text rather than verifying facts. For an ETO bid, an unsupported number or a fabricated compliance statement costs money. The safe approach reads the documents like an LLM but cites every value to a source and refuses to invent the rest.
What should a tool for engineered-to-order bids do instead?
A tool for engineered-to-order bids should read the tender documents, extract every requirement, find conflicts, and complete the client's returnable schedules and compliance matrix, with each line cited to its source document and page. It should never invent a price, and it should surface anything it cannot match for human review. Pricing and the comply-or-deviate judgment stay with the estimator and engineer; the tool removes the reading and re-keying.
Send a real tender. Get the output back.
Hand Elora Grid one real task and judge the result yourself.