Most recall automations I write about chase something soft. A dental patient who "should" come back, a salon client who "might" rebook. Optometry has something rarer: a hard, patient-specific expiry date printed on a piece of paper. A contact lens prescription runs out, and when it does, the patient cannot simply keep ordering. They need a new exam first. That one fact turns recall from a nagging suggestion into a timing problem, and timing problems are exactly what automation is good at.
As Gideon Wafula, AI Automation Engineer, I build narrow revenue automations for local businesses, and this is one of the cleanest I have seen on paper. It is also easy to get wrong in ways that cost goodwill. Here is how the leak works, what the build looks like, and where I would not use it.
A patient walks out with a twelve-month contact lens prescription and a box or two of lenses. Somewhere around month ten they run low, go to reorder, and discover the prescription is about to lapse or already has. Now they have a choice. Book an exam with you, or find the path of least resistance, which for many people is whichever online retailer or competitor offers the easiest route. Your practice never knew it was a decision point, because nothing in your day was scheduled around it.
Industry vendors describe the broader recall problem in similar terms. One recall-software vendor, Jelo, claims that roughly a quarter to a third of optometry patients fail to return for their next recommended exam, and it attributes that to four gaps: missing recall data, no trigger tied to benefit or prescription expiry, single-channel reminders, and no follow-up when a patient does not respond. Treat those as vendor claims rather than neutral research, but the shape matches what I see in small practices: the list exists somewhere, nobody owns it, and the messages go out in bursts when someone has a quiet afternoon.
I made the case in The AI Agents That Actually Make Money Are Narrow and Boring that the builds that earn their keep do one job with a clear input and a clear output. Contact lens recall fits. The input is a prescription expiry date and a patient record. The output is a booked exam. Everything between is a schedule and a handful of rules. There is almost no room for a language model to wander, which is what you want near patient communication.
I would build this in n8n on top of whatever practice management system the office already uses. The steps below are the ones I would insist on, in this order.
Pull every contact lens patient into a single table with: last exam date, prescription expiry date, lens type if known, preferred channel, language, consent status, last human contact, and whether an exam is already booked. Do not assume a missing expiry is twelve months. Leave it empty and route those records to a person. The first week of this project is usually data cleanup, not messaging, and that is normal.
A nightly job calculates days until each prescription expires and classifies the patient: on track, inside the recall window, expiring soon, or already lapsed. A patient who was last seen in October gets a different timeline from one seen in March, which is exactly right and exactly what a blast email to "everyone who has not visited in a year" cannot do.
The message does one thing: tell the patient their contact lens prescription is coming up for renewal and give them a direct link to book. The same vendor material suggests text messages outperform email on opens, and a practice-software source I read noted that some patients will ignore anything sent by mail and only respond to text. I would still treat the channel as something to test on your own patients rather than a settled fact. Keep it plain, put the booking link first, and name no prices.
My starting point is two automated touches and then a phone call from a person for anyone still silent, with the expiry date and last visit on the screen. I would not send a fifth message. More automation after the second touch tends to turn a helpful reminder into pressure, and it is the lapsed patients with the most history that are worth a real call.
Check the schedule at send time, not at selection time. If the patient has booked, called, replied, or opted out since the list was built, the message does not go. This single rule prevents most of the embarrassing automation stories.
Anything beyond "yes, I want to book" goes to staff: questions about price, insurance, a different lens brand, or any mention of discomfort, redness, or vision changes. A model should never answer a clinical question, and it should not try to triage symptoms. Flag it and a person takes it from there.
The model drafts tone. Every date, appointment slot, and practice name is injected from your system as a validated variable, and a draft containing a number the system did not supply is rejected before it sends. Keep health detail out of message bodies entirely: "your prescription is due for renewal" is plenty. In the US, text messaging needs prior express consent and an immediate opt-out path, with sensible local sending hours; in the UK and EU, servicing a patient's existing relationship is different from marketing, so keep the message free of upsell. Rules vary by location, so have someone qualified check yours. I am not a lawyer, and this is not legal advice.
Add a circuit breaker too. If opt-outs or complaints cross a threshold you set, the workflow pauses and pages a human. It costs almost nothing to build and it is the difference between a small mistake and a large one.
Baseline four things before launch. First, the share of expiring prescriptions that turn into a booked exam within the window, measured separately from the blended recall rate. Second, days from first message to booking, because if that number is large while your calendar is full, you have a capacity problem and no message will fix it. Third, opt-out rate, which should act as an automatic stop signal. Fourth, how many lapsed patients you win back by phone after the automated touches, since that tells you whether the call step is earning its staff time.
For context on the money, the Jelo analysis illustrates that for a two-doctor practice with roughly 7,500 annual visits at about 280 dollars of revenue per visit, a ten-point lift in return rate would be on the order of 750 visits and 210,000 dollars a year. That is the vendor's own worked example with assumptions I cannot verify for your practice, so plug in your own visit volume and average revenue before believing any figure, including that one.
If your next available exam is six weeks out, automating the reminder just creates a queue of annoyed patients. If patients are leaving because of frames pricing, a poor fitting experience, or a doctor who moved on, a perfectly timed message only delivers them to the same disappointment. Automation finds the patients you were already losing quietly. It does not make the experience worth coming back to.
It also does not replace the human relationship. The best version of this build makes your front desk more present, not less: they spend their time calling the twenty patients who matter instead of working through a spreadsheet.
Expect roughly 30 to 120 USD per month in running costs for a single practice: the automation platform, messaging fees, and a small amount of model usage. The real expense is the one-time integration with your practice management system and the data cleanup in step one. If you want to see how this sits alongside the rest of the recall and reactivation work, read my piece on database reactivation, the related expiring-benefits recall build that covers the December insurance deadline, and the dealership recall teardown, which uses the same expiry-driven logic in a different industry. You can see what I build on my services page.
Gideon Wafula builds custom AI automation systems, n8n, WhatsApp, Voice AI, and more.
See Services →