WhatsApp Business API patient funnel: setup and attribution
How to wire the WhatsApp Business Platform into a clinic funnel: account setup, template categories, webhooks, CRM mapping and source attribution.
By Roozbeh Nazari · CEO
In clinics that attract patients from abroad, first contact is usually not a form but a WhatsApp message. Where that message came from, who picked it up and whether it turned into a booking all get lost in an account run from a phone app. The WhatsApp Business Platform, the API side of the product, is the only way to make this flow measurable. This article walks through the setup from scratch: which account, which message types, where the webhook connects and how source information gets attached to a conversation.
The focus here is infrastructure. Which leads count as qualified and how the chain to booking is designed was covered in our lead quality measurement article; here we lay the pipes that chain runs on. Our clinic-specific working model is described on the clinics industry page.
App or platform: the cost of the decision
WhatsApp offers businesses two separate products. The WhatsApp Business app runs on a phone, is tied to a single device and keeps conversation data on that device. The WhatsApp Business Platform is an API running in Meta's cloud; messages land on a server and are forwarded to whatever system you choose. For a small practice the app may be enough. For a clinic handling hundreds of international conversations a month with several patient coordinators, the app is a black box where measurement is impossible.
The cost of moving to the platform is organisational rather than technical. Once the number leaves a single device and connects to a system, the question "who replied" is answered by software, and the personal patient chats piling up on coordinators' phones disappear. Some teams resist this, and it is exactly what needs to be discussed before setup begins.
Setup order: account, number, templates
Setup has four parts. First, opening a WhatsApp Business Account under a Meta Business account and verifying the business. Second, migrating the number to the platform; the number cannot be used in the app at the same time, so the moment of transition has to be planned. Third, getting the business display name that patients see approved. Fourth, preparing message templates and submitting them for approval.
Templates are the most misunderstood part in clinics. When a patient writes to you, you can reply freely inside the window that opens; but if you are the one initiating contact, or the window has closed, you can only send a pre-approved template. Meta sorts these templates into three categories: marketing, utility and authentication. Appointment reminders, document requests and flight detail confirmations fall under utility; a message like "our new season campaign" is a marketing template, which is priced differently and needs separate approval.
There is also a legal layer. Meta requires the patient's explicit opt-in for business-initiated messages, and the promotion regulation that applies to healthcare providers in Türkiye also sets limits on unsolicited messaging. Read both layers together during setup; writing down from the start which template may be sent under which consent is cheaper than an account restriction later.
Webhook: the moment a conversation lands in the CRM
The platform's real value is the webhook. Every incoming message, every delivery status and every read receipt is sent as JSON to an address you define. What sits behind that address is your decision: patient coordination software, a CRM or a simple middle layer.
In practice three rules make life easier. First, store every event the webhook receives as-is before processing it; when processing fails, the raw data is still there. Second, key the patient record on the conversation ID the platform provides, not the phone number; the number is kept as a secondary key so that the same patient writing from a different number does not open two records. Third, write the coordinator's reply into the same record; first response time can only be measured that way.
Attribution: how source information rides on the conversation
This is the real question. When a patient writes on WhatsApp, how will you know whether they came from a Google search, an Instagram ad or a referral from another patient? The answer depends on the channel, and no single method covers all of them.
For clicks from Meta ads, the platform attaches a referral object to the incoming message event. It contains the ad source and click identifier; when your webhook reads that field, the conversation is tied to the ad set from its very first message. This is the cleanest attribution path for clinics and the first thing to build.
For clicks from the website, your tool is the pre-filled message text. The WhatsApp button on your site opens with a short code specific to the page and channel; when the patient sends that text, your webhook reads the code and ties the conversation to the page. Keeping the code short and page-specific lowers the chance the patient deletes it. Which code goes on which page should follow the button's place in the landing page anatomy.
On the organic search side the chain is one step longer: the patient first lands on the site, then taps the button. The click on the site is recorded on the analytics side together with the source of the session; the conversation record created from the pre-filled code carries the same code, so the two sides can be joined later. For that join we keep a separate mapping table on the analytics and data side; four columns, code, page, channel and date range, are enough.
For patients who save the number and write directly, or who come by referral, there is no automatic method. Here the coordinator has to ask a single question in the first conversation and record the answer in the CRM's source field. The share of "unknown" in that field is the most honest indicator of the setup's health; if it is not falling as a percentage, the problem is process, not technology.
The measurement table: what to count, and where
When setup is done you should have a table that answers these questions: which source opened the conversation, how quickly the first reply was sent, which stage the conversation reached, whether a booking was made and on which date. These five columns are enough to calculate booking rate by source. Add ad spend and you get cost per booking by channel.
One warning matters: this table is not the same thing as the "results" figure in an ad dashboard. The dashboard counts conversation starts; the table counts bookings. The gap between them is the clinic's real conversion rate. Putting the dashboard number in the report and ignoring the booking count is the most common mistake we see.
Three common setup mistakes
First, not verifying the webhook before processing events. Meta checks that your endpoint is up and returns the right response; if that step is skipped, events never arrive and the problem is noticed days later.
Second, giving each coordinator a separate number. When measurement is not gathered on a single number, source information scatters too; the right design is one number, multiple operators.
Third, opening templates in the marketing category and trying to send utility messages with them. Beyond approval rejections and the cost difference, a message sent to a patient in the wrong category lowers the account's quality rating.
Conclusion
The WhatsApp Business Platform is the only WhatsApp setup in a clinic funnel where measurement is possible. The setup order is account, number, templates and webhook; attribution is built per channel from the trio of referral object, pre-filled code and coordinator question. None of them is enough on its own, but together the three give a real answer to "which channel brings bookings".