BlogResources

Automated dental booking over WhatsApp: what a booking needs to know

A dental appointment is not one length or one clinician. What the booking exchange has to establish, what it must not decide, and where it hands over.

Rebecca PearsonRebecca PearsonUpdated 11 min read

Summarize with AI

Automated dental booking over WhatsApp: what a booking needs to know
On this page

Automated dental booking over WhatsApp works when the booking flow first asks what the appointment is for. That answer sets the appointment length, the clinician, the equipment and whether the patient needs to be seen sooner than the next free slot. A flow that only asks "when would you like to come in?" skips this step, and reception then corrects the booking by phone, which is the work the automation was meant to remove.

Key takeaways

  • A dental booking flow must ask what the appointment is for before it offers any time.
  • Ask five things only: the reason, new or existing patient, pain, timing constraints and clinician preference.
  • Route anyone in pain to a person, because urgency is a clinical decision.
  • Write every booking to the practice system and check the slot is still free before confirming.
  • Book the next appointment while the patient is still in the chair, and use recall messages only as the backup.

What we'll cover

Why dental booking is not simple booking

Dental booking is not simple booking because the reason for the visit decides the length, the clinician and the room. A restaurant table needs a time and a party size. A dental appointment needs more.

Appointment length varies a lot, from a short check-up to a long treatment session.

Not every clinician does everything, and hygienist, dentist and specialist appointments are different things.

Some appointments need equipment or a room that is not always free.

Some patients need to be seen sooner than the calendar suggests, and that is a clinical call.

A wrongly booked appointment costs twice: the slot is wrong and the practice has to contact the patient.

The booking flow is therefore mostly a triage question, which generic booking tools skip.

What the exchange has to establish

The exchange has to establish five facts, and nothing more.

  • What the appointment is for, in the patient's words.
  • Whether they are an existing patient, which changes almost everything downstream.
  • Whether they are in pain, which the flow should ask directly and early.
  • Any constraint on when, such as school hours, work or transport.
  • Whether they have a preferred clinician, which matters for continuity.

Every additional question costs completions, and the practice can collect the rest later.

Mapping what patients say to what you book

Map what patients say to your appointment types approximately, and book the longer slot when the match is unclear. Patients say "my tooth hurts", not "emergency assessment".

Map their words to your categories, and accept that the mapping is approximate.

When unsure, book the longer slot or route to reception, since under-booking a slot is worse than over-booking one.

Watch for the description that does not fit, because that is the case that needs a person.

Keep the categories few, since a long list of appointment types is a menu nobody can use.

Review the mapping against what was actually needed, since the corrections show where it is wrong.

Building it with CodeWords

You build this in CodeWords by describing the booking exchange to Cody, the automation builder. CodeWords connects to 3,000+ integrations (CodeWords pricing page, 2026), and you make each connection once and reuse it.

  1. Open CodeWords and start a new automation.
  2. Describe what should happen in plain language to Cody: what is asked, how answers map to appointment types, and what routes to reception.
  3. Authorize the connections to your practice management system and your WhatsApp Business Platform account.
  4. Describe the exceptions: pain, an unclear request, a new patient, a clinician-specific need, no suitable slot.
  5. Run it with reception reviewing every booking before confirmation, until the mapping is reliable.

You describe the outcome; Cody builds it, connects it, and deploys it. The Free plan costs $0 and covers light use, Pro is $39 per month ($33 billed yearly) and Business is $100 per month (CodeWords pricing page, 2026). Details are on the pricing page.

Urgency, which is a clinical judgement

Urgency is a clinical judgement, so the bot may ask about pain but must not interpret the answer. Deciding how soon somebody needs to be seen is a clinical decision with consequences.

Route anybody in pain to a person, promptly, rather than offering them the next routine slot.

Do not offer reassurance about what a symptom means, because that is clinical advice.

Have a defined out-of-hours response, since pain does not arrive during working hours and a silent channel is worse than none.

Say what to do in an emergency, clearly, including the route that is not your practice.

New patients versus returning ones

New patients need registration, medical history and a longer first appointment, while returning patients need almost nothing. Asking returning patients for information the practice already holds is the most common irritation.

New patients need more: registration, medical history, a longer first appointment, sometimes different availability.

Recognise returning patients by phone number where you can, and ask them to confirm rather than interrogate them.

Put more effort into new-patient bookings, since conversion matters and the process is longer.

Set the expectation for a first visit: what happens, how long it takes and what to bring.

Do not lose new patients in a form, which is where new-patient bookings are most often abandoned.

What to confirm and what to send after

Confirm immediately with the time, clinician, duration and location, then send the rest in separate, later messages.

Add the appointment to their calendar, so the time is easy to find again.

Say what to bring and anything they need to do beforehand.

Send the intake link separately, a few days ahead, if one is needed.

Do not send everything at once, because a wall of text goes unread.

Make changing the booking easy from the confirmation, which prevents a future gap.

Where it must hand over

The flow must hand over to a person for six situations.

  • Pain or a symptom, immediately.
  • Anything clinical, including questions about treatment, treatment cost, or whether something is normal.
  • A complaint, which has process requirements.
  • An unclear or unusual request, rather than guessing.
  • A patient who asks for a person, without resistance.
  • Anything about a child where a parent's involvement is needed, which is worth handling explicitly.

Recall, which is the appointment nobody books

Recall works best when the next appointment is booked while the patient is still in the chair, and a recall message is the recovery when that did not happen. Practices lose returning patients mostly because nobody asked at the right moment.

Book the next one in the chair, a step that busy practices often skip.

Send a recall message at the right interval where the booking did not happen.

Set the interval clinically, per patient, rather than applying one period to everybody.

Make booking from the recall one exchange, not a prompt to call during working hours.

Track who has lapsed, a list most practices cannot produce, which represents known, previously satisfied demand.

Contact lapsed patients differently from overdue ones, since somebody eighteen months late needs a different message from somebody two weeks late.

Making it survive

A durable booking flow treats the practice system as the source of truth and never holds a booking only in the conversation.

Write to the practice system for every booking.

Check the slot is still free immediately before confirming.

Make booking idempotent, so a repeated confirmation does not create two appointments.

Handle the practice system being unavailable by taking details and routing to reception rather than failing.

Report the outcome: bookings made, routed to reception, abandoned, and corrected afterwards.

Limits worth knowing about

Five limits apply to dental booking over WhatsApp.

Practice management systems vary in what they allow from outside, and some allow nothing.

Clinical triage cannot be automated, so the boundary needs to be explicit.

Patients describe symptoms inaccurately, which is why the mapping is approximate and the corrections matter.

Messaging consent applies before you message anybody proactively.

Regulatory requirements for patient communication and records apply to this channel as to any other.

What to build first

Build the triage question first: what is the appointment for, and are you in pain. Ask it before any calendar interaction. It is one message, and it sets everything else. A flow that offers times before asking it produces appointments the practice then has to correct.

Two habits make the difference. Route anybody mentioning pain to a person rather than offering a routine slot, because urgency is a clinical judgement and the cost of getting it wrong is not administrative. And book the longer slot when the mapping is uncertain, because an over-booked appointment costs a gap and an under-booked one sends a patient away unfinished.

Frequently asked questions

Why is dental booking harder than ordinary booking?

Dental booking is harder because the appointment length, the clinician and sometimes the room all depend on what the appointment is for. A flow that asks when somebody would like to come in skips the part that determines everything else.

What does the booking exchange need to establish?

The exchange needs to establish what the appointment is for in the patient's words, whether they are an existing patient, whether they are in pain, any timing constraint and any clinician preference. Nothing else is needed, because every additional question costs completions.

How do I map what patients say to appointment types?

Map patient wording to appointment types approximately, and book the longer slot when unsure. Patients say "my tooth hurts", not "emergency assessment". Route cases that do not fit to reception rather than guessing.

Can the bot decide how urgent something is?

No, the bot cannot decide urgency. Asking about pain is fine, but interpreting the answer is clinical triage with real consequences. Route anybody in pain to a person promptly rather than offering the next routine slot.

What is different about new patients?

New patients need registration, a medical history, a longer first appointment and sometimes different availability. They are also where bookings are most often abandoned, so the process deserves more care than a returning patient's.

What annoys returning patients most?

Returning patients are most annoyed by being asked for information the practice already has. Recognise them by phone number and ask them to confirm their details rather than repeating the full intake.

What should the confirmation contain?

The confirmation should contain the time, clinician, duration and location, a calendar addition, what to bring and an easy way to change the booking. Send the intake link as a separate message a few days later rather than everything at once.

What must always hand over to a person?

Hand over pain or symptoms, anything clinical including treatment costs, complaints, unclear requests, anybody asking for a person, and anything involving a child where a parent needs to be involved.

When should the next appointment be booked?

Book the next appointment while the patient is still in the chair. Busy practices often skip this step. Recall messaging is the recovery for when the booking did not happen.

What list do most practices not have?

Most practices do not have a list of lapsed patients: people who attended regularly and then stopped. The list is known, previously satisfied demand, and it stays invisible because nothing reports on absence.

Get started today

Your first workflow is free to build.

Describe what you need. Cody handles the build, the connections, and the deployment.