Build a Product Selector That Helps Customers Choose Correctly

Start with a decision your store can actually support

Define the first version narrowly: help customers find a suitable replacement part for a defined range of products, nothing else. The tool shouldn't diagnose a broken device, recommend repairs, or infer a performance upgrade from a marketing description.

That boundary is what makes the first version inspectable. A catalogue owner can name every product involved, a support colleague can describe the common mistakes, and a developer can work from a finite set of outcomes.

Check that the uncertainty is real before building anything. Look at support tickets, search terms and return reasons. Watch how a colleague currently answers the question. If they already use a reliable model-to-part table, the opportunity is making that knowledge available at the point of purchase. If they rely on one experienced person's memory, documenting and verifying those relationships comes first — a selector can't automate knowledge that doesn't yet exist in a checkable form.

Don't assume a selector is the right fix just because customers ask questions. Clearer product titles or a visible compatibility table can solve the same problem for less engineering. A selector earns its complexity when customers need several pieces of information combined, in sequence, to reach one answer. Pick the first range partly on evidence quality: a smaller family with current documentation beats a huge range with conflicting descriptions.

Build the compatibility record before the recommendation

Compatibility is a relationship between two identified things, under stated conditions — not a resemblance. A product title that contains the right model family is a lead to check. A photo that looks similar is another lead. Neither one supplies the missing relationship.

Picture a simple fictional example: bag BG-A1 is confirmed to fit model VX-210-A, and bag BG-B1 fits VX-210-B. The final letter changes the answer. Filter FT-A1 is approved for VX-210-A; FT-B1 for VX-210-B. The store also recognises model VX-400-A but currently has no confirmed bag for it at all. Each of those relationships needs an inspectable source — a manufacturer record, a verified spec sheet, something a human approved on purpose — recorded with its suffixes, generations and exceptions. A broad statement about a product family should never silently become approval for every member of it.

An unsupported substitute doesn't remove the uncertainty — it just moves it into the order.

Two separations matter more than any database choice:

• Keep compatibility and stock apart. A suitable filter doesn't stop fitting because the warehouse sold out, and an available filter doesn't become suitable just because it's the closest thing left in stock.
• Keep missing evidence separate from negative evidence. If no record connects a bag to a model, the tool can't conclude it fits — but it also can't claim proven incompatibility just because the relationship is absent. A confirmed exclusion needs its own basis.

When two current documents disagree, flag the relationship and suspend any recommendation that depends on it until the catalogue owner resolves it. A model shouldn't settle that disagreement by picking the more confident-sounding sentence.

Give every outcome a precise meaning

Once the customer's inputs are confirmed, ordinary rules — not a generative model — should decide what fits: identify the product, identify the requested part, check the relevant conditions, establish the eligible items, then check availability. Commercial ranking only happens inside that eligible set.

Before matching starts, help the customer supply the one fact that actually changes the answer. Show them where the model label is, explain which part of the code matters, and if a suffix changes the result, show a worked example so they understand why the extra character is there. If AI is reading a typed description or a label photo, treat its output as a proposed input: display what it extracted and ask the customer to confirm it before using it for the compatibility decision. Someone typing "VX210, the blue one" has given you a family, not an identifier — colour is not a substitute for the missing suffix unless an approved record says otherwise.

A vague "no results" message hides several different problems that each need a different answer:

• Confirmed match, in stock: show the exact product.
• Confirmed match, out of stock: say so plainly and offer a real stock option or a support route — don't call it incompatible.
• Documented exclusion: explain the condition that rules it out.
• Incomplete identifier: ask the specific missing question, not a generic one.
• Recognised product, no confirmed listed part: explain the catalogue limit — it doesn't mean no compatible part exists anywhere.
• Unavailable or conflicting data: pause the recommendation and offer a recovery route, rather than guessing.

If the customer corrects their model after seeing a result, clear that result and recompute. Leaving the old answer on screen makes the interface contradict its own decision.

Build, test and maintain it like a decision service

A usable build brief names the inputs, the decisions, the visible states and what "done" means — "build an AI shopping assistant" leaves the commercial logic undefined. Sketch the full journey, including the missing suffix, the unsupported model and the failed data lookup, before polishing any screen. Build one complete path first, confirm a real approved record produces the correct result and opens the matching product, then add the remaining states one at a time.

Testing is two different jobs. The matching rules need cases with known correct answers, approved by the catalogue owner independently of the implementation, then run through the actual selector — not a mock. Any AI that extracts identifiers or interprets descriptions needs a separate set of previously unseen examples: ambiguous characters, incomplete codes, unfamiliar wording. Score wrong answers and valid requests for clarification separately — a system that refuses every hard input avoids wrong recommendations while leaving customers stuck, and one that always guesses looks efficient while creating the opposite failure.

Unknown and incompatible have to stay two different answers.

Then watch real or likely customers attempt the task without being told which button to press. People read serial numbers instead of model codes. They read "no confirmed catalogue item" as a broken website. Those sessions won't give you a conversion rate, but they will surface wording and instruction problems that rule-testing alone never finds.

Every recommendation depends on facts someone has to keep current. Name an owner for compatibility approvals, separate from whoever runs the system technically, even if it's the same person at first. Decide what triggers a review — a new product generation, revised manufacturer guidance, a support-reported conflict — and build that into the catalogue workflow, not a calendar reminder. Define the stop action before launch: if the underlying data turns unreliable, the owner should be able to suspend the affected recommendations and show a working support route, instead of leaving an uncertain selector online because it usually works.

Six checks before you ship it:

• Choose one recurring purchase decision using real support and search evidence, not a guess.
• Get the catalogue owner to approve exact model-to-part relationships and exceptions before anything recommends from them.
• Write distinct behaviour for every unanswered case: missing input, unsupported model, incompatibility, catalogue gap and unavailable data.
• Confirm the one input that changes the answer, and show the customer what any AI extraction read before using it.
• Keep the matching rules separate from the explanation text — the rules decide, the text only explains.
• Watch a limited release, measure outcomes separately, and keep someone able to pause it.

A precise request for a missing suffix or an honest stock message gives the customer a usable next step — a stronger commercial asset than a confident guess.