WhatsApp Questionnaire Templates: Formats That Fit a Chat Window

A question that reads fine on a laptop can fall apart on a phone, squeezed between a message from a colleague and a delivery notification. Matrix grids, ranking drag-and-drops and ten-option dropdowns don’t survive the trip. WhatsApp adds its own constraints: approved templates, a limited set of tappable elements, and a conversation window that closes.

This post covers the question formats that work in WhatsApp, the ones that should stay on the web, and five reusable questionnaire patterns. It ends with a worked example for a B2B SaaS onboarding check-in. The goal is a questionnaire your customer can finish with a thumb, in under a minute, without thinking about the tool.

The constraints that shape every WhatsApp question

Four rules decide what you can ask and how.

1. Business-initiated messages need an approved template. When you message a customer first, or after the 24-hour customer service window has closed, the opening message must be a template that Meta has approved. Free-form questions are only possible once the customer replies and the window is open.
2. Tappable elements are limited. Interactive messages offer up to three reply buttons, or a list of up to ten options. Button labels are short (20 characters at most), so “Yes, that matches our experience” won’t fit.
3. Opt-in is your responsibility. You need a phone number on the contact record and a record that the person agreed to receive WhatsApp messages from you. Many B2B contacts have given you a work email and never a messaging opt-in, so check this before planning a program.
4. Length is felt immediately. In a chat window, every question is a new message bubble. Five questions feel like a conversation. Fifteen feel like an interrogation.

Template category and pricing also depend on how Meta classifies your message. That is a separate topic, covered in our post on what WhatsApp surveys actually cost. The design point is that you get one template message to earn the first answer, so make that message count.

Question formats that work

1. Reply buttons: the single-choice workhorse

Three buttons is the best-fitting format in WhatsApp. It suits questions with a small, mutually exclusive set of answers:

1. How did the kickoff go? Great / Okay / Not great
2. Did that solve your problem? Yes / Partly / No
3. Is the person who set this up still the right contact? Yes / No / Not sure

Write the options as plain verbs or short adjectives, and keep the neutral middle option. If the answer set needs more than three choices, move to a list.

2. List messages: four to ten options, one tap

A list message opens a picker, so it works for “what was the main reason?” questions. Keep it to single choice and put the most common answers first. Always include “Something else”, because it routes people to a follow-up text question instead of forcing a wrong pick. Skipping it is the fastest way to corrupt your reason-code data.

3. A rating question that fits

An 11-point NPS scale doesn’t fit on three buttons. You have two honest options:

1. Use a list or a Flow dropdown with 0 to 10 as options. It costs one extra tap but keeps the scale intact, so your scores stay comparable with email and web results.
2. Use a three-point sentiment scale on buttons for transactional questions where you don’t need an NPS-style score.

Don’t mix the two scales and then average them together. If you want to report NPS from WhatsApp responses, use the full scale. Our post on how to calculate NPS covers the arithmetic.

4. One open-text question, placed last

People will type a sentence on WhatsApp more readily than they will in a web form, because typing is what the channel is for. Ask for one thing, specifically: “What’s the one thing we should fix first?” works better than “Any other comments?”. Put it after a tap question so the respondent has momentum, and branch it so only the relevant group sees it, for example only people who tapped “Not great”.

5. Flows for multi-field input

When a question needs more than a tap, a WhatsApp Flow gives you an in-chat form with several fields on a screen. Flows carry date pickers, photo and document pickers, and per-language versions of the same survey. That makes them the right format for:

1. Checkbox-style “select all that apply” questions
2. A target date (“when do you need this live?”)
3. Attaching a screenshot or a PDF, such as an error message or an invoice
4. A short block of two to four related fields that belong together

Flows are more work to set up than buttons, and they need the Cloud API integration to be in place. Use them where the extra structure pays off, not by default.

6. Appointment preference, with a caveat

An appointment question inside WhatsApp records the respondent’s preferred date and time. Nothing is booked inside WhatsApp. If you need an actual slot against Calendly, Google Calendar or Outlook, that happens in the web survey. A good pattern is to capture the preference in chat, then send a booking link, or have a person confirm the time. Don’t promise “you’re booked” in a message that only recorded a preference.

Formats to keep on the web

1. Matrix and grid questions. They render poorly and invite straight-lining.
2. Ranking. Drag-and-drop doesn’t exist in chat, and ranking by typing numbers produces errors.
3. Long scales repeated across many items. Ten consecutive “rate this feature” questions will end the conversation by question four.
4. Signature and payment capture. These involve side effects such as charging a card or capturing a legal signature, and they belong in a web survey with a proper confirmation step.
5. Anything needing a long explanation. If the question needs a paragraph of context, it’s a web survey with a link, not a chat message.

A common pattern is chat for the first two or three questions, then a link to the web survey for anyone who wants to continue.

Five reusable questionnaire templates

These are the structures worth saving as templates. Each is one opening message plus a branch.

1. The one-tap pulse. One question, three buttons, nothing else. Use it after a discrete event. Low friction produces the highest completion, and the cost is depth.
2. Tap plus why. Three buttons, then a list of reasons or a single open-text prompt for the people who chose a negative or neutral answer. Positive responders finish after one tap.
3. The scored check-in. A 0-10 question as a list, followed by one open question: “What’s the main reason for that score?” It’s the classic relationship pattern adapted for chat.
4. The evidence request. A tap question (“Did you hit an error?”) followed by a Flow that asks for a screenshot or document and a short description. It’s good for operations teams who need something to act on.
5. The callback preference. A tap question, then an appointment-preference question recording when the customer would like to talk. A person, or a booking link on the web, completes the job.

For the first-contact template, keep the body short, name your company, say why you’re writing, and make the first question answerable from the notification preview if possible. Approval is more predictable when the message is plain and its purpose is clear.

Worked example: a B2B SaaS onboarding check-in

Consider a B2B SaaS company that sells a workflow product to mid-market operations teams. Its implementation lead marks the kickoff and configuration call as complete in the CRM. The company wants early signs that an account is stuck, before the customer goes quiet. This is a hypothetical setup to illustrate the structure.

Step 1: the trigger

The CRM sends a webhook when the implementation call is marked complete, and a workflow picks it up. The webhook carries the customer’s contact ID, the account, and the phone number with a recorded WhatsApp opt-in. If there’s no opt-in, the workflow falls back to email. It never sends to someone who hasn’t agreed.

Step 2: the opening template

The approved template reads: “Hi Priya, thanks for the kickoff with us today. One quick question: how did it go?” with three buttons: Great, Okay, Not great.

Step 3: branch on the tap

1. Great: a thank-you, then one optional open-text question: “Anything we should repeat for your next team?” The questionnaire ends there.
2. Okay or Not great: a Flow opens, containing four fields on one screen:
3. A multi-select of blockers: SSO setup, data import, permissions, team training, something else
4. A date picker for “When does your team need to be live?”
5. An optional photo or document picker for a screenshot or file
6. A callback preference for the best time to talk

The Flow is built once and can have per-language versions, so a customer in Madrid gets the same questionnaire in Spanish. The callback preference only records the time. The CSM follows up with a booking link, which is where Calendly or Google Calendar enters the picture, because booking happens in the web survey rather than in WhatsApp.

Step 4: route and act

The workflow acts on the structured answers, not on a text blob. Text Blob needs to go via text ananlytics before being useable for conditionals. “Not great” combined with “SSO setup” goes to the implementation engineer. “Not great” combined with a go-live date inside two weeks goes to the implementation lead with higher priority. “Okay” with “team training” gets a reminder to the CSM to schedule a session. Each answer is a field, so each routing rule is simple to write and easy to audit.

Step 5: read it against the rest of the account

The WhatsApp responses land in the same analytics as web and email responses. Joined on the customer’s own contact ID, you can compare “Not great” kickoffs against product usage in the first weeks and against support tickets opened by the same account. If accounts that cite data import as a blocker also show few completed events in the product, you have a reason to rewrite the import guide and not just chase those customers one by one. This is the analytics side of the work: the chat message is the collection point, not the whole system.

What this setup requires

1. A WhatsApp Business setup on Meta’s Cloud API, with the template approved before you can send.
2. Recorded opt-in for every contact, plus a phone number on the contact record.
3. A webhook or event source that tells the workflow when to send. A CRM stage change works, as does a clickstream event from your product.
4. A named person who owns the follow-up. Routing rules are only useful if someone acts on what lands in their queue.

Testing the template before you send it

1. Read it on a phone. Send it to yourself and check that the first question is visible without scrolling.
2. Count the taps. A happy-path respondent should finish in one or two. An unhappy one can take four.
3. Check every branch. Use a test number and walk each path, including “Something else” and ignoring the open-text prompt.
4. Check the translations. Button labels have a character limit, and some languages need more room than English.
5. Plan for no answer. Decide in advance what happens when the customer doesn’t reply. One reminder inside the window is plenty. After that, stop.

The rule of thumb

Ask what a person can answer with a tap, and save typing for the one question where their own words matter. Use Flows when you need structure, such as dates, files or multi-select. Keep ranking, grids and payment off the channel, and be clear about what each element does: a preference isn’t a booking. A short, honest questionnaire gets answered, and its structured answers can drive real next steps. You can browse survey templates to adapt for the web portion of the journey.

How SurveyAnalytica helps

SurveyAnalytica runs WhatsApp surveys on Meta’s Cloud API directly, with WhatsApp Flows, programmatic template creation, and responses landing in the same analytics as every other channel, so the questionnaires above can be built, branched and routed to the right owner from one place. See how it works at SurveyAnalytica’s WhatsApp workflows.