Build an industrial catalog assistant like our demo

Watch the demo

The industrial catalog demo helps engineers move from a spec question to a buying decision. They can search by part number, rating or interface; compare parts; check stock and lead time; open a datasheet; and build a live quote without leaving the catalog.

This guide follows the build in the order that matters: index the evidence, make search the fast path, add tools for real actions, then test the result.

1. Index the pages and the documents

Create a memory dataset and capture product, category, specification and stock pages. Then include the product documents that contain the details a product card cannot.

Place each document on the relevant product page so the crawler can index it and return it as a source. Engineers ask about maximum ratings, current draw, reflow profiles and I²C addresses; those facts are usually in the PDF, not the marketing copy.

See Build a knowledge base and Configure data capture jobs.

“A correct number with the wrong datasheet behind it is still the wrong answer.”

2. Make the fast path a spec search

An engineer who knows the constraint should be able to type it and get a direct, cited answer. The homepage therefore leads with a Smart Search Center, while an application-engineer chat handles the deeper questions that need context or a back-and-forth.

Use a placeholder that teaches the query style: “Search by part number, spec, interface, package or category.” When search is empty, show featured parts so the homepage still reads as a catalog.

Use one knowledge base for both surfaces

The search experience and the chat are separate configurations, but they use one dataset. That keeps every fact consistent and lets you maintain a datasheet revision once.

• Keep sources aligned. Search and chat retrieve the same part information.
• Keep capabilities where they belong. Forms and linked services belong to the assistant; the shared dataset keeps their answers grounded in the same catalog.
• Keep the jobs distinct. Search is for a fast, cited answer. Chat is for the next question: “Which is cheaper at volume, and is it in stock?”

See Build a search center and Configure search center retrieval.

Give the assistant a precise role

Configure the floating Assistant as an application engineer for this catalog. Its behaviour should be unambiguous:

• Answer from indexed specifications and datasheets.
• Cite the part or document that supports the answer.
• Identify parts by their catalog identifier.
• Use a live action for a quote, stock check or selector instead of describing how to do it.
• State when the sources do not support an answer.

This is more than tone. A wrong voltage or torque figure is not simply a weak recommendation; it can lead to the wrong order. See Create an assistant and Launch an assistant.

3. Use suggestions that prove the catalog can answer

Technical suggestions should name real parts and real decisions. Each is a small promise the assistant needs to keep.

• 3.3 V I²C sensor for the CX-40
• Which modules are CE and FCC certified?
• CX-40 datasheet, stock and lead time
• Compare the CX-40 and the CX-08

These examples cover a spec search, compliance, document and availability lookup, and comparison. See Write useful search center suggestions.

4. Turn a question into a technical workflow

Text answers handle “What is the rating?” A part selection or purchase decision needs a few structured details. The demo collects them with short widgets inside the conversation.

Each widget is an assistant form with a trigger, fields and a submit action. Rich widgets use a WIDGET field: the template contains the markup, helper functions handle events, and a linked service provides the data.

// A helper wired from the widget markup (oninput="skdwn.instance.helpers.ikcCompareSearch(event)").
function ikcCompareSearch(event) {
  skdwn.instance.executeProxyRequest('part-search', {}, (res) => {
    const matches = JSON.parse(res.payload.reply).matches;
    renderCompareRows(matches);
  }, { query: event.target.value });
}

See Capture leads and use forms.

5. Connect live catalog actions

Use linked services for data that changes: selector results, price tiers, stock and lead time. The assistant calls each service by its ID, while the real endpoint and any credentials stay server-side.

Register each service with an ID, method and URL. Put per-call values in {{params.x}} placeholders:

part-quote  GET  https://your-site/api/quote?sku={{params.sku}}&quantity={{params.quantity}}

Return a small response the conversation can render directly:

{
  "reply": "**Quote VC-Q-560146** — 20 × CX-40 — **Total EUR 699** — lead time 4 days",
  "references": [
    { "title": "CX-40 Cortex-M4 Dev Board", "url": "/demos/industrial-catalog/product/cx40-dev-board" }
  ]
}

Use GET for exploratory widget lookups, such as typeahead, and POST for a deliberate form submission such as sending a quote request. Send a normal browser User-Agent from the service so a WAF does not quietly block the request. See Linked services.

6. Match the mode and appearance to the page

The same assistant should not present the same way everywhere.

Use per-page metadata for the description, suggestions and context. On a product page, keep a question tied to that part. On an account page, make room for a conversation about orders and quotes.

Match brand and accent colours, surfaces, text, buttons and the search masthead to the catalog. Style form fields as carefully as the widget shell so comparison and quote tools read as part of the product experience. See the appearance section of Launch an assistant.

7. Add the embed and buyer context

Load the runtime once, then start the search and the application-engineer assistant in their own containers.

<div id="seekdown-assistant-root"></div>
<script src="https://saas.seekdown.ai/js/seekdown-assistant.js"></script>
<script>
  // Spec search center and floating application engineer on the same page.
  skdwn.startAssistant({ assistantId: 'catalog-search', container: '#catalog-search',
    config: { settings: { baseTemplate: 'overlay' } } });
  skdwn.startAssistant({ assistantId: 'application-engineer', container: '#app-engineer',
    config: { settings: { floatingActionButton: { useFloatingActionButton: true } } } });
</script>

For the trade account, pass userId and concise additionalContext when the assistant loads. Every account-aware answer can then use that context, while the private lookup stays behind a linked service.

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

8. Test the evidence and keep it current

Test the catalog as an engineer would:

• Exact part numbers and specification constraints.
• Certification questions and document retrieval.
• A quote for a real quantity and a stock check.
• Unsupported requests.

For every result, check the answer and its source. A correct number that points to the wrong datasheet is still a defect.

After any catalog or document revision, verify the new fact in the source, the dataset and the assistant answer. Schedule captures to match the rate of catalog and datasheet changes.

Build the integration with an MCP client

The endpoint glue, widget helpers, embed and behaviour instructions are all suitable work for an MCP client such as Claude Code, GitHub Copilot or Codex. Give it a specific brief, then review the data contracts and results: “Find parts by spec, compare them, quote a quantity and check stock.” See Connect MCP clients.

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