Buttons vs Free Text in a Chatbot

When a Menu-Based Chatbot Wins, and When to Let Customers Type

Quick answer: Give a button when you can list every acceptable answer and the list fits the channel; leave the field open when you cannot, and read what comes in with an intent model or an LLM. Neither is the bot. A menu-based chatbot is the cheapest thing you can ship and, in IBM's words, "if a user's need isn't listed as a menu option, the chatbot will be useless because it lacks a free text input field." A free-text bot understands anything and pays for it: Google's design guidance for Dialogflow CX puts the floor at "at least 20 training phrases for every intent," with "roughly 50" desirable for the head intents of a large agent, and a language model swaps that labor for latency, a per-message bill and answers you did not write. So the decision is not made once per bot. It is made once per question, and this guide is the rule for making it.

The rule has four tests, applied to each question a flow asks: whether the answers can be enumerated, whether the answer is a value you will store or branch on, whether the customer already knows what they want, and whether the channel can render the list at all. Most questions in an SMB bot pass the first two, which is why the flows that carry money (booking, order status, lead capture) are mostly buttons, and why the questions that open a conversation ("What can I help with?") should not be buttons alone. The worked example below runs a six-question booking flow through the tests. Between here and there are the channel caps that decide the format, and what six builders do at the moment this guide is really about: when the customer ignores the buttons and types.

What each kind of input costs

A button costs you the list. Somebody has to write every option the customer may pick, keep it under the channel's character cap, and keep it current when the services change. In exchange, the answer arrives as a value: Landbot's own case for its structured layer is that "using buttons for company size, for example, standardizes data and avoids ambiguity," and the Instagram Messaging documentation describes the mechanism exactly, "Instagram dismisses the buttons and posts the tapped button's title to the conversation as a message," with the payload you attached riding along to your webhook. No parsing, no intent recognition, no fallback. The costs are the ones IBM lists for menu bots: they "might take longer to understand customer needs, especially if users must go through several iterations of menu buttons before reaching the final option," and they are blind to anything off the menu.

Free text costs you understanding. With a classifier, that is training data: Google's twenty phrases per intent is a floor, with fifty desirable for head intents, and its same page tells you to expect answers that do not fit the question at all ("what's your travel dates?" answered with "I don't know yet") and to build an intent for them. With a model, the training phrases go away and three other costs arrive: time per turn, money per turn, and Landbot's description of the unstructured result, "visitors type freely, the system responds in lengthy paragraphs, and important details end up buried in unstructured text." Telegram's bot documentation, which has to serve both kinds of developer, states the trade in one line: "Bots are able to interpret free text input from users, but offering specific suggestions is often more intuitive."

Neither cost is the reason to choose. The reason is the question.

The rule, one question at a time

Run each question a flow asks through four tests. All four run on every question: tests 1 and 2 decide the format (a button, a list or a typed field), test 3 decides whether typed text beside the options is expected and routed to a classifier or model rather than re-prompted, and test 4 decides how the channel renders the result.

1. Can you list every acceptable answer, and is the list short? "Book, reschedule or cancel" is three answers; "which of our eight services" is eight; "what seems to be the problem" is unbounded. If the list exists and fits the channel (the caps are in the next section), the question is a button question. If the list exists but is long, it is a list message, a searchable button set, or a typed answer matched against the list, in that order of preference. If no list exists, the format is a typed field, and test 2 decides whether it is a validated field or an open one.

2. Will you store or branch on the answer? Company size, order type, a yes or a no, a slot in a form that a CRM will receive: these want a value, not a sentence. A typed "about fifty of us, give or take" is a parsing job that a three-button "1–10 / 11–50 / 51+" is not. Landbot's post on its hybrid design keeps "company size (using button-based selection)" in the structured layer for exactly this reason, and Manychat's AI Step exists partly to catch the other case, where a typed reply still needs to land in a field. If test 1 and test 2 both say button, it is a button, and the only remaining question is which kind.

3. Does the customer already know what they want, in their own words? Returning customers, high-intent visitors and anyone arriving from a specific link do. Forcing them through "How can I help? [Sales] [Support] [Other]" is the "several iterations of menu buttons" IBM warns about. For these questions the field stays open and the model or classifier does the routing, with buttons offered as suggestions rather than gates. This is also the case for the opening question of almost every support bot, which is why the welcome message guide keeps the opening to two to four routing buttons and a visible path to a person, with the field open for the customer who arrives with a sentence.

4. Can the channel render it? A voice channel cannot; there the "buttons" are a spoken list and a reprompt if the caller says nothing. WhatsApp can render three reply buttons or a ten-row list, not four buttons. Messenger can show thirteen quick replies that vanish on the first tap. If the channel cannot render the list you need, the question becomes either a list message, a numbered menu the customer answers by typing a digit, or a typed answer. The next section is the map.

A question that fails test 1 (no list) but passes test 2 (a value) is a typed field with whatever validation the value allows: a date, an email or an order number is checked and re-asked once if the format is wrong; a name is simply captured. A question that fails both is a free-text question, and the honest design for it is an open field with a way out: a skip for an optional question, a person for one the bot cannot answer. A question that passes tests 1 and 2 is a button question even if the customer is sophisticated, because the button is faster for them too; test 3 then decides whether a typed answer beside the buttons is expected and read by a classifier or model, or simply re-prompted. Google's guidance on ending every turn with a question, with "Would you like to cancel or submit that order?" as one of its examples, is a button question written as a sentence; on a channel with buttons, render it as two.

The channel decides the format

The caps below are read from the channel operators' documentation on 11 September 2026 (Meta's WhatsApp, Messenger and Instagram pages; Telegram's bot features page) and from the builders' own articles where a builder imposes a tighter limit than the channel. The chatbot scripts guide carries the complete per-field table for WhatsApp; this one is the part that decides button versus text.

Three consequences follow. First, on every messaging channel the customer can type regardless of what you show, so the button is a suggestion, not a constraint, and the flow needs a path for the typed answer (next section). Second, a four-way choice on WhatsApp is a list message, not four buttons, and a fourteen-way choice on Messenger is two messages or a typed answer. Third, the builders sit at or under the channel caps: Manychat allows "11 Quick Reply options per message" against Meta's thirteen (its Data Collection block's Skip button counts as one of the eleven), "3 buttons per message" for persistent buttons, and notes that "Quick Replies are currently available only for Facebook and Instagram"; Landbot's Messenger buttons top out at "14 buttons per block, including 'Any of the above'," which is Meta's thirteen plus the fall-through.

When the customer types anyway: six builders, six answers

This is the moment the whole decision was for. You showed three buttons; the customer typed a sentence. What the platform does next is documented, and it differs.

The editorial rule that falls out of the table, and it is reasoning rather than a measurement: show buttons, leave typing open, and route the typed text somewhere useful. Concretely, a typed reply to a button question should be matched against the button labels first (a customer who types "cancel" under a Cancel button has answered), then against the bot's intents or model, and only then treated as a miss, where the copy in the fallback copywriting guide takes over and the second attempt offers the buttons again with a person among them. Lock typing only when the flow is transactional and short (a three-step confirmation, a payment handoff), and never on a channel where the customer expects to be able to talk; on the messaging channels the input field is the app's, not yours, so the lock is a website-widget option only.

Generative bots change the cost, not the rule

A language model reads typed text without training phrases, which is why the free-text side of the ledger looks cheaper in 2026 than it did. It does not make the button question go away. Landbot's February 2026 post, written to sell an AI agent, still has the agent introduce "selectable options or buttons to simplify interaction and reduce cognitive load" and keeps company size on a button; Botpress's example prompt for its LLM node asks for buttons "whenever possible"; Voiceflow ships a separate "buttons system tool" so a Playbook can generate options "dynamically created based on conversation context." Our Chatbase review captured the same instinct on a pure-AI product: its test widget rendered "auto-generated Quick Reply chips" under the model's answers. The model is deciding which buttons to show, which is test 1 automated, not abolished.

What a model does change is test 3. When the field is open and a model is behind it, the opening question can be open without a menu, because a typed "do you do balayage and how much is it" is answerable. Dialogflow CX's design is the clearest statement of the split: language models "always" interpret what the user meant, and "you can decide whether and how language models are used for agent responses." Read the typed text with the model; answer the button questions with the flow.

A worked example: six questions in a booking flow

A hair salon's WhatsApp bot, eight services, five stylists, built on any of the flow builders we review. Each question through the four tests:

Six questions: one set of buttons with the field left open, two lists, one validated field, one plain capture, one open field. The flow is a menu-based chatbot for questions 2 and 3, a form for 4 and 5, buttons plus free text for 1, and free text for 6, which is what a hybrid chatbot means in practice. The mistake this table prevents is the one IBM names: making question 1 buttons-only, so that the customer who typed "do you do balayage" gets a menu of Book / Reschedule / Cancel and leaves.

Measure the choice after you ship it

Every button question produces two numbers a week later, and they tell you whether the tests were applied right. The tap share is the fraction of answers to that question that were taps rather than typed text; a button question with a low tap share has options the customer does not recognize, or is really a free-text question. The typed-miss rate is the fraction of typed answers to that question that ended in the fallback; a high one means the escape hatch is not connected or the model is not reading the typed text. Per-question abandonment is the third, and a list message with ten rows that loses a third of customers is a sign that test 1 was passed on paper and failed on a phone. Where your platform's analytics do not break these out per question, the transcript export does; the conversational analytics guide covers the export.

One accessibility note, because buttons are the input most likely to fail it. On a website widget, a quick reply that is a styled div with a click handler is invisible to a keyboard and silent to a screen reader; the accessibility guide has the audit ("unplug your mouse"), and its rule that a launcher "needs to be a real button, reachable by Tab" applies to every option you render.

What our fifteen reviews record

Searched 11 September 2026, case-insensitively, across the fifteen files matched by sample-reviews/*-review.md: button or buttons appears in 12; quick repl in 5 (AiSensy, Blip, Botpress, Chatbase, Tidio); free text, free-form or open-ended in 5 (AiSensy, Landbot, Manychat, Tars, Voiceflow); list message in 1 (AiSensy). The captures that bear on this page: the Tidio review photographed a Decision (Quick Replies) node with three options and "Transfer to agent toggle" and the "Facebook Messenger 20-character truncation warning surfaced inline" (28 May 2026); the Blip review captured a block editor offering Texto, Quick reply, Imagem, Carrossel and Menu as content types under a 25-element cap per block; the AiSensy review captured a WhatsApp message-type picker reading Text Message / Text With Buttons / Media With Buttons / List Message inside its tool-calling configuration; the Landbot review captured the Validation error message field that fires when a typed answer fails a question block; the Manychat review records that the structured Data Collection block is PRO-only and that Free-plan users "can capture lead data only via free-text Telegram messages," which is test 2 decided by the plan tier and, as the review notes, not surfaced on the pricing page; and the Tars review places the product as a form-bot for "collecting structured data through conversational flows rather than open-ended LLM dialogue." None of the fifteen protocols measured tap share or typed-miss rate per question; that is a gap in the protocol, recorded here, not a finding about the platforms. Corrections to editorial@chatbotscape.com.

Where it breaks

The rule fails in two known ways. A list that was short when the bot shipped grows: eight services become fourteen, and a WhatsApp list message carries ten rows, so rows eleven to fourteen do not fit; what your builder does with them (refuse to save, split the message, drop them) is builder-defined, and the customer is the one who finds out. Review button lists on the same cadence as the content strategy review. And the escape hatch rots: the intent or prompt that catches typed answers under a button question is written once and never retrained, so the typed-miss rate climbs while the tap share looks fine. Read the typed answers themselves, monthly; they are the customer telling you which buttons are missing.

FAQ

Should a chatbot use buttons or free text?

Both, decided per question. Use a button when you can list every acceptable answer and the list fits the channel, and when the answer is a value you will store or branch on. Leave the field open when the answer cannot be listed, or when the customer arrives knowing what they want. On every messaging channel the customer can type regardless, so a button is a suggestion; connect the typed path.

What is a menu-based chatbot?

A bot whose every step is a set of options the customer taps, with no free-text understanding behind it: IBM's "most basic kind of chatbot," and in its words these bots "operate like a decision tree." It is the right design for a transactional flow with enumerable answers (booking, order status) and the wrong one for the opening question of a support bot, where the customer's need may not be on the menu.

How many buttons can a chatbot show?

It depends on the channel, not the builder. WhatsApp allows up to three reply buttons per message or a list message with up to ten rows; Messenger and Instagram allow up to thirteen quick replies, each capped at 20 characters; Telegram's bot features page states no count for its keyboards; a website widget allows whatever the builder does. Builders often sit under the caps: Manychat allows eleven quick replies and three persistent buttons per message.

What happens if a user types instead of clicking a button?

Whatever the builder is set to do, and the default is often nothing good. Landbot's documentation says that on Messenger the bot "will stop" if its "Any of the above" output is unconnected; Manychat can resend the options up to five times; Voiceflow's No match setting sends a message or follows a path; Tidio can prevent typing during a flow on a website widget. The rule this guide recommends is to match typed text against the button labels, then against intents or a model, then fall back with the buttons offered again.

Are buttons better than typing for accessibility?

Only if they are real buttons. A styled element with a click handler is invisible to keyboard users and silent to screen readers, which makes a button-only flow impassable for them, while a plain text field is usable by default. Our accessibility guide has the audit.

Do AI chatbots still need buttons?

Yes. The vendors selling the model say so in their own documentation: Botpress tells its LLM node to "use buttons for quick replies and easy navigation whenever possible," Landbot's AI agent introduces "selectable options or buttons to simplify interaction," and Voiceflow ships a tool for generating buttons from context. The model changes who writes the list, not whether a list beats a sentence for an enumerable answer.

Related guides

• Quick reply vs button (glossary) — the two button objects, per channel, and which one to use.
• Chatbot quick reply (glossary) — the chip itself and its UX rules.
• Chatbot scripts — the complete WhatsApp field-cap table and the words that go in the fields.
• Multi-turn form design — keeping state across the free-text and field questions.
• Chatbot fallback copywriting — what to say when the typed answer misses.
• Generative vs rule-based chatbot — the flow-by-flow decision above this page's question-by-question one.
• Hybrid chatbot (glossary) — the word for a bot built out of both kinds of question, and the order in which the layers run.
• Conversational UX patterns — the legibility signals a transcript cannot show.
• Chatbot accessibility (WCAG) — the keyboard and screen-reader audit for every button you render.

Sources

• Meta, Interactive reply buttons messages, WhatsApp Cloud API (developers.facebook.com/docs/whatsapp/cloud-api/messages/interactive-reply-buttons-messages), read 11 September 2026: "send up to three predefined replies"; button label "Maximum 20 characters"; body "Maximum 1024 characters"; the button_reply webhook with the button ID.
• Meta, Interactive list messages, WhatsApp Business Platform (developers.facebook.com/documentation/business-messaging/whatsapp/messages/interactive-list-messages), read 11 September 2026: "up to 10 sections, with up to 10 rows for all sections combined"; button text "Maximum 20 characters"; row title "Maximum 24 characters"; row description "Maximum 72 characters"; body "Maximum 4096 characters"; the list_reply webhook.
• Meta, Quick Replies Reference, Messenger Platform (developers.facebook.com/docs/messenger-platform/reference/buttons/quick-replies), read 11 September 2026: "A maximum of 13 quick replies are supported"; title "20 character limit"; the user_phone_number and user_email content types. Meta, Quick Replies, Instagram Messaging (developers.facebook.com/documentation/business-messaging/instagram-messaging/features/quick-replies), read 11 September 2026: "A maximum of 13 quick replies are supported and each quick reply allows up to 20 characters before being truncated"; "Instagram dismisses the buttons and posts the tapped button's title to the conversation as a message"; "This feature is currently not available on desktop."
• Telegram, Bot Features, the Keyboards and Inline Keyboards sections (core.telegram.org/bots/features), read 11 September 2026: "Bots are able to interpret free text input from users, but offering specific suggestions is often more intuitive"; custom keyboards "replace the user's keyboard with predefined answer options"; the one_time_keyboard and input_field_placeholder parameters; "pressing buttons on inline keyboards doesn't send messages to the chat."
• Google Cloud, General agent design best practices, Dialogflow CX (docs.cloud.google.com/dialogflow/cx/docs/concept/agent-design, "Last updated 2026-09-03 UTC"), read 11 September 2026: "You should have at least 20 training phrases for every intent ... roughly 50 is desirable"; "Guide the conversation" with the example "Would you like to cancel or submit that order?"; "Consider defining intents to handle non-compliant form filling answers" with the "I don't know yet" example. Google Cloud, Generative versus deterministic (docs.cloud.google.com/dialogflow/cx/docs/generative-deterministic, "Last updated 2026-09-03 UTC"), read 11 September 2026: agents "always use language models for understanding end-user intention, but you can decide whether and how language models are used for agent responses." Google Cloud, Data store hybrid agents (docs.cloud.google.com/dialogflow/cx/docs/concept/data-store/hybrid; stamped "Last updated 2026-07-29 UTC" in the copy fetched first and "Last updated 2026-09-03 UTC" when re-read about an hour later the same day, quoted text identical), read 11 September 2026: the input evaluation order beginning "Parameter input while form filling."
• IBM, 6 types of chatbots and how to choose the right one for your business (ibm.com/think/topics/chatbot-types, dated 7 March 2025), read 11 September 2026: menu-based bots "operate like a decision tree"; "might take longer to understand customer needs, especially if users must go through several iterations of menu buttons before reaching the final option"; "if a user's need isn't listed as a menu option, the chatbot will be useless because it lacks a free text input field."
• Manychat Help, Quick Reply Buttons (help.manychat.com, article 14281157129116, updated 3 December 2025), read 11 September 2026: "Limit of 11 Quick Reply options per message" with the Skip button counted; "Limit of 3 buttons per message"; "Disappear after the contact makes a selection or continues the conversation" versus "Static"; "20 characters per option"; "Quick Replies are currently available only for Facebook and Instagram"; "Retry if reply isn't a Quick Reply ... up to five retry attempts"; "Follow up if contact hasn't engaged ... (up to 24 hours)"; a Text block "cannot contain both regular Buttons and Quick Replies." Manychat Help, Manychat AI Step (article 14281187288860, updated 31 July 2026), read 11 September 2026: the option "to save the user's reply" to a field. Manychat Help, Default Reply in Manychat (article 14281159586588, updated 3 December 2025), read 11 September 2026: "It acts as a safety net, ensuring users always receive a reply"; the trigger fires "every time a user sends a message" or "once every 24 hours for the same user"; the tip to "incorporate Buttons or Quick replies to guide users in the right direction if they get stuck."
• Landbot Help, Buttons block (help.landbot.io/article/e6dfcixed0-buttons, shown as "Updated 11 months ago" when read), read 11 September 2026: Searchable options for "a long list (10 or more options)" with the twelve-cities example; Randomize Button Order; Multiple choices and the "Any of the Above" requirement; "The Buttons block is no longer fully supported on WhatsApp"; Messenger "maximum of 14 buttons per block, including 'Any of the above'"; "Each button label is limited to 20 characters"; "If the user doesn't tap a button and instead types something random, the bot will stop." Landbot Help, Any of the above Output (help.landbot.io/article/sjs29gih11-default-ouput-explained), read 11 September 2026: on WhatsApp "users always have the input field available," "buttons are displayed as a numbered list of choices," and "In case users type anything else, the flow will follow the Any of the above output." Landbot, Is Landbot a Chatbot or an AI Agent? (landbot.io/blog/is-landbot-a-chatbot-or-an-ai-agent, by Irene Pomares, 20 February 2026), read 11 September 2026: "Using buttons for company size, for example, standardizes data and avoids ambiguity"; "Visitors type freely, the system responds in lengthy paragraphs, and important details end up buried in unstructured text"; "When appropriate, the AI Agent introduces selectable options or buttons to simplify interaction and reduce cognitive load. When needed, users can also type their own questions."
• Voiceflow Documentation, Buttons (docs.voiceflow.com/documentation/buttons/steps/buttons, which redirects to the same page under voiceflow.com/docs/documentation/build/steps/buttons; no date in the Markdown rendering), read 11 September 2026: "No match: When enabled, handles situations where the user's response doesn't match any button label"; "Listen for other triggers ... When disabled, the agent only responds to button clicks"; "For agentic button generation where buttons are dynamically created based on conversation context, use the buttons system tool inside a Playbook."
• Tidio Help, Disable Text Input (help.tidio.com, article 5465426393756, dated 15 May 2025), read 11 September 2026: "your visitors won't be able to type anything in the chat while a flow is running"; "until you enable it again using the Enable text Input node or until the flow ends." Tidio Help, How do flows, Lyro, and live agents work together? (article 14667264947356, dated 4 September 2025), read 11 September 2026: "The visitor can decide to ignore or interrupt the flow by sending a chat message"; "the visitor won't be able to interrupt your flow if you've used the Disable Text Input action."
• Botpress Documentation, Autonomous Node (botpress.com/docs/studio/concepts/nodes/autonomous-node, no date on the page), read 11 September 2026: the example instructions line "Use buttons for quick replies and easy navigation whenever possible"; the "Menu choice, then transition" prompt ("If the user sends 1 ... If they send 2").
• Chatbotscape review corpus (the fifteen platform reviews listed at /reviews), searched 11 September 2026 from the repository root. Denominator: ls sample-reviews/*-review.md | wc -l returns 15. grep -liE '\bbuttons?\b' sample-reviews/*-review.md returns 12; grep -liE 'quick repl' sample-reviews/*-review.md returns 5; grep -liE 'free[- ]text|free[- ]form|open[- ]ended' sample-reviews/*-review.md returns 5; grep -liE 'list message' sample-reviews/*-review.md returns 1. Passages cited: tidio-review.md lines 574–575 (the Decision (Quick Replies) node and the 20-character warning, captured 28 May 2026); blip-review.md lines 616–617; chatbase-review.md line 461 (the auto-generated Quick Reply chips); aisensy-review.md line 708; landbot-review.md lines 708 and 714 (the Validation error message field); manychat-review.md line 617; tars-review.md lines 157 and 160.
• Ahrefs Keywords Explorer, US overview, queried 10 September 2026 — the demand figures in this guide's keyword note.
• Chatbotscape evaluation methodology. /methodology (continuously updated).

About this guide

Chatbotscape launched in 2026 as an independent review site for chatbot platforms. This guide is part of our SMB chatbot Academy and is written for the owner or marketing lead of a small business who is deciding, question by question, what a bot should let a customer do: tap, or type. It reads the channel caps from Meta's and Telegram's documentation and the typed-reply behavior of six builders (Manychat, Landbot, Voiceflow, Tidio, Botpress and Google's Dialogflow CX) as worked examples; it does not rank them, and the platforms named are those whose documentation, or our own dated review screenshots, state the behavior. Reviews of the SMB platforms are at /reviews, and each carries its own evidence level. Feedback and corrections to editorial@chatbotscape.com.

Methodology

The Meta, Telegram, Google, IBM, Manychat, Landbot, Voiceflow, Tidio and Botpress pages named in Sources were read in full on 11 September 2026, and every cap, setting name and quotation carries its source and, where the page shows one, its date; the Messenger button-template count is taken from our own quick reply vs button entry (verified 11 June 2026) rather than re-read, and is marked as such in the table. The corpus counts are ours and the commands are printed. The editorial judgments on this page: the four tests and their order, the escape-hatch rule, the six-question classification, and the two metrics. They are reasoning from the vendor documentation quoted and from the failure modes in our reviews, not a measured result; where a vendor's own guidance supports a rule (Botpress and Landbot on buttons inside AI conversations, Google on non-compliant form answers), it is quoted beside the rule.

Last updated

11 September 2026.