Ecommerce Chatbot Playbook

Your Catalog Is the Product, and Two Readers Now Consume It (2026)

Quick answer: Most of the advice we see about ecommerce chatbots is advice about conversation: tone, flows, the order in which you move funnel steps into the thread. That advice is fine and we have published our share of it. It is also not where these projects fail. A support bot answers from a policy document that changes twice a year, while a store bot answers from a catalog that changes hourly, and every wrong price, wrong stock line and wrong delivery estimate it produces is a commercial promise you did not intend to make. The first question, then, is what the bot reads, how old that reading is, and what it does when it does not know. In 2026 there is a second reason to care, because the same product data can now be read by a second consumer: shopping agents that buy on a customer's behalf through a published feed. Reading that feed specification is the cheapest catalog audit available, and its most instructive detail is that price and availability are optional fields.

What this covers that our other two commerce guides do not

We have three pages in this cluster and they answer three different questions.

Our conversational commerce playbook answers a sequencing question: which funnel step to move into the thread first, and in what order the four moves should follow. Our abandoned cart recovery playbook answers a campaign question: timing, copy and the discount you should not lead with.

This page answers a data question. Given that you are going to put a bot in front of a catalog, what has to be true about the catalog, how do you find out whether it is true, and what should the bot do in the gap. It is the layer underneath both of the others, and it is the layer chatbot vendors have the least incentive to write about, because it is unglamorous and it belongs to whoever runs the store rather than to whoever runs marketing.

The constraint that makes ecommerce different

Every chatbot has a knowledge problem. Few have a knowledge problem that changes while the conversation is happening. A store bot always does.

Listen to what a shopper actually asks, in their own phrasing. Do you have this in a size ten. How much is it right now. When will it arrive if I order today. Can I return it if it does not fit. Is the discount code still valid. Four of those five have answers that can change between the moment your bot's index was built and the moment it replies. The remaining one, the returns question, changes only when somebody edits a policy page, which is a different problem with a different fix.

This is why the standard chatbot advice transfers poorly. A support bot that is a week out of date is slightly unhelpful. A store bot that is a week out of date sells things you do not have, quotes prices you have withdrawn, and promises delivery windows your carrier abandoned. Each of those is a customer-service incident that costs more than the sale it created, and in some markets a stated price a shopper relied on carries obligations beyond embarrassment.

The design conclusion is unpopular with anyone selling a five-minute setup: an ecommerce chatbot should read live data for the volatile claims and cached data only for the stable ones. A retrieval index over your site, which is how quick integrations typically work, is a snapshot. It is the right mechanism for the durable material and the wrong one for stock and price. Our entry on retrieval-augmented generation covers why grounding reduces invention without eliminating staleness — a grounded answer from a stale index is confidently wrong, which is worse than an ungrounded one that hedges.

Rank your claims by how fast they rot

Before wiring anything, sort what the bot will be asked to assert. The half-lives below are our judgment for a typical small store rather than a measurement, and you should adjust them to your own operation. The ordering has held on every store we have looked at.

Two rules fall out of the table. First, anything in the top four rows should either be answered from a live source or not answered at all — "let me check that for you" with a handoff beats a confident guess, and our confidence policy guide is the framework for deciding when the bot should decline. Second, the bottom row needs a process rather than a technology: when someone edits the returns policy, something has to re-index it, and on a small store that something is usually a person, and people forget. Put it on the same checklist as publishing the policy.

Use OpenAI's product feed spec as a catalog audit

Here is the part that is new this year, and it is useful whether or not you ever sell through an agent.

Through 2025 and 2026 a standard emerged for letting AI assistants complete purchases on a shopper's behalf. The Agentic Commerce Protocol is maintained by OpenAI and Stripe, published under Apache 2.0, and its repository describes the specification as being in beta. It uses date-based versioning; as of 17 August 2026 the latest stable snapshot is dated 2026-04-17 and covers, in the repository's own listing, "Cart, feed, orders, authentication, and MCP." Earlier snapshots run back to an initial 2025-09-29 release, with fulfillment enhancements, capability negotiation and payment handlers added along the way.

The part worth your attention is the product feed. OpenAI publishes its own schema, separate from the protocol repository, describing what a merchant should send so that products can be indexed with, in the specification's own words, "up-to-date price and availability." Read the requirement column and something jumps out.

In the three tables that decide whether a feed is accepted at all, which are the header, the product and the variant, the fields marked Required are the identifiers and the routing: feed_id, account_id, target_merchant, a target_country that "[m]ust be a valid two-letter country code," a product id that "[m]ust remain stable over time," a variants array, and each variant's id and title.

The fields marked Optional include price. And list_price. And availability. And url, description, media, barcodes, categories and seller.

Required does appear again inside the nested objects, and it is worth being precise about what it means there: Price will not accept an amount without a currency. That is a rule about how to write an object you have already chosen to send, not a rule about whether you have to send it at all.

So a document whose stated purpose is accurate price and availability does not require you to supply either. That is not a criticism of the schema. One that rejected a feed for a missing price would reject a lot of legitimate catalogs, the requirement column is about validation rather than about quality, and the spec says as much in its own prose: "Supplying all required fields ensures your products can be displayed correctly, while optional fields enrich relevance and user trust." What the requirement column does state very clearly is where the burden sits, and it maps exactly onto the burden your own chatbot carries.

Three details in the schema are worth copying into your internal checklist regardless of whether you ever submit a feed.

Availability is two independent fields, and they can disagree. The Availability object carries a boolean available and a separate status drawn from an enumerated list: in_stock, backorder, preorder, out_of_stock, discontinued. Both are optional. The description of status hints at a relationship, calling it the "[f]ulfillment state when availability is reported," but the Dependencies and Validation Rules columns are both empty, so nothing enforces it. A feed can therefore assert that an item is purchasable while also reporting it out of stock. If two fields in a published schema can contradict each other, the two systems inside your own store very likely can too, and the question of which one your chatbot reads has an answer you should know rather than assume.

Prices are integers in minor units. The Price object takes an amount that is an integer "expressed in ISO 4217 minor units" plus a three-letter currency code. The spec's own example is 7999 with currency USD, which is to say the shoe your store knows as 79.99:

{ "price": { "amount": 7999, "currency": "USD" } }

Integer minor units are the standard way to avoid floating-point rounding, and they are also the standard way to publish a price a hundred times too high or too low. Hand 79.99 to a field expecting minor units and you have advertised a seventy-nine cent pair of shoes; hand 7999 to a renderer expecting decimals and you have quoted eight thousand dollars. If your catalog stores decimals anywhere and your chatbot renders whatever it is handed, that conversion is a place to look before a customer finds it for you.

Identifiers must be stable, and small stores break this routinely. Both the product id and the variant id carry the validation rule "must remain stable over time." Re-generating SKUs during a platform migration, a re-photograph or a seasonal cleanup is routine on small stores and it silently orphans every downstream reference — reviews, analytics, saved carts, and any index your bot built. Stability is not a technical property here; it is an operating rule someone has to enforce.

There is a fourth detail worth a line. The Seller object can carry typed links, and the enumerated types are privacy_policy, terms_of_service, refund_policy, shipping_policy and faq. Those are the five documents a buyer is most likely to ask a bot about, named explicitly by a commerce schema. If you cannot produce five live URLs for that list today, your chatbot has been answering policy questions from something other than your policies.

What the second reader changes for a small store

It would be easy to over-read this. Agentic checkout is a beta protocol with two maintainers, its adoption among small merchants is not something we have measured, and we publish no forecast about how much retail volume will move through it. Nothing in this section is a recommendation to build an integration.

What we would say is narrower and, we think, hard to argue with. The data hygiene that makes a catalog legible to an agent is the same hygiene that makes your own chatbot truthful: stable identifiers, populated prices with correct units, an availability field that means one thing, and reachable policy URLs. That work has a return today, inside your own store, with no protocol involved. If agentic commerce turns out to matter for businesses your size, you will have done the prerequisite by accident. If it does not, you will still have a bot that stops inventing stock levels.

The second thing worth saying is a caution about attention. A store that has not fixed its returns policy page should not be reading protocol specifications, and the ordering of the build below reflects that.

Build order

1. Inventory your claims. Take the table above and mark which of the six rows your bot will be allowed to answer. It is entirely reasonable to launch with the bottom two and a handoff for everything else.
2. Find the live source for each volatile claim, or decide not to answer it. The major store platforms expose stock and price through an API or an app integration; our Shopify integration guide covers the three common wiring patterns. What it does not tell you, and what you have to ask the vendor, is how often each pattern refreshes. If there is no live source, write the decline into the bot rather than hoping.
3. Fix identifier stability before anything else. If SKUs move, everything downstream is sand.
4. Check units and currency end to end. Look at what your catalog stores, what your integration sends, and what the bot renders. Do this with a product whose price ends in something other than round numbers.
5. Produce the five policy URLs. Privacy, terms, refunds, shipping, FAQ. Put them where the bot can read them and add a re-index step to whatever process edits them.
6. Write the not-knowing behavior. What the bot says when stock lookup fails, when the price source times out, and when a question is outside scope. This is the single highest-leverage part of the build and it is usually done last or not at all.
7. Only then think about the funnel. Which conversation to move into the thread first is a real question with a real answer, and it is in our conversational commerce playbook.
8. Test the failure paths, not the happy path. Our QA testing protocol covers the general shape of a pre-launch test set, including its wrong-path and edge-case runs. The ecommerce-specific additions are yours to write: an out-of-stock variant, a promotion that ended last week, a price changed this morning.

Where it breaks

Treating the site crawl as the catalog. A crawl captures the page as rendered at crawl time, promotional banner and all. It will happily tell a shopper about a sale that ended in June.

Letting the bot recommend from an index rather than from stock. Product recommendation is the demo the vendor runs. A recommendation for something you cannot ship is worse than no recommendation, because it converts.

Assuming the platform integration refreshes. Some integrations sync on a schedule, some on webhook, some on install and never again. Find out which. Vendor marketing rarely distinguishes them.

Answering delivery questions with a single number. Carrier estimates are ranges that widen under load. A bot that says "two days" during peak season is generating refund requests on a two-week delay.

Confusing hallucination with staleness. They look identical to the customer and need different fixes. Our hallucination guide covers the first, and its content-fix loop reaches the edge of the second when it tells you to update a stale page and confirm the index re-synced. It stops there, reasonably. A catalog that changes hourly is not a page you can rewrite; it is a pipeline you have to query.

Skipping the human path for high-value carts. The economics of a handoff change with basket size. A shopper on a large order who cannot reach a person is a lost order, whatever the containment dashboard says.

FAQ

Related guides

• Conversational commerce playbook — which funnel step to move into the thread first, and in what order
• Abandoned cart recovery playbook — sequence, timing and the discount you should not lead with
• Chatbot Shopify integration — the common case for wiring live catalog data
• Build a chatbot knowledge base — what belongs in the cached half
• Reduce chatbot hallucinations — the invention problem, and the content-freshness loop that stops short of live catalog data
• Chatbot confidence policy — deciding when the bot should decline rather than guess
• Chatbot QA testing protocol — building the failure-path test set
• Conversational commerce (glossary) — the definition and which funnel steps chat can own
• Retrieval-augmented generation (glossary) — why grounding reduces invention but not staleness
• Abandoned cart recovery (glossary) — the definition behind the recovery playbook
• Best chatbot for ecommerce — our comparative assessment for online stores

Sources

• Agentic Commerce Protocol. Repository README, read 17 August 2026 — the source of every protocol fact on this page: that ACP "is an interaction model and open standard for connecting buyers, their AI agents, and businesses to complete purchases seamlessly"; that the specification "is maintained by OpenAI and Stripe and is currently in beta"; the Apache 2.0 license; the statement that "ACP uses date-based versioning in YYYY-MM-DD format" and that "Each version represents a complete snapshot of the specification at that point in time"; and the released snapshot list, 2025-09-29 (initial release), 2025-12-12 (fulfillment enhancements), 2026-01-16 (capability negotiation), 2026-01-30 (extensions, discounts, payment handlers) and 2026-04-17 (cart, feed, orders, authentication, and MCP), which the README's Quick Links table identifies as the latest stable version. github.com/agentic-commerce-protocol
• OpenAI. Product Feed Spec — Agentic Commerce, developer documentation, read 17 August 2026 — the source of every schema claim on this page, taken from the specification's own field tables. The page's stated purpose, "Provide a structured product feed so ChatGPT accurately indexes and displays your products with up-to-date price and availability," and its scope note that the reference "describes non-Ads Commerce product feeds." Required header fields feed_id, account_id, target_merchant and target_country, the last with the validation rule "Must be a valid two-letter country code." Product-level id, Required, with validation rule "Must remain stable over time," and variants, Required; product title, description, url and media all Optional. Variant id (Required, same stability rule) and title (Required), with price, list_price, unit_price, availability, barcodes, categories, condition, variant_options, media and seller all marked Optional. The prose statement that "Supplying all required fields ensures your products can be displayed correctly, while optional fields enrich relevance and user trust," quoted so that the schema's own framing sits alongside our reading of it. The Availability object's two fields, boolean available ("Indicates whether the variant is currently purchasable") and string status ("Fulfillment state when availability is reported") with supported values in_stock, backorder, preorder, out_of_stock and discontinued, both Optional, with both the Dependencies and the Validation Rules column empty for each. The Price object's amount, an integer "expressed in ISO 4217 minor units" with the example value 7999, and currency, a "Three-letter ISO 4217 currency identifier." The Link object's enumerated type values privacy_policy, terms_of_service, refund_policy, shipping_policy and faq. The observation that a specification whose purpose is accurate price and availability marks both fields Optional is ours, and is offered as a reading of the requirement column rather than as a criticism of the schema. developers.openai.com
• Ahrefs Keywords Explorer, US overview and volume-by-country, queried 17 August 2026 — the search-demand, difficulty, parent-topic and country-split figures in this page's keyword note, including the check that routed 'shopify chatbot' away from this page.
• Chatbotscape. Conversational commerce playbook and abandoned cart recovery playbook — the two sibling guides this page sits underneath. The sequencing-versus-campaign-versus-data split across the three is our editorial framing.
• Chatbotscape platform reviews — the four platforms in this page's related reviews are ones we have evaluated hands-on. We have run no comparative test of catalog-sync freshness or live inventory lookup across them, and this guide therefore contains no ranking for this use case.
• Chatbotscape evaluation methodology. /methodology (continuously updated).

About this guide

Chatbotscape launched in 2026 as an independent review site for chatbot platforms. This guide is part of our SMB chatbot Academy. It covers the data layer beneath an ecommerce chatbot: which product claims decay fastest and how each should be sourced, what a published agentic-commerce feed specification reveals when read as an audit of your own catalog, and the order in which to build so that the bot stops asserting things your store cannot honor. The funnel-sequencing half is in our conversational commerce playbook and the recovery half is in our abandoned cart playbook.

Methodology

Every protocol and schema fact on this page was read on 17 August 2026 from two primary sources, the Agentic Commerce Protocol repository and OpenAI's published product feed specification, and quoted from those documents' own text and tables rather than paraphrased from secondary coverage. The two are separate documents with separate maintainers: the protocol repository is maintained jointly by OpenAI and Stripe, while the product feed specification is OpenAI's own ingestion schema for non-Ads Commerce feeds. Every requirement level, enumerated value and validation rule quoted here comes from the second of those. Where a requirement level, an enumerated value or a validation rule is stated, it is the one printed in the specification's requirement, supported-values or validation column.

The editorial judgment on this page is listed here rather than flagged line by line: the claim that data freshness rather than conversational quality is the defining constraint on a store bot; the six-row decay table and its half-life estimates, which are planning judgments for a typical small store and not measurements; the rule that volatile claims should be answered live or declined; the reading of the feed spec's Optional markings as a statement about where the burden sits; the observation that available and status can contradict each other, which follows from both being Optional with an empty Dependencies and Validation Rules column despite the semantic relationship implied by the status description; the argument that agent-legibility and chatbot truthfulness require the same hygiene; and the eight-step build order. None of these is a claim made by OpenAI, Stripe or the protocol maintainers.

We have not built or submitted an agent-facing product feed for a live store, we publish no adoption, volume or forecast figures for agentic commerce, and we have run no comparative test of catalog synchronization across chatbot platforms. See our methodology for how platform facts are verified.

Last updated

18 August 2026.