How-To: Build Conversational Search for a Storefront

Conversational Search helps shoppers describe what they need in natural language, answer a few useful follow-up questions, and receive products directly in the conversation. It combines the flexibility of an AI language model with the catalog awareness, filtering, personalization, and relevance of Relewise Search.

This guide presents a reusable approach for adding Conversational Search to any storefront. It focuses on the responsibilities, decisions, and implementation phases rather than a specific programming language or AI provider.

Implementation responsibility

Conversational Search is not a ready-made Relewise endpoint, hosted AI service, or storefront component. It is a custom experience that you build and operate on top of Relewise. Your implementation connects an AI model to Relewise Search and owns the conversation, orchestration, prompts, and user interface.

What Relewise provides and what you build

Relewise provides the product search, filtering, personalization, merchandising, and catalog metadata used by the experience. Your application converts the shopper's conversation into a structured Relewise search request and renders the returned products.

You build and operate:

• The storefront conversation interface.
• A server-side orchestration endpoint.
• The integration with your chosen AI model or provider.
• Planner instructions, structured output validation, and fallback behavior.
• Conversation state, security, monitoring, and evaluation.

Relewise remains the source of product results and relevance. Relewise does not host the conversational flow or call the AI model on your behalf.

What you are building

Conversational Search is not a general-purpose chatbot. Its purpose is to turn an incomplete or conversational shopping request into a well-formed Relewise search request.

A successful experience should:

• Understand the product the shopper is looking for.
• Ask only questions that can materially improve the results.
• Preserve useful requirements across multiple messages.
• Convert hard constraints, such as a maximum price, into Relewise filters.
• Produce a concise search term instead of sending the conversation transcript as a query.
• Return products with the properties required by the storefront's existing product component.
• Let the shopper refine the current results without starting over.

Reference architecture

                              Catalog structure
                              and available data
                                      |
                                      v
+------------+    message    +-----------------------+    context    +------------+
| Storefront | ------------> | Custom orchestration  | ------------> | AI planner |
| overlay    |               | API and state         | <------------ |            |
+------------+               +-----------------------+    decision    +------------+
      ^                                  |
      |                   +--------------+---------------+
      |                   | Ask follow-up                | Search
      |                   v                              v
      |           Assistant response          Structured Relewise request
      |                   |                              |
      |                   |                              v
      |                   |                    +--------------------+
      |                   |                    | Relewise Search API |
      |                   |                    +--------------------+
      |                   |                              |
      +-------------------+------------------------------+
                         response or products

The storefront, orchestration API, and AI planner are parts of your implementation. The important boundary is between planning and searching: your AI planner interprets the conversation and proposes a structured decision, while Relewise executes the actual product search and remains responsible for relevance, personalization, filters, and merchandising.

Responsibilities

Component	Responsibility
Storefront (you build)	Opens the conversation, sends messages, renders replies and products, and retains the current conversation state.
Orchestration API (you build)	Validates the request, coordinates the planner and Relewise, and returns a stable response contract.
AI planner integration (you build)	Decides whether to ask a follow-up question or search, condenses the product intent, and identifies structured constraints.
Relewise	Executes the product search with the correct User, Language, Currency, filters, selected properties, and result count.
Catalog metadata	Helps the planner ask questions that are relevant to the fields and values available in the current Dataset.

Step 1: Define the storefront experience

Start with a focused user journey before choosing an AI model or writing prompts.

Decide:

• Where shoppers can enable or open Conversational Search.
• Whether it complements or replaces the normal search field.
• How many products to show for each search.
• How products should appear inside the conversation.
• How a shopper starts a new conversation.
• What happens when the AI service or Relewise is unavailable.

Reuse the storefront's existing product tile or product card. The same component should render prices, images, Variant information, badges, links, and tracking consistently across conventional and Conversational Search.

Step 2: Establish a stable API contract

Place the orchestration behind a server-side endpoint. The storefront should send the current message together with the conversation state and shop context. The server should return:

• A response kind, such as follow-up, results, or error.
• An assistant message when one is needed.
• The updated conversation state.
• Relewise Product results when a search was performed.
• An optional context bag with safe, display-oriented information about the decision.

The request should also allow the storefront to specify selected Product and Variant properties. This lets Relewise return products that are ready for the existing UI to render, without a second product lookup.

Keep Dataset credentials on the server or pass them only through a trusted server-to-server boundary. Never expose privileged API Keys through public diagnostics or conversation context.

Step 3: Keep structured conversation state

Do not build the next query by appending every message. A transcript such as "gaming gift nephew try again too expensive" is not a useful product search term.

Maintain a small structured state instead:

• The shopper's original request.
• Audience or use case.
• Product interests and requirements.
• Budget or maximum sales price.
• A condensed search term.
• The message history needed by the planner.

Each planner response should update this state. Later refinements should replace or amend the relevant fields rather than adding conversational phrases to the search term.

Step 4: Give the planner catalog awareness

Generic follow-up questions often produce a poor shopping experience. A question such as "What matters most?" gives the shopper little guidance and may not relate to the available catalog.

Provide the planner with a compact description of the current Dataset's catalog structure and available Product data. For example, include relevant category names, brands, and commonly populated data fields. This can be obtained from catalog metadata or taxonomy information and cached because it changes less frequently than conversations.

Catalog awareness helps the planner ask questions such as:

• Which size and fit do you prefer?
• Is this for everyday use or a specific activity?
• Do you have a preferred screen size or refresh rate?
• Are there dietary requirements?

The planner should use catalog metadata as guidance, not as a fixed list of product-type strategies. The same planning flow should work across technology, clothing, food, beauty, home, sports, and other retail segments.

Step 5: Ask only high-value follow-up questions

Instruct the planner to choose between two actions:

1. Ask one specific follow-up question.
2. Search with the information already available.

A follow-up question is useful when the answer is likely to change which products should be returned. Product type, intended use, recipient, size, compatibility, and maximum price are common examples, but none should be universally required.

Set clear stopping rules:

• Do not repeat a question that the shopper has already answered.
• Do not ask for information the catalog cannot use.
• Search once the product type and the most important differentiator are known.
• Search immediately when the shopper explicitly asks to see products.
• Reply in the same language as the shopper whenever possible.

The goal is not to collect every possible preference. It is to gather enough information to improve the first useful result set.

Step 6: Produce a clean search plan

The planner should return structured output rather than prose that the application must interpret. A search decision should contain:

• The action to take.
• The assistant's next message.
• A concise search term.
• Updated audience and requirement fields.
• Structured constraints, such as a maximum sales price.

The condensed search term should contain product nouns, useful synonyms, attributes, brands, model names, and relevant use-case terms. It should exclude:

• Budget wording and currency.
• Conversation labels such as "refinement."
• Retry phrases such as "try again" or "show me more."
• Sentences about previous products being too expensive.
• Recipient details that are not real product terms.

Treat the planner output as untrusted input. Validate required fields, handle malformed responses, and provide a deterministic fallback so a temporary AI failure does not leave the shopper in a broken loop.

Step 7: Translate constraints into Relewise requests

Use the condensed product intent as the Relewise search term. Translate constraints into the corresponding Relewise filters or request settings instead of leaving them in natural-language text.

Shopper requirement	Relewise request behavior
Maximum price	Apply a ProductSalesPriceFilter with the current Currency.
Brand, category, size, or another exact field	Apply a filter when the requirement maps reliably to catalog data.
Preference that should influence relevance	Keep it in the condensed search term.
Number of products to display	Set a fixed result count appropriate for the conversation UI.
Product data needed by the UI	Set selected Product and Variant properties on the search request.
Shopper identity	Pass the current Relewise User to preserve personalization.

Avoid converting uncertain statements into hard filters. A hard filter can remove otherwise relevant products, while a good search term still allows Relewise to rank alternatives.

For more information, see Search, Filters, and Faceting.

Step 8: Render results inside the conversation

Return Relewise Product results in the same response as the updated conversation state. Render them as part of the assistant's message history instead of navigating the shopper away from the conversation.

The conversation should remain open after results are shown. This lets the shopper refine the search naturally:

• "Can they be cheaper?"
• "Only show black ones."
• "I would prefer a smaller size."
• "These are for outdoor use."

Keep the input focused after each response and scroll to the beginning of the new assistant response. This makes multi-turn refinement feel continuous, especially when a response contains several product tiles.

Step 9: Add safe observability

Conversational Search is easier to improve when solution architects can inspect the effective search plan. Consider returning an optional context bag containing values such as:

• Planning action.
• Search term sent to Relewise.
• Applied sales price filter.
• Audience or use case.
• Interests and requirements.

Show this information behind an optional context control rather than in the normal shopper flow. Do not include secrets, full prompts, internal credentials, or unnecessary personal data.

Operational logging should distinguish between AI planning failures, invalid planner responses, Relewise authorization failures, and valid searches with no matching products.

Step 10: Test across retail segments

A Conversational Search flow can appear successful while being overfitted to one product type. Build an evaluation set that covers different catalogs and shopping behaviors.

Include scenarios for:

• Technology with specifications and compatibility requirements.
• Clothing with size, fit, style, and occasion.
• Food with dietary requirements and use occasions.
• Beauty with concerns, ingredients, and preferences.
• Home products with dimensions, rooms, and materials.
• Gifts with recipient, age, interests, and budget.

For each scenario, verify:

• The first follow-up question is specific and useful.
• The planner stops asking questions at the right time.
• The search term contains product intent rather than transcript noise.
• Numeric price constraints become filters.
• The results match the requested product type.
• Refinements update the existing intent instead of replacing it accidentally.
• Responses stay in the shopper's language.

Rollout approach

Introduce the experience in controlled phases:

1. Internal evaluation: Test curated conversations against representative Datasets and review the generated search context.
2. Optional storefront mode: Let shoppers choose between conventional and Conversational Search.
3. Limited production rollout: Enable the experience for a subset of traffic or selected markets.
4. Measure and refine: Compare search engagement, product clicks, zero-result searches, conversion, latency, and abandonment.
5. Expand carefully: Improve planner instructions and catalog context based on observed failure patterns rather than adding product-specific rules.

Continue using normal Relewise behavioral tracking for products displayed and selected through the conversation. This preserves the feedback signals used by personalization and analytics.

Common pitfalls

Sending the transcript as the search term

Conversation history contains corrections, social language, and previous constraints. Condense it into current product intent before searching.

Asking a fixed questionnaire

Different catalogs need different details. Let the planner choose one high-value question based on known context and catalog data.

Encoding every preference as a filter

Filters are appropriate for reliable hard constraints. Keep softer or uncertain preferences in the search term so Relewise can rank useful alternatives.

Letting the AI rank or invent products

The AI should plan the search, not replace the search engine. Always retrieve actual catalog products through Relewise.

Building a separate result UI

Reuse existing product components and tracking behavior. A separate rendering path quickly becomes inconsistent with the rest of the storefront.

Hiding the effective request

A small, safe context view helps teams understand unexpected results and improve the planner without exposing technical details to every shopper.

Summary

Conversational Search requires a custom storefront, orchestration layer, and AI integration built on top of Relewise. A strong implementation has a clear division of responsibility: your AI planner turns conversation into structured intent, while Relewise executes the real product search. The storefront keeps the interaction familiar by rendering existing product tiles directly in the conversation and allowing immediate refinement.

Start with a stable API contract, catalog-aware follow-up questions, structured conversation state, and explicit filter mapping. Then evaluate across multiple retail segments and improve the shared instructions based on observed behavior instead of accumulating product-specific strategies.

For the wider Relewise implementation journey, see Implementation Steps and the Relewise Demo Shop.