Why made-to-order manufacturers live in Excel, and what a pricing engine changes
Walk into a fabricator, a joinery workshop, a signage manufacturer or a specialist assembler and ask how a quotation is produced. The answer is almost always a spreadsheet, usually one that began life a decade ago and has been copied for every job since.
Software people treat this as a failing. It is not. Excel is the only tool that ever did what these businesses need: express arbitrary rules about their own product in a form the person who knows the rules can edit themselves, without waiting for anyone. Every ERP that promised to replace it lost, because the ERP had opinions about the product and the product does not fit them.
Understanding why the spreadsheet won is the only way to build something that improves on it.
What the spreadsheet is actually doing
A made-to-order quote is a computation over a configuration. Dimensions, material, gauge, finish, options, quantity, delivery. From those, the sheet derives sheet consumption with a wastage allowance, cut and weld time, finishing time, bought-in components, freight, overhead recovery and margin. Change the length and thirty derived numbers move.
That is a genuinely parametric model, built by a person who understands both the product and the shop floor. It encodes real knowledge — how many linear feet of weld a particular joint takes, why a brushed finish costs more on one gauge than another, which nesting the cutter actually achieves rather than the theoretical one. That knowledge is worth preserving.
What goes wrong, and it is not the formulas
The failure is not the model. It is that the model has no identity, no owner and no version.
Copies diverge. Every quote begins as a duplicate of a previous quote, so the logic in circulation is whatever was in the file somebody happened to duplicate. Someone corrects a wastage factor in their copy. It never reaches the other eleven copies, and now two estimators pricing the same job get different answers for reasons that cannot be reconstructed afterwards.
Rate changes are retroactive by accident. The steel price moves. Someone updates the rate cell in the master sheet. Every quote reopened from that master now prices differently, including ones already sent, and there is no record of what any given quote was priced at which rate. When a job turns out unprofitable, the cost basis it was quoted on no longer exists anywhere.
Errors are invisible. A dimension typed into the wrong cell produces a number, not an error. It flows through material and labour and arrives at a total that looks like every other total. Nothing in a grid of figures signals that the object being priced is not the object the customer described.
Discounting has no record. Margin gets adjusted in the sheet directly. There is no threshold, no approval, no trace of who authorised what against which cost base — so the question “where did our margin go last quarter” cannot be answered from the quotes themselves.
The knowledge is one person’s. The sheet is legible only to whoever built it. When they leave, the business owns a file it is afraid to change.
What a governed engine changes
The move that matters is separating things that change often from things that must not change casually.
Reference data has an owner and an effective date. Material rates, wastage factors, labour rates, standard operations and bought-in prices live in one place, are versioned, and carry the date from which they apply. Change the steel rate today and quotes issued yesterday keep the rate they were priced at, because every quote records the rate version it used. That one property makes margin analysis possible for the first time.
The estimator configures, they do not compute. The person quoting enters what the job actually is — dimensions, material, options, quantity. Everything downstream is derived. There is no formula to edit per job, so there is no formula to get wrong per job, and two people entering the same specification necessarily get the same number.
Rules stay editable by the people who own them. This is the requirement that kills naive implementations. If changing a wastage factor means a development ticket, the workshop goes back to Excel within a month and they are right to. Rules belong in configuration with an interface the estimating lead can use, with versioning and an audit trail behind it.
A visual preview catches specification errors. Rendering the configured unit as it is priced converts an arithmetic error into a visible one. A counter with a wrong dimension looks wrong, and it looks wrong to the person who typed it, before it is sent. This is a better error check than any validation rule, because it uses the reviewer’s eye rather than their patience.
Approval is structural. Discounts beyond a defined threshold require approval that is recorded against the quote, along with the cost base it was measured against.
The quote becomes a versioned object, not a document. Issued as a link rather than an attachment, the customer always opens the current revision, previous revisions remain inspectable, and acceptance attaches to a specific version.
The honest constraints
This only works if the rules are extracted properly first, and that means sitting with the person whose sheet it is and getting the logic out of the cells and into something stated. It is slower than it sounds and it is the part that determines whether the result is trusted.
It also only works if the engine stays as flexible as the spreadsheet was. The moment an estimator meets a job the system cannot express and has no escape hatch, they open Excel, and everything above is undone. Build the escape hatch — a manual line with a reason — and treat its frequency as the measure of how much of the real business the model still fails to cover.