Appointment reminders that can handle the reply
Every booking system sends reminders. Almost none of them can do anything with the answer, so "sorry, can we push this to Thursday?" lands in an inbox nobody watches, and the appointment quietly becomes a no-show.
4 min read
The reminder was never the hard part. Handling the reply is.
What the agent is actually for
Four jobs, in the order they happen.
Confirm on booking. A short message with the details and one instruction: reply here if anything changes. That last line is what makes the rest possible, because it establishes the thread the customer will use later.
Remind at the right distance. Far enough out that moving is still possible, close enough to be useful. For most service appointments that is roughly a day.
Handle the answer. Reschedule, cancel, confirm, or answer the question the customer actually asked. This is the part a scheduler cannot do.
Close the loop. Update the booking in your system, record what changed, and stop.
Reminders are replies, which is why this delivers
A confirmation is the first message in a thread the customer expects. Every reminder afterwards should go in that same thread, so the whole exchange sits in one place for the customer and gives the agent its own context on the next turn.
The alternative, a fresh message per reminder, is worse in three ways: the customer sees an unlinked pile, the agent loses the history when they finally reply, and repeated unlinked mail to the same recipient is a shape that gets filtered. Threading mechanics are in how email threading works.
send_email { to: ["customer@example.com"], subject: "Your appointment, Tuesday 09:00" }
wait_for_reply { thread_id: "thr_...", timeout_seconds: 172800 }
reply_all { message_id: "msg_...", body: "Moved to Thursday 14:00. Confirmed." }wait_for_reply is doing real work there. The reminder does not need a scheduled job checking for answers; the thread is held open and the run continues when the customer writes.
The replies you will actually get
| They say | The agent should |
|---|---|
| "Confirmed" or "yes" | Acknowledge briefly, or say nothing and stop |
| "Can we move it to X" | Check availability, propose or confirm, update the booking |
| "I need to cancel" | Cancel, confirm in writing, and offer to rebook once |
| "What do I need to bring" | Answer from your documentation, not from memory |
| "Who is this" | Escalate. Something upstream is wrong |
| Silence | One reminder, then stop |
That last row is the discipline. A reminder cadence that escalates to three or four messages converts nobody and generates complaints, which cost more than the appointment did, per keeping an autonomous agent from becoming a spam problem.
The rules worth enforcing in tooling
Some of this is prompt work and some of it must not be.
The calendar is the source of truth, not the conversation. The agent proposes times your system says are free, and writes the change back to your system. An agent that agrees to a slot it cannot hold has created a double booking with a confirmation attached.
Money escalates. Deposits, cancellation fees, refunds. All of it belongs to a person, and the tool should refuse rather than the prompt discouraging.
No-shows are a human decision. The agent can note it. Charging for it, or deciding a customer is a repeat offender, is not its call.
Do not chase past the appointment. A reminder that arrives after the fact is a small, memorable failure.
Where it fits your stack
The booking system stays where it is. The agent gets its own address, reads the thread, calls your calendar and booking tools, and writes back. The email side is independent of the vendor: whatever holds your appointments, the agent talks to it through tools you expose, exactly as in the scheduling and recruiting patterns.
Two practical details. Put the timezone in the message and never make the customer do arithmetic. And keep the subject stable across the whole thread, since a customer searching their inbox next week will look for the original words.
What it changes
The measurable effect is fewer no-shows, and the mechanism is not the reminder, it is that rescheduling became a reply instead of a phone call. The second effect is quieter: the people who would have called your reception to move an appointment now do not, which is time back for whoever was answering.
Hotel enquiries run the same loop against live availability, in booking enquiries that arrive while the desk is busy. Property viewings are the same loop with more urgency, covered in answering property inquiries, and event logistics are in running an event's inbox. For a service business, this is usually the first agent worth running, because the volume is steady, the language is narrow, and the worst realistic failure is a time that has to be corrected rather than a promise you cannot keep. That makes it a good candidate for the plan in the first week with an email agent.
Questions
- Can an AI agent handle appointment reminders?
- Yes, and the valuable part is handling the reply: rescheduling, cancelling, or answering a question, rather than sending a reminder nobody can respond to usefully.
- How many reminders should it send?
- One, in the existing thread, roughly a day before. Then stop. Escalating cadences convert almost nobody and generate complaints.
- Should reminders be replies or new messages?
- Replies in the confirmation thread. The customer sees one conversation, the agent keeps its context, and unlinked repeated mail to the same person is a filtering risk.
- Can it reschedule on its own?
- Within limits you set, and only against times your booking system says are free. It must write the change back rather than agreeing to a slot it cannot hold.
- What should it escalate?
- Anything with money in it, anyone who seems not to know who you are, repeated no-shows, and any request outside the narrow set it handles.
- Does this replace my booking system?
- No. The booking system stays the source of truth. The agent handles the conversation around it, which is the part the booking system was never built for.
Give your agent an address it can answer from.
Create an inbox