A catalogue nobody could price by hand became a source of offers

Where this started

The client sources vehicles from a partner catalogue of around 2,600 vehicles. Each one needs a tax calculation and a full cost calculation before a selling price can be set, and that calculation runs against a price list of roughly 224,000 rows.

Until then, a person performed the calculation one vehicle at a time. That made it unrealistic to work through the entire catalogue manually simply to establish which vehicles were worth considering.

Why “just calculate all of them” was not the answer

The apparently obvious solution was to let the system calculate all 2,600 vehicles.

Before building that, I ran the calculation across the whole catalogue to see how far the results could be trusted at all:

THE FULL CATALOGUE — 2,600 VEHICLES

RELIABLE CALCULATION ............ 41.6 %
NO DATA IN THE PRICE LIST ....... 27.5 %
UNCERTAIN CALCULATION ........... 23.6 %
EXEMPT FROM THE TAX .............  7.3 %

The 27.5% are not a hidden problem. For those vehicles the system says plainly that the data is missing, so a person knows the case has to be handled by hand. The exempt 7.3% are electric vehicles, where there is no tax and the figure is always correct.

The 23.6% are the problem. Those vehicles can produce a figure that looks just as convincing on screen as a reliable calculation, even though the system does not have enough basis to trust it. If the tax calculation comes out too low, the difference comes out of the margin, with no warning to the user.

What that would mean in practice was estimated from 19 real customs decisions: per 1,000 vehicles, roughly 135 to 235 would receive a figure that is too low, with nothing anywhere to show it. That is an estimate rather than a measurement — and the sample it was derived from was more favourable than this catalogue, so the real number is likely closer to the upper bound.

What was built

The answer was not to make a better guess. It was to separate calculations that could be used from cases that needed a person.

For every vehicle, the system assesses the confidence of the calculation. When the range of plausible values is narrow enough, the calculation proceeds automatically. When it is not, the vehicle goes into a visible review queue with plausible options already prepared. The operator chooses between concrete candidates rather than starting the lookup from scratch.

Invisible uncertainty became a work list that somebody can review.

ACROSS THE 540 VEHICLES THEN IN THE SYSTEM

CARRYING A USABLE CALCULATION ... 21 %  →  77 %
MANUAL REVIEW QUEUE ............. 430  →  120

Where even a conservative choice is not possible — there is no emissions figure, the relevant price row is stale, or the vehicle category itself is uncertain — the system still refuses to produce a figure. That is deliberate: combining several uncertain assumptions would recreate exactly the kind of result the mechanism is designed to separate out.

A rule that lives in the system, not in people’s heads

The client has a hard rule: a vehicle below a set level of profit does not go on sale. Previously that rule lived in people’s heads and in one spreadsheet column.

The system now enforces it. A vehicle that does not clear the threshold fails the check and cannot be published.

One detail is easy to miss but important: the system never writes the threshold itself back as its own calculation. If a missing cost were replaced with the threshold value, every vehicle would pass the check by construction. A check that always passes is not a check. It is decoration.

What this example shows

A tool that returns a number for every question is easier to build and can look more convincing at first. The problem is that its errors and uncertainty remain invisible until they become expensive.

The value here is not only the speed of the calculation. The system assesses when a calculation has enough support to proceed and when the case needs a person. That distinction becomes a review queue — a place where the remaining manual work is visible, together with the reason it is needed.

If a tool is currently giving you numbers that business decisions depend on, one question is worth asking: does it know when it does not have enough information for a reliable answer — and what does it do then?

PythonFlaskSQLiteDockercronNjuškalo feed