WhatsApp Flows: interactive forms and experiences inside conversations

Home / Everything About / Everything About Social Media / WhatsApp Flows: interactive forms and experiences inside conversations

The form is the moment most leads disappear. A customer interested enough to message a brand hits a question that requires them to type out their name, date preference, address, and service choice one message at a time in a chat window, and the effort alone is enough to make them stop. WhatsApp Flows replace that back-and-forth with a native form experience built inside the conversation itself. Instead of asking questions sequentially and waiting for each reply, a Flow presents a structured screen with fields, dropdowns, date pickers, and selectors that the contact fills in and submits in one action, without leaving WhatsApp.

This article covers what WhatsApp Flows are, what they can be used for, how they are built and sent to contacts, and how to measure whether they are working.

What are WhatsApp Flows and how do they work?

The difference between a flow and a regular conversation

A regular WhatsApp conversation is unstructured: the contact types whatever they want, the brand responds, and the exchange continues until something is resolved or agreed. This works well for open-ended conversations but poorly for situations where the brand needs specific, structured information from the contact. A WhatsApp Flow is a pre-built interactive screen, or sequence of screens, that presents form fields, options, and selections in a defined structure. The contact completes the screen and submits it as a single action, and the brand receives the data in a structured format rather than scattered across multiple messages. Flows are not a replacement for conversation. They are a tool for the moments in a conversation where structure produces better results than freeform exchange.

How flows appear to contacts inside WhatsApp

When a Flow is triggered, a button appears in the conversation for the contact to open it. Tapping the button opens a full-screen overlay inside WhatsApp that contains the form or interactive experience. The overlay looks and behaves like a native app screen: it has fields, labels, input controls, and a submit button. The contact fills it in and submits, the overlay closes, and a confirmation message appears in the conversation. The entire interaction happens inside WhatsApp without opening a browser or switching to another app. From the contact's perspective, it feels like using a form that is part of the WhatsApp experience rather than being redirected somewhere external to complete a task.

Which accounts can use WhatsApp Flows

WhatsApp Flows are a Business Platform (API) feature. They are not available in the WhatsApp Business app. Brands need a WhatsApp Business API connection, accessed through a business solution provider or directly via Meta's API, to build and send Flows. This means Flows are used by brands with higher conversation volumes, more complex customer journeys, or operational needs that justify the API setup. For smaller brands using the WhatsApp Business app, Flows are not currently an option, though the feature set available in the app has expanded over time. Any brand considering Flows as part of their WhatsApp setup needs an API connection before any flow-building can begin.

How flows connect to backend systems

Flows can operate in two modes: as static forms where the fields and options are fixed when the flow is built, and as dynamic flows where the content of screens is populated in real time from a connected backend system. A static flow for appointment booking might present a fixed list of available time slots. A dynamic flow for the same purpose would call an endpoint when the contact opens it, pull the current available slots from the booking system, and display only the times that are genuinely open at that moment. Dynamic flows require an endpoint that responds to WhatsApp's data requests within a defined time window, but they produce a far more accurate experience for use cases where the available options change frequently. Connecting flow submissions to a backend system, so that a completed form creates a booking, a lead record, or a support ticket automatically, removes the need for a team member to manually process each submission.

The Flow Builder and how flows are created

WhatsApp Flows are built using Meta's Flow Builder, a visual editor accessible through the Meta Business Suite or the WhatsApp Manager. The Flow Builder allows screens to be designed with a drag-and-drop interface using a set of available components: text fields, dropdowns, radio buttons, checkboxes, date pickers, image displays, and text blocks. Each screen can have one or more components, a title, and a footer with a submit or continue button. Flows can have a single screen for simple use cases or multiple screens that progress in sequence, with each screen's content optionally depending on the contact's responses on previous screens. Once a flow is designed and tested, it is submitted for review by Meta before it can be sent to contacts, which adds a review step that brands should account for in their planning timeline.

What can you use WhatsApp Flows for?

Appointment booking and scheduling

Appointment booking is one of the clearest use cases for WhatsApp Flows because the alternative, asking a contact to pick a date and time through freeform messages, is slow and error-prone. A booking flow presents available dates and times, collects the contact's preference in a single screen, confirms the booking in the same conversation, and can send the data to a calendar or booking system automatically. For service brands where appointments are the primary conversion point, a booking flow shortens the path from first contact to confirmed appointment from several messages exchanged over potentially hours to a single interaction completed in under a minute. Dynamic booking flows that pull real-time availability from a connected calendar system prevent the problem of a contact selecting a slot that has since been taken.

Lead capture and qualification

A lead capture flow collects the specific information a sales team needs before following up: name, contact details, the nature of the inquiry, budget range, timeline, and any other qualifying data the brand has identified as relevant. This replaces a series of qualifying questions asked one by one in conversation, which requires the sales team to be active in the conversation and creates gaps when responses come hours apart. A lead flow sent at the start of an inquiry conversation collects all qualifying data in one submission and routes it to the sales team in a structured format, so the team can review the lead and respond with relevant information rather than starting every conversation from scratch. For brands with high inquiry volumes, a qualification flow also filters out contacts who are not yet serious buyers, which concentrates the sales team's time on leads most likely to convert.

Customer support triage and routing

Support triage flows collect information about an issue before a support agent engages, which means the agent receives the contact with context rather than needing to ask the same opening questions in every conversation. A triage flow might ask for the product or service involved, the nature of the problem, whether the contact has already tried specific steps, and the contact's order number or account reference. The submitted data can route the conversation to the correct team or agent automatically, apply a label in the conversation management system, or trigger an automated response with relevant troubleshooting steps if the issue matches a known pattern. For support teams handling multiple product lines or issue types, triage flows reduce the average handling time per conversation by eliminating the diagnostic opening exchange.

Surveys and feedback collection

Feedback flows sent after a purchase, a service appointment, or a support resolution collect structured ratings and open responses within the same WhatsApp conversation the customer has been using throughout their journey. Because the feedback request arrives in a channel the customer is already engaged with, and because completing a flow requires less effort than following a link to an external survey tool, response rates for WhatsApp-based feedback flows tend to be higher than for email or SMS survey links. The flow can include a rating scale, a multiple-choice question about the specific aspect of the experience, and an optional open text field for comments. Keeping feedback flows short, two or three questions at most, produces higher completion rates than longer surveys that ask for too much in a single interaction.

Registration, onboarding, and data collection

Flows suit any situation where a brand needs to collect structured data from a contact as part of an onboarding or registration process: event registration, membership sign-up, warranty registration, or preference collection for a loyalty program. A registration flow can collect name, contact details, delivery address, product preferences, and consent for communications in a single multi-screen experience that takes under two minutes to complete. For brands that previously handled registration through email forms or landing pages, moving registration to a WhatsApp Flow puts the process in the channel where the customer is already active, which typically increases completion rates. The submitted data can populate a CRM record, trigger a welcome message sequence, or create an account in a connected system automatically on submission.

How do you build and send a WhatsApp Flow?

Screen types and layout components

WhatsApp Flows support several screen types, each designed for a specific purpose. A form screen collects input from the contact through a combination of components: short text fields for names and references, long text fields for open responses, dropdown menus for single selection from a list, radio buttons for choosing one option from a small set, checkboxes for multiple selections, date pickers for scheduling, and image components for displaying visual context. A confirmation screen presents a summary of the contact's selections before submission. An end screen closes the flow with a message or next step. Each screen can combine multiple components, but keeping each screen focused on a single task or decision produces a cleaner experience and higher completion rates than packing every question onto one screen.

Dynamic flows: pulling live data into screens

Dynamic flows connect to an endpoint that the brand controls, which is called when the contact opens the flow or moves between screens. The endpoint returns data that populates the screen content: available time slots, product options, personalized information based on the contact's account, or any other data that changes over time or varies by contact. Building a dynamic flow requires a working endpoint that responds within WhatsApp's timeout window, returns data in the expected format, and handles errors gracefully when data is unavailable. The technical investment is higher than for a static flow, but the accuracy improvement is significant for any use case where the options presented to the contact need to reflect the real state of the brand's systems at the moment of completion rather than at the moment the flow was built.

Testing a flow before sending it live

The Flow Builder includes a preview mode that simulates how the flow will appear to contacts, which allows the screen layout, field labels, and navigation to be reviewed before submission. Beyond the visual preview, flows should be tested on a real device using a test phone number to verify that the experience works as intended in an actual WhatsApp conversation. For dynamic flows, the test should confirm that the endpoint responds correctly, that the data displayed in the flow is accurate, and that the submission sends the expected data to the connected system. Meta requires flows to pass a review before they can be sent to contacts, but the review checks for policy compliance, not for operational correctness. The brand is responsible for ensuring the flow works as intended before it reaches real contacts.

Sending a flow to contacts: triggers and entry points

A WhatsApp Flow is sent to a contact as a message containing a button that opens the flow. The message can be sent manually by a team member in an individual conversation, triggered automatically by a chatbot or automation when certain conditions are met, or included in a template message sent as part of a proactive outreach campaign. A booking flow might be triggered automatically when a contact sends a message containing "book" or "appointment." A feedback flow might be triggered by an automation rule that fires 24 hours after an order status is marked as delivered in the connected e-commerce system. The trigger logic determines how and when contacts encounter the flow, and well-designed trigger conditions ensure the flow appears at the right moment in the conversation rather than at an arbitrary point that feels out of context.

Getting flows approved by Meta

All WhatsApp Flows must be submitted to Meta for review before they can be sent to contacts. The review process checks that the flow complies with WhatsApp's commerce and messaging policies, does not collect prohibited data types, and meets the platform's standards for contact experience. Review times vary and can take several days. Flows that collect sensitive personal data, financial information, or health-related information are subject to additional scrutiny and may require specific disclosures or consent language within the flow. Building in time for the review and potential revision before a campaign or feature launch prevents the situation where a flow is built and ready but cannot be sent because it is still pending approval. Submitting flows well in advance of any planned send date is the practical standard for brands using Flows as part of a scheduled campaign.

How do you measure and improve flow performance?

Completion rates and where contacts drop off

The primary metric for a WhatsApp Flow is the completion rate: the percentage of contacts who open the flow and submit it versus those who open it and abandon before submitting. A low completion rate signals that the flow is too long, too complex, confusing at a specific screen, or asking for information the contact does not have or is not willing to provide. Meta's Flow analytics show open and completion counts, and for multi-screen flows, the drop-off point between screens reveals where the experience breaks down. A screen with a high drop-off rate is usually asking for something the contact cannot easily answer, presenting too many options at once, or following a screen that has already asked too much. The fix is almost always simplification: fewer questions per screen, clearer labels, or removing a question that is not necessary for the brand's operational purposes.

Connecting flow submissions to your CRM or booking system

A flow that collects information but does not send it anywhere useful creates manual work: a team member reads the submission in the conversation and enters the data into a separate system by hand. Connecting the flow submission to a CRM, booking system, helpdesk, or spreadsheet through an API endpoint or a connected automation tool removes this step and makes the data usable without manual intervention. The connection is configured on the endpoint that receives the flow submission data and maps each field to the corresponding field in the destination system. For brands without in-house technical resources, many business solution providers offer pre-built integrations between WhatsApp Flows and common CRM and booking tools that do not require custom development. Getting this connection right from the start determines whether the flow creates operational efficiency or just moves the manual work from the conversation to a separate data entry task.

Common flow design mistakes that reduce completion

The most common design mistake is building a flow that is too long. A contact who opens a flow expecting a quick interaction and finds six screens of questions will abandon it before completing, and the brand loses the data entirely. A flow of one to three screens with a clear purpose completes at a higher rate than a flow that tries to collect every piece of information the brand might ever need. The second most common mistake is using unclear field labels that require the contact to guess what format or level of detail is expected. A field labeled "date" with no guidance on format or available range produces inconsistent responses or abandonment. A date picker component is better than a free text field for date inputs because it removes the format question. The third mistake is sending a flow at the wrong point in a conversation, before the contact has enough context to know why they are being asked for information.

When to use a flow versus a chatbot

Flows and chatbots solve different problems. A chatbot handles unstructured conversation: it reads what the contact sends, interprets intent, and responds appropriately. A flow handles structured data collection: it presents defined fields and collects specific information in a controlled format. The practical distinction is that a chatbot works well when the brand does not know what the contact will say, and a flow works well when the brand knows what information it needs and wants to collect it efficiently. Many WhatsApp automation setups use both: the chatbot handles the opening conversation, identifies that the contact wants to book an appointment or make a complaint, and then triggers a flow to collect the specific details needed for that task. Choosing between them comes down to whether the brand needs to interpret what the contact says or simply collect what the brand already knows it needs. For how chatbots work in more detail, see WhatsApp chatbots: building automated conversation flows.

Keeping flows current as products and processes change

A flow built for a specific product range, service list, or process becomes outdated when any of those change. A booking flow that presents service options no longer offered, a registration flow that asks for a membership tier that has been discontinued, or a support triage flow that routes to a team structure that has been reorganized all create friction and confusion for contacts who encounter them. Flows should be included in the same review cycle used for the catalog, the quick replies, and any other WhatsApp content that reflects current operations. Any time a product, service, price, process, or team structure changes, the flows that reference those elements should be updated before the change takes effect for customers. For how Flows connect to the broader API and automation setup, see WhatsApp Business API and automation.

Frequently asked questions

We use the WhatsApp Business app, not the API. Can we use Flows?

How long does Meta's flow review process take?

Can a flow send different screens to different contacts based on their profile or previous responses?

What happens to the data if a contact abandons a flow partway through?

Can we use Flows to collect payment information or process transactions?

Our team does not have developers. Can we still build and use Flows?