A build, written up
Not a demo and not a tool. This is a WhatsApp booking automation I built for a clinic, taken apart decision by decision — what the owner has to supply, how the flow decides, what the patient sees, and what it costs to run.
Everyone sells WhatsApp automation and nobody shows you what it actually involves. So here is a complete one, built for a fictional dental clinic: what the owner has to supply, how the flow decides, what it costs, and the restraint rules that stop it becoming spam.
Automation is only as good as the facts behind it. This is the whole input list for Bright Lane Dental, a two-surgery practice in North London. It takes about ninety minutes to collect, and it is the part clients underestimate.
Every treatment, its duration, its price or price range, and whether it needs a consultation first. Vague pricing is the single biggest cause of an automation handing over to a human unnecessarily.
Opening hours, per-dentist working days, appointment lengths per treatment, buffer times, and how far ahead the diary opens. Ideally a calendar the flow can read rather than a static table.
What the bot may promise and what it may not. Can it offer the last slot of the day? Can it quote implant pricing? Can it discuss a symptom? For a clinic the answer to that last one is always no.
The exact phrases that must reach a human immediately. For a dental practice: pain, bleeding, swelling, knocked-out tooth, anything a child. These bypass every other branch of the flow.
How the practice speaks, and the disclosure line confirming this is an assistant rather than the dentist. Pretending otherwise is both dishonest and, for a health provider, a regulatory problem.
Who may be messaged, on what basis, how they opt out, and how long conversation history is kept. Health context makes this stricter, not looser.
Time to gather: about 90 minutes with the practice manager. Time to build once gathered: two to three days. Anyone quoting you a same-day build has not asked for input 04.
Built in ManyChat on the official WhatsApp Business API. Every inbound message runs down this ladder and stops at the first match, which is why the urgent branch sits at the top rather than buried in a menu.
Scan for pain, bleeding, swelling, trauma, or a child. Match means the flow stops, replies with the emergency number and today's earliest slot, and alerts the practice. No booking logic runs at all.
Known number gets greeted by name with their usual dentist pre-selected. Unknown number gets a short introduction and the assistant disclosure.
Book, reschedule, cancel, ask a price, ask about hours or location, or something else. Six branches covers roughly 90% of inbound. "Something else" routes to a human rather than guessing.
Treatment type and rough preference: this week or next, mornings or afternoons. Two questions, never five. Every additional question loses people.
Three options pulled from the live diary, never "when suits you?" which puts the work back on the patient and produces times that do not exist.
Booking written to the practice system, confirmation sent, and a note added to the patient record. If the write-back fails the patient is told plainly and a human is alerted, rather than a silent failure.
One 48 hours before, one on the morning. Nothing else. This is the rule most implementations break.
An out-of-hours enquiry, start to finish. Six messages, one booking, no menu trees, no "press 1 for reception".
The whole exchange is under three minutes, at a time the practice was closed. That is the entire value: the enquiry converted while the competitor's phone was off.
This is the part that separates automation people tolerate from automation people block. Message volume is the whole game, and almost every implementation gets it wrong in the same direction.
Nothing is sent that was not either asked for or directly attached to a booking they made. No cold outreach, no "we noticed you were browsing".
48 hours before, and the morning of. A third message does not increase attendance; it increases blocks. This is measurable and the data is consistent.
A booking is not consent to receive offers. Whitening promotions go to people who explicitly agreed, on a different list, with an unsubscribe in every message.
Six-month check-up reminders are welcome. Anything more frequent reads as a business chasing revenue, because it is.
If someone stops replying mid-flow, the flow stops too. One gentle close after 24 hours, then nothing. Never a sequence of escalating nudges.
"Stop" works anywhere, instantly, with no retention attempt and no "are you sure?". Anything else is a dark pattern and, on WhatsApp, a fast route to being reported.
The commercial argument for restraint: a blocked number cannot be recovered. On WhatsApp your sending reputation is an asset with a quality rating attached, and burning it to send one more promotion is a bad trade in every direction.
Worth stating plainly: the figures below are the metrics I would set up and the pricing model as it works, not results from a real Bright Lane. There is no Bright Lane. Anyone showing you conversion percentages for a fictional client is showing you fiction.
Enquiries answered outside opening hours that became bookings. This is the number that justifies the whole build, and it was previously invisible because those enquiries simply vanished.
Should be seconds. Compare against the practice's previous average, which is usually hours and occasionally days.
Percentage reaching a human. Too high means the flow is thin; near zero means it is answering things it should not. There is a healthy middle and it is not 0%.
Before versus after reminders. This is where a clinic sees money, because an empty chair is pure lost revenue.
The honesty metric. If it climbs, the flow is sending too much, and no amount of booking volume compensates for a burned list.
Platform fee plus per-conversation charges divided by bookings. WhatsApp bills per 24-hour conversation window, not per message, so a chatty exchange costs the same as a terse one.
Rough running costs for a practice this size: a ManyChat plan in the low tens of pounds a month, plus Meta's per-conversation charges which for UK service conversations are pennies each. The build is the real cost, not the running.