Conversational commerce, grounded in your catalog
The advisor your website never had
A shopper describes what they want in their own words. The assistant renders your familiar product grid — same cards, same filter rail, same sort — already filtered to the request, and adds to the real cart in one click. There is no API to build, no customer data to hand over, and no page to rewrite.
- A measured pilot
- Three months at a fixed scope, with a control group from day one.
- Zero engineering
- One tag and one CSP line. No API, no deploy.
- Only your catalog
- Every product, price and stock level is a live row in your catalog.
This is no longer an experiment. Four of the largest marketplaces in the world put a conversational shopping assistant on their own sites in the past two years.
- AmazonAlexa for ShoppingIn the search bar and a dedicated chat window. Answers questions, compares products, adds to cart.
- WalmartSparkyAn "Ask Sparky" button across all shopping categories in the app.
- eBayAI shopping agentAppears inline on the page the shopper is on — the closest example to proactive placement.
- AlibabaAccioA sourcing agent with more than 10 million monthly users by the company’s account.
None of them settled for a better search box. All of them chose a conversation.
What it is
The model writes the query. Your catalog writes the answer.
Most shopping chatbots generate a sentence and hope it is true. This one does not get to. The model’s job is to turn a request into a structured query — a category, a set of filters, a sort. A deterministic search against your own catalog produces the products.
- 1
The shopper writes
"Something for dry skin under 100 shekels, nothing with fragrance." Typed or spoken, in Hebrew or English, in whatever words they have.
- 2
The model writes the query
Not the answer. It emits a category, filters and a sort — and every filter it chose becomes a live chip the shopper can edit or remove.
- 3
Your catalog writes the answer
The listing the shopper already knows, pre-filtered. Every product named is a row in your catalog, at your price, with your availability. Add to cart is your own add-to-cart.
Scope
What it does, and what it will not pretend to
What it does
- Understands a need described in ordinary language, and keeps answering in the language the shopper opened in.
- Renders your own product listing — same cards, same filter rail, same sort — pre-filtered, with the filters it chose as live chips.
- Answers questions about a specific product from stored product knowledge rather than from the model’s memory.
- Compares a shortlist side by side on the attributes that actually differ.
- Handles the questions a search box cannot: gifts, occasions, routines, "what do I need for…" — and verifies each product type exists before offering it.
- Says you do not carry something, instead of quietly showing the nearest unrelated thing.
- Adds to the real cart through your own add-to-cart function, so the badge, mini-cart and analytics all update natively.
- Optional voice input, where the shopper speaks instead of typing.
What it is not
- Not a support bot. It does not handle order status, returns, refunds or account questions, and it will not pretend to.
- Not a page takeover. It never navigates away, never touches your browser history, and hands the layout back byte-identical when it closes.
- Not a data grab. No account, no cross-session identifier, and no shopper profile kept between visits.
Evidence
What the published results say
The figures below measure an assistant running on the retailer’s own site, not traffic arriving from an external AI product. They are real in the sense that they were measured and published — and none of them was measured against a control group. We show them as they are, and mark what each one does not prove.
conversion at retailers running an on-site agent, against those that do not
Salesforce, 2026 · cohort comparison
conversion for shoppers who engaged an assistant vs. everyone else
Dashly benchmark · self-selected
site conversion after deploying an assistant, +38% basket
Tatcha, vendor case study · no holdout
of LLM-referred visits engage a shopping assistant
329-brand study · engagement, not lift
So the pilot is a measurement, not a launch
We propose a holdout from day one: a randomly assigned share of traffic never sees the entry point, and the comparison is engaged-eligible against holdout, not engaged against everyone. It is the only design that tells you what the assistant caused rather than what it attracted. We would rather find out with you in month one than defend a self-selected number in month nine.
Placement
Traffic does not size this. Placement does.
You are billed only for sessions in which a shopper actually talks to the assistant. So the outcome is not sized by your monthly visits — it is sized by the fraction of them that ever open it. The published range for proactive placement reaches 6%, against 0.5% for a corner bubble — twelvefold on identical traffic.
This is the one decision that sits with you, and it changes the size of the outcome more than any other parameter. A corner bubble nobody is invited to open will produce a defensible-looking failure.
Implementation
Three things for your engineers, and the third is usually already done
No API to build, no authentication, no CORS, no code deploy. The assistant sends a product code and receives a boolean. The work is a tag manager entry and a line on a list your team already maintains.
<!-- Google Tag Manager → Custom HTML → All pages -->
<script src="https://<widget-origin>/tag.js" async></script>Content-Security-Policy:
frame-src https://<widget-origin>;What the assistant will not do to your page
Never navigates away
A product named in a sentence is a button that opens it over the conversation, not a link.
Never touches your history
It refuses to write into the top page’s session history on your behalf; your back button stays yours.
Never reads your page
Cross-origin framing means it cannot see your DOM, cookies or cart even if it tried.
Never leaves the layout changed
When the panel closes, the page is handed back exactly as it was — same widths, same scroll.
Privacy and data protection
Your customer data never reaches us. Not because we promised — because it cannot.
The assistant loads as a separate frame inside your page, and the browser keeps the two apart. It receives only what the page chooses to send it. Your cookies, the shopper’s account and the cart contents it neither receives nor can read — not because we undertook not to look, but because the browser itself does not permit it, and will not permit it even if there is a bug in our code.
What never reaches us
The browser blocks it, not our code.
- Cart contents, order history and your customer records.
- Cookies, sign-in identifiers and anything your site stores in the shopper’s browser.
- Payment data of any kind. The assistant is never on a checkout page.
- A shopper profile. No account, no cross-session identifier, and no memory between visits.
What does reach us
Isolated to you, deletable on request, never used for training.
- What the shopper types or says, in order to answer it.
- Which products were shown, which chip was tapped, which product was added — so a complaint can be answered with the actual turn.
- A random session identifier with no link to a person, an account or a device.
- Usage and billing data: what each answer cost. No conversation text at all.
What goes into the contract
- A DPA on your paper or ours, signed before any production traffic.
- No shopper data used to train any model, ours or a provider’s.
- Your catalog and your conversations isolated by tenant at the database level.
- Deletion on request within 30 days, and a documented export on termination.
- Notice before any sub-processor is added.
- Named security contact and a 24-hour breach notification commitment.
Where it sits
Not a search platform. Not a support bot.
The category makes itself hard to compare. Discovery platforms re-index your catalog and replace your search; support bots answer tickets. This is a third thing — an advisor that sits on top of the storefront you already have.
| Discovery platformsConstructor, Algolia, Bloomreach | Support botsIntercom Fin, Zendesk AI, Gorgias | AgalitAn advisor on the page you already have | |
|---|---|---|---|
| What it replaces | Your search and category pages | Your help desk | Nothing. It sits beside your listing |
| What the shopper sees | A new results page | A chat window with sentences in it | Your own product grid, pre-filtered, with editable chips |
| Integration | Re-index the catalog, rebuild the PLP, weeks of engineering | Connect the ticketing stack | One tag and one CSP line |
| Priced by | Requests, or a platform fee | Resolutions — the bill grows as the AI improves | Shopper sessions, capped, with an allowance |
| Where the answer comes from | A ranking model over their index | A language model, and hope | A deterministic search over your catalog |
Per-resolution pricing has a pathology worth knowing about before you sign one: as the AI gets better, the same volume costs more. A capped session price does the opposite.
Commercials
A fixed line for the budget, and an allowance worth filling
Pure per-session pricing punishes the thing both sides want, which is more shoppers using it. So the fee carries the floor, the allowance carries the volume, and overage is charged at one flat rate published in advance. The result is a budget line you approve once a year, not an invoice that moves with every campaign.
What protects your bill from abuse
You are billed for answers produced, never for requests received. There is a per-caller rate limit, each session carries its own budget, and when the system identifies an abnormal usage pattern from a caller it stops answering them — that caller alone. Your real shoppers never notice.
- Starts
- At the first answer the assistant gives. Loading the widget is free, and impressions are never billed.
- Ends
- After 6 shopper messages, or 30 minutes idle, whichever comes first.
- Rolls over
- A shopper who keeps talking is never cut off — the history compacts and a new session opens.
- Billed on
- Answers produced, never requests received. A failed or rejected request costs you nothing.
- Reported
- Session counts, engagement rate and per-session cost visible to you in a dashboard, reconciled monthly.
Next
We suggest starting with a measured pilot, bounded in scope and in time.
What exactly the assistant will do to your conversion rate, neither of us can know today. One month of your own traffic, against a control group, will answer it. That is why the initial scope is limited, and why the decision to continue should rest on what was measured.
- 1
Read access to your catalog
Product and category data. That is all we need from you to begin.
- 2
We prepare on our side
Indexing the catalog, building the product knowledge, tuning the models on your categories. Nothing is required from your teams.
- 3
One tag, one line
Full embedding documentation. In practice a GTM tag and a line in your CSP.
- 4
Three months, with a holdout
Fixed scope, control group from day one. Continue on what was measured, not on what was promised.
The long pole is never the integration
It is catalog access and the placement decision. Everything else is measured in days.