Register your interest: Tag @Cody, get an agent
BlogResources

A dental practice's guide to WhatsApp automation: what order to do it in

The sequence matters more than the individual automations. What to set up first, what to leave until the channel is established, and what never to automate in a clinical setting.

Rebecca PearsonRebecca Pearson11 min read

Summarize with AI

A dental practice's guide to WhatsApp automation: what order to do it in
On this page

Most practices attempting this start with the most visible thing — a booking bot — and it is close to the worst place to begin. Booking is the hardest exchange to get right, it touches the diary, and a mistake there produces the phone call the practice was trying to remove.

There is an order that works, and it starts with the things that carry no risk to the diary and build the channel's standing with patients before anything depends on it.

What we'll cover

Why the order matters

Early mistakes are expensive on a channel where the number is the asset.

Patients need to adopt it before anything important depends on it, which takes months.

Messaging limits start low, so a practice cannot message its whole list on day one regardless.

The diary is the risk. Anything writing to it can create a problem that reaches a patient in a waiting room.

Confidence is built by small things working, which is what makes the later stages acceptable to the team.

Each stage earns the next, and a practice that starts at the end usually stops.

Stage one: be reachable

An automatic acknowledgement that says you received the message and when somebody will reply.

Answers to the questions you already answer daily: opening hours, location, parking, whether you take new patients, the cost of a check-up.

A route to a person, visible, from the first message.

No diary access, which means nothing can go wrong in a way patients see.

Collect opt-in during this stage, which is what makes stage two possible.

Run it for a month before adding anything.

Stage two: reminders

The highest-return automation in a practice, and it still does not write to the diary.

Appointment reminders at the intervals that suit your patient mix.

Rescheduling by reply, handled by a person initially — which is the safe version and captures most of the benefit.

Watch the quality rating as volume increases, which is when it first becomes relevant.

Fall back to SMS or a call for patients not on the channel.

This is where a practice that stops still comes out ahead, which is worth knowing.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

  1. Open CodeWords and start a new automation.
  2. Describe what should happen in plain language to Cody, the automation builder: the stage you are at, what it handles, and what reaches reception.
  3. Authorize the connections to your practice management system and your WhatsApp Business Platform account.
  4. Describe the exceptions: pain, a clinical question, a complaint, an unclear message, a patient not on the channel.
  5. Run each stage for a month before starting the next.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Stage three: the things that move the diary

Automated rescheduling, which is the first thing that writes to the calendar.

Short-notice cancellation filling, which is high value and needs the race handled correctly.

New bookings, which is the hardest and should be last rather than first.

Reception reviews everything initially, until the mapping between what patients ask for and what gets booked is reliable.

Never hold a booking only in the conversation, which is the failure that double-books a chair.

This stage needs the practice system to cooperate, which is where some practices discover their software will not.

Stage four: intake and recall

Intake links sent ahead of appointments, with the form itself in a proper system.

Recall messaging at clinically set intervals.

Lapsed patient contact, carefully, since somebody who stopped attending may have a reason.

Post-treatment instructions, which patients keep and refer back to.

Treatment plan follow-up, where a plan was discussed and not booked.

By this point the channel is established, which is what makes these acceptable rather than intrusive.

What never gets automated

Clinical advice, in any form, including reassurance about a symptom.

Triage, meaning how urgently somebody needs to be seen.

Results or anything about a diagnosis.

Complaints, which have a defined process.

Anything to a patient in pain beyond routing them to a person immediately.

Safeguarding concerns, which follow the established route without delay or queue.

Who owns it in the practice

Name somebody, usually the practice manager, since an unowned channel degrades.

They watch the quality rating, the message volume and what reached reception.

They review the unanswered questions weekly, which is the list of what to improve.

They have authority to turn it off, which matters on a bad day.

The clinical team decides the boundaries, which is not the practice manager's call.

Fifteen minutes a week is the honest ongoing cost once it is running.

Bringing the team with you

The practice team hears "automation" and reasonably wonders what it means for their job, and how that is handled determines whether the thing is used or quietly worked around.

Say what happens to the time, directly, because the unspoken question is about headcount and not answering it is worse than any answer.

Start with what reception hates — the same five questions, the voicemail backlog — rather than with something they were proud of handling.

Let them keep the override. A receptionist who cannot intervene will stop trusting it and revert to the phone.

Involve them in the wording, since they know how patients actually ask things and you do not.

Show them what it caught: the evening enquiry, the cancellation filled, the form completed in advance.

Watch for the parallel system. A notebook by the phone means the automation is not covering something real, and that is information rather than disobedience.

Making it survive

The practice system is the source of truth, always, for anything about the diary.

Have a manual route that works when the automation does not.

Watch the quality rating from the first message, not from the first problem.

Keep opt-in records in a form you can produce.

Report the outcome: messages, handled automatically, reaching reception, and what could not be answered.

Limits worth knowing about

Practice management systems vary, and some do not integrate at all.

Patient adoption takes months, and some patients will never use it.

Messaging limits start low and rise with demonstrated quality.

Regulatory requirements for patient communication and record-keeping apply here as elsewhere.

Automation does not create clinical capacity, it removes administration — which is worth saying to a team worried about what it means for them.

What to build first

Stage one, complete, for a month: an acknowledgement, the answers you already give daily, a visible route to a person, and opt-in collection. It touches nothing that can go wrong, it removes a real share of the phone volume, and it is what makes every later stage safe to attempt.

Two habits make the difference. Do not let anything write to the diary until the practice system is the confirmed source of truth and reception has reviewed a month of bookings, since a double-booked chair costs more than every efficiency gained. And name one person who owns the channel, because an automation nobody watches on a channel where the number is the asset is a risk rather than an improvement.

Frequently asked questions

Where should a practice start?

Not with booking, which is the hardest exchange and touches the diary. Start with an acknowledgement, the answers you give daily, a visible route to a person, and opt-in collection — none of which can go wrong in a way patients see.

Why does the order matter?

Because patients take months to adopt the channel, messaging limits start low, and anything writing to the diary can produce a problem that reaches somebody in a waiting room. Each stage earns the next.

What is the highest-return automation?

Appointment reminders, which still do not write to the diary. A practice that implements only stages one and two comes out clearly ahead.

When should booking be automated?

Last. Reception should review every automated booking until the mapping between what patients ask for and what gets booked is reliable, and nothing should ever be held only in the conversation.

What must never be automated in a practice?

Clinical advice including reassurance about symptoms, triage, results or diagnoses, complaints, anything to a patient in pain beyond immediate routing, and safeguarding concerns.

Who should own it?

A named person, usually the practice manager, watching the quality rating and the weekly list of unanswered questions, with authority to turn it off. The clinical boundaries are the clinical team's decision rather than theirs.

How much ongoing work is it?

About fifteen minutes a week once running — the quality rating, the volume, and reviewing what could not be answered.

Will this reduce the need for staff?

It removes administration rather than creating clinical capacity, which is worth saying plainly to a team that will be wondering.

How do I introduce this to the practice team?

Answer the headcount question directly rather than leaving it unspoken, start with what reception actively dislikes, keep their ability to override it, and involve them in the wording since they know how patients actually ask things.

What does it mean if reception keeps a notebook by the phone?

That the automation is not covering something real. It is information rather than resistance, and the contents of that notebook are the most accurate list of what to fix.

Get started today

Your first workflow is free to build.

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