WhatsApp Flows vs templates: when a form beats a message

A wholesale client of mine sends about 900 order confirmations a month. When we started, their "order confirmation" was a template that said: reply with your order ID and quantity. That was it.

What came back was free text. "10 box", "ten boxes pls", "10 boxes but make it 12", "10 BX as discussed with Ramesh". Some people replied with a voice note. One person sent a photo of a handwritten slip. Every one of those needed a human to read and retype, and roughly one in twenty was misread. The error was not in WhatsApp. The error was in my client asking for structured data through a channel that treats every reply as a sentence.

That is the entire Flows-versus-templates decision, and it is not a technical question at all. It is a question about what shape you need the answer in.

What each one actually is

A template is a pre-approved message you send to someone. It can contain text, media, buttons and quick replies. Its job is to deliver a message and invite a response, and the response arrives as whatever the customer decides to type. That freedom is a feature for complaints and a liability for order numbers.

A Flow is Meta's multi-screen form rendered natively inside the chat. You define the screens and their logic as JSON, attach the Flow to a message, and the customer fills it in without leaving WhatsApp. When they finish, the completed form arrives at your webhook as structured data: named fields, typed values, one submission per order. Nothing to parse, nothing to read off a photo.

Both are messages. Only one of them is a form.

If you have not built against the API yet, the approval mechanics of template messages are worth understanding first, because Flows travel inside templates when you are outside an open conversation. I keep a walkthrough of that in the template approval guide.

The three signals that you need a form

I use the same three tests on every conversation before deciding, and they have not let me down yet.

1. The reply has a schema. If your system needs specific fields in specific formats, free text is the wrong input. An address, a GST number, a delivery slot, a list of five SKUs with quantities: each of those has a correct shape, and a sentence cannot guarantee it.

2. A mistake costs real money. A wrong pincode is a failed delivery. A wrong quantity is a credit note. A wrong pickup date is a wasted trip. When the cost of a misread is a phone call and a driver, the form pays for itself in a week.

3. There are more than two inputs in a row. Ask one question and a template is perfect. Ask name, then address, then slot, then payment method, and the customer is now writing four messages and you are now chasing the ones they abandon halfway.

If two of those three are true, build the Flow. If none are, you are about to spend a week on a form that solves a problem you do not have.

Where a template is genuinely better

I have talked more people out of Flows than into them, and here is where that conversation usually lands.

The pattern behind the table is simple: the more the reply looks like a sentence, the better a template is. The more it looks like a row in a database, the more you need a form.

There is also a rhythm argument. A template feels like a person texting you. A Flow feels like an app. For a reminder, a person is better. For an address, an app is better. Most teams get this backwards because the form is the shinier thing to build.

What Flows do not fix

Three things I have watched people expect from Flows and not get.

They do not create consent. A customer filling in a form is not the same as a customer opting in to marketing messages. If anything, capture the opt-in state as a field and store it deliberately. The rules around consent are separate from the format of the message, and opt-in is its own conversation.

They do not remove the 24-hour rule. The session window governs when you can message someone freely. A Flow sent outside a session still has to travel inside an approved template. The mechanics of that window trip up almost every first build, so read how the 24-hour window works before you design the trigger.

They do not validate your business logic for you. A Flow can check that a field is filled and that a number is a number. It cannot know that this customer is on credit hold, or that the SKU they picked is out of stock this week. For that you need an endpoint-backed flow that calls your system mid-form, and that is a real piece of engineering, not a JSON file.

The pattern I actually ship

In practice I almost never choose one. I send both, in sequence:

1. Template first, as the invitation. Short message, one clear reason to tap, and a button that opens the Flow. This is the part that gets read on a lock screen.
2. Flow second, as the capture. Four screens maximum. Prefill anything you already know: name, last order, saved address. Every field should earn its screen.
3. Confirmation template last. A summary message with the order number and the total. This is the message the customer screenshots and shows to their accountant, so make it look like a receipt.

The template does the persuasion and the Flow does the typing. Splitting them this way means you can rewrite the invitation without touching the form, and you can add a field without rewriting the message. When the two live in one artefact, every small copy change becomes a version bump and a re-test.

One more thing on sequencing: put the confirmation on the same thread, immediately. If a customer fills four screens and then hears nothing for an hour, they will message you to ask whether it worked, which puts you back to reading free text.

The build cost nobody quotes for you

A Flow is not a one-afternoon job if you do it properly, and the cost is concentrated in places that are not obvious from the docs.

• The JSON is the source of truth. Screens, fields and logic all live in it, and it has to be versioned like code. Teams that edit it by hand in a console lose track of which version is live within two months.
• Static flows are fast to ship, dynamic flows are not. The moment you need your own data mid-form, you are running an endpoint with its own auth, timeout and error handling.
• Testing on a real handset is not optional. Form behaviour inside the WhatsApp client differs from what your emulator shows, particularly with keyboards, back navigation and long lists.
• Every field is a drop-off point. A ten-field form has ten chances to lose the order. I have never regretted cutting a field; I have regretted keeping one "for reporting".

For a 900-order-a-month wholesaler, that cost amortises in weeks. For a shop sending forty appointment reminders a month, it never does.

Where this does not fit

Flows are the wrong answer when the conversation is emotional, when the input is genuinely open-ended, or when the customer is on a slow connection and a four-screen form is the difference between an order and an abandoned cart. They are also the wrong answer when your team cannot maintain the JSON, because a stale form that asks for the wrong delivery slots is worse than a text message that asks a human to check.

And if your real problem is that messages pile up unanswered in three different phones, no message format fixes it. That is an inbox problem, which is why the product I build, BNex, starts there: one shared place for the team to answer, with templates and automation on top. A form only helps once somebody is actually reading the replies.

How I would decide it in five minutes

• Write down the exact answer you need back.
• If it fits in one sentence a human can read correctly every time, use a template.
• If it has fields, formats, or more than two questions in a row, build a Flow.
• Send the invitation as a template either way.
• Confirm the result as a template, immediately.

That is the whole decision. The rest is JSON.

If you are mapping out WhatsApp for a business and cannot tell which conversations need a form, message me on WhatsApp. I will tell you which ones to build and which ones to leave as a message.

Related Reading

• WhatsApp automation: flow builder or code? covers the tooling choice underneath this one.
• Why WhatsApp templates get rejected is the checklist I run before submitting anything for approval.
• Choosing a WhatsApp Business Platform provider explains what to get in writing before you pick a vendor to run this on.