Chatbot Product Variants: How to Get Size, Color and Price Right

A chatbot handles product variants well when each variant is its own record in your catalog, linked to a parent product. It also has to ask for missing details before it answers, and it has to read price and stock from live data instead of guessing. Most failures come from skipping one of those three. Below is how to set each up, how to handle preorders, and how to test the result before shoppers see it.

TL;DR

• Give every purchasable variant its own ID, price and availability, and link variants to a parent product with a shared group ID.
• Make the bot ask for the missing attribute (size, color, material) instead of picking one for the shopper.
• Keep price and stock in one live source. The model writes the words, and your systems supply the numbers.
• Tell shoppers when a variant is a preorder or backorder, with the expected dispatch window.
• Test with real shopper questions, including vague ones, and decide in advance what the bot says when data is missing.

Table of Contents

• Why variants break chatbots
• Structure the catalog so every variant is identifiable
• Make the bot ask instead of guess
• Keep price and stock out of the model’s hands
• Keep variant data current
• What to say about preorders, backorders and lead times
• Test before shoppers do
• Our perspective: variants are a data problem first
• Setting this up with Konvuno
• FAQ
• Sources

Why variants break chatbots

A shopper asking “do you have the blue one in medium?” is asking about a single row in your catalog. A bot that only sees a product page may find the product, then answer for the wrong size, quote the price of the cheapest option, or say “in stock” because some variant is.

The trouble is that variants are often near-identical in name. A developer in a public discussion about retrieval-based bots describes exactly this: products that share almost the same title, where context decides which one the customer means. If your data lets two variants look the same, the model will mix them up.

Three questions cover most of the problem:

1. Can the bot identify each variant unambiguously?
2. Does it ask when the shopper has not said enough?
3. Does the price and stock it quotes come from a trustworthy, current source?

Structure the catalog so every variant is identifiable

The foundation is a parent-child relationship. Google Cloud’s retail documentation says variants should use a primary-variant structure, with a separate SKU for each purchasable variant. The same documentation notes that this hierarchy allows richer ranking and more diverse results than a flat catalog.

Feed specifications say the same thing in practical terms. OpenAI’s commerce product spec asks for a separate row for each purchasable variant, with a distinct item ID, the same group ID, and its own price and availability. Google’s Shopping data includes an itemGroupId field for grouping products, which is how a feed tells the world that a red medium and a blue large belong to one product.

A simple example

A t-shirt sold in three sizes and two colors is six purchasable items and one product group.

The figures are illustrative. The point is the shape: price and availability differ by row, so a chatbot that answers from the group alone cannot be right. A bot that answers from the item ID can.

Clean the titles and attributes first

Before you connect anything, audit the facts shoppers ask about: size, color, material, compatibility, pack count. Write them as separate attributes, not buried in a title like “Classic Tee - Blue/M - New”. Structured attributes are what let a bot tell variants apart and what let it notice that something is missing.

Make the bot ask instead of guess

When the shopper’s request does not narrow things down to one variant, the right move is a question. Firmly’s agentic commerce documentation recommends that a chatbot identify missing required attributes and ask for specifics like size, color or material before guessing. It also recommends that when a search returns several products, the bot show a short list of 3 to 5 items and ask for clarity if intent is ambiguous.

In practice, a good exchange looks like this:

Shopper: Do you have the Classic Tee in blue?

Bot: Yes, the Classic Tee comes in blue. Which size do you need: S, M or L?

Shopper: M

Bot: Blue, size M is $26.00. It is currently a preorder, so I can tell you the expected dispatch window. Would you like that?

Notice what the bot does. It confirms the attributes it already has, asks for only the one it lacks, and repeats the final choice (color, size, price) so the shopper can catch a mistake. A bad bot answers “Yes, $24.00, in stock” on the first turn, which is wrong on two counts.

Rules worth writing down

• Ask for one missing attribute at a time, in the order shoppers think about them.
• Offer the valid options only. If blue comes in S, M and L, do not invite “XL”.
• When two variants differ only in a detail the shopper has not mentioned, name the difference instead of picking one.
• Cap lists at a handful of options, then ask a narrowing question.
• Repeat the selected variant and its price before any hand-off to checkout or to a person.

Keep price and stock out of the model’s hands

Language models are good at conversation and unreliable at numbers they only half remember. The open-source ecommerce-catalog-agent project proposes a clear split: keep volatile price and stock in an authoritative database, use search indexes only for discovery, and re-fetch price and availability live before every answer. It adds a structured output contract in which the model supplies product identifiers and prose, and application code fills in the customer-facing price and stock from live data. That way a made-up figure never reaches the shopper.

A commerce data article makes the same case: to avoid ambiguity, bots need access to live systems for volatile data such as price and stock, not static index snapshots.

The division of labor is worth keeping in mind whenever you evaluate a tool:

The same logic that makes product data useful to shoppers also helps it surface in search. If you want the wider picture, this ecommerce AI SEO playbook covers how structured product information serves both search engines and AI answers.

Keep variant data current

A correct structure goes stale the first time a price changes. Two habits keep it fresh.

One master source. Webtures recommends one master inventory source, variant-level availability and frequent incremental updates. If your store, your marketplace feed and your chatbot each hold their own copy of stock, they will disagree.

Event-driven updates where available. Shopify’s developer preview of its newer Events system lets you use field-level triggers, such as a variant price change, to limit deliveries to relevant updates. It is a developer preview, so treat it as a direction rather than something to build on today. For most small shops, a scheduled feed sync is the practical answer.

That is the approach we took: Konvuno syncs product catalogs automatically from WooCommerce or any Google Merchant or Facebook product feed, so answers about products, prices and availability follow your store without anyone re-uploading a spreadsheet.

What to say about preorders, backorders and lead times

A variant that is not in stock is not always unavailable. The wording matters, and the bot should never treat a preorder as ordinary stock. Webtures recommends keeping preorder or backorder data separate, with an availability date, so an agent can communicate a lead time instead of treating a preorder as ordinary stock.

A design studio’s guidance on delivery messaging adds a useful distinction: separate when the customer may order, when the item is expected to dispatch, and when it may arrive, instead of squeezing all three into one vague phrase. The same note suggests labeling the status plainly as preorder or backorder, near the title, price or purchase button.

For a chatbot, that translates into a short answer template:

1. State the status of the exact variant: in stock, preorder, backorder or out of stock.
2. Give the dispatch window if your data has one, and say “expected” rather than promising.
3. Separate it from transit time, and mention that only if you know the destination.
4. Offer an in-stock alternative, such as another size or color, when one exists.
5. Say you do not have a date when the data has none, and offer a human.

Keep the date field in your data. A bot cannot tell a shopper “ships in about three weeks” if the only thing in the feed is the word “preorder”.

Test before shoppers do

Testing is where most small shops skip ahead, and it is where the real errors surface. One testing-focused write-up on ecommerce bots lists inaccurate recommendations as a leading failure, caused by outdated, incomplete or poorly integrated data, such as suggesting items that are out of stock.

A practical test set

Write 30 to 50 questions from your real inbox, search logs and past chats. Make sure the set includes:

• Fully specified: “Blue Classic Tee, medium, how much?”
• Underspecified: “Do you have the Classic Tee?”
• Near-duplicates: two products with almost the same name.
• Out-of-stock combinations: a size you know is sold out.
• Preorder variants: does the bot give a window and not call it in stock?
• Invalid options: a size or color that does not exist.
• Recent changes: raise a price in the store, wait for the sync, and ask again.

For each question, check three things: did it identify the right variant, were the price and stock correct against the store, and did it ask when it should have.

Decide what happens when data is missing

Write the fallback before you need it. If a variant has no price, no stock value or no matching record, the bot should say it cannot confirm that detail, point to the product page and offer to pass the question to a person. It should never fill the gap with a plausible number. Then review real conversations after launch: the questions visitors actually ask will show you the gaps your test set missed.

Our perspective: variants are a data problem first

We build Konvuno for owners who do not have a developer or a support team, so we see the same pattern often. People blame the AI when an answer is wrong, but the cause is usually upstream: a flattened catalog, a stale feed, a title that hides the size.

Our view is that you should fix the data once, at the source, and let the assistant inherit it. That is why we sync from the feeds and plugins stores already maintain, rather than asking you to rebuild your catalog inside another tool. It is also why we built a dashboard where you can configure and preview the assistant before paying, and read what visitors ask. Those questions tell you which variants confuse people, which attributes are missing, and which answers need a human.

We would rather the assistant say “let me connect you with someone” than guess a price. A handoff costs you a minute. A wrong quote costs you trust.

— Konstantin

Setting this up with Konvuno

If you run WooCommerce or publish a Google Merchant or Facebook product feed, Konvuno connects to it with one script tag and a hosted dashboard, with no developers and no per-seat pricing. The assistant answers from your catalog, FAQs and site content, captures leads into a built-in CRM and hands off to a human when needed. Plans are Starter at 29 EUR per month, Growth at 79 EUR per month and Business at 199 EUR per month, and every plan includes full conversational catalog capabilities. You can see them on the Konvuno plans page and preview your own setup before you pay.

FAQ

Do I need a separate product entry for every size and color?

You need a separate record for each variant someone can buy, grouped under one parent product. Each record carries its own ID, price and availability. That is what lets a chatbot answer for the exact size and color instead of the product as a whole.

What should the chatbot do when a shopper does not say which variant they want?

It should ask for the missing detail, one attribute at a time, and offer only valid options. If a search returns several similar products, a short list of three to five with a narrowing question works better than a long list. Guessing is the one thing it should not do.

How does a chatbot stay accurate on price and stock?

By reading them from a live source, such as your store or a regularly synced feed, rather than from the model’s memory. The model should write the explanation while the numbers come from your data. Frequent syncs from one master inventory keep the store and the chatbot in agreement.

How should a bot talk about preorder or backorder variants?

It should name the status plainly, give the expected dispatch window if your data has one, and avoid promising an exact arrival date. If there is no date, it should say so and offer a person or an in-stock alternative.

Sources

• About catalogs and products, Google Cloud retail docs
• Products, OpenAI commerce file upload spec
• Products API guide, Google Content API for Shopping
• Chat to Checkout, Firmly docs
• ecommerce-catalog-agent on GitHub
• Conversational Commerce Starts With Better Product Data
• One Inventory Truth for Agentic Commerce
• Next Generation Events in developer preview, Shopify
• How to communicate preorder and backorder delivery dates
• AI Chatbots in eCommerce: 5 Failures and How AI Testing Fixes Them
• Ecommerce AI SEO: A Playbook for Online Stores