AI for E-commerce: Search, Support, and Merchandising That Stay Honest

AI on an e-commerce site is honest only when product answers come from the catalog you actually sell. Invented stock, prices, shipping times, or compatibility will create cancelled orders and chargebacks. The useful features are grounded search, support that cites policies, and merchandising that suggests items you have — not a chatbot that role-plays as a salesperson with a warehouse it cannot see.

The catalog is the source of truth

Every public answer about a SKU should be able to point at a product record: title, attributes, price, availability, shipping class, and the policy pages that apply. If the model cannot see that record, it must not state a number. That is stricter than general website chat, and it is the rule you want. Retrieval should query the same database or API the storefront uses, not a stale CSV from last season.

If you are still choosing how to operate the shop — inventory, returns, and payments — start with starting an online store. AI will not fix a catalog with duplicate SKUs, missing sizes, and policies that contradict the checkout. Garbage in, fluent garbage out.

Search and Q&A on product pages

On-site search is a better first AI feature than a sitewide bubble. Shoppers type like people (“will this fit a 2018 Civic rear seat”) while your nav is organized like a warehouse. A grounded assistant can retrieve matching products and the relevant attribute (dimensions, material, vehicle fit) and list them with links. If nothing matches, it should say so and offer filters or a human path, not a near-miss presented as a sure thing.

• Show the product title, price as currently stored, and a link; do not let the model reformat price as a “deal.”
• Pass availability as a field. “In stock” from last week’s embedding is a lie.
• For fitment, only answer if the catalog has a fitment table; otherwise send them to a guide or support.
• Respect catalog visibility: hidden, wholesale-only, and geo-blocked products must not appear.

Support that does not fight checkout

Return windows, customs, and delivery estimates belong in policy documents you retrieve by topic, plus order-specific data behind authentication. A guest asking “where is my package” should be sent to order lookup. A logged-in customer can get status from the order object. The bot should not scrape a carrier page unless you have a real tracking integration; guessed ETAs are worse than a tracking link.

Merchandising without fake scarcity

Recommendations can use catalog relationships you already maintain (similar, frequently paired, required accessories) and, if you have the data, collaborative signals. Generating “customers also loved” from a model with no purchase data is fiction. If you use a model to draft product descriptions, a human should approve them, and the facts (weight, contents, legal warnings) should still come from fields, not from the prose generator.

Feature	Grounding	Do not allow
Product Q&A	Live product record + spec fields	Invented compatibility or certifications
Policy chat	Current help center / shipping matrix	One-off discounts the bot “approves”
Size help	Size chart attached to the product	Body measurements guessed from a photo the user did not ask to process
Bundle suggestions	Defined relations or rules	Out-of-stock items presented as available
Review summary	Your actual reviews, with a date range	Made-up quotes

Checkout, payments, and what the model must never do

Do not let a chatbot complete a purchase by collecting card numbers in the chat window. Send people to checkout. Do not let it promise a price that is not in the cart. Coupons should be validated by the commerce engine. If you add an assistant in the cart, its job is to explain shipping options you already configured, not to negotiate. Payment security remains the processor’s cardholder-data job plus your account hygiene — the bot is not a till.

1. Block tools that can change orders, prices, or inventory without a staff role.
2. Log every catalog id the model saw for a given answer so you can reproduce a complaint.
3. Re-embed or re-fetch on product update; do not wait for a nightly job if you sell fast movers.
4. Localize only with catalogs and policies you actually maintain in that language.
5. Keep ordinary search as a fallback when the model is down; a store cannot depend on a single API for findability.

A sensible sequence for a live store

First, clean titles, attributes, and policies. Second, ship grounded search or a product-page Q&A with citations. Third, add policy chat with handoff to whatever inbox already runs the store. Fourth, consider draft descriptions and staff-only tools. Skip the homepage orb until the product-page answers are boringly accurate. A store that already struggles on mobile checkout should fix that path before adding another third-party script.

Scriplit builds catalog-grounded helpers as part of AI integration services, usually on Shopify or custom PHP shops where we can read live product data. If you want that scoped, send the platform, whether stock is reliable in the admin, and a few questions shoppers actually ask, via the AI integration contact form. Screenshots of a messy product record are useful; they tell us whether AI is the next step or whether the catalog is.