Designing an AI Shopping Concierge for a Live E-Commerce Store

Most "AI" on an online store is a support widget in the bottom right that answers shipping questions. The concierge described here is a different idea: it is the front door. Instead of dropping a customer into a product grid, it opens a short conversation about what they want out of the purchase, reflects that back, and recommends two or three specific products with a genuine reason for each. This is the design thinking behind it, for a live store that currently has no AI anywhere.

Start from the outcome, not the filter

A product grid asks the customer to already know what they want and translate it into filters. A lot of buyers cannot do that, especially in a category where the taxonomy is unfamiliar. The concierge inverts it. The opening move is a question about the outcome the customer is after, in their own words. From that, the system infers a target profile, and only then maps that profile onto the catalogue. The grid still exists as a fast fallback for people who do know exactly what they want.

Recommendations need a rationale, not just a match

"Here are three products" is a search result. "Here are three, and here is why each one fits what you told me" is a recommendation. The design requires every suggestion to carry a short, specific reason tied back to something the customer actually said. If the system cannot articulate why, it does not suggest.

A real product knowledge model comes first

The store’s product attributes today are thin, and some are derived at display time from keyword matching on the description text. A concierge cannot reason on that. So a prerequisite piece of work is a structured product knowledge model: real, curated attributes per product, stored properly, that the recommendation logic can query. The conversation is only as good as the data under it.

It has to remember you

A concierge that reintroduces itself every visit is a form. The design includes a memory layer so a returning customer is greeted with context: what they liked, what they reacted badly to, the boundaries they set. That memory architecture is involved enough to be its own article.

Duty of care is built in, not bolted on

In a regulated category, responsible use is not a line at the bottom of the page. The persona is designed to be unhurried and never pushy, to respect stated limits, and to treat a hard boundary from the customer as a permanent rule the system enforces, not a preference it weighs.

Deliberately not a fast build

This is scoped as an initiation phase, not a sprint. The order it goes in: API and data model first, then the conversation, then memory, then post-purchase follow-up. Trying to do the conversational layer before the product data exists would produce a demo that cannot survive contact with the real catalogue.

“A concierge is only worth building if it can say why. Everything else is autocomplete over a product feed.”

Related