Capture WhatsApp enquiries as contacts you can actually follow up
- Trigger
- POST /relay
- Lands in
- The Contacts dashboard
- Setup
- 10 min
- Needs
- A website you can add a component to
WhatsApp enquiry about corporate training
Budi Santoso asked about a team of 40 in Jakarta
- Contact
- [email protected]
- Page
- /corporate-training
- Campaign
- brand-id-2026 · google / cpc
- Reference
- K7Q4XM
The chat continues in WhatsApp. The reference in the prefilled message is what ties that conversation back to this record.
Why WhatsApp goes uncounted
This is worth understanding before you instrument anything, because the usual fixes address the symptom. A click counter tells you how many people pressed the button, which was never the hard part.
Consider a WhatsApp button on a training company's site, the ordinary kind that opens a chat with a generic hello. Over a month it is pressed forty six times, and every one of those presses reaches the team as the same line of text. Nobody can tell the person comparing two courses from the person asking whether the office is open on Saturday, and nobody can follow up with either afterward.
The pipeline reporting reads worse than empty. Because none of those clicks carries an email address, none of them becomes a contact, so the sales that eventually come out of those conversations arrive with no origin attached. They get credited to whatever touch did carry an address, which is usually the contact form or the payment itself. WhatsApp is not merely uncounted at that point. It is funding another channel's numbers.
Adding three fields in front of the handoff changes what the same forty six presses produce. Fewer of them go through, and the ones that do arrive as named people with a question attached, matched to the page they were reading and the campaign that brought them there, joined to any payment that person has ever made. The conversation still happens in WhatsApp, and the record of it no longer stops at the click.
Send the landing URL with its query string intact and Viably reads the UTM tags off it, so a WhatsApp enquiry carries its campaign, network and medium the same way a form fill does. Click to WhatsApp ad spend finally has something on the other end of it.
The email address is the identity key, so a WhatsApp enquiry in March and a payment in June under the same address land on one contact. The person your sales team chatted with is the same row your revenue reporting already knows about.
Instead of a stranger saying hello, the first message names what they are looking at and what they want, and the contact record beside it already holds their email, the page they were reading and the campaign that brought them. Nobody has to open with a round of qualifying questions.
An untracked WhatsApp click does not simply go uncounted. The sale it eventually produces gets attributed to whatever later touch did carry an email, usually your contact form or the payment itself, so the channel quietly funds other channels' numbers.
Set up in 3 steps
Around ten minutes, most of which is the widget itself. Nothing here requires a Slack workspace, and nothing requires anything from Meta.
In the Viably dashboard, open Webhook Relay and add a new endpoint for your site. Copy the relay URL and token, and keep the token on your server rather than in browser code, behind a small API route of your own.
Replace the plain WhatsApp link with a panel that asks for a name, an email and what the visitor needs. On submit it posts the enquiry to your relay endpoint and opens WhatsApp with the message prefilled. The payload reference below is the whole contract.
The first submission registers whatsapp in your event catalog on the Contacts page. Open it and set the meaning to Enquiry to answer. From that point every enquiry becomes a contact, lands in your Needs reply queue, and keeps the visitor's message in full.
The widget runs in the browser, so it must not carry your relay token. Post to a small API route on your own site and forward the request from there with the token attached. A token shipped to every visitor is an open door into your own contact list.
Until you set the meaning of whatsapp in your event catalog, enquiries are accepted, logged and relayed, and no contact is created. That is deliberate. A new event type cannot write itself into your CRM or your billed capture count until somebody decides it should. If enquiries arrived before you made that decision, they are recoverable from your relay log rather than lost, so make the decision early and ask us to replay the gap.
What your site sends
One POST per enquiry, from the widget's submit handler. Only type and an identifying email are doing essential work. Everything else makes the resulting contact more useful, and anything Viably does not consume structurally is kept on the contact as captured data you can promote into a field later.
It is tempting to clean a URL before putting it in a payload. Do not. Viably reads the campaign off the query string and strips it separately for the source label, so a tidied URL silently discards the attribution you are doing all of this for.
The handoff reference
A submitted form is not a sent message. The visitor still has to press send inside WhatsApp, and the number they send from is something only WhatsApp knows. A short reference in the prefilled message is what lets those two facts find each other.
A bare code reads as machine litter and gets deleted before sending, and every deletion is a conversation that can no longer be tied to the enquiry it came from. A short parenthetical costs nothing and keeps most of them intact.
Somebody is going to read this off a phone screen. Drop the characters that get misread, which in practice means the pairs I and 1, O and 0, S and 5, and B and 8. Six characters from what is left is plenty.
Whether the enquiry became a real conversation, since a form submission that never turned into a message is worth knowing about rather than sitting in your reply queue forever. And the phone number behind the contact, which the form could never have collected because it only exists on the other side of the handoff.
What lands in the CRM
Once the event catalog says whatsapp is an enquiry, each submission opens as a full contact record rather than a line in a log.
The email address is the identity key, so a WhatsApp enquiry joins whatever leads, signups and payments already exist under that address. Somebody who bought from you last year and now asks a question on WhatsApp reads as a returning customer rather than a new name.
The widget's own label becomes the source, and the campaign, network and medium are read from the landing URL. WhatsApp appears in acquisition by source and in lifetime value by source as a channel of its own, beside your forms and your paid campaigns.
What the visitor typed is kept in full on the contact's timeline, dated by when they sent it rather than by when it was processed. Anyone on your team can open the person later and read what they originally asked.
The landing page, the referrer, the device, the page title and the handoff reference are all kept on the contact under captured data. If one of them turns out to matter on every contact, promote it into a field and it fills in retroactively on everyone who ever carried it.
Declaring the type an enquiry also puts these contacts in Needs reply, so a WhatsApp question sits in the same work queue as an email one. Nothing goes unanswered because it arrived through a different door.
Keeping the form cheap
Asking for three fields in front of a one tap action costs you some conversions. That is the honest trade, and most of it is recoverable through the design of the panel rather than by asking for less. These are the levers, roughly in order of how much they move.
Writing the first sentence is the work, and an empty textarea is where a pre chat form loses most of the people it loses. Prefill it with something drawn from the page they are on, left deliberately unfinished, and the visitor is editing rather than authoring. Somebody who sends it barely touched still tells you more than a bare click ever did.
A visitor prices the form before they read it. Leading with two empty boxes makes it look like three units of work, while leading with the one that is already mostly written makes the panel open on progress.
They are about to hand over a phone number, so asking for an address as well needs a reason attached to it. One line under the field is enough, along the lines of sending them anything that does not fit in a chat.
Office hours are a fact you can check, and a typical reply time is usually a claim nobody is measuring. Showing that you are open now, or that you will pick it up the next working day, sets an expectation you can keep.
Keep the name and email in the browser after a successful enquiry and prefill them next time. A second conversation should be one edit away, which takes most of the friction back out of the form for the people most likely to buy.
Do not close the panel silently on submit. On a desktop the link lands on WhatsApp Web, which shows a sign in wall to anyone without a linked session, and popup blockers stop the window outright often enough to matter. Confirm what happened, offer the link again, and say plainly that you have the message either way.
Count panel opens as well as submissions. Without the first number a form nobody opens looks exactly like a form everybody completes, and you will end up debating the cost of the form on instinct. With both, the completion rate is a figure you can watch as you change the copy.
A wa.me link is the end of your visibility. The visitor leaves a page you instrumented, carrying a URL, a referrer and a campaign, and arrives as a phone number in an inbox that knows none of it. Nothing crosses that boundary on its own, so a plain WhatsApp button produces events that are identical on every press. You can count them, and you cannot tell one from another or follow any of them up.
No. The conversation still happens in WhatsApp, on the visitor's own phone, in the app they already use. The widget asks for a name, an email and what they need, then opens WhatsApp with that message prefilled. What changes is that the enquiry exists in your CRM before the chat begins, rather than never.
Yes, some. A form in front of a one-tap action always does. The trade is volume for workability: twenty enquiries carrying a name, an email and a question are worth more to a sales team than fifty anonymous clicks nobody can follow up. Viably instruments both ends of that funnel, so what the form costs you is a number you can read rather than a guess. The guidance further down covers how to keep the cost low, and the biggest lever is prefilling the message box.
No. This works with an ordinary WhatsApp number and a wa.me link, with no Meta app review, no number registration, and no template message approvals. Your sales team keeps using the WhatsApp app they already have on their phones.
As a source of its own. The widget sends the landing URL with its query string intact, so Viably reads the UTM tags off it and files the campaign, network and medium on the contact the same way it does for a form fill. Because WhatsApp is its own event type rather than being folded into your contact form, it appears as its own row in acquisition by source and in lifetime value by source, and any payment that follows is credited to the page and campaign that started the conversation.
It is how a conversation in WhatsApp is matched back to the enquiry that produced it. A submitted form is not a sent message, since the visitor still has to press send inside WhatsApp, and the number they send from is something only WhatsApp knows. The code appears in both places, in the message your team receives and in the contact's captured data, so the two halves can be joined.
The widget carries a honeypot field and a timing check, which together stop the ordinary run of form bots, and the relay endpoint is rate limited. Email addresses are checked for shape rather than verified, since nobody proved they own the address, so treat a WhatsApp contact the way you would treat any contact form submission until they reply.
Yes, and Viably records those separately so the two paths never get confused in your reporting. A bare handoff names nobody by definition, so it does not create a contact, and it is still counted and still carries the page it came from.
Start capturing the channel you already have
The button is already on your site and people are already pressing it. The only thing missing is the part where you find out who they were.
Open Webhook Relay, add an endpoint for your site, and post your first WhatsApp enquiry to it. Set the event meaning on the Contacts page and the next person who taps your WhatsApp button becomes a contact you can answer, attribute, and count. The free plan includes the endpoint and the full contacts workspace.
Add Viably to Slack