How to add an AI sales assistant to a WooCommerce store that actually knows your catalog

storebird — Fri, 19 Jun 2026 12:25:33 +0000

You drop a chatbot on your WooCommerce store. A customer asks "do you have the blue one in size M, and is it in stock?" The bot replies with a cheerful, confident, completely useless answer. It has no idea what you sell.

That gap is the whole problem. And it has a clear technical cause.

Why do generic AI chatbots fail on a WooCommerce store?

Because they have no catalog context. A general-purpose LLM (or a no-code bot builder hooked to one) knows how English works. It does not know your 1,400 SKUs, today's stock levels, your shipping rules, or that order #10428 shipped yesterday.

When the model has no grounding data, it either deflects ("Please check the product page" — friction, lost sale) or hallucinates ("Yes, in stock!" — worse, because now you have an angry customer).

Neither is what a customer wants. They asked a sales question. To answer it, the assistant needs live access to two things: your product catalog and your order data. Getting that access right is the entire job.

What does "knows your catalog" actually require?

Three capabilities, in order of difficulty:

Product Q&A grounded in real data — answering "is this waterproof?" from your actual product descriptions and attributes, not from the model's training data.
Order lookup — answering "where's my order?" by reading the real order, verified so customer A can't read customer B's order.
Human handoff — knowing when to stop and route to a human, with full context, so the customer doesn't repeat themselves.

Let's take them one at a time, with the concepts a developer needs.

How do you ground answers in your product catalog? (RAG)

You can't paste 1,400 products into a prompt — you'd blow the context window and the bill. The standard approach is Retrieval-Augmented Generation (RAG): you index your catalog once, then at question time you retrieve only the few products relevant to the question and hand those to the model.

The indexing step turns each product into a vector ("embedding") and stores it in a vector database:

// Index step (runs in a queue when products sync/change).
// Each product becomes a searchable vector — done once, then incrementally.
foreach ($products->chunk(50) as $batch) {
    $texts = $batch->map(fn ($p) => implode("\n", [
        "Name: {$p->name}",
        "Price: {$p->price}",
        "In stock: " . ($p->stock_status === 'instock' ? 'yes' : 'no'),
        "Description: {$p->short_description}",
        "Attributes: " . $p->attributes_as_text(), // colour, size, material...
    ]))->all();

    // 'document' inputType for content being indexed
    $vectors = $embeddingService->embedBatch($texts, 'document');
    $vectorDb->upsert($websiteId, $batch, $vectors);
}

At question time you embed the question (note 'query', not 'document' — it matters for retrieval quality), pull the top matches, and only those go into the prompt:

$questionVector = $embeddingService->embed($userMessage, 'query');
$relevant = $vectorDb->search($websiteId, $questionVector, limit: 5);

$answer = $llm->complete(
    system: "You are a sales assistant for this WooCommerce store.
             Only use the products below. If unsure, say so — never invent stock.",
    context: $relevant,        // the 5 real products, with live stock
    message: $userMessage
);

Two non-obvious details that separate a demo from production:

Keep stock fresh. The embedding can be stale, but stock status must be read live (or re-synced on WooCommerce's woocommerce_product_set_stock hook). A woocommerce ai chatbot that confidently sells out-of-stock items destroys trust fast.
Constrain the model. "Only use the products below; never invent stock" in the system prompt is what stops hallucination. The retrieval gives it truth; the instruction makes it stay there.

How do you answer "where's my order?" safely?

Order status is the single most common support question on a store — a real woocommerce order tracking chatbot use case. The trap is security: order data is personal, so you cannot let a bot read any order from any visitor.

The pattern that works: require an order number plus a second factor (the billing email or postcode), and never put your WooCommerce API keys in the chatbot's cloud. Keep the credentials on the WordPress side and expose a single narrow endpoint:

// In your WP plugin — credentials stay on the store, not in the SaaS.
register_rest_route('yourbot/v1', '/order/lookup', [
  'methods'  => 'POST',
  'permission_callback' => 'yourbot_verify_signed_request', // shared secret
  'callback' => function (WP_REST_Request $req) {
    $orders = wc_get_orders([
      'limit' => 1,
      'search' => sanitize_text_field($req['order_number']),
    ]);
    $order = $orders[0] ?? null;

    // Second factor: the order number alone is NOT enough.
    if (! $order || strtolower($order->get_billing_email()) !== strtolower($req['email'])) {
      return new WP_REST_Response(['error' => 'not_found'], 404);
    }
    return [
      'status'   => $order->get_status(),      // processing / completed / ...
      'tracking' => $order->get_meta('_tracking_number'),
    ];
  },
]);

The assistant collects order_number + email, calls this endpoint, and reads back the real status. Because the verification happens on the store with the real billing email, one customer can't fish for another's order. If you'd rather use core WooCommerce, the same idea works against the wc/v3/orders REST endpoint — just keep the consumer keys server-side, never in the browser or the bot's prompt.

When should the bot stop and hand off to a human?

Always have an escape hatch. Refunds, complaints, anything emotional or high-value — route to a person. The detail that makes handoff good rather than annoying: pass the full conversation transcript and any order context to the human, so the customer never re-explains. A handoff that loses context feels worse than no bot at all.

Build it yourself or use a WooCommerce-native tool?

Now the honest part. Everything above is buildable — none of it is exotic. But "buildable in a weekend" and "running reliably for a year" are different sentences.

Build it yourself if: you want full control, you already run a vector DB and queue workers, and ongoing maintenance (re-embedding on every catalog change, prompt tuning, abuse handling, multilingual, the order-security edge cases) is a cost you're happy to own. It's a genuinely good project and the right call for some teams.

Use an off-the-shelf tool if: you'd rather ship this week and keep your time on the store. Popular options — Tidio, Gorgias, Intercom — are general e-commerce/support chat tools you bolt onto WooCommerce; the catalog-grounding is something you configure, not something native.

One option built specifically as an AI sales employee for WooCommerce (not a generic chatbot) is Storebird. It does the pattern above out of the box: embeds your catalog into a vector store for grounded answers, does verified order lookup through the WordPress plugin (so your WooCommerce keys never leave your store), and hands off to a human with full context. There's a free WordPress.org plugin if you want to wire it to a real store first — which is the only honest way to evaluate any of these: connect it to your catalog and ask it your hardest product question. If you've been hunting for a Tidio alternative for WooCommerce that treats the catalog as a first-class input, it's worth a look (short demo if you want to see the order-lookup flow first).

I'm biased toward the WooCommerce-native route because catalog-grounding is the hard 80% of the value and a generic bot makes you rebuild it. But the architecture is the real lesson — whichever route you take, judge any ai sales assistant for woocommerce on one question: does it actually know your catalog and your orders, or is it guessing?

TL;DR

Generic chatbots fail on WooCommerce because they have no catalog or order context.
Ground product answers with RAG: embed your catalog into a vector DB, retrieve the few relevant products per question, and constrain the model to those (read stock live).
Answer "where's my order?" with order number + a second factor, and keep WooCommerce credentials on the store, never in the bot.
Always offer human handoff with full context.
Build it if you want control and will own the maintenance; otherwise use a WooCommerce-native tool and spend your time on the store.

DEV Community: storebird