Quoting a product with 24 features and 62 variants

If you make things to order, you cannot write a price list. A customer can choose a sink or not, a splashback or not, legs of one height or another, and every combination is a different product. The most complicated item in one fabricator’s catalogue had 24 features, 62 variants of those features, 20 dimensions and 85 material choices, and it resolved to 140 separate pricing mappings.

The trouble starts when somebody tries to price it product by product. Every new product needs its own set of formulas, and every one of those repeats the same sums. A splashback is priced separately inside every product that has one, and the day the price of steel sheet changes, or somebody spots an error in the splashback sum, you have to find and fix every copy. The copies drift apart, and then two quotes for near-identical work disagree. The cost is quotes sent at the wrong price, and we have no figure to put on that.

What was actually going on

The catalogue for this business had 57 product types, 86 features, 175 sub-features and 613 cases of a feature being offered on a product. The pricing rules numbered 362.

Look at how those numbers relate. The 362 rules were reused across roughly 1,400 mappings, where a mapping says that this rule prices this feature on that product. That ratio is the whole argument. A rule is reused across many products, so the number of rules grows with the number of different calculations, not with the number of things you sell.

A splashback is a splashback. It is priced from its length, its height and the sheet it is made from, and that does not change because it is fitted to a work table this week and a service counter next week. Once the rule exists, a new product with a splashback costs one mapping, not one formula.

What we changed

The price rule belongs to the feature, not to the product. A product is simply a list of the features it offers.

Each rule then needs only a few inputs. Legs need a height and a count. A cross support needs a length and a breadth. A splashback needs length, breadth and its own height. A sink bowl needs its own three dimensions, which are not the outer dimensions of the item. A product’s full list of measurements is whatever its features ask for, worked out rather than written by hand. When an estimator picks a product, the system gathers what each feature needs and shows exactly those fields, and adding a feature to a product makes its fields appear with no form being edited.

A third layer sits between rule and product: the mapping that says which rule prices which feature of which product. It can also be tied to a particular variant or a material grade, or left open to cover them all. Most features price the same whatever variant is chosen, so one open mapping covers them. Only features where the variant really changes the sum need one per variant, which is why 1,400 mappings were not several times more.

Because mappings are rows of data, not conditions buried in code, you can ask a direct question: which product-and-feature combinations have no pricing rule? The answer is the test of whether a catalogue is ready to quote from.

I was wrong about one thing. I assumed the client’s fabrication drawings would give the list of dimensions for each product. They do not. For one work table with a sink, the model wanted 11 measurements and the drawing annotated 5. The drawing was not incomplete. It was a drawing of one specific item that had been ordered, and the sink bowl was a standard size on that job, so it was never separately dimensioned. The model has to price an item that has not been ordered yet, so it asks for every optional measurement. A drawing of a built item and a model of a sellable one are different things, and some inputs will always have to come from the estimator.

What it did not fix

Two things got harder. When a price is wrong you have to establish which rule fired before you can look at the rule, and the mapping that fired is invisible in the result unless somebody builds a way to show it. That has to be built deliberately.

And a rule shared by many products cannot be changed casually. A tweak that suits one product reprices everything else that uses it. Reuse is the benefit and the hazard in the same mechanism, so the editing screen has to show how many features use a rule before somebody changes it. Showing that count is cheap, and it prevents a whole category of accident.

The pattern, for anyone who makes things to order

Find the smallest piece of work that always has the same calculation, which for made-to-order goods is almost always a feature, not the finished item, and attach the price to that. Then treat the product as a list of features and let the fields, the price and the check that a catalogue is ready all follow from the list.

The warning sign is easy to check in your own business. If your count of pricing rules or price-list lines grows in step with your count of products, the price is attached to the wrong thing, and the copies have already started to drift.

Where this ends up

Pricing rules attach to features in Quote, and a product is a list of features, so the fields an estimator sees, the price and the readiness check are all worked out from that list rather than kept alongside it.