Every appointment AIVA books — over the phone, through the web widget, or by text in the first place — triggers the same two messages afterward: a confirmation as soon as the booking is made, and a reminder ahead of the appointment itself. That part isn't unusual; most booking software does some version of it. What's different is what happens when the customer actually replies.
Not a one-way notification
Most confirmation and reminder texts are broadcast messages — they go out, and a reply either goes nowhere or lands in a generic inbox somebody checks later, disconnected from the booking it was about. That's the default because most systems that send these texts don't have anything on the other end able to understand a reply and act on it. This is also the pattern messaging platforms themselves point businesses toward — Twilio's own guidance on conversational messaging treats a reply as the continuation of a single thread, not a one-way broadcast, which is the same distinction that separates a genuinely two-way booking flow from a text that only looks like one.
AIVA's confirmation and reminder messages land in the same conversation thread as everything else, because they come from the same conversation engine that took the booking in the first place. A customer who replies "can we push this to 5 instead" to a reminder text isn't filing a new request into a queue — they're continuing the exact conversation that created the booking, and AIVA can act on it directly: check the new time, confirm it, update the booking. The same goes for a quick "STATUS" or "RESCHEDULE" reply, which routes through the same commands as anything else on the SMS channel.
What actually triggers each message
The confirmation fires the moment a booking is created, regardless of which channel created it — a call, the web widget, or a text conversation that turned into a booking on its own. It isn't a nightly batch job or a queued send; the message goes out as part of the same action that writes the booking, so there's no gap where a booking exists but the customer doesn't yet have anything in hand confirming it.
The reminder fires ahead of the appointment itself, timed to the kind of appointment it is rather than one fixed rule applied to everything a business books. What matters more than the exact lead time is what the reminder actually contains: the specific date, time, and service, not a generic "you have an upcoming appointment" that makes the customer open a different app just to check what it's even about.
It doesn't matter where the booking started
Because every channel shares the same underlying system, the flow works identically regardless of how the appointment was made. Book over the phone, and the confirmation still arrives by text, because a text is the channel that reaches a customer without asking them to open anything. Book through the web widget while sitting at a desk, and the reminder still shows up on the phone in their pocket days later, with the same context intact — AIVA isn't re-deriving the booking from scratch when it sends that reminder, it already knows exactly what was agreed to and who agreed to it. That's the same one conversation engine running underneath every channel that makes a booking made on a call visible the moment a customer texts about it instead.
This is also why the reminder text works for customers a chat widget could never reach in the first place — no app, no login, and it lands on any phone, including one without a data connection at the moment it arrives. We've written more about why SMS reaches customers other channels structurally can't.
Why the reply matters more than the send
It would be easy to treat the confirmation and reminder as the whole feature — the text goes out, box checked. We think the actual value is almost entirely in what happens after: a customer who gets a reminder and realizes they need to move it has a real, immediate way to do that without calling anyone or waiting for the business to notice a problem before it becomes a no-show. Plans change between the moment someone books and the moment the appointment happens. The flow is only as good as how easy it is to fix that when it does.
The commands riding on the same thread
Three shorthand replies do a lot of the heavy lifting on top of plain-language replies: STATUS, RESCHEDULE, and REFUND. A customer who just wants to confirm an appointment is still on the books can text STATUS and get a direct answer instead of calling and waiting on hold to ask something that simple. RESCHEDULE opens the door to picking a new time without a phone call at all. REFUND routes a cancellation-related request the same way. None of these require the customer to know they're "commands" in any formal sense — they read naturally as the shortest possible way to say what the customer already wants, and AIVA treats them accordingly.
What happens when a reply isn't one of the three commands
Most replies aren't a clean keyword — they're a sentence, like "can we push this to 5 instead" or "actually I need to cancel, something came up." That's the more common case, and it's handled the same way a command would be: loaded against the open conversation thread, understood in context, and acted on. The three commands exist because some replies are short enough that a keyword is genuinely the fastest path for the customer, not because plain language falls back to something worse. A customer never has to learn the shorthand to get the flow to work — it's there for people who want the fastest possible reply, not a requirement for everyone else.
Edge cases worth knowing about
A few situations are worth naming honestly rather than glossing over. A customer who replies to an old reminder well after the appointment has already passed still gets a response grounded in what the thread actually shows — a stale reply doesn't quietly vanish, but it also doesn't get treated as though the appointment were still upcoming. A reply that arrives while a business is actively rescheduling that same booking through another channel is read against the booking's current state at the moment the message is processed, not a snapshot from when the reminder was originally sent — which is why the underlying record, not the text message itself, stays the source of truth. And a customer replying about something unrelated to the booking entirely — a new question, not a change to the existing appointment — gets treated as its own topic rather than being forced to connect to whatever the reminder was about.
Why this matters for no-shows specifically
A confirmation and reminder that can't be acted on by reply does roughly half the job a reminder should do — it tells the customer about the appointment but gives them no low-friction way to change it if their plans shift. SMS reminders reduce no-shows more reliably than a phone call reminder precisely because of this: the slot only reopens once a customer actually says they're not coming, and a two-way text is a much easier way to say that than picking up the phone. A reminder that only broadcasts leaves that decision sitting with the customer with no easy way to act on it, which is a large part of how a booking quietly turns into an empty slot instead of a rebooked one.
Setup, and what a business actually has to do
There's no separate configuration step to turn this on beyond connecting AIVA to how a business already takes bookings. Once that connection exists, confirmations and reminders go out automatically around whatever gets booked, on whichever channel it was booked through — nothing for a business to manually trigger per appointment. SMS runs on the same pay-as-you-go pricing as the rest of AIVA, at ₹1 per message, whether that message is a confirmation, a reminder, or the customer's reply.
That's the actual design goal behind this flow: not "send a text," but "leave a live channel open, all the way through to the appointment, that the customer can actually use if something changes." See how the SMS channel works end to end, or start free and watch your own first confirmation land.