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

The client remembers the look, the salesperson looks for the name

In our example, the client asks about “a black box with a clear lid”. In the catalogue this product group is listed as “transport containers”. It holds two similar variants: one with a handle, one without. The client's description fits both. So the search shows two items, their SKUs (the product codes) and the features recorded in the catalogue. For each one you can open the source sheet saved on the device.

The salesperson sees the difference and asks the client about the handle. They can point to the right item once they have the missing information. A description that matches a sheet does not confirm that the product suits a specific use. If the client asks about that kind of fit, you need the right data and the assessment your company's selection process provides for.

How much names, filters and aliases solve in offline catalogue search

Before adding a model, check search across the descriptions and filters on product features. Aliases help too: saved alternative names that clients use. If the team keeps hearing “box”, you can link that word to the right category. The salesperson then does not need to know the exact heading of the sheet.

SQLite describes FTS5 as a full-text search module for database applications. It is one way to build search over a stored catalogue. For the whole app to work without the network, it also needs local access to the product sheets and to the results view itself.

A model is worth comparing with such a solution when clients describe products in many ways and fixed aliases are not enough. It can help turn a sentence into terms that are useful for finding an item. The app should take the variant names and their features from the catalogue. That way the salesperson has something to check, even when the model's proposal leads to the wrong product group.

The queries from the team's work decide the choice. On the same descriptions you can compare search with filters and aliases against a version supported by the model: whether the right items appear, how many unneeded results have to be reviewed and whether the employee can tell the variants apart. The size of the catalogue alone does not settle whether AI is needed.

The catalogue copy during a visit

At the meeting the salesperson uses data downloaded earlier. They should see the date of the update and the scope of the catalogue available, so they know what they can search for. An item missing from this copy does not mean the company lacks it in the full range.

Current stock, price and availability may need a connection to the company system. Searching for a product offline does not provide this current information. In the proposed view, the stored product features are easy to tell apart from the data the salesperson will check once the connection is back.

The scope of the sync has to be agreed with the catalogue's owner: which product groups and attachments go onto the device, and how the app shows that the data refresh has finished.

What you can look at before a wider rollout

A useful trial is a part of the real catalogue on the device used during visits. In airplane mode, the salesperson can see whether they can open the app, find a product in their own words and read its sheet. This lets you judge the whole way of working, including the waiting time and how easy it is to compare variants on screen.

If the version with a model means more waiting or more mistakes than filters and aliases, you can stay with the simpler search. The decision on the model should come from comparing queries and the salespeople's work on the target hardware. Agree how app and catalogue updates are handled with the person who will later support the team in the field.

The proposed scope for field sales

The first scope of work with Syntalith can cover a chosen product group and a comparison of search with aliases against a small model. On the salesperson's device you can judge which version to develop and how much of the catalogue to make available.

Salespeople pass on examples of the terms clients use, and the catalogue's owner points to the data and features that tell variants apart. With the IT department we agree the approved devices, how the copy is updated and later maintenance of the app. These arrangements let us price a solution that fits the team's daily work.

Describe to us a product that is hard to find from a client's description, and the device used during visits. That is enough to start a conversation about scope, with no need to prepare the whole catalogue for hand-over. Pricing information is on the pricing page.

What offline catalogue search costs and when it pays back

The search runs on the device, so the scenario has no token or server cost.

Where to start

In the free process review we choose one process and count the team's volume and working time, and within 2 working days you get a written summary with a price. We build as part of AI apps, and we price maintenance separately.