Shoppers often cannot translate a need ("a waterproof jacket for Norway in March, under 200 EUR") into filters and keywords. A shopping assistant takes the need in natural language, asks clarifying questions, searches the live catalogue, explains trade-offs and moves the shopper to the cart. Done well it lifts conversion and basket size and deflects pre-sales questions; done badly it invents products, prices and policies.
Problem & value
- Today: faceted navigation, keyword search and static FAQ pages; pre-sales questions (fit, compatibility, delivery) go to email or live chat with long waits, or are not asked at all and the cart is abandoned.
- AI value: guided discovery in natural language, multilingual by default, available 24/7, consistent with catalogue and policy, and able to hand over to staff with context.
- Evidence: large platforms report double-digit-million user bases for their assistants (for example Amazon Rufus and Zalando's assistant), but figures are company-reported and uplift numbers vary strongly by shop and by how A/B tests are run. Treat vendor claims on conversion uplift as hypotheses and measure your own with a holdout group [3][4].
Variants
- On-site assistant (web/app): search-plus-chat widget on the shop; most common.
- Messaging commerce: WhatsApp Business, Instagram or Messenger flows for order, reorder and support, often in markets where chat is the main channel.
- Guided selling / configurator: complex or technical products (B2B spare parts, bikes, furniture) where compatibility rules matter; combine LLM with a rules or constraint engine.
- Visual shopping: upload a photo, get similar items (VLM plus visual search).
- Outbound into third-party agents: instead of your own chat, expose the catalogue so ChatGPT, Gemini or other assistants can buy from you: see AGENT-022.
How it works
- shopper message (text/voice/image)
- guardrails (prompt-injection, PII, off-topic) + language detection
- intent routing (discover | compare | policy | order status | complaint)
- tools: catalogue search (hybrid BM25 + embeddings + rerank), stock/price API, order API (authenticated), policy RAG, recommender
- LLM composes answer ONLY from tool results, with product cards and links
- optional action: add to cart / checkout link / in-chat checkout (shopper confirms)
- handover to human on low confidence, complaint, legal or payment topics
- logging, evaluation, feedback loop
- Grounding: prices, stock and delivery times must come from live APIs, never from the model's memory. Answers cite the product record they used.
- Search backbone: hybrid retrieval and reranking over the catalogue (see KNOW-005); the LLM is the dialogue layer, not the index.
- Recommendations: collaborative or behavioural recommenders supply candidates, the LLM explains and adapts them to the stated need.
- Human-in-the-loop: handover for complaints, returns exceptions, B2B quotes, vulnerable users; staff review of unanswered-question reports to fix catalogue and policy gaps.
Data preparation
The core data is the product catalogue: titles, attributes, descriptions, images, prices, stock and variants, living in the shop system, ERP or PIM, supplemented by manuals, size charts, return and shipping policies (PDFs, CMS pages). Typical gaps: missing or inconsistent attributes, free-text descriptions instead of structured fields, duplicate or outdated SKUs, stock data that lags, policies scattered across pages, and no mapping of customer wording to product terms.
Preparation steps: (1) export the catalogue via shop API or CSV and check completeness of the 10 most queried attributes; (2) normalise units, categories and variants into tidy tables; (3) build a synonym and abbreviation list (customer slang versus product terms); (4) consolidate policies into one maintained source; (5) set up daily sync for price and stock so the assistant never quotes stale data; (6) assemble 50-100 typical shopper questions as test set. Tools: shop or PIM export, spreadsheets, n8n for sync, an embedding index. Rough share of effort: 50 percent or more, because catalogue quality limits answer quality.
Useful PREP use cases: PREP-011 (tidy tables), PREP-015 (terminology and synonyms), PREP-013 (knowledge base), PREP-018 (test sets). See also GUIDE-003.
Implementation paths
Which path for whom
- SMB — A: shop-system plug-ins and hosted shopping assistants exist at SMB prices and cover standard catalogue Q&A.
- Enterprise — B: the assistant must use own catalogue, stock, pricing and customer data and is a core revenue channel, so control and unit costs matter.
- Developer — B: cloud LLM APIs with catalogue RAG and shop-API tool calls give full control of the shopping flow.
Path A — Buy (recommended for most SMBs)
- Platform-native: Shopify (Storefront MCP/Sidekick-era tooling and app ecosystem), Shopware (DE/EU) and its AI features, commercetools and Salesforce Commerce Cloud for enterprise.
- Specialist shopping/service assistants: Klaviyo and Gorgias-style bots for support-plus-sales; Algolia (EU-founded, EU hosting available) and Bloomreach with conversational search; Constructor; Intercom Fin; Zendesk AI; Tidio; Emarsys; Cognigy (DE) for enterprise-scale flows. EU-based: Algolia (FR origin), Cognigy (DE), Userlike (DE), Shopware (DE).
- Check: EU data residency, DPA and sub-processors, live catalogue sync, brand and claim controls, handover, analytics, AI-disclosure support, price of resolutions versus sessions.
- Choose A when: a standard shop platform is used and the main need is faster time to value.
Path B — Build on cloud APIs
- Models: Mistral (EU provider), Claude, Gemini and GPT via EU-region endpoints (Azure OpenAI in EU data zones, Vertex AI EU, AWS Bedrock Frankfurt); use tool/function calling and structured outputs.
- Retrieval: managed hybrid search (Algolia, Elastic, OpenSearch, Azure AI Search, Vertex AI Search for commerce) plus embeddings and a reranker.
- Orchestration: MCP-style tool servers for catalogue, cart and order; Shopify exposes Storefront MCP for catalogue and cart operations [1]. Evaluate with a fixed set of real shopper queries.
- Checkout: hand off to your existing PSP checkout, or use agentic-commerce protocols (ACP with Stripe, Google's UCP and AP2 mandates) when selling inside third-party assistants [2][5].
- Choose B when: you need custom journeys, B2B rules or deep ERP integration.
Path C — Self-host (open source)
- Models: Mistral Small/Nemo, Qwen3, Llama and Gemma families served with vLLM or Ollama; BGE-M3 or multilingual-e5 embeddings with a BGE reranker.
- Stack: OpenSearch, Qdrant or pgvector for retrieval; Rasa, Botpress or Langflow/LangGraph for flows; Langfuse for tracing; Llama Guard or NeMo Guardrails for safety.
- Hardware: HW2 handles a mid-size shop with a ~8-30B quantised model; peak load needs batching or a second GPU.
- Choose C when: strict data sovereignty, very large traffic with a stable cost profile, or regulated product categories.
Path D — Custom training
Rarely needed. Fine-tune an embedding model on click and purchase pairs, or train a reranker and a small router on your logs. Fine-tuning the dialogue LLM is only justified for tone and domain vocabulary at scale. Needs thousands of labelled queries or interaction logs.
State of the art (2026)
- Shopping agents are now a channel: OpenAI (with Stripe) introduced the Agentic Commerce Protocol for in-chat checkout; Google announced the Universal Commerce Protocol with Shopify and others in January 2026, and AP2 for cryptographically signed payment mandates [2][5]. Merchants must now serve both humans and agents.
- Tool-grounded answers with structured outputs and rerankers outperform pure RAG on catalogue questions; multimodal queries (photo plus text) are routine.
- Limits and failure modes: hallucinated specs, prices or compatibility; outdated stock; sycophantic upselling; prompt injection through product reviews or listing text; sponsored-ranking bias that is not disclosed; weak size/fit advice; inconsistent behaviour across languages. Always test with adversarial and long-tail queries.
Shared resources & combinations
- Shared stack: hybrid search and embeddings with KNOW-005 and CONV-001; the same LLM gateway can serve CONV-001, CONV-005 and CONV-026 on one HW2/HW3 server.
- Combines with: LANG-001 (generated product copy that feeds answers), PRED-020 (return-risk signals shown in sizing advice), AGENT-020 (shop operations agent), AGENT-022 (selling via third-party agents), CONV-005 (B2B lead qualification) and CONV-007 (human agent assist after handover).
Effort, cost & KPIs
- Path A: days to a few weeks; pricing per resolved conversation, per session or tiered per month.
- Path B: 2-4 months including catalogue tooling, evaluation and integration; inference cost is driven by tokens per session and number of tool calls.
- Path C: 3-6 months plus ongoing MLOps.
- KPIs: assisted conversion rate versus control, average order value, add-to-cart rate, containment and handover rate, answer groundedness (sampled audits), return rate of assisted orders, complaint rate, latency, cost per conversation.
People & change
Involve management and the e-commerce or shop lead (process owner) first to set scope: advice only, or also cart and checkout actions. Product data owners (PIM, ERP, purchasing) must commit to maintaining attributes; IT handles shop integration, payments boundaries and security. The DPO checks chat logs, personalisation and cookie or consent handling, the AVV with the provider and whether a DPIA is needed. Customer service staff (end users) should review handover cases and feed back wrong answers.
Works council: usually no, because the assistant serves customers and does not monitor employees. It becomes relevant (§87(1) no. 6 BetrVG) if chat handover logs are used to evaluate service staff, and §90(1) no. 3 calls for information when work processes change. Only applies where a works council exists.
AI literacy: support the team through short training on how the assistant works, its limits and how to correct it (AI Act Art. 4). Tell customers clearly that they talk to AI (Art. 50). Pilot with one product category or one market for a few weeks, with a visible "talk to a human" option. Typical concerns: wrong prices or false product claims, and customer-service jobs; address with grounding in live catalogue data, no binding offers without confirmation, spot checks and clear escalation rules. Keep humans in control of returns, complaints and exceptions.
Guides: GUIDE-008 (change management), GUIDE-005 (data protection), GUIDE-009 (pilot).
Risks, regulation & compliance
- EU AI Act: typically limited risk. Art. 50 requires that people are told they interact with an AI system unless obvious from context; the transparency duties apply from 2 August 2026 [6]. Providers and deployers share duties, so check the vendor contract. Art. 5 bans manipulative or exploitative techniques that materially distort behaviour or exploit vulnerabilities (age, disability, social or economic situation): no dark-pattern persuasion, no pressure tactics aimed at vulnerable users. Using the assistant for credit decisions or similar would move it into high risk.
- GDPR: chat logs, order history and preference memory are personal data; define legal basis (contract versus consent), retention, DPA and transfers. Profiling for personalised offers requires transparency; Art. 22 applies to solely automated decisions with significant effects, such as refusing a purchase on credit.
- Consumer law: Unfair Commercial Practices Directive and the Consumer Rights Directive (price indication, withdrawal right, clear order button); the Digital Services Act adds transparency for recommender systems and ads on platforms [7]. Price personalisation must be disclosed. Product claims (health, sustainability) must be accurate.
- Security: treat user and product text as untrusted (prompt injection); never allow the assistant to change prices, refunds or addresses without authenticated, rule-checked tools.
- Mitigations: grounded answers only, disclosure banner, human handover, logging, regular audits, red-teaming, clear opt-out of memory.
Getting started
- Export the top 200 pre-sales questions and search queries; classify them by intent and by whether live data is needed.
- Clean the catalogue (attributes, variants, compatibility) and connect stock and price APIs.
- Pilot a Path A tool or a thin Path B prototype on one category, with an AI disclosure and human handover.
- Build an evaluation set from real queries; check groundedness, price accuracy and tone before launch.
- Run an A/B test with a holdout, then review KPIs and complaints monthly; plan agent-readiness (AGENT-022).
Sources
- Shopify Dev — Storefront MCP — https://shopify.dev/docs/apps/build/storefront-mcp
- Agentic Commerce Protocol (OpenAI and Stripe) — https://www.agenticcommerce.dev/
- Amazon — Rufus shopping assistant — https://www.aboutamazon.com/news/retail/amazon-rufus
- Zalando — Fashion assistant announcements — https://corporate.zalando.com/en/newsroom
- Google — Agent Payments Protocol (AP2) — https://github.com/google-agentic-commerce/AP2
- Regulation (EU) 2024/1689 (AI Act), Art. 5 and 50 — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Regulation (EU) 2022/2065 (Digital Services Act) — https://eur-lex.europa.eu/eli/reg/2022/2065/oj
- Universal Commerce Protocol — https://ucp.dev/