Buttons, lists or free text: choosing how customers answer

Every question a bot asks makes a choice about how the answer arrives. Offer buttons and you get a clean value and learn nothing you did not already anticipate. Ask openly and you get what the customer actually meant, in a form somebody has to interpret.

Most implementations pick one and apply it everywhere, which is why so many feel either like a phone menu or like shouting into a void. The choice should be made per question, and the deciding factor is whether you already know the full set of possible answers.

What we'll cover

• The real question
• What the platform gives you
• When structured input wins
• When free text wins
• The limits that bite
• Building it with CodeWords
• Always leave the door open
• A tapped button is weak evidence
• Accessibility, and who buttons exclude
• What the numbers tell you
• Making it survive
• Limits worth knowing about
• What to change first
• Frequently asked questions

The real question

Not which is nicer. Whether you genuinely know every answer somebody might give.

For "which of these three dates suits you", you do. The set is closed, you produced it, and anything outside it is not available. Buttons are correct.

For "what's wrong with it", you do not, and any list you write is a guess that will be wrong for a meaningful share of people. Free text is correct, and the moment somebody has to pick "other" you have wasted a turn and learned nothing.

The failure mode is offering a closed set for an open question. A customer forced to choose the nearest wrong option has given you data that is worse than nothing, because it looks clean and is untrue.

What the platform gives you

Three shapes, with limits that are part of the design rather than details.

Reply buttons. A small number of options shown as tappable buttons, with short labels. Good for a binary or a very small closed set.

List messages. A larger set behind a tap, grouped into sections, with a title and description per row. Good for a genuine menu.

Free text. Anything the customer types, plus media and voice notes, which are frequently the most informative thing they send.

The limits on option counts and label lengths are tighter than people expect and they change, so check the current specification before designing around a number. Two practical consequences: a label that fits in English may not in another language, and a list long enough to need scrolling has usually replaced one good open question.

When structured input wins

Closed sets you control. Appointment slots, service types you actually offer, yes or no.

Anything you will act on automatically. A tapped value needs no interpretation, which matters where the next step is a booking rather than a person reading it.

Confirmations. A single button is the cleanest possible yes.

Where typing is hard. Somebody driving, in the cold, or on a cracked screen.

Where free text has been ambiguous. If a question keeps producing answers you cannot parse, that is evidence the set is closed enough to offer.

Structured input also caps the conversation length, which after the October 2026 pricing changes is a small but real cost consideration.

When free text wins

Anything descriptive. What is wrong, what happened, what they need. A list here is a guess.

First contact. "How can I help?" produces far better information than a menu, and the reply tells you what to build next.

Anything where the customer knows more than you. Their situation, their history, their constraint.

Where the set is large. Twenty options behind a tap is a worse experience than typing three words.

Where you are still learning. Open questions during the first month are how you discover what the closed set should eventually be.

There is a reason the best first message in this medium is a question rather than a menu: it gathers the one thing a designed flow cannot, which is what people actually want.

The limits that bite

Label length, which is short enough to force abbreviation, and abbreviations read badly.

Option counts, which are lower than a designed menu usually wants.

Translated length, where the same label overflows in another language.

People type anyway. A customer sent buttons may reply in words, and a flow that only accepts a tap will break on it.

Old clients and forwarded messages do not always render interactive elements as intended, so the underlying question should still make sense as plain text.

That last point is a useful discipline generally: if the message is incomprehensible without its buttons, it is badly written.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which questions have a closed set of answers, which are open, and what happens when somebody types instead of tapping.
3. Authorize the connections to your existing systems and your WhatsApp Business Platform account.
4. Describe the exceptions: an answer outside the options, a question you did not anticipate, somebody asking for a person.
5. Look at how often people type instead of tapping, since a high rate on a particular question means the set is wrong.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Always leave the door open

Whatever you offer, accept what people send.

Somebody presented with three dates will reply "have you got anything the week after". Somebody offered service types will describe their problem instead. Both are reasonable, and a flow that responds by repeating the options is the single most irritating thing in this medium.

So: always parse free text alongside the options, never repeat the same buttons a second time after an unmatched reply, and treat a typed answer that does not fit as a signal rather than an error. If it happens often on one question, the question is wrong.

Include an escape in anything with more than a couple of steps. "Or just tell me what you need" costs a line and prevents the trapped feeling that makes people give up and ring.

A tapped button is weak evidence

Worth thinking about before using taps as confirmation for anything consequential.

A tap is one gesture, easily made by accident, frequently made without reading. For "which day suits you" that is fine. For "confirm this £340 of work" or "yes, cancel my appointment", it is thinner evidence than it looks.

Two habits. For anything that costs money or destroys something, ask for a typed confirmation or follow the tap with a written restatement of what was agreed. And keep the record of what the button actually said, because a label changed three months later leaves you unable to say what somebody agreed to.

Accessibility, and who buttons exclude

Structured input is usually the more accessible option and not always.

It helps people who find typing difficult, people with limited literacy in the written language, and anyone in a hurry or in bad conditions.

It works against people using a screen reader where labels are abbreviated to fit, people on old devices where components render imperfectly, and people whose answer is genuinely not in your list, who are then forced to misrepresent themselves.

The resolution is the same in every case: offer the structure, accept anything, and make sure the question reads sensibly without its buttons. That combination serves everybody and costs nothing.

What the numbers tell you

Four measurements, all cheap, and each one answers a design question you would otherwise argue about.

Typed answers on a button question. The clearest signal there is. Above a low threshold, your closed set is missing something real.

Which option is never chosen. An option nobody picks is either wrong, badly labelled, or listed somewhere nobody scrolls to. Remove it and see whether anything changes.

Drop-off by question. Where people stop tells you which question is too early, too intrusive or too hard to answer on a phone.

Time to answer. A question that takes people a long time is usually one that requires them to go and find something, which is worth knowing before you put it third in a flow.

None of these require analytics tooling. A month of conversations and an afternoon of counting produces all four, and the answers are consistently more surprising than the debate that preceded them.

Making it survive

Measure typed answers per question, and treat a high rate as a design signal.

Check label length in every language before submitting templates.

Never repeat the same options after an unmatched reply.

Record what a button said, not just which one was tapped.

Re-read the questions as plain text periodically, without their components.

Limits worth knowing about

Option counts and label lengths are fixed by the platform and change, so check before designing.

A clean value is not a true one if the customer had to pick the nearest wrong option.

Taps are weak evidence for anything consequential.

Buttons cap discovery, so an all-structured bot never learns what it is missing.

Rendering varies across clients and forwarded messages.

What to change first

Accept free text everywhere, including on questions where you offer buttons. Most implementations reject a typed answer and repeat the options, which is the behaviour customers complain about most, and fixing it is usually a small change.

Two habits make the difference. Choose per question rather than per bot, using whether you genuinely know every possible answer as the test. And watch how often people type on each question, because that number tells you which of your closed sets are guesses.

Frequently asked questions

How do I choose between buttons and free text?

Ask whether you genuinely know every answer somebody might give. Closed sets you control get buttons; anything descriptive gets free text. Decide per question rather than per bot.

What does the platform offer?

Reply buttons for a small closed set, list messages for a larger menu behind a tap, and free text including media and voice notes. Option counts and label lengths are limited and change.

When is structured input the right choice?

Closed sets, anything acted on automatically, confirmations, situations where typing is hard, and questions where free text has repeatedly been ambiguous.

When is free text better?

Anything descriptive, first contact, anything where the customer knows more than you, large option sets, and the first month when you are still learning what the closed set should be.

What if someone types instead of tapping?

Accept it. Always parse free text alongside the options, never repeat the same buttons after an unmatched reply, and treat frequent typing on one question as evidence the set is wrong.

Is a tapped button good enough as confirmation?

For low-stakes choices, yes. For anything that costs money or cancels something, ask for a typed confirmation or follow the tap with a written restatement of what was agreed.

What should be recorded when somebody taps?

What the button actually said, not just which one. Labels change, and without the text you cannot say later what somebody agreed to.

Are buttons more accessible?

Usually, for people who find typing hard or are in a hurry. They work against screen reader users where labels are abbreviated, old devices, and anyone whose real answer is not in the list.

Do translated labels cause problems?

Yes. The same label can overflow in another language, so check length in every language before submitting templates rather than after rejection.

What is the most common mistake?

Offering a closed set for an open question. A customer forced to pick the nearest wrong option gives you data that looks clean and is untrue.

Related reading

• How a bot should sound
• Multi-stage flows and keeping state
• The smallest version worth launching