AI Appointment Systems

The standard reminder is a one-way SMS twenty-four hours ahead. It gets delivered, sometimes read, and changes almost nothing — because the customer who cannot attend has no way to say so from that message. They would have to find the number, call during business hours, and wait. So they do nothing, and you find out when the slot is empty. A reminder that works is bidirectional and low effort: confirm, reschedule or cancel, each resolvable by replying in the same thread.

Reschedule offers two or three specific alternative slots rather than asking an open question, because open questions produce free text like next week sometime that requires a human anyway. Timing matters more than most operators expect. A single reminder the day before underperforms a sequence: one at booking time, one a few days out where the booking was made far in advance, and one the morning of. The morning-of message is the one that recovers slots, because it reaches the person whose plans changed overnight while there is still time to backfill.

Channel matters just as much. In India, WhatsApp is read and SMS increasingly is not, but WhatsApp template messages have rules — utility templates for transactional reminders, a twenty-four hour service window for free-form replies — and a system that ignores them gets throttled or blocked. We build to those rules rather than around them, with SMS and voice fallback for the customers who genuinely are not on WhatsApp.

• Two-way reminders where confirm, reschedule and cancel resolve in one reply
• Reschedule offers specific alternative slots, never an open-ended question
• Sequenced reminders — at booking, a few days out, and the morning of
• WhatsApp-first for India, with template compliance built in rather than worked around
• SMS and voice fallback for customers not reachable on WhatsApp

Most businesses have a waitlist and almost none of them work it, because doing so means someone calling down a list the moment a cancellation lands — precisely when the front desk is busiest. Automated backfill inverts this. When a slot frees, the system identifies waitlisted customers who match on service type, practitioner, location and stated availability, then messages the top few simultaneously with the slot offered on a first-response basis. Whoever confirms first takes it; the others receive a message that it has gone, which matters for trust and is the step teams forget.

The design decisions that make this work are unglamorous. How many people do you offer a slot to at once — too few and it goes unfilled, too many and you annoy people repeatedly. How long does an offer stay open before moving down the list. Do you allow a customer to be offered slots more than a set number of times per week. And critically, the confirmation has to be atomic: two people replying yes within the same second must not both get booked, which is a database transaction problem rather than a messaging one.

We also apply this to the gaps that are not cancellations — the awkward thirty-minute holes between bookings that nobody sells. A system that knows a specific practitioner has a gap at 3pm on Thursday can offer exactly that to the customers for whom it fits, which is not something a front desk has the attention to do.

• Matched offers on service, practitioner, location and stated availability
• First-response wins, with an atomic booking transaction so double-booking is impossible
• A courteous message to those who missed it, which is the step most systems skip
• Offer caps per customer per week, so backfill does not become a nuisance channel
• Gap-filling for the awkward holes between bookings, not just full cancellations

Nobody abandons an appointment system because the language was slightly stiff. They abandon it because it booked two patients into the same slot, or because it moved a 9am appointment to 4:30am for a customer travelling abroad, or because a network retry created three identical bookings and a customer received three confirmations. These are boring engineering problems and they are the ones that matter. Idempotency is the foundation: every booking action carries a key so that a retried request resolves to the same appointment rather than a new one.

Concurrency is handled at the database level with proper locking, not by hoping two requests do not arrive together — under waitlist backfill they absolutely will. Timezones are stored as instants with an explicit zone, never as naive local strings, and daylight-saving transitions are tested rather than assumed, which matters for any business with customers in Europe or North America. Where the calendar of record is an external system — a practice management platform, a Google Workspace calendar, a CRM — we treat it as the source of truth and reconcile continuously, because a locally cached view that drifts is worse than no automation at all.

When the external system is briefly unreachable, the system degrades to holding a provisional booking and confirming once reconciled, rather than either failing outright or promising a slot it cannot guarantee.

• Idempotency keys on every booking action, so retries cannot duplicate
• Database-level locking for concurrent confirmations under waitlist backfill
• Instants with explicit zones, with daylight-saving transitions actually tested
• External calendar treated as source of truth, reconciled continuously
• Graceful degradation to provisional bookings when the calendar system is unreachable

An appointment assistant that tries to answer everything will eventually answer a medical question, and that is a category of mistake no efficiency gain justifies. We define the boundary explicitly and narrowly: the system schedules, reschedules, cancels, answers logistics questions about location, timing, preparation and pricing where those have documented answers, and does nothing else. Anything touching clinical or professional advice, complaints, refunds or disputes goes to a person immediately.

Sentiment triggers matter too — a customer who is clearly frustrated should reach a human on the first sign of it, not after three more automated turns that make it worse. The handover has to carry context. A staff member picking up the conversation should see the full thread, the appointment record, and what the system was attempting, so the customer does not repeat themselves. Getting this wrong is the fastest way to make automation feel worse than the phone.

We also make the escalation path visible: at any point a customer can ask for a person and get one, without a hidden keyword. Businesses sometimes resist this because it reduces deflection rate. Deflection rate measured without a satisfaction floor is a vanity metric — anyone can raise it by making escalation difficult, and the cost lands in reviews rather than in the dashboard.

• A narrow, explicit scope: scheduling and documented logistics, nothing further
• Immediate escalation on clinical, professional, complaint or payment topics
• Sentiment-triggered handover on the first sign of frustration, not the fourth turn
• Full conversation and appointment context passed to the staff member picking up
• A visible, always-available route to a human — no hidden keyword required