Six weeks on, the customer asks why the table cost that

A customer comes back six weeks after the quotation went out and asks why a work table came to what it came to. Reasonable question. The sheet rate has moved twice since then. One material has been replaced by another. The estimator who built the quote is on site and will not be back today.

If you price the same table again now, you get a different number, and you cannot say why the old one was what it was. You can describe your method. You cannot show the sum. A bespoke price you cannot reconstruct is a price you end up conceding, and the concession is made on the line the customer chose to argue about, which is never the cheap one.

What was actually going on

Most quoting systems keep the answer and throw away the working. The line stores a price. The rates and the rules that produced it live elsewhere and keep changing. Six weeks later the price is still there and everything that explains it has moved on.

What we changed

Every calculated line keeps the full working of its pricing run, stored beside the figures: for each feature, which rule ran, the steps in order, the expression at each step, the value each step produced, every variable those expressions were evaluated against, and the rate that was looked up for every material and every rate code. The per-feature working is stored again on the feature itself, so one feature can be explained without loading the whole line.

That makes each stored line a good deal larger, and it is a deliberate trade. In exchange, the arithmetic behind every quotation the business has ever sent can be reproduced from what is stored, without depending on today’s rate tables, today’s formulas or today’s catalogue. For anything where a number was given to someone outside the business and might be disputed, that is the right trade almost every time. Storage is cheap. The argument is not.

Because the working is kept, the screen can show it. An estimator can open a feature and see the steps, the intermediate values and the rates that produced its cost. A small information control on each feature in the quoting flow shows the pricing rule behind it, its code, its name and its steps, and a company setting turns that off for a business that does not want its estimators reading formulas.

What it paid for that nobody planned

Two things were built later that were in nobody’s plan when the working was first stored, and both sit almost entirely on top of it.

The first is a bill of materials for a quotation: what material is actually consumed across every line, so the workshop can see what has to be bought before the job is accepted. It reads the stored working. It does not re-run the pricing, does not need the rate tables, and works on quotations priced months ago under rates that no longer exist.

The second is a cutting list, and that one needed something the working does not hold. A cutting list has to know the rectangular pieces cut from sheet, a top panel of this width by that height, a back panel, two sides, and then fit them onto standard sheet sizes with as little waste as possible. The stored working records the arithmetic that produced a cost. It records no shapes, because the pricing rule never needed shapes: a rule that multiplies the area of a top by a rate knows the area and has no idea of the panel. So the cutting list needed its own per-product description of pieces, each with a width and a height written over the same dimension codes the pricing rules use, a quantity per unit and a material grouping. The fitting itself is a simple placement onto the two standard sheet sizes, largest pieces first.

The lesson is not that storing the working failed. It is that the working preserves what the calculation needed, and a later feature may need something the calculation never used.

What it does not do well

The bill of materials has one genuinely weak part. To say how much of a material is consumed, it needs a physical quantity: kilograms, square feet, running metres. The stored working holds every intermediate value, so the quantity is in there somewhere. Nothing says which one it is.

So the extraction looks through the stored values for names that look like quantities, weight first, then area, then length and volume and a few variants, skipping anything that is a rate rather than an amount. If it finds nothing it says nothing, and the column is left empty rather than filled with a guess. That last behaviour is the only thing that makes it defensible. It is still matching on names a business chose for its own reasons, and it works here because the naming happens to be consistent. A second business naming its values differently gets a bill of materials with no quantities and no explanation.

The right design is for a rule to declare which of its steps produces the physical quantity, one mark on one step, made by the person who writes the rule. That is not built. The honest position is that the quantity column is best-effort, and the system knows when it has failed, which is better than nothing and not the same as correct.

The mechanism, in one sentence

A system that keeps its working can explain itself; a system that keeps only results can only assert. Every explanatory feature in the product became cheap the day the working was stored, and none of them would have been affordable otherwise. When a computed number leaves your business and reaches a person outside it, store the inputs and the steps that produced it, not only the result, and assume the rates, the rules and the catalogue will all have changed by the time anyone asks.

Where this ends up

The stored working is what lets Sazinga Quote explain a six-week-old line from the formula that produced it, rather than pricing it again at today’s rates and hoping the two agree.