If your clinic's WhatsApp number is answered by whoever is at reception, and booking requests wait until someone is free, this is for you. If you take a few bookings a day and reception keeps up, you do not need an agent yet. This is written for the person who owns the build and the bill, and it covers one decision: whether to build the agent on Vercel's Chat SDK, and how.
What does the Chat SDK do for a WhatsApp agent?
It gives you one TypeScript API for chat apps, so the agent's logic is written once. Vercel describes it as "a unified TypeScript SDK for building chat bots across Slack, Discord, Linear, WhatsApp, Telegram, GitHub, and more." It is free: "You can use it for free in personal and commercial projects."
How it works, in four steps. You create a Chat instance with an adapter for each platform and a state adapter. Meta's webhooks hit your route, and the adapter verifies and normalises the event. Your handlers react to messages and button taps. Replies go back through the adapter in WhatsApp's own format.
The SDK also ships tools for agents built with the AI SDK, so a model can post, react and edit, "with approval required for writes by default." For a clinic, that default is the right one.
Which WhatsApp adapter should a clinic use?
The official one: WhatsApp Business Cloud, published as @chat-adapter/whatsapp and maintained by Vercel. The Chat SDK lists three tiers of adapter, and the tier tells you who fixes it when Meta changes something.
The community pair is the trap. Both are built on "the unofficial WhatsApp Web API", self-hosted, signed in with a QR or pairing code. That is a phone session pretending to be a person, not the Business Platform. A clinic's number is the one patients have saved; we would not risk it on a route Meta does not offer to businesses.
The official adapter needs four values from your Meta app: an access token, the app secret, the phone number ID and a verify token you choose. The docs say the token Meta shows first is temporary; for production, generate a permanent System User Token.
What does WhatsApp itself limit?
More than the SDK does. The adapter can only send what WhatsApp accepts, and its docs spell the limits out.
- 01Outside the 24-hour customer service window, only templates approved in WhatsApp Manager can be sent. A reminder the day before is a template.
- 02A card with 3 or fewer buttons becomes WhatsApp reply buttons, each title up to 20 characters. More than 3 buttons fall back to plain text.
- 03One media item per message. Several files go as several messages.
- 04Messages over 4,096 characters are split automatically. Card body text stops at 1,024.
- 05Patients can appear by a business-scoped user ID instead of a phone number. Subscribe to the user_id_update webhook so the thread survives a change.
Two of these shape the design. Three buttons with 20 characters each means a slot picker reads "Tue 10:30" and "Wed 16:00", not a calendar. And the 24-hour rule means every message the clinic sends first, such as a reminder or a follow-up, needs a template written and approved before launch.
What does a booking agent look like for a clinic?
Here is a worked example, not a client. A clinic in Dubai with three doctors gets booking requests on WhatsApp all day. The agent answers, offers slots, and leaves the booking itself to a person until the clinic trusts it.
- 01A patient writes "Can I see Dr Amal tomorrow?". The agent marks the message read and shows typing while it checks the calendar.
- 02It offers three reply buttons: two free slots and "Talk to reception".
- 03The patient taps a slot. The agent drafts the booking but does not write it.
- 04A receptionist approves the draft in the staff chat the clinic already uses. Then the booking is written.
- 05The day before, an approved reminder template goes out, with a tap to confirm or move it.
Step 4 is why the Chat SDK fits here. Its docs describe durable approvals: "Pause a durable workflow until a human approves it in chat." Slack, Microsoft Teams and Google Chat all have official adapters, so the approval sits where staff already work, in the same codebase as the patient's channel. Before launch, agree the edit rate that counts as "the drafts are right". When the approval log shows the receptionist edits fewer drafts than that, the agent may write simple bookings itself, with a person on the exceptions.
If the clinic only needs patients to pick a slot, it may not need an agent at all: our Bookings app does that without code. And if the job is WhatsApp answering and booking for the whole front desk, our WhatsApp offer is the place to start.
Which steps need a model, and what does each cost?
Fewer than you think. Our design rule: a model reads free text, and code does everything else. In the flow above, only step 1 needs a model, to turn "Can I see Dr Amal tomorrow?" into a doctor and a date. The slot lookup, the three buttons, the draft and the reminder are code and a template, with no tokens spent.
That keeps cost per booking readable: log tokens per conversation, divide by confirmed bookings, and you can see the one step that spends. Two more lines for whoever signs the bill. Patient text goes to the model provider you call, so confirm its retention terms in writing, and whether zero data retention is on for your account, before the first message. And on lock-in: the npm package is MIT licensed and the adapter calls Meta's Cloud API, so if you leave the SDK, the Cloud API, your number and your templates stay yours.
What does it cost to run, and where does it run?
The SDK is free; the running costs are around it. The state adapter needs a real store in production: the docs say the memory adapter suits local development, and to use Redis or PostgreSQL in production so threads and identity survive restarts. Model calls cost what your model costs. Meta charges for WhatsApp separately, and our WhatsApp cost tool works through those numbers.
Where it runs matters to a clinic. Vercel lists 19 compute regions and none is in the UAE or Saudi Arabia; Mumbai (bom1) is the nearest. Chat SDK itself makes no data-residency statement, because it runs wherever you deploy it. So where patient messages are processed and stored is confirmed per project before you sign, not promised in the pitch. We are not a Vercel partner, and if a host in the UAE is a must, the job picks a different stack; see our Vercel overview for what we do run there.
What do you settle before the first message?
Settle these in writing first, because each one is hard to change after launch:
- 01The number: a WhatsApp Business Platform number on the official adapter, never a personal phone session.
- 02The templates: every message the clinic sends first, written and approved in WhatsApp Manager.
- 03The write: which actions a person approves, who approves them, and on which channel.
- 04The store: Redis or PostgreSQL, and where it is hosted.
- 05The handover: how a patient reaches a person in one tap, at any point.
If your clinic takes a few bookings a day, a booking link is enough. If requests wait for hours, name the process someone runs by hand today and send it to us. We start with a free assessment; the first build week is AED/SAR 14,900. Our method is Spec, shadow, gate: write the spec, run the agent in shadow next to reception, then put a person on every write until the drafts are right.
