Offline catalog search: from a customer's description to a product variant

Syntalith proposes an application with a copy of a selected part of the catalog on the rep's device, with search and a view for comparing variants. A small language model can be added where customer descriptions are hard to match using names and filters. The starting point is how the team searches for products and which devices reps take to meetings.

Finding a catalog item from the customer's description

In our example, the customer asks for a “black box with a transparent lid.” The catalog lists this product group as “transport containers.” It contains two similar variants: one with a handle and one without. The description fits both. The search application shows both items, their SKU product identifiers and the properties recorded in the catalog. Each result opens a locally stored source product sheet.

The rep sees the difference and asks about the handle. Once the customer supplies that detail, the rep can identify the relevant item. A description matching a product sheet does not establish suitability for a particular application. If the customer asks about that, the rep needs the relevant information and the assessment required by the company's product selection process.

What names, filters and alternative terms can do

Before adding a model, consider searching product descriptions and filtering by product properties. Aliases, stored alternative names that customers use, can also help. If the team repeatedly hears “box,” that term can be linked to the relevant category. Reps then have a way to search without knowing the exact product sheet heading.

SQLite describes FTS5 as a full-text search module for database applications. It is one option for building search over a stored catalog. For the whole application to work without a connection, the product sheets and results view must also be accessible locally.

A model is worth comparing with this approach when customers describe products in many different ways and fixed aliases do not cover enough of them. It can help turn a sentence into terms useful for finding catalog entries. The application should retrieve variant names and properties from the catalog. That gives the rep something to check, including when the model's suggestion leads to the wrong product group.

The team's actual queries should guide the choice. Compare search using filters and aliases with model-assisted search on the same descriptions: whether the right items appear, how many irrelevant results the rep has to review and whether the variants are easy to distinguish. A small catalog alone does not establish a need for AI.

A catalog copy for the customer visit

During the meeting, the rep uses data downloaded earlier. The application should show when it was updated and which parts of the catalog are available, so the rep knows what they can search. An item missing from this copy may still be part of the company's full range.

Current inventory, pricing and availability may require a connection to the company's systems. Finding a product offline does not provide that live information. The proposed view can distinguish stored product properties from information the rep will check once a connection is available.

The catalog owner helps define synchronization scope: which product groups and attachments reach the device, and how the application shows that a data refresh has finished.

What the team can inspect before a wider rollout

A useful trial puts part of the actual catalog on a device used for customer visits. In airplane mode, a rep can see whether they can open the application, find a product in their own words and read its product sheet. That lets the team assess the whole workflow, including waiting time and the ease of comparing variants on the screen.

If the model-assisted version involves more waiting or more mistakes than filters and aliases, the team can keep the simpler search. The model decision should follow a comparison of queries and reps' work on the intended equipment. Application and catalog updates also need an agreed owner who will support the field sales team after launch.

Proposed scope for field sales

An initial engagement with Syntalith could cover one product group and a comparison of alias-based search with a small model. Trying both on the rep's device helps the team decide which version to develop and how much of the catalog to make available.

Sales reps contribute examples of customers' wording, while the catalog owner identifies the data and properties that distinguish variants. With IT, we agree on permitted devices, catalog updates and ongoing application maintenance. Those decisions provide a basis for estimating work that fits the team's daily routine.

Tell us about a product that is hard to find using customers' words and the device your reps use on visits. That is enough to start discussing scope without preparing the entire catalog to share. See our pricing page for information about estimates.