Interactive Messages on WhatsApp: When a Button Is Worth More Than a Question

List: when a button doesn’t fit

The list solves the case of many options without turning the message into a wall of text. It appears as a single button; when tapped, it opens a menu organized in sections, with a title and description for each item.

It’s the right format to choose a unit, service, time slot, product category, or reason for contact. And it has two often overlooked advantages: the description of each item allows explaining the option without cluttering the conversation, and the list doesn’t take up screen space while closed — the conversation remains readable.

A common mistake is using a list where two buttons would fit. The menu adds an extra tap and a moment of reading; when there are two obvious options, the button always converts better.

A design caution is worth noting: a long list is a symptom of a poorly designed process. Fifteen options mean the company is asking the customer to do the triage that should be done by someone who knows the business. Two short chained lists — category then item — work better than one giant list.

Action buttons: link, call, and code

Action buttons don’t return a choice; they perform something on the device. Each has a natural use and a frequent misuse.

The link button is used to take the person to payment, tracking, document, or scheduling. Misuse is sending to the homepage — the person leaves the conversation and gets lost. Links in messages must arrive exactly where the conversation left off, preferably already identifying the customer.

The call button is underrated. In urgent services, it converts more than any question flow, because someone with a burst pipe doesn’t want to fill anything out.

The copy code button solves a small but annoying problem: coupons the person has to select manually, and verification codes typed incorrectly. It’s mandatory in authentication format and optional in promotions.

One operational detail: the link button can be dynamic, with part of the address coming as a variable. This allows the same template to take each customer to their own order. Without this, each campaign would require a new template.

Button in template requires approval

Here lies the distinction that confuses beginners the most: within the service window, the company freely creates buttons; outside it, buttons are part of the template and undergo review.

In practice:

• If the customer wrote in the last few hours, the company responds with buttons or lists created on the spot, with no approval needed.
• If the company is initiating the conversation, buttons must be in the approved template — text and type defined beforehand, no improvisation.

This has an important design consequence: the template that starts the conversation should include buttons that open the service window. A template without a button asks the person to type, and many don’t type. A template with "I want to know more" and "I’m not interested" turns a broadcast into an open conversation — from there everything is free and cheaper.

There is also the list, which is not available inside templates the same way buttons are. The working standard is: template with buttons to open the conversation, list right after, with the window already open.

What the choice returns to your system

When the person taps a quick reply button, the company’s system receives an event with the identifier of that option — not the text shown on screen, but a code defined by whoever created the message.

This changes what can be built. With free text, automation depends on interpreting words. With an identifier, it branches precisely: whoever tapped "quote" goes to one queue, whoever tapped "support" to another, and there is no ambiguity.

Three precautions to avoid rework:

• Use stable and readable identifiers, like confirm_appointment. Changing the button text later should not break automation.
• Store the choice in the contact record, not just in the flow. It’s commercial information: whoever tapped "still interested" is a hot lead and this needs to survive beyond the conversation.
• Also handle text responses. There will always be people who write "I want" instead of tapping. Ignoring them because they didn’t use the button is the worst possible outcome.

How not to become a menu IVR

The risk with interactives is building on WhatsApp what customers already hate on the phone: a menu tree that never reaches a person. Four rules prevent this.

Maximum depth of two levels. After the second menu, the conversation must reach someone or resolve the issue. Three levels already cause abandonment.

Human exit always visible. One option must be "talk to a person" at every level. Hiding this option doesn’t reduce service cost — it increases complaints.

Menu is not a welcome. Opening the conversation with a seven-item menu before knowing what the person wants reverses the order. Better to ask in one sentence and use the menu later, once the category is known.

Existing customers don’t go through triage. If the system recognizes the contact and knows there is an ongoing order, the first button should be about that order — not the generic menu.

Writing a button

Space is short and every word counts. What works:

• Verb in first person. "I want to reschedule" converts better than "Rescheduling," because it describes the intention of the tapper.
• One idea per button. "See price and deadline" divides attention; choose one.
• Parallel options. If one button is "I confirm," the other is "I need to reschedule" — not "Other options," which is not the same nature.
• No ambiguity between buttons. "Support" and "Help" in the same message paralyze the person.
• The negative is also a button. Offering "I’m not interested" may seem like losing a sale but actually protects the number because it replaces complaints.

An operation in numbers

A clinic with 1,200 appointments per month serves as an example. The plain text reminder, asking "reply YES to confirm," had:

• 1,200 reminders sent
• 1,068 delivered — 89%
• 374 responses — 35% of delivered
• No-show rate of 18% on the schedule

Switching the text to a template with two buttons — "I confirm" and "I need to reschedule" — and keeping everything else the same:

• 1,068 delivered, same level
• 726 responses — 68% of delivered
• Of these, 91 tapped "I need to reschedule"
• No-show rate of 9% on the schedule

The important takeaway isn’t the no-show rate halving — it’s where it came from. The 91 people who tapped "I need to reschedule" were previously silent no-shows: slots no one knew would be empty. With the button, they became advance notices, and each one is a slot the reception can rebook. With an average ticket of R$ 220, the 91 recovered slots represent about R$ 20,000 per month that previously evaporated — produced by two buttons that replaced the word "YES."

Five mistakes with interactives

• Asking to type when a button solves it. Every typing charges a toll and some people give up along the way.
• Using a list where two buttons would fit. The menu adds a tap and a moment of reading, and converts less.
• Sending a template without buttons to start a conversation. Misses the chance to open the window, which makes everything else free and cheaper.
• Hiding the human exit. Doesn’t reduce service cost; increases complaints and reports.
• Ignoring those who respond in text. There will always be people who write instead of tapping, and they tend to be the most interested.

Numbers to track

Five indicators show if interactive formats are working. The interaction rate on delivered — how many tapped an option — is the direct measure of the format. The distribution of choices reveals what the audience really wants and often contradicts company assumptions. The abandonment rate by menu level shows at what depth the conversation dies and usually condemns the third level. The proportion of free-text responses even with buttons available indicates if options cover real cases. And the human exit activation rate should not be treated as automation failure but as data showing where self-service still doesn’t resolve.