What It Actually Takes to Put an AI Shopping Assistant on Your Store

Deploying an onsite AI shopping assistant is a catalog project wearing a widget costume. The chat interface is the easy part, which is why timelines quoted in this category vary from two days to two months without anybody being dishonest.

These are the nine questions that decide which end you land on. They come from evaluation calls we have run with retailers this year, reported in aggregate.

1. Do you need new APIs, or wrappers around the ones you have?

Almost every retailer already has what is needed: catalog, inventory, cart and checkout endpoints. What is usually missing is a consistent shape. The integration work is a thin wrapper that returns standard JSON, not a rebuild.

Ask a vendor directly whether they need a deep dependency on your stack or just those four surfaces behind a documented contract. If it is the latter, the engineering ask on your side is days, and it is reversible. If a vendor wants to sit inside your checkout, that is a different risk conversation.

2. How many attributes does each product need?

This is the variable that actually sets the timeline.

An assistant narrows by constraint. To answer a question about occasion, recipient, colour, compatibility or personalisation, those have to exist as fields, not as prose in a description. Catalogs we have scoped run from a dozen usable attributes per SKU to around seventy for categories where the buying decision is highly conditional.

Two things to settle before you sign:

One-time or ongoing? The bulk enrichment is one-time. The sync as new products land is forever, and it needs an owner on your side.

Can you get the enrichment back? You are paying for structured attributes that also decide whether ChatGPT, Gemini and Alexa for Shopping can recommend you. If the enriched attributes only live in the vendor's index, you are renting your own product data. Ask for an export path in writing.

3. Is your inventory location-bound?

If availability or delivery varies by postcode, the assistant must collect the location before it recommends anything. Not at checkout. Not as a validation step afterwards.

An assistant that recommends first and checks deliverability second produces the worst possible shopper experience: a confident recommendation followed by a refusal. It is also one of the six failure modes we catalogued in how to stop an assistant recommending out-of-stock or wrong-variant products, and it is the one that cannot be patched later without redesigning the conversation.

Make the location question step zero, and make it feel like service rather than a form.

4. Who holds the semantic index, and who owns the catalog?

These are two separate questions and vendors often answer only the first.

The vendor typically hosts the vector store, because that is what makes retrieval fast. Your catalog should remain the source of truth, with the index rebuilt from it. That arrangement is normal and fine. What is not fine is an arrangement where the enriched, structured version of your catalog exists only inside the vendor and cannot be retrieved.

5. How deep does the recommendation logic go?

This is where the difference between vendors actually lives, and it is the hardest thing to assess in a demo.

A shallow implementation retrieves semantically similar products and lets the model write a sentence around them. A deep one applies hard filters for availability, price bounds, market eligibility and variant state before the model sees any candidates, and it reasons over the constraint the shopper actually stated.

Test it adversarially rather than watching a scripted demo. Ask for a product that is sold out in the size you want. Ask with a hard budget ceiling. Ask for something your catalog genuinely does not stock. The third one is the most revealing: a good assistant says so.

6. Is post-sale support in scope?

Pre-sale is sizing, shipping and returns policy. Post-sale is order tracking and refund status, and it is a different integration: it needs live order state and an identity check, not a catalog feed.

Buyers raise this unprompted in almost every conversation we have, and several products in this category quietly stop at pre-sale. Get the answer before pricing, because it changes which team owns the tool internally.

7. What is the support SLA when it breaks?

Split it in two, because one number covers two very different failures.

Critical is the assistant down, checkout broken, or something wrong in front of shoppers. Hours, not days. A reasonable bar is one to two hours to response.

Long-tail is a bad recommendation, a data issue, or a question answered poorly. That needs investigation against logs and a day is a reasonable target. Insisting on a one-hour SLA here buys a fast reply rather than a fix.

8. What do you measure, and against what?

Agree this before launch, because it is much harder to define a baseline afterwards. Three metrics, and the second is the one people get wrong.

Sitewide conversion rate. Not engaged-visitor conversion. The two get conflated constantly and the gap between them is the single biggest source of inflated claims in this category, which we set out in the conversion-claims audit.

Engagement rate, defined as shoppers who interact with the assistant as a share of all visitors. If a vendor reports engagement as a share of people who opened the chat, that number is close to meaningless.

The funnel inside the assistant: add to cart, to checkout, to address, to payment. This is the diagnostic. A healthy engagement rate with a collapse between address and payment is a checkout problem, not an AI problem, and only the step-level funnel will tell you that.

If you can, run a holdout - withhold the assistant from a random share of sessions and compare. It is a small change and it is the only design that supports the word "lift" without a footnote.

9. How long, realistically?

Two ranges, and the honest answer is that they are both true for different stores.

Days if you are on Shopify, WooCommerce, Magento or BigCommerce with a reasonably complete catalog. The integration is a script tag and a read-only feed, and the assistant inherits attributes that already exist.

Two to three weeks from kickoff if you are on a custom stack, need API wrappers, have location-bound inventory, or need substantial attribute enrichment. The enrichment dominates that timeline, not the engineering.

Any vendor quoting you a single number without asking about your catalog first has not scoped your deployment.

The order to do this in

1. Run a readiness check on the catalog before you talk to vendors. The agentic readiness scan reports whether your product data can satisfy a constraint query at all.
2. Fix the attribute gaps it finds. This work is not vendor-specific and it is not wasted whichever product you choose - the same fields decide whether external agents recommend you, which is what Citation Rank measures.
3. Then evaluate assistants, with the nine questions above and the demo tests in section five.

Doing it in that order means the enrichment is done once, benefits both surfaces, and stops being the thing that makes your deployment take three weeks instead of three days.

Sources

• Implementation questions are drawn from Tru Commerce evaluation calls with retailers in September 2026, reported in aggregate and unattributed.
• Failure modes and the constraint-filtering argument: Tru Commerce citation corpus, 26,629 citations across 250 prompts, 5 engines, US/UK/India, captured 16 September 2026.