Skip to content

Insights ·

How to match customer requests to ERP SKUs without guessing

The hardest part of answering an RFQ is rarely the price. It is working out which of thousands of near-identical products the customer actually means — from a line they wrote in a hurry, in their own words.

What a line actually looks like

Very few customers write your SKU. They write a description (“panel 60x60 4000K, and the usual driver”), a code from another brand, a reference from an old catalog, or a specification with no product name at all. Sometimes they write “or equivalent” and expect you to propose the match.

Each of those needs a different kind of work, and a single keyword search on the product name handles none of them well.

The same spec, written five ways

Colour temperature arrives as 4000K, 4000 k, 4.000K or 6500ºk with a degree sign. Wattage arrives with a decimal comma in Portugal and Spain and a decimal point elsewhere. Dimensions arrive as 60x60, 600x600 mm or 60 × 60 cm.

Before any matching, those specs have to be read the way the trade writes them and turned into comparable values. Skip that step and a perfect match is missed because one side wrote a comma.

Codes from other brands

A request for “the equivalent of” a competitor’s code is common, and it cannot be answered from your own catalog alone: first you need to know what that code is — its wattage, lumen output, IP rating — and only then which of your products comes closest.

Brand names make this harder than it looks. A brand the system has never seen, or one written with a hyphen or an unusual capital, can slip past detection entirely, and the line gets matched on its words instead of its specification. Good matching treats an unrecognised brand as a question to resolve, not as noise.

Near-identical is the dangerous case

In a deep catalog, many products differ by one attribute: 3000K against 4000K, IP54 against IP65, a 60° beam against 90°. One transposed digit in a code is a different product at a different price.

That is why a matcher should be judged on what it does when it is unsure. Picking the closest neighbour and pricing it looks efficient and quietly puts the wrong product on a quote.

Flag it, do not guess

The safer design is explicit uncertainty. In Ettore every line ends in one of a few states — Ready, Check match, No match, More details needed — and anything unrecognised defaults to Check match, never to Ready. That is a rule in the architecture, not a setting someone can switch off.

The point is not that the machine is always right. It is that the team only has to look at the lines that genuinely need a person, and can trust the ones marked Ready.