Build a retail store assistant like our demo

Watch the demo

The retail demo turns a store catalog into two helpful shopping experiences. Ask for “a gift for someone who loves the outdoors, under €60” and it returns a plain-language recommendation with real products and source links.

This guide explains the build in the order that makes the decisions easiest to follow: start with the catalog, choose the shopper experiences, add live data where it matters, and then test the result.

1. Start with the catalog

The catalog is the assistant’s source of truth. Create a memory dataset, then run a website capture job over the pages that answer genuine buying questions.

Include: product and category pages, size and fit guides, and shipping and returns help.

Exclude: cart, checkout, account and marketing pages. They add noise without helping the assistant answer a shopper’s question.

After the capture finishes, check a sample of records. Product names, prices, canonical URLs, size guidance and return details should all be present and readable. A duplicate navigation block or print stylesheet can weaken retrieval across the whole experience.

See Build a knowledge base and Configure data capture jobs.

2. Give each shopper intent the right surface

The demo uses two experiences because shoppers arrive with different needs.

The search center appears on the homepage and on its own search page. The floating chat stays available across the store. This keeps a quick product query quick, without making a shopper who needs advice start over in a search box.

Keep the knowledge base shared

The two experiences have different entry points, display modes and capabilities, but they use one dataset. That is intentional:

• Keep answers consistent. A product fact should not change depending on where someone asks.
• Maintain the catalog once. Re-index a change once and both experiences receive it.
• Add capabilities without splitting knowledge. The chat can use forms and live lookups while still answering from the same catalog as search.

Think of the knowledge base as the shared store record and the two experiences as different ways to access it.

“One catalog, two ways to help a shopper make a decision.”

Set a narrow, useful persona

The stylist is a personal stylist for this store, not a general-purpose assistant. Its behaviour instructions set the role and tone, then spell out the guardrails:

• Recommend only items that appear in the catalog.
• Cite the product being recommended.
• Do not claim a price or stock level that cannot be verified.
• Say so when the available information does not answer the question.

Add a name, avatar and welcome message that fit the store. Clear instructions and a focused role make the assistant more dependable than a vague “helpful assistant” prompt.

See Create an assistant and Launch an assistant.

3. Configure search for natural questions

Create a Smart Search Center on the shared catalog dataset. Unlike a keyword-only search box, it can return a reasoned answer alongside the product cards that support it.

Use a placeholder that invites a real question, such as “Find a gift, an outfit, or the right size…”. When the search is empty, show a short welcome message and featured products. The page then feels useful before a shopper has typed anything.

Make suggestions show real capability

Suggestions are product copy. Each one should lead to an answer the catalog or a live service can actually support.

• A gift for someone who loves the outdoors, under €60
• Put together a smart-casual outfit for under €150
• Which backpack is best for a rainy daily commute?
• Where is my order and when will it arrive?

Together, these examples show gifts, styling, product comparison and live account help. See Build a search center, Create a search center from website content and Write useful search center suggestions.

4. Use forms when a few details make the answer better

Text is enough for a direct question such as “Which backpack is best for a rainy commute?” Styling and sizing need a little more context. The demo uses short forms in the conversation to collect it.

For each form, configure three things: when to show it, the fields to ask for, and what happens on submit. A well-placed form turns an open-ended browsing question into a structured request without forcing the shopper through a long conversation.

See Capture leads and use forms.

5. Connect live actions for account questions

Catalog content answers what do you sell? Live actions answer where is my order?

Register each live lookup as a linked service. The assistant calls the service by a short ID; the real endpoint and any secret headers remain server-side, so they do not reach the browser.

The setup is deliberately small:

1. Give the service an ID, method and URL.
2. Use {{params.x}} placeholders for per-call URL values. They are URL-encoded.
3. Keep any secret in an authentication header.
4. Pass the service ID as proxyId from a form, or call it directly from a widget or button.

// Look up the signed-in shopper's order, then render the reply in the conversation.
skdwn.instance.executeProxyRequest(
  'order-status',            // the linked-service ID
  { orderId },               // request body (POST)
  (res) => renderReply(res), // endpoint response
  { locale: 'en' }           // fills {{params.locale}} in the service URL
);

Have the endpoint return a small, ready-to-render response: a markdown reply and a references list. That is simpler and more reliable than asking the assistant to format raw domain JSON.

See Linked services and Assistant forms.

6. Match the experience to the page

Match the assistant’s display mode to the page a shopper is on.

Use the base template (overlay or embedded) and the floating action button per page. Per-page metadata can provide a description, suggestions and extra context. On a product page, this keeps a simple question in place; on an account page, it makes the conversation relevant to the shopper’s orders.

Match the visual language of the store

Set the brand and accent colours, surfaces, text, primary button and search masthead to match the site. The appearance is configured on the entity and reaches the live embed independently of a site deployment, so you can tune it against the real page.

See the appearance section of Launch an assistant.

7. Add the embed and shopper context

Load the runtime once, then start the assistant in its container.

<div id="seekdown-assistant-root"></div>
<script src="https://saas.seekdown.ai/js/seekdown-assistant.js"></script>
<script>
  skdwn.startAssistant({ assistantId: 'your-assistant-id', accessToken: 'your-api-key' });
</script>

To use the store search and the floating stylist on the same page, give each a container and start each one with its own display settings:

skdwn.startAssistant({ assistantId: 'store-search', container: '#store-search',
  config: { settings: { baseTemplate: 'overlay' } } });
skdwn.startAssistant({ assistantId: 'stylist', container: '#stylist',
  config: { settings: { floatingActionButton: { useFloatingActionButton: true } } } });

For order questions, pass the signed-in shopper once when the assistant loads. userId and a concise additionalContext string are then available to every answer and to analytics.

skdwn.startAssistant({ assistantId: 'stylist', accessToken: 'your-api-key',
  userId: shopper.id,
  additionalContext: 'Signed-in shopper: ' + shopper.name + ', 2 open orders.' });

Before launch, generate an API key and add your site to the allowed origins. See Deploy an assistant, including allowed origins.

8. Build and maintain it with confidence

Most of this build is configuration plus a small amount of integration code. If you use an MCP client such as Claude Code, GitHub Copilot or Codex, it can work directly with your Seekdown workspace. It can help scaffold order and stock endpoints, write the embed, draft behaviour instructions and suggestions, and test the live assistant from a clear brief. See Connect MCP clients.

Test the questions shoppers will really ask

Test more than polished demo prompts. Include:

• Exact product names and broad requests such as “a gift for my dad”.
• Size and fit questions.
• Order-status questions.
• Questions about products you do not sell.

For every result, check both the written answer and the linked product. An answer with the wrong source is still a defect.

Keep the answer current

Set a capture schedule that matches how often the catalog changes. After a price, product or policy update, confirm the change in three places: the source page, the dataset record and the assistant answer.

Related: Build a knowledge base · Build a search center · Build an assistant · Linked services · Deploy an assistant · Connect MCP clients. For the technical-catalog version of this setup, see How the industrial catalog demo was built.