AI product search when customers do not know the name or code

AI product search can connect what a customer describes to items the business actually sells. Meaning helps retrieve candidates; product records establish whether those candidates meet the requirements. A useful result explains the match, exposes unresolved details and makes the next decision easier to check.

For the owner, the question is whether customers or staff can reach a usable selection. If every answer still goes to the same specialist for a fresh search, adding a chat box has not removed much work. Talvyn Labs develops catalogue search and product assistants that connect business data, selection rules and the review experience.

Consider an illustrative request: “A document tray that fits inside our existing shelf and lets us remove paper from the front.” It contains a use case, a size constraint and a product characteristic. Searching for “document tray” alone may return many items without resolving the choice.

The assistant should separate known requirements from missing details. It knows front access matters but does not know the shelf's usable dimensions. It should not substitute the most popular size or guess the available space. If the customer has an old product code, search that code first and check the model's current status.

The principle extends to spare parts and specialised equipment, where constraints can be stricter. Similar names do not establish interchangeability. A product owner must define which compatibility rules and substitutions the system is allowed to use.

A catalogue often needs exact keyword or identifier search alongside semantic retrieval. Microsoft's hybrid-search documentation describes combining these approaches and explains why exact terms remain useful for product codes and specialised terminology.

Finding a conceptually similar item is only the first step. Mandatory conditions must be checked against stored attributes. Missing evidence also needs a different state from evidence that a requirement is not met.

A strong retrieval score is not a compatibility certificate. Equally, “information unavailable” does not necessarily mean a product fails the requirement. Result wording should reflect what the system can establish.

Start with stable product identifiers, common names, selling units, decisive attributes and supporting documents for each model. Record the document version or date and identify who maintains it. Discontinued items need an explicit status so old descriptions do not present them as available to order.

Customer-specific pricing or restricted products require access checks before retrieval and display. A prompt telling the model to keep prices private is not a data-permission system. The application must select records appropriate to the authenticated user.

If product identifiers differ across systems, establish product-code mapping first. Adding AI over ambiguous product identities can make an answer appear organised while still pointing at the wrong item.

A customer-facing result might show candidates, matching attributes, outstanding questions and product documents. A sales workspace may also need the request history, a reason for the selection and a way to pass checked items into a quotation draft. The users and permissions differ, so the interfaces do not have to be identical.

Chat is not required for every task. A search field that interprets a sentence and populates visible filters may be easier to inspect. When a follow-up question is needed, ask for information that changes the selection, such as the available dimensions or the equipment model the item must fit.

An unsuccessful search also needs a next step. Staff should receive the question, candidates already considered and missing information when a request is escalated. Customers should not have to explain the entire problem again.

Collect authorised examples of actual searches. Include catalogue names, abbreviations, spelling errors, trade language and mixed Thai-English requests. Product specialists should define acceptable candidates and mandatory constraints before evaluation begins.

The evaluation set needs exact matches, questions requiring clarification, discontinued models and requests for which no suitable product exists. Check unsuitable recommendations and access to another customer's restricted information. Results from clean, easy queries alone do not establish coverage of everyday work.

Business measures include whether users find an acceptable candidate, total time to a checked selection, repeat searches by staff and the completeness of quotation handovers. Sales also depend on price and stock availability, so sales totals alone should not be presented as the effect of AI search.

Begin with a category whose records are reliable and whose owner can review answers. If the existing search tool already supports useful aliases and filters, improve the data and test it first. Custom development is worth evaluating where selection rules, integrations or the required workspace exceed what the current tool can support.

For a scope discussion with Talvyn Labs, prepare sample questions, one catalogue category, supporting product documents and examples of acceptable answers. Agree on retrieval, constraint checks, the result interface and ongoing data updates. When the next step is commercial preparation, continue with AI quotation drafts from purchase requests.