What memory-driven recall looks like
Picture a dental front desk on a slow Tuesday. Someone remembers that a handful of patients have not been back in a while and starts scrolling the schedule to find them. A sticky note and an old personal spreadsheet list names with no dates. By Thursday the schedule is full, the calls never happen, and nobody knows who was contacted, who declined, or who was never reached.
That scene is an illustration, not a TwoQM client. Many medical and wellness practices, dental offices included, run recall from memory and good intentions. TwoQM builds business automation that turns recall into a list driven by dates the office already records, with a named owner and a logged outcome for every patient on it.
This article is about the administrative recall list: who is due back, who was contacted, how, and what happened. It is not new-patient paperwork requests, which covers first-visit forms, and it is not booking or inquiry routing. It gives no clinical or health advice. How often a patient should return is set by the dentist and clinical team, not by software or by this article.
Here is an original example, not a measured result. A two-dentist office in the Rio Grande Valley keeps a "recall" tab in its practice management system that only one long-time coordinator knows how to filter. When she is out, nobody runs it. Another staffer calls patients from a printed list, but writes results on the printout, which goes in a drawer. Two months later, the same patients get a second call, and one family that asked to be contacted only by text gets a voicemail instead.
Nobody is careless. The due date, the attempts, and the preferred channel never lived together on one list the whole front desk could see.
Build the list from the dates you already have
A recall list should be calculated, not remembered. Each row needs only a few administrative fields:
Last completed visit date. Pulled from the scheduling or practice management system, not typed by hand.
Recall interval. The interval the clinical team set for that patient, stored as a number of months. Software stores the decision; it does not make it.
Due date. Calculated from the two fields above, so the list sorts itself.
Preferred contact method and language. Text, phone, or email, in English or Spanish, as the patient chose.
Recall owner. The named staff member responsible for that row this month.
Clinical details and patient health information stay in the practice management system and the other tools your practice and its compliance advisor have approved. The recall list does not need a reason for the visit to know that a patient is due. "Due for your next visit" is enough.
Log every attempt and outcome
The second half of the list is the log. Each contact attempt records the date, the channel, who made it, and an outcome from a short fixed menu: scheduled, left message, no answer, asked to call later, declined, wrong number, moved away, or asked not to be contacted. Notes are fine, but the outcome field is what lets the office filter.
Two rules keep the log honest. First, the row stays open until a person records an outcome; an automated message going out is not an outcome. Second, "asked not to be contacted" and "moved away" stop all future reminders for that patient until a staff member reviews it. Your office decides the consent and contact rules; the system only enforces the ones you write down.
Let dates trigger the reminders
Once due dates and outcomes exist, the repeatable steps become ordinary automation. A first reminder goes out in the patient's preferred channel and language around the due date your office chooses. If there is no outcome after a set number of days, the row moves to the owner's phone list instead of getting a third automated text. Patients who schedule drop off the list when the appointment appears.
The front desk works from one short view: overdue and unreached, sorted by due date, with the last attempt and owner visible.
Where AI helps, and where it stops
Calculating due dates and sending scheduled reminders is predictable work that does not need AI. AI can help on the staff side: drafting a friendlier reminder template, producing a first Spanish draft that a bilingual team member edits, or summarizing which outcomes came up most this month. It never decides a patient's recall interval, never reads clinical notes, never marks a patient as contacted, and never sends messages on its own.
Connect it to the systems you already run
Your practice management system stays the source of truth for visits and the schedule. The recall layer can read last-visit dates and new appointments from it, if the system allows that, and write nothing clinical back. Contact preferences and the outcome log can live in a lightweight CRM used for communication only. TwoQM calls this connected systems work. Whether your current software supports those connections is confirmed during scoping. Sometimes the built-in recall report plus a shared outcome log is enough, and scoping should say so.
Where to start this week
Run whatever recall report you have today and count three things: patients past due, patients with no recorded contact attempt, and patients whose preferred channel is unknown. Then name one recall owner for next month and write down your outcome menu on one page. That page is the first draft of your recall rules.
If you want recall driven by last visit dates and logged outcomes instead of memory, TwoQM can scope the fields, reminders, and connections around the systems your office already uses. Pricing explains how business apps, systems, and custom software are scoped. Nothing here is clinical, legal, or compliance advice.