WhatsApp Flows vs chatbots: When to use which

WhatsApp Flows arrived in late 2023 and quietly changed what's possible inside a chat window. For the first time, businesses can render multi-screen forms — with input fields, dropdowns, date pickers, and conditional logic — entirely inside WhatsApp, no browser detour.

A lot of teams now ask "should we still build a chatbot, or do we just use Flows?" The honest answer is "both, and they do different things." This piece walks through where each fits and how to combine them.

What is a WhatsApp Flow exactly?

A Flow is a Meta-defined JSON document that the WhatsApp app renders as a native form-style sequence of screens. Each screen can have:

• Text headers and paragraphs
• Single-line and multi-line text inputs
• Single-select and multi-select dropdowns
• Date pickers
• Photo / file pickers
• Footer buttons (Next, Submit)
• Conditional navigation based on previous answers

When the user taps Submit, all the data is posted as a single payload to your webhook. No 25-back-and-forth message thread.

The visual language is WhatsApp's own — buttons, fonts, spacing all match the chat — so users don't feel they've been thrown into a third-party form. Conversion rates we see on lead-capture Flows are typically 1.6–2.4× higher than equivalent web forms reached from a click-to-WhatsApp ad.

What is a chatbot in this context?

For our purposes, a "chatbot" is a sequence of conditional message + reply steps inside the WhatsApp chat itself. The user types or taps a quick-reply button, the bot reads the input, picks a branch, sends the next message. There's no separate UI — every interaction is a chat bubble.

Two broad chatbot styles:

• Keyword chatbots — match on the user's free-text input ("hi", "menu", "support"). Simple, robust, very common.
• Button-driven chatbots — every step ends with one or more quick-reply buttons; the user taps to advance. More guided, less open.

WBIZ ships both as part of the Automations module.

When to use a Flow

Flows shine when you need structured data from the user, especially when more than 2–3 fields are involved.

Good Flow use cases:

• Lead qualification — name, company, role, budget, timeline. Five fields in a single screen, submit, route to sales.
• Appointment booking — service type → date picker → time slot → contact details.
• KYC / onboarding — multi-screen wizard with document upload.
• Insurance quote — age → health questions → cover amount → city.
• Order modification — pick which order, pick what to change, confirm.
• Survey / NPS — multi-question rated form.

Anything you'd otherwise build as a 5-step chatbot back-and-forth, you should build as a single Flow. The user's experience is dramatically smoother — and Meta's policy treats a Flow as a single conversation regardless of how many screens it has, so the cost is the same as a single message.

When to use a chatbot

Chatbots are still the right tool when:

• The interaction is short and conversational ("hi" → menu → pick one of three things → done).
• You want branching dialogue that feels human rather than a form.
• The user's input is likely to be a yes/no/free-text rather than a structured field.
• You're handling support routing ("I have a question about my order" → bot collects order ID → hands off to human).
• You're sending proactive nudges that have a single CTA reply ("Reply STOP to opt out").

In these cases, a Flow would feel heavy. The customer expects a conversation, not a form.

When to combine them

The most powerful patterns combine both. A chatbot can act as the conversational front-door, gate the user, then launch a Flow when structured data is needed.

Example — a clinic appointment journey:

1. User messages "appointment".
2. Chatbot replies with three quick-reply buttons: "New patient", "Existing patient", "Talk to receptionist".
3. User taps "New patient".
4. Chatbot launches the New Patient Booking Flow — a 3-screen Flow capturing name, DOB, symptoms, preferred slot, address.
5. On Flow submit, the chatbot sends a confirmation card and creates the appointment in your back-office.

This pattern has the chatbot doing what it's good at (greet, classify, route) and the Flow doing what it's good at (collect a structured payload).

Encryption — the one technical thing to know

Flows come in two flavours:

• Static Flows — JSON is fixed. No server callback during the form. Ship-and-forget.
• Dynamic Flows — your server is called between screens to provide the next screen's data (e.g. "fetch available slots for this date"). Powerful, but requires you to host an HTTPS endpoint and implement Meta's encryption protocol (RSA + AES-128-GCM).

If you go dynamic, you'll need:

• A 2048-bit RSA key pair generated specifically for Flows.
• The public key uploaded to your WABA.
• Your endpoint to decrypt incoming requests and encrypt the response with the per-request AES key.

WBIZ handles the encryption layer for you when you build a Flow inside the platform — so you can use dynamic Flows without writing the cryptographic plumbing yourself. If you're going direct via Cloud API, expect a few days of careful implementation.

Common pitfalls

Trying to do too much in one Flow

Flows are great, but they're not infinite. Hard caps to remember:

• Max 10 screens per Flow.
• Max 8 fields per screen.
• Max 5MB total Flow JSON size.

If your form needs more, split it across two sequential Flows or make it conditional.

Using a Flow when a quick-reply would do

A "Yes / No" question doesn't need a Flow. Use a quick-reply button. Flows that ask one question annoy users — they expect Flows to be substantial.

Treating Flow submissions as final

The user taps Submit, your webhook fires — but the user is still in the chat. Use that moment. Send a confirmation message immediately, and ideally a follow-up CTA ("Want to also book a follow-up? Tap here.") so the conversation keeps going.

Ignoring the data in your CRM

A Flow submission is a structured JSON payload. Push it to your CRM, your warehouse, or a Slack channel — wherever your team actually works. WBIZ has webhook routing built-in for this exact purpose.

A starter Flow

If you want to ship a Flow this week, start with lead qualification. The data shape is well-understood, the value is obvious to your sales team, and you'll see the conversion uplift inside a week.

A 1-screen, 5-field qualification Flow ("Name / Company / Role / Monthly volume / Best time to talk") routed into your CRM is, in our experience, the single highest-leverage automation a B2B WhatsApp deployment can ship.

Measuring Flow performance

Once you've shipped a Flow, instrument it from day one. The metrics that matter:

• Open rate — what fraction of users tap into the Flow when prompted? Below 60% means the entry message isn't compelling.
• Completion rate — what fraction who open the Flow tap Submit? Below 50% means the form is too long or asking for too much.
• Drop-off by screen — which screen do users abandon on? Almost always the one with the field they don't want to share (DOB, salary, company size).
• Submit-to-conversion rate — of users who submit, how many become customers/leads/bookings? Below 20% means your qualification fields aren't predictive.

WBIZ tracks all four out of the box on every Flow. If a Flow has been live for two weeks and one of these is below the benchmark, the dashboard will flag it.

The biggest source of Flow performance gains is iteration on the entry message — the chat bubble or button that prompts the user to open the Flow. Small copy changes there often double the open rate without touching the Flow itself.

Build it, measure it, then expand. Both Flows and chatbots reward iteration far more than upfront design.