How to Automate Dental Patient Recalls: A Setup Guide for Philippine Clinics

Say Smile & Skin Clinic in Mandaue runs the report for patients due for a cleaning. It comes back with 412 names. The clinic has twelve cleaning slots open next week.

Put those two numbers next to each other and most advice on this topic falls apart. Almost everything written about automating recalls is about the message: what to say, when to send it, which wording gets a reply. Wording is not what is wrong here. Even a decent message sent to 412 people produces more replies than a two-chair clinic can answer and more demand than it can seat, and everyone it cannot seat gets offered something four weeks out. That is how a patient works out you were not really expecting them.

The message is the last part of a recall system. This article is about the rest of it: how a recall gets created, where it waits, how many leave at once, and what has to happen for one to close. If those are right, a plain message does the job. If they are wrong, the wording never saves it.

The short version

1. Fix capture first. A recall that was never created cannot be automated. Count how many of last week's completed visits left with a next due date.
2. Store a reason, not just a date. A cleaning, a perio maintenance visit and a retainer check are different clocks and different messages.
3. Give every recall a state. Most clinics hold a list, and a list cannot tell you who already booked. That is how patients get texted after they said yes.
4. Release the queue in batches sized to the slots you actually have open, oldest due first.
5. Make the booking write back. If your messaging cannot see your appointment book, stop here and fix that before automating anything.
6. Create the next recall at the end of the visit, or your loop is a straight line that runs out.
7. Write the message last. It matters, and it is still the smallest part of this.

Steps 1 and 5 are where clinics lose. The rest is admin.

Recall and reactivation are two different machines

These get used interchangeably and they should not be.

A recall is a dated obligation you created for a patient who is still yours. You saw them, you decided when they should come back, and that date is sitting in the future waiting to arrive.

A reactivation is what you do after recall failed. The patient has not been seen in a year or two, nobody is holding a date for them, and you are asking somebody who used to trust you to come back.

The second one is harder, and it has its own article: how to get old dental patients back covers the list-building, what the Code of Ethics and the Data Privacy Act permit you to say, and the three-touch sequence.

Here is why the distinction matters for automation. If you automate reactivation without fixing recall, you will clear the backlog this quarter and rebuild it by next year, because the machine that produces lapsed patients is still running. Reactivation is a mop. Recall is the tap.

A recall is created at the chair, not by your software

Most clinics skip this part, and it is why their recall automation disappoints them.

No system can message a patient it has no record for. When a clinic tells me its recall automation is not working, the first thing I want to see is not the message. It is this count:

Take last week. Count the visits you completed. Now open your system and count how many of those patients have a next recall date on them today.

If you finished 38 visits and 11 have a due date, your recall system is broken a long way upstream of any software. Automating the send just delivers the same eleven people faster. The other 27 are invisible, and they will surface in about two years as a reactivation problem.

Capture four things before the patient stands up:

• Who. A mobile number that is current, not the one from 2021.
• Why. The reason for the recall, which decides both the interval and the wording.
• When. The due date, set by the dentist rather than by a default.
• Whether you may contact them, and how. Consent and preferred channel, recorded once and honoured after.

Better still, book them before they leave

The best thing you can do with a recall is turn it into an appointment before the patient leaves the clinic. An appointment already in the book needs a reminder, which you almost certainly already automate. A recall needs persuading.

You will find confident numbers online about how much better pre-appointed patients return. I could not trace any of them to a study, only to consultancy and vendor blogs quoting each other, so I am not going to repeat them as fact. The mechanism does not need a statistic. One patient holds a slot with their name on it and gets a reminder. The other holds nothing and has to be talked into coming back. Those are not the same job.

This works for perio maintenance, orthodontic adjustments and staged treatment, anything on a short interval. It struggles with a six-month cleaning, because plenty of Filipino patients will not commit to a Tuesday in March, and asking twice makes it worse. For those, capture the recall properly and let the system do the work later.

One clock per reason, not one clock for the clinic

Most clinics run a single interval for everybody, usually six months, and treat the recall list as one thing. It is not one thing. It is several queues sharing a spreadsheet.

Recall reason	What starts the clock	Who sets the interval	What the message must carry
Oral health review and cleaning	Date of the last review	The dentist, per patient	Price, how long it takes, two specific times
Periodontal maintenance	Last maintenance visit	The dentist	The same, plus why this one is shorter
Orthodontic adjustment	Last adjustment	The orthodontist	Usually just the time, since it sits inside the plan
Retainer check	The debond date	The orthodontist	The reason, because patients think retainers are finished business
Post-operative review	The procedure date	The dentist	Short and specific, and never sent as part of a batch
Denture check or reline	The fit date	The dentist	The reason, because people put up with a bad fit for years
Paediatric review	Last visit	The dentist	Addressed to the parent, not the child
Unfinished treatment	A plan with steps left	The dentist	The actual tooth and what is left to do

The intervals themselves are clinical judgement and they belong to the dentist, not to whoever configures the software. A blanket six months is a convention rather than a safety floor. NICE guideline CG19 recommends setting the interval from the individual patient's disease risk, choosing from 3, 6, 9, 12, 15, 18, 21 or 24 months for an adult and 3, 6, 9 or 12 months for anyone under 18. The evidence behind that, and why Philippine attendance patterns complicate it, is in the follow-up article.

The last row is a borderline case. Unfinished treatment behaves more like a follow-up than a recall, and it is handled as its own trigger in that same article. I have left it in the table because it competes for the same chair time and the same front desk attention, so it belongs under the same queue discipline.

What this means for software: if the only interval your tool understands is one global number, you have bought a mailing list. A recall system needs the interval stored per patient, per reason.

Give every recall a state

A recall record has to know where it has got to. Most small clinics have nowhere to store that, which is the single cheapest thing to fix on this list.

A recall record moves through states:

1. Scheduled. The due date is in the future. Nothing happens and nobody looks at it.
2. Due. The date arrived. The record is in the queue, waiting for a batch.
3. Contacted. A message went out. Record which touch this was, and when.
4. Closed, booked. An appointment exists. The recall is finished.
5. Closed, stopped. The patient asked you to stop, or three touches went out with no reply. The record leaves the recall queue and joins the reactivation list.

A list has none of this. A list has names and a date, so the same forty people appear every time anyone opens it, and nothing distinguishes the ones who booked last Tuesday from the ones who have ignored you since March.

That produces the two failures that actually damage a clinic.

Texting people who already booked. A patient books on Monday, gets a recall message on Wednesday telling her she is due, and now quietly wonders whether her appointment exists. You have spent money to make somebody trust you less.

Never closing anything. Without a stop state the queue only grows, the front desk starts ignoring it, and within two months the automation is running into a void.

The rule that prevents the first one: the booking has to write back to the recall record. This is the most important integration question to ask a vendor, and it is worth asking in plain words. If a patient books, does your messaging know? If the answer involves somebody ticking something manually, it will not survive a busy week.

It is the same principle as picking one calendar to be the truth, which is the foundation of automating your booking at all.

Close the loop at the other end too

When a recall converts and the patient attends, something has to create the next recall. If that does not happen at the chair, your system is a straight line that runs out rather than a loop, and you have moved the leak six months into the future.

Meter the queue to your chairs, not to your list

Back to the 412 names and the twelve slots.

The instinct with a fresh recall queue is to send everything, because the software makes it free and the list has been sitting there accusing you for a year. Resist it. You promise availability you do not have, your front desk drowns in replies, and you spend a month of SMS allowance in an afternoon. You also burn the list, because a patient who was offered nothing useful in March is harder to reach in September.

Send in weekly batches sized to the chair time you actually have open, oldest due first.

You do not know your own booking rate yet, so start small and measure it:

• Week one, send 40 messages. Say 5 of them become booked appointments. That is roughly one booking for every eight messages, and that ratio is yours, not a benchmark.
• Twelve open slots at one in eight is about 96 messages a week.
• Now check that against two other limits. Can your front desk handle the replies 96 messages produce, given that most of them arrive within an hour of sending? And does 96 a week fit inside the SMS allowance you are paying for?

Whichever of those three numbers is smallest sets your batch. For most small clinics it is not the slots. It is the replies.

That is also the honest argument for automating the conversation rather than only the send. Sending is easy and cheap. Answering "magkano na po ngayon?" forty times on a Monday is the part that costs something.

What you can automate with a spreadsheet and no budget

You do not need a platform to run most of this. You need a table somebody actually maintains, and twenty minutes a week.

Columns, in order:

Patient, Mobile, Last visit, Reason, Interval (months), Due date, Touch 1, Touch 2, Touch 3, Outcome, Next due

The weekly ritual, Monday morning:

1. Filter to rows where Due date is on or before today and Outcome is blank.
2. Sort oldest due first.
3. Take the top N, where N is the batch you worked out above.
4. Send, filling in the touch date on each row as you go.
5. When somebody books, write the outcome immediately. This is the write-back rule done by hand, and it is the step that gets dropped.

This is genuinely fine for a clinic with a few hundred patients. It stops being fine when the replies outgrow the person answering them, which usually happens before the list does. If you are choosing a management system, whether recall dates are stored per patient and per reason is worth more than most of the feature list: see what to look for in dental clinic management software.

The message, briefly, because it is covered elsewhere

Three things belong in a recall message, in this order: what it costs, how long it takes, and two specific times. A recall that says "you are due for your check-up, please call us to schedule" hands the patient all the work and answers none of the reasons people put dentistry off.

For Philippine SMS the delivery rules matter more than the copy:

• No links. Carriers drop them silently and your sending report will still say delivered.
• Register your sender ID, and put the clinic name in the first line anyway.
• Mirror the patient's language. Somebody who messages you in Bisaya should not get formal English back.
• Write PHP, not the peso sign. The symbol sits outside the SMS alphabet and pushes the whole message into an encoding with less than half the room.

One counted example, using a nine-character sender ID with the clinic name in the body:

Smile & Skin Clinic: Hi Ms Reyes, your cleaning is due this month. It's PHP 1,500, about 45 minutes. We have Tue 10AM or Thu 2:30PM. Reply TUE or THU to book.

That is 158 characters and bills as one message. Swap PHP 1,500 for the peso symbol and it gets three characters shorter and bills as three, because that one symbol forces every character in the message into the longer encoding. There are eighteen more templates counted the same way in dental appointment reminder SMS templates, and the delivery rules are set out in full in how to automate dental appointment reminders.

The second touch should hold something specific rather than repeat the first:

Smile & Skin Clinic: Hi Ms Reyes, still holding Thu 2:30PM for your cleaning. Reply THU to take it, or STOP if you'd rather we don't text.

138 characters, one message, and it gives the patient a clean way out. Letting people off the list costs you a few names and keeps the rest of it worth sending to.

Common mistakes

Automating the send before fixing the capture. The most common one by far. You end up with a fast, reliable system for contacting a fraction of the people who should be in it.

One interval for the whole clinic. Six months for everybody is a convention. It also guarantees that your perio maintenance patients and your retainer checks run on the wrong clock.

No write-back. Patients who already booked keep getting recall messages. This is the failure that costs you trust rather than just money.

Blasting the whole list. Covered above. The list is not the constraint. The chairs and the front desk are.

Treating no reply as no. One unanswered text is not a decision. Three unanswered texts over a few weeks is, and then you stop. Write that stop rule down before you send anything.

Putting a booking link in an SMS. It feels like the obvious answer, and it is the most reliable way to make a Philippine recall message disappear.

Reaching for a discount. The Philippine Dental Association's Code of Ethics rules out promotional rates, so the American playbook of a comeback offer is not available to you. The detail is in the reactivation article. A recall does not need a discount anyway. You are telling somebody they are due, not selling them something.

How to tell whether it is working

Three numbers, and none of them is "messages sent".

Capture rate. Completed visits that left with a next recall date, divided by completed visits. This is a leading indicator and the only one you can fix this week. If it is not close to everybody, nothing downstream matters.

Queue age. The due date of the oldest recall nobody has contacted yet. If that keeps getting older, your batch is too small or nobody is running it. One number, checked weekly, tells you whether the system is alive.

Conversion inside 30 days. Of the recalls contacted last month, how many became an attended appointment. Not booked. Attended, because a recall that becomes a no-show has cost you twice, and that is a different problem with its own fixes.

You will find recall benchmarks quoted all over the internet, usually something around eighty percent completion. I have not been able to trace those to anything primary, and a figure drawn from American practices with insurance-driven attendance would not transfer here anyway. Your own first month is a better baseline than somebody else's number. Measure yours, then try to beat it.

Where OtterFlow fits

Read back over this article and notice which parts are conversations. The due dates, the intervals and the reporting live in whatever runs your clinic. That is not the part we do.

OtterFlow handles what happens after the recall goes out. The batch leaves on the schedule you set. When Ms Reyes replies, Flo answers the price and timing questions from information you approved, checks what is genuinely open instead of guessing, offers real times, and writes the booking. Because it made the booking, it knows the recall is closed, so nothing waits on somebody remembering to tick it off. The confirmation goes out immediately, the reminder follows before the appointment, and anyone who does not turn up gets a rebooking link instead of falling back onto the list you just worked through. It answers in English, Taglish or Bisaya, matching however the patient writes.

Two things it deliberately will not do. It will not answer a clinical question, because recall messages invite them and "is it normal na masakit pa rin?" belongs to your dentist. And it will not invent an answer it does not have, so anything outside what you approved goes to your team, who can take over the conversation completely.

Setup is ₱5,000 once and ₱2,500 a month after that, and we configure it around your services, prices, hours and booking rules rather than handing you a dashboard to fill in.

If you want to see it running a recall against your own service list and your own open slots, that is what the fifteen-minute call is for. Bring the report with the 412 names.

Questions clinic owners ask

How far ahead of the due date should the first message go out?

A few weeks before, rather than after. Contact somebody the week their cleaning is due and you are competing with everything else in their week. Contact them three or four weeks out and you are offering a choice of times while they still have an empty diary. The exception is post-operative review, which goes out on the clinical schedule and never in a batch.

Nobody in my system has a recall date. Where do I start?

Generate them from the last visit date plus a default interval per procedure, then mark those as estimated. They are good enough to build a queue from. Fix each one properly at the patient's next visit, and within a cycle the estimates have been replaced by real clinical decisions. Do not let the absence of perfect data stop you from starting, and do not let the estimates harden into permanent truth either.

Do I need consent to send a recall message?

Your patient list is health data under the Data Privacy Act, a stricter category than an ordinary customer list. Contacting your own patient of record about a clinical due date is ordinary practice rather than marketing, but the surrounding obligations still apply: identify yourself, keep it to the fact that they are due, honour a request to stop, and hold the list securely. The longer treatment is in the reactivation article and in our privacy notice.

Should the AI decide the recall interval?

No. That is a clinical decision and it belongs to the dentist. Software should store the interval, act on the date, and stay out of the judgement. If a tool offers to work the intervals out for you, turn that part off.

Can I use email instead of SMS?

Send it as well, by all means, since it costs nothing. I would not build the system on it. Most Philippine clinics collect an email once at registration and never learn whether the patient reads it, whereas a mobile number gets used. Messenger is worth more than email here, with the caveat that Meta's 24-hour rule limits what you may send outside an active conversation, which is set out in automating your clinic's Facebook messages.

We are a single-dentist clinic with 300 patients. Is this overkill?

The spreadsheet version is not. Eleven columns and twenty minutes on a Monday does everything this article describes except answer the replies for you. Start there. The argument for software begins when the replies stop fitting into the gaps between patients, and you will know when that happens, because the Monday ritual will start getting skipped.