Quick Reply vs Button· Chatbot UX pattern
Quick Reply vs Button — What's the Difference in Chatbots? (2026)
Quick answer: A quick reply is a disappearing chip that sends a pre-set text answer and vanishes once tapped — it belongs to the conversation moment. A button is attached to a specific message, stays in the chat history, and can carry richer actions (open a link, trigger a flow, start a call) — it belongs to the message. Channels enforce the split differently: Messenger separates quick replies from button templates, WhatsApp offers reply buttons, call-to-action buttons, and list messages, and Telegram splits reply keyboards from inline keyboards. Choosing the wrong one is a small mistake users feel on every turn.
Why two controls exist at all
Both elements solve the same root problem: free-text input is slow to type and unpredictable to parse. Tapping a labeled option skips intent recognition entirely and gives the bot a deterministic answer. If that were the whole story, one control would be enough.
The split exists because "answer this question now" and "offer this action permanently" are different jobs. A size picker (S / M / L) only makes sense at the moment the bot asks for a size; once answered, leaving the options on screen invites contradictory taps. A "Track my order" or "View product page" option is the opposite: it should remain available in the history, because the user may want it five messages later. Messaging platforms encoded this distinction directly into their APIs, which is why the two controls look, persist, and behave differently.
The core differences
| Dimension | Quick reply | Button |
|---|---|---|
| Lifespan | Disappears after one tap (or the next message) | Persists in chat history, tappable again |
| Attached to | The conversation's current turn | A specific bot message |
| What a tap does | Sends the label as the user's text message | Sends a postback, opens a URL, dials a number, or launches a flow |
| Best for | Answering the bot's current question | Standing actions, navigation, links out of the chat |
| Typical limits | ~10-13 chips depending on channel | 2-3 per message on most channels |
| Re-tap risk | None — the row is gone | Real — old buttons can fire outdated flows |
The re-tap row deserves emphasis. Because buttons persist, a user can scroll up and tap a button from yesterday's conversation. A well-built flow handles that gracefully (re-validates state, restarts the relevant step); a fragile one resurrects a half-dead context and produces nonsense. This is a classic source of the confusing sessions that end in a fallback intent.
How each channel draws the line
- Messenger and Instagram. Meta's platform keeps the two as separate API objects: quick replies are chips above the keyboard, capped at 13, gone after a tap; button templates attach up to 3 persistent buttons to a message, with postback, URL, and call types. This is the cleanest implementation of the distinction.
- WhatsApp. The WhatsApp Business API has no disappearing chips. Its reply buttons (max 3) behave like persistent buttons that send text; call-to-action buttons open URLs or dial numbers; list messages put up to 10 options behind a "Choose" tap. When a question needs more than 3 answers on WhatsApp, the list message is the intended tool — not a wall of follow-up messages.
- Telegram. Reply keyboards replace the user's system keyboard with custom answer keys (the closest thing to quick replies, though they persist until removed), while inline keyboards attach callback buttons directly to messages. Telegram is unusual in letting bots edit an inline keyboard after the fact, so a tapped button can be visibly disabled.
- Website chat widgets. No platform police here — vendors decide. Most widget builders render both patterns: disappearing answer chips inside the flow, persistent buttons on cards and menus.
Choosing between them
The decision is rarely aesthetic; it follows from what happens after the tap.
Use a quick reply when you are collecting an answer the flow needs right now: a yes/no confirmation, a category pick, a rating. The ephemerality is the feature — once the flow moves on, the stale options remove themselves, keeping the conversation design tidy and the state machine safe from out-of-order input.
Use a button when the option should outlive the turn: linking to a sizing guide, opening checkout, offering "Talk to a person" on a persistent card, or exposing a small menu of standing actions. If the tap leaves the chat (URL, phone call), it must be a button — quick replies cannot carry those actions on most channels.
Mixed cases come up constantly, and the channels force the compromise. A 6-option product picker on WhatsApp cannot be quick replies (none exist) or reply buttons (capped at 3) — it becomes a list message. The same picker on Messenger fits comfortably in quick replies. Builders that abstract across channels, such as Manychat and SendPulse, will silently translate one element into the nearest native equivalent per channel — worth checking in preview, because a design that feels right on one channel can render awkwardly on another. Conversation-first builders like Landbot and Typebot treat both as first-class blocks, while widget-centric tools like Tidio lean on persistent card buttons for their menus.
Common mistakes
- Persistent buttons for one-time answers. A yes/no asked with message buttons leaves a tappable "Yes" in the history forever. Users tap it again; flows break.
- Quick replies for navigation. "Visit our store" as a quick reply wastes the chip and dies after one tap. Links belong on buttons.
- Ignoring per-channel caps. Designing 5 reply buttons for WhatsApp guarantees a degraded render; the channel allows 3, full stop.
- No free-text escape. Whichever control you use, users must be able to type. Both patterns supplement free text — they never replace it. The broader option-count and phrasing guidance in the chatbot quick reply entry applies to both controls.
Related terms
- Chatbot quick reply — the deep-dive on the quick-reply pattern itself, with UX best practices.
- Conversation design — the craft of deciding when options beat free text.
- WhatsApp Business API — the channel with the most distinctive button rules.
- Intent recognition — what both controls let the bot skip.
- Fallback intent — where conversations go when stale buttons fire.
FAQ
Are quick replies and buttons the same thing?
No, though vendors blur the names. A quick reply is an ephemeral chip near the keyboard that sends its text and disappears; a button is attached to a message, persists in history, and can carry actions beyond sending text (URLs, calls, postbacks). Several channels implement them as entirely separate API objects.
Does WhatsApp have quick replies?
Not in the Messenger sense. WhatsApp's interactive messages offer reply buttons (up to 3, persistent, send text), call-to-action buttons (URL or phone), and list messages (up to 10 options in a tap-to-open sheet). There is no disappearing-chip element; cross-channel builders map their "quick reply" blocks onto reply buttons or lists.
Which converts better, quick replies or buttons?
Neither wins universally — they serve different turns. Tappable options in general outperform free-text prompts for predictable choices, but the gains come from matching the control to the job: ephemeral chips for in-flow answers, persistent buttons for standing actions. Mismatching them (links on chips, one-time answers on buttons) is what costs conversion.
What happens when a user taps an old button?
The channel delivers the postback as if it were fresh, so the burden is on your flow. Well-built bots re-validate state and either resume the relevant step or explain that the option expired. Untested bots resurrect stale context — a failure mode worth probing explicitly during QA.
Can I show more than three options on WhatsApp?
Yes — use a list message, which holds up to 10 options behind a single "Choose" button. Reply buttons cap at 3 per message. Splitting options across several 3-button messages is the usual workaround seen in the wild, and almost always the worse experience.
Sources
- Meta. Messenger Platform — Quick Replies and Button Template. developers.facebook.com/docs/messenger-platform (verified 11 June 2026).
- Meta. WhatsApp Business Platform — Interactive Messages. developers.facebook.com/docs/whatsapp (verified 11 June 2026).
- Telegram. Bot API — Keyboards. core.telegram.org/bots/api (verified 11 June 2026).
- Chatbotscape Glossary. Chatbot quick reply. /glossary/chatbot-quick-reply (verified 11 June 2026).
- Chatbotscape evaluation methodology. /methodology (continuously updated).