Product card layouts

Requires the Product Catalog module.

When the assistant finds products, it doesn't describe them in a paragraph — it renders them as cards the visitor can scan. This page covers how those cards are arranged and what appears on them in the widget. What fills the fields comes from your catalog mapping; see Product cards.

🖼️ [Image] — Product cards in the chat window showing image, name, price, and a View details button.

Choosing a layout

Set it at Dashboard → Widget → UX Features → Product Card Layout, then Save Changes:

The layout reflows on its own

Your choice is a desktop preference, not a fixed rule. Two overrides apply automatically:

• On mobile, the carousel always wins — whatever you selected. Below 640px of width there simply isn't room for anything else, and swiping beats scrolling on a touchscreen.
• In expanded mode, Vertical becomes Grid. When a visitor expands the chat, stacked cards would waste the width they just asked for, so they lay out in two columns instead. Collapse the chat and it returns to your setting.

Carousel navigation arrows appear only when there are three or more products — with one or two there's nothing to scroll to. Each click glides one card's width.

🎬 [Video] — Switching between Vertical, Carousel, and Grid, then expanding the chat to watch Vertical reflow into a grid.

What appears on a card

In order, top to bottom:

• Thumbnail — from your mapped image field. Missing or broken images fall back to a tile with the product's initial rather than a hole in the layout. Images are lazy-loaded, so a carousel of thirty products doesn't cost thirty downloads.
• "Out of stock" badge — overlaid on the image, and only when your mapped stock field explicitly says the item is unavailable. An unmapped stock field means no badge, not a false "in stock" claim.
• Brand badge — optional, from your mapped brand field. It doesn't have to be a brand: real-estate catalogs commonly map a neighbourhood here, which is what visitors scan for.
• Product name — with the full name on hover when it's too long for the card.
• Price — a single price normally; when a sale price is lower than the list price, the original appears struck through beside the highlighted sale price.
• Custom fields — every field you marked card-visible in your mapping, as Label: value rows. There's no cap, which is exactly why you should be selective in the mapping: eight rows on a card is a spec sheet, and nobody reads a spec sheet in a chat window. Three or four decide a purchase.
• View details — a button linking to the product page, opening in a new tab. It appears only when the product has a mapped URL; without one, the card is a dead end and the visitor has to ask you for the link.

Labels and formatting

The labels on those custom-field rows come straight from your catalog mapping, so an unmapped API field name shows up verbatim — bedroom_count rather than Bedrooms. Set friendly labels in your field mapping, or override them per widget if the same catalog serves two audiences.

Individual fields can also carry formatting from the mapping — a prefix or suffix (m², /month), an emphasis, or a rule that hides the row when the value isn't interesting (zero, empty, below a threshold). Configure all of it in Schema detection & field mapping.

When cards appear at all

Cards render when the assistant's answer came from a product search. An answer built from your knowledge base returns prose, because a returns policy isn't a card. If you expected cards and got a paragraph, the question was probably classified as a knowledge question — see Intent routing — or the catalog search came back empty, which the bot will say plainly rather than filling the gap with something close.

The assistant deliberately returns a small number of results. A chat is not a search results page, and ten cards in a message reads as noise.

Related

• Product cards
• Schema detection & field mapping
• Customizing the widget
• Embedding the widget
• Intent routing