Fewer people drop off mid-form
A student who was already inside WhatsApp finishes the enquiry there instead of abandoning it at a browser redirect, which is where most of that third was being lost.
Available now
In build
The whole team
Nineteen specialists, each with a defined job and an honest status label.
See all nineteenThe business collects clean, structured customer data (bookings, orders, applications) without redirecting people to an external website.
Works with
What it does
A team builds a multi-screen form using WhatsApp's native Flows JSON — text fields, dropdowns, date pickers, and a submit button — that renders as an in-chat overlay. Submitted data is pushed to the business's backend in real time via a webhook, so a booking or lead can be confirmed inside the same conversation.
A coaching institute asks prospective students to fill a Google Form — name, class, subjects, preferred batch — and loses a third of them at the link. They were interested enough to message on WhatsApp; they weren't interested enough to leave the app, open a browser, and fill a form that feels like homework.
Native form flows keep the entire thing inside the chat. A multi-screen form — text fields, dropdowns, a date picker, a submit button — opens as an in-chat overlay built from WhatsApp's own Flows JSON, and the completed answers land in the institute's backend the moment the student taps submit, still inside the same conversation they started.
Wavy runs this directly on the platforms your customers already use — no separate app for them to install.
How it works
Lay out each screen of the form — text inputs, dropdown lists, date pickers — using WhatsApp's own native Flows components, in the exact order a student should be answering each question, one after another, without confusion.
Point the flow at the institute's CRM or booking system so a completed submission is pushed there automatically and instantly, rather than sitting in a chat log someone has to copy out laboriously by hand later.
Attach the flow to a keyword, a chatbot branch, or a click-to-chat link, so it opens for the student at the right moment in the conversation, not as a cold, unexplained popup out of nowhere.
Each completed flow submission arrives via webhook, gets validated against its token, and is routed into the connected system — a new lead record, a confirmed booking — in real time, as soon as it lands.
Why it matters
A student who was already inside WhatsApp finishes the enquiry there instead of abandoning it at a browser redirect, which is where most of that third was being lost.
Dropdowns and date pickers stop the free-text guesswork of a chat reply like 'sometime in June maybe', giving the institute a properly formatted date and batch choice to work with.
The booking or enquiry is confirmed in the same chat thread the student started, so there's no second channel to check and no 'did that form actually go through' uncertainty.
The detail
Flows only render inside the WhatsApp mobile app — a student on WhatsApp Web or desktop cannot open or complete one. Any flow that matters needs a fallback path for that audience, typically a plain link to a hosted web version of the same form, or the conversation should detect the platform and offer the classic in-chat question-and-answer sequence instead. Building a flow without this fallback quietly excludes every desktop user from ever completing it.
The technical constraint that matters most for reliability is the data-exchange endpoint: when a student moves between screens or submits the form, Wavy's backend has to respond within Meta's timeout window or the flow simply errors out on the student's screen, mid-form, with no clear explanation of what went wrong. This makes flow reliability a backend performance question as much as a design one — a slow CRM lookup on submission can break the experience even if every screen was designed correctly.
Security also has to be handled server-side, not assumed. Every submission carries a flow_token that identifies which session it belongs to, and that token must be validated on receipt to make sure a submission wasn't replayed or forged by someone who intercepted an earlier one. A booking or enquiry system that trusts an unvalidated token risks a duplicate or fraudulent entry showing up as if a real student submitted it.
Industry use cases
10 industries where Wavy applies this directly.
A customer messages a dealership's WhatsApp number after seeing a Click-to-WhatsApp ad, browses the vehicle catalog in-chat, and books a test drive slot through a native form that checks the showroom's real-time calendar.
See the automotive playbookA prospect fills out a website contact form, receives an automated WhatsApp qualification flow asking about company size and budget, and is routed to the assigned account executive's shared inbox queue the moment they answer "yes" to wanting a demo.
See the b2b sales playbookA lending business sends a one-time passcode via an authentication template when a customer logs into their loan portal, and later sends a utility template reminding them a payment is due in three days.
See the banking and finance playbookA shopper browses a product catalog inside WhatsApp, adds a lipstick shade to their cart, doesn't complete checkout, and receives a reminder message with the exact shade and a link back to the cart twenty minutes later.
See the beauty and cosmetics playbookA prospective student messages an ed-tech company's number, completes a lead-capture flow asking about the course of interest, and is booked into a counselor's calendar slot without ever leaving WhatsApp.
See the education playbookA patient books a consultation through a native form, receives a reminder template the morning of the appointment with confirm/reschedule quick-reply buttons, and gets a post-visit follow-up message asking for feedback.
See the health and wellness playbookA customer asks about curtain pricing via a click-to-chat website widget, browses a curated catalog of fabric options in-chat, and receives a follow-up message a day later if they didn't confirm an order.
See the home decor and furnishing playbookA buyer clicks a Click-to-WhatsApp ad for a listed property, answers a short qualification flow about budget and timeline, and books a site-visit slot through a native form connected to the agent's calendar.
See the real estate playbookA regular client receives an automated reminder that their usual six-week haircut appointment is due, taps a quick-reply button to confirm the suggested slot, and gets a same-day reminder message before their visit.
See the spas and salons playbookA traveler inquires about a weekend package via a QR code at a travel fair booth, completes a native form capturing travel dates and group size, and receives a utility template confirming the booking with itinerary details attached.
See the travel and tourism playbookMore from Wavy
The business reaches thousands of opted-in customers with one send instead of manually messaging contacts one by one.
Learn moreThe business answers routine questions instantly, day or night, without adding support staff.
Learn moreMultiple staff members handle customer conversations from one WhatsApp number without stepping on each other or losing context.
Learn moreCustomers browse products, ask questions, and place an order without leaving the WhatsApp conversation.
Learn moreThe business wins back sales that would otherwise be lost when a customer starts checkout but doesn't finish.
Learn moreThe business fills more of its calendar and loses fewer no-shows by confirming and reminding customers automatically.
Learn moreQuestions
WhatsApp Flows only render in the mobile app, so a desktop or Web user cannot open the overlay at all. A properly built flow includes a fallback — usually a plain link to a hosted version of the same form, or a switch to a regular question-and-answer chat sequence — so desktop users aren't simply left with nothing to click.
Flows are built for structured data collection — text, choices, dates — not for processing payment directly inside the overlay itself. A booking flow typically collects the necessary details and confirms the slot, with any payment link sent afterwards as a plain follow-up message once the data-exchange step confirms the submission went through correctly and completely, ready for the institute to act on.
If the backend doesn't respond within Meta's timeout window during a screen transition or final submission, the flow errors out for the student mid-form, and they'd need to reopen it and restart from scratch. This is why the connected CRM or booking system needs to respond quickly — a slow lookup on submission is the single most common cause of a flow breaking partway through an otherwise smooth process.
Every submission carries a flow_token tied to that specific session, and the backend validates it carefully before accepting the data it contains. This stops a replayed or forged submission from being processed as though it were a genuine, fresh answer coming from the actual student who started that particular conversation in the first place, protecting the institute's records from tampering.
The rest of your stack
No rip-and-replace — collect structured data in-chat works alongside the systems already running your business.
Available today