Can customers tap reply buttons instead of typing?

Yes. When the assistant needs the customer to pick among a small set of discrete replies, it can show compact stacked buttons in the storefront widget. Tapping a button sends that label as the customer's next message, so the conversation continues as if they had typed it.

This is for in-chat choices, not storefront links. A taste question, a format choice, or a yes/no confirmation is a good fit. A quiz page, a recipe, a collection, or a single recommended product page still uses the existing single call-to-action button, which opens a URL instead of sending a chat reply. Taste options stay as reply buttons until one product is the recommendation; then the next step is that product-page button.

When the buttons appear

The assistant invokes this itself when a short list of replies would be clearer than asking the customer to type. Typical cases: which use they have in mind, lighter versus bolder taste, can versus bag, or whether to go ahead with a change it can complete with an enabled tool. Ordinary informational lists stay as text. The assistant does not turn every bullet list into buttons, and it does not invent a storefront destination for a choice that belongs in the thread.

Reply buttons are storefront-widget only. Email conversations keep the question in the message body; the customer replies in text.

What you configure

Nothing. Reply buttons are a platform behavior, not a merchant setting and not a flowchart. You do not add a button builder, and you do not write special FAQ markup to enable them. Keep product and policy knowledge in your catalog, FAQs, and merchant instructions; the assistant decides when a tap is clearer than typing.

Staff see the same labels in the dashboard transcript, so a handoff still shows which choices were offered. After the customer replies, by tap or by typing, those buttons are no longer the active prompt.