What is a product feed?
It is a plain file with a list of products. Most often it is XML or CSV, stored at a fixed URL from which Google Merchant Center or price comparison sites such as Ceneo (a popular Polish comparison engine) download it. Each product has fields in it, from ID and price to availability and an image link. A chatbot can read from the same file.
CartBot loads a catalog in several ways. On WooCommerce, Shopify, PrestaShop and Shoper (a Polish store platform) it connects to the store API, so a separate product feed is not needed. In other stores it reads an XML or CSV feed from a URL, or a file you upload by hand, and it always sees the data from the last synchronisation, which runs on a schedule. A price change in the store therefore reaches the chat with a delay. A manually uploaded file stays as it was until you upload a new one.
Every variant needs its own stock level
Back to the jacket. The customer sees one jacket with three sizes on the page, but in the data there should be three separate items, each with its own ID and its own stock. The stock of the parent product is not enough to promise a particular size.
Open the export of the product with the most variants. Check whether every colour and size has its own ID and whether availability sits against each variant separately.
Then walk the whole route from question to cart. Write to the bot “red jacket in M”, add it to the cart and compare it with what shows up in the order. In CartBot, variant selection depends on the platform and the store theme, and sometimes the customer finishes it on the product page, so click through that path too. Finally, ask about a size you do not have, because the bot should know that before the customer adds anything to the cart.
How to check prices and variants before importing a catalog
Do not connect everything at once. Every import looks fine on simple products, so take a small sample with the hard cases:
- A product with several colours and sizes.
- An unavailable item.
- A product whose price you changed the day before, to see whether the import already has the new amount.
- Something made to order, with a longer lead time.
Compare the import with the store page
After the import, set each item from the sample against its product page, field by field. Prices and availability have to match, and for variants so do names and units.
If you already have a feed for Google Merchant Center or for Ceneo, you have a good starting point, because Google's documentation explains how to mark IDs and variants. Matching Google's format does not guarantee that another tool will read every field the same way, though. When you connect a tool, the fields need to be checked and mapped.
That leaves the question of who keeps the data fresh. The store generates a new file and the bot downloads it, so there are two places along the way where something can stall. Run a simple test. Change the price of one product and note how long it takes for the new amount to appear in the chat. That is roughly your delay, unless the synchronisation happens to fail.
Descriptions the bot can answer from
The bot has an instruction forbidding it to guess parameters. When a customer asks about the lining and the description only says “perfect for autumn”, the bot should admit it does not know. That is better than inventing something, but the customer still ends up without an answer.
Start with the products customers have already asked about and set their messages against the description, because the gaps are obvious then. For a spare part it is usually compatibility with a device, for clothing it is how the size is measured.
Write numbers with units. A bare “40” in a dimension field could mean centimetres, a size or forty pieces in a pack, and the bot has no way to decide, since it is not allowed to guess. If you copy data from a manufacturer, check that it applies to exactly your variant, including colour and size. Leave a missing parameter empty and mark it to be clarified, instead of entering a value typical of similar products.
Read the description without looking at the photos, too. A chat has no “above”, so a sentence about “the version shown above” needs to be replaced with the name of that version.
Store policies are data too
Return rules and delivery terms are usually not in the product catalog. The bot takes them from the store's knowledge base, meaning the text it receives at setup, which should contain delivery terms with prices and lead times and return rules that match your terms and conditions. Assign exceptions to specific goods. If you make something to order, the lead time for in-stock goods cannot be the default answer for that product.
Every time a policy changes, you fix two places at once, the page in the store and the bot's knowledge. Let one person do it.
A test with someone from outside the store
Give the prepared data to someone who does not know your products and ask them to answer a few real customer questions. You add nothing, even if you know from the manufacturer that the jacket has a detachable hood, and every spot where that person had to guess goes on a sheet of paper.
Then ask the same questions in the chat. Compare the bot's answers with the specific catalog fields, because a person and a bot can go wrong in different places, and only both tests together show where the data has holes. The list of guesses from the first test is a ready queue of description fixes for the coming week.