AI chatbot for an online store: where search breaks
A customer searches for “a jacket that won't get soaked in the rain” or “a case so the phone doesn't overheat in the car” — and gets empty results. The catalog contains name, SKU, and attributes, not the words people use to describe a need.
Exact word match search doesn't find such queries, and the share of zero-result searches grows unnoticed: first at single-digit percentages of traffic, then on a noticeable portion of queries.
The cost of such results is higher than it seems. The customer doesn't just close the tab — they go to a competitor or write to chat, and the question moves to first-line support.
The load on first-line support grows mainly due to repetitive questions: “do you have…”, “will it fit…”, “what's the difference…”. The operator manually answers what search should have shown.
Expanding the synonym dictionary and adding keywords to product descriptions helps only partially — as long as formulations repeat. Search over product descriptions tied to exact words doesn't handle typos, different word order, mixed languages, and everyday category names.
The catalog grows, dictionaries become outdated faster than they can be corrected, and the rule “add another synonym” stops scaling.
Semantic catalog search removes the gap between query and product: both are compared by meaning, not by letters, so results don't depend on whether the customer guessed our internal name for the item.
Below we break down how this is closed and what exactly changes in search, product cards, and first-line work.
What semantic search and a conversational assistant provide
Semantic search begins with each card getting a vector representation — by name, attributes, category, and review texts.
A query like “need running shoes for asphalt, non-slip” is encoded into the same space, and results are ranked by semantic similarity, not by word matching in the name.
This removes a whole class of “nothing found” failures: product selection by free-form description works even where the customer doesn't know the exact model.
We keep indexes next to the catalog: PostgreSQL with a vector search extension allows updating the product representation in the same transaction as the card itself.
Catalog and search index don't diverge — a discontinued size disappears from results immediately, not after the next rebuild.
The conversational assistant sits on top of this search and handles clarification: purpose, size, compatibility with already purchased items.
The answer is assembled only from found cards and approved texts, so invented specs don't appear in the answer — the risk is closed at the data source level.
The second half of the effect — support. Typical requests (delivery status, return terms, compatibility) are closed without an operator, and people switch to non-standard cases.
At launch we look at three numbers: share of orders placed through dialogue, product selection time from first query to cart, and catalog search conversion.
Solution formats: catalog search, assistant, hybrid
Simple word search relies on exact match: the customer enters the name from the card — and gets a result.
As soon as the query becomes descriptive (“warm sweater for winter”, “gift for a child under three”) or contains a typo in the SKU, results empty out, and some visitors leave without reaching the cart. We break down which schemes are used in practice and where each one's limits lie.
| Option | When it fits | Limitations |
|---|---|---|
| Word search | Catalog is small, product names match customer wording, predictable results matter | Doesn't understand synonyms, typos, descriptive queries; share of empty results grows with assortment |
| Search based on a knowledge base | Catalog from several thousand SKUs, there are filled cards, instructions, reviews — answers assembled from them | Requires base preparation: markup, chunking, regular index updates. Without it, assistant confidently answers wrong |
| Ready cloud platforms for assistant | Need launch in a few weeks and no in-house team for ongoing support | Weak integration with accounting systems and warehouse stock, limited logic customization to own rules, dependence on vendor policy |
| Hybrid search and dialogue scheme | Large catalog, non-standard questions, need both precise selection and detail clarification in dialogue | More expensive to develop: two loops, quality evaluation on live traffic, constant monitoring and retraining on new queries |
The choice is dictated by three things: catalog size, data quality in cards, and who will maintain the index after launch. Where word search loses a noticeable share of queries, the hybrid scheme pays off.
Work stages: audit, scheme, setup, acceptance
Each stage ends with a result that can be checked on store data. So we start with an audit of actual queries, not guesses about what customers ask.
- Search query audit. We export the site search log and support requests: where results are empty, which formulations don't find the product — synonyms, typos, SKUs, everyday names instead of catalog ones.
- Catalog analysis. Card and attribute structure, availability, stock: what needs to be supplemented so the bot answers based on fact, not general description.
- Catalog integration scheme. How current data arrives, how often the knowledge base updates, what happens when a product is discontinued or export fails. Failure points and bot behavior in them are fixed in advance.
- Answer and escalation rules. What the bot has no right to invent, under what conditions it transfers dialogue to an operator, separate branches for delivery, payment, and warranty.
- Answer quality check. Set of reference questions with expected answers and runs on it: share of correct hits, share of honest “I don't know” instead of fabrication, response time.
- Acceptance on real traffic. Shadow mode on part of visitors, comparison with current search, manual labeling of disputed dialogues — before full enablement.
- Handover of control. Documentation, metrics panel, knowledge base replenishment procedure, and rollback to previous version.
After acceptance, your team has a regulation: how to add categories, how to check new answers, and where to look if quality drops.
Deliverables: configurations, schemes, regulations
The project ends not with a dialogue demo, but with a set of artifacts the customer's team works with without us. Everything we configured during work is transferred to the repository and internal knowledge base: configurations, schemes, policies, regulations. Below — what exactly remains in hand and how to use it.
- Working assistant configurations — dialogue scenarios, system instructions, escalation rules to operator, confidence thresholds. Deployed in a clean environment with one run, without manual edits.
- Integration scheme with accounting system — exchange map: which entities (availability, prices, order statuses) are read from where, at what frequency, what happens when the source is unavailable. Diagram plus description of failure points and behavior during desync.
- Data access policies — role separation, what the assistant sees from the customer card and order history, what is masked in contact logs. Separate block — rules and retention periods for correspondence.
- Knowledge base update regulation — who and how loads new articles, in what format, how answer quality is checked after update, how an unsuccessful search index version is rolled back.
- Assistant documentation — solution architecture, domain entity dictionary, list of scenarios, instructions for support operator and content manager.
- Set of checks — test questions with expected answers; a run before each knowledge base update shows which topics the assistant stopped covering.
- Handover plan — session with customer team, review of typical incidents, issuance of accesses and roles, escalation procedure for the support period.
After handover, the assistant can be developed in-house: scenario edits or knowledge base replenishment don't require us as intermediary.
Case study: assistant for a catalog with several tens of thousands of SKUs
Launched an assistant on a catalog of about forty thousand SKUs: tools, consumables, compatible SKUs. Before that, search worked by exact word match, and queries like “attachment for an old rotary hammer” went to an operator — the client either waited or closed the cart.
What we measured and what changed
| Metric | Before | After |
|---|---|---|
| Queries where no SKU was found | 27% | 6% |
| Requests closed without operator | 14% | 68% |
| Average product selection time | 4 min 20 s | 35 s |
| Results with irrelevant first card | 31% | 9% |
The assistant answers not “from the head” of a language model, but by assembling facts from cards: name, SKU, compatibility, stock. Results are hybrid — lexical search plus vector semantic matching, on top reranking with purchase history.
If confidence is below threshold, the bot doesn't invent a product, but clarifies the query or transfers the dialogue to an operator.
Elasticsearch holds both the lexical index and vector representations in one cluster — no need to synchronize two databases and catch desync when updating stock.
Implementation into production took six weeks: two — for collecting and labeling query–product pairs from logs, two — for setting up search and reranking, the rest — for evaluation on a holdout sample and controlled enablement on part of traffic with daily error review.
What to do if the chatbot is already built on a ready platform
The ready platform doesn't need to be thrown away — it remains the channel and dialogue framework, only the layer that prepares the answer changes. The bot stops searching for keyword match and starts going to the catalog: first for product facts, then for wording.
If it works in Telegram, the message handler is replaced — menu, buttons, entry points remain in place.
Approaches to answers are compared by question type, not “which is more modern.” Delivery, payment, return, and warranty are more reliably kept on hard templates — the wording is agreed once, and it won't drift.
Semantic search is connected where the question is about the product: compatibility, model differences, availability of the needed size. The result is not one approach instead of another, but three levels, and each works on its own class of requests.
The catalog is connected via export from the accounting system: SKU, characteristics, availability, compatibility. Descriptions are indexed less often, stock and statuses are pulled in a separate stream so the bot doesn't answer from an outdated card.
If confidence is below threshold, the question goes to a template or live operator — an invented product is worse than “I'll check with the manager.”
Migration of scenarios to the new scheme is done step by step: inventory branches, mark which remain hard and which become a hint for the model, run accumulated dialogues and compare answers. What breaks — stays on the old engine until fixed, we switch by groups of questions.
Contact history is stored with the user identifier, and each answer is logged with source: catalog card, template, or operator.
Technical doubts: questions before project start
Before project start, customers ask the same practical questions — and these are right questions. Below — short answers to four technical doubts that most often surface at the solution evaluation stage.
What if the customer writes a query with a typo or in different words?
The search layer compares not strings but the meaning of the query, so typos, cases, and synonyms (“sneakers” / “trainers” / “sport shoes”) lead to the same results.
On top of that we maintain a dictionary of domain synonyms and trade names, replenished from zero-result query logs.
How does the assistant answer if the product is out of stock?
It doesn't invent availability: the answer is assembled only from catalog data. If the SKU is absent, the bot states it directly and offers close analogues by category, price, and characteristics or signs up for restock notification.
Where do current stock and prices come from?
Stock and prices are pulled from the store accounting system — on schedule and on event when warehouse data changes. Cards and related answers are reassembled on update, so the bot doesn't sell what's already gone.
How do you control assistant answer quality?
We collect dialogue logs and label a sample by three metrics: share of answers without source support, share of requests that went to operator, and share of unanswered queries.
Based on these numbers we adjust assistant instructions, search index composition, and threshold for transfer to a live manager.
Let's discuss the task and come back with an estimate and work plan
So that the assistant estimate relies on your data, not average assumptions, it's useful to send a catalog slice and anonymized search logs for a month. Nothing closed is needed — structure of fields, export, and description of scenarios the bot should cover is enough. Then analysis of current search and calculation of work scope go by fact, not by feel.
What is useful to prepare and what we'll review on the call:
- catalog export: categories, attributes, product variants, availability — they are used to build the semantic index and choose card chunking strategy;
- search logs: share of zero-result queries, wording length, typos and synonyms — show where current search loses the customer;
- how search works now: ranking rules, synonym dictionaries, filters and sorting — so as not to break what works;
- integration points: catalog, warehouse, support service, contact channel — determine composition and order of stages;
- constraints: personal data, access rights, requirements for storing dialogue history;
- reference questions: 20–30 typical requests with expected answer — basis for quality checks;
- acceptance criteria: share of correct answers, share of refusals, response time — fixed before start.
Describe the task in free form — we'll come back with an assistant project estimate and a stage-by-stage work plan: from search analysis and data preparation to channel connection and documentation handover.
