Ask most people what stands between a customer and a changed appointment and they will say the form. Three fields, a date picker, a confirm button. Take the form away, let the assistant do it in the conversation, and the friction is gone.
The form is not the friction. A reschedule is a write to a live operation, and the moment a conversational layer can perform one, you have to answer out loud every question the form used to answer implicitly by making a human press the button. Here is what has to be true first, from building this on a healthcare-adjacent deployment, and why I ended up more conservative than the pitch.
A reschedule and a cancellation are not the same risk
Both look like one action on one record. They are not.
A reschedule is a swap: hold the new thing, then release the old one. If it half-completes you get a recoverable mess. Two slots held, or none held, and a customer who can be told the truth within the hour.
A cancellation releases capacity into a pool other people are actively drawing from. Twenty minutes later the slot belongs to somebody else and there is nothing to undo. The same conversation, the same request, and a completely different cost when the system is wrong.
So the permissions are asymmetric by design. There are records our assistant may move that it may not cancel. That reads as an inconsistency until you write down what each action costs when it misfires. Reversibility, not effort, should decide how much rope an agent gets.
The handover link is the design, not a cop-out
Where I landed: the assistant carries the customer all the way up to the change, and then hands over a link scoped to that one appointment, which the customer submits themselves. Not because the machinery to write directly is missing. Because the confirmation should belong to the person whose appointment it is.
Treated seriously, a scoped link is a real primitive: one capability, one record, a limited life. The W3C TAG's note on capability URLs is short and worth reading before you issue your first one. It is specific about how these things leak, through referrer headers, shared screenshots, browser history, and about what that implies for how long they should live.
The link also buys something an in-conversation write never does: a moment where the whole change sits in one view before it happens. Chat is a poor medium for "here is everything about to be different about your appointment", because it arrives a sentence at a time and the important line scrolls away. A summary someone reads and submits is not a worse experience than an assistant saying "done". It is a different distribution of certainty, and where a wrong move costs somebody a wasted visit, I want that certainty on the customer's side.
A date change is rarely just a date change
Move an appointment and the preparation instructions can change. What is included can change. If the original booking bundles several procedures, every one of them has to land on the new date or the change has not really happened, which is the coherence problem I wrote about earlier.
Then the system of record has to explain itself afterwards. Where a move alters what was booked, the annotation left behind has to say so in a form a person reads at a glance, because whoever deals with the consequence on the day is not whoever made the change. Writing the new state is the easy half.
One authority on "may this move"
If two code paths answer the same permission question, they call the same function, or one of them is a bug waiting for the right input. I have watched a booking be correctly declined by one check and cheerfully accepted by another, both working exactly as written.
That is the general form of the security pass an agent build earns before write access, and it bites hardest here, because a reschedule is the action most likely to arrive through several doors: the conversation, an internal tool, a link, a staff member working directly in the underlying platform. Every one of those is the same question about the same record.
Intent goes stale
A link issued is a promise still waiting to be kept, and reality does not wait with it. If the customer phones and changes the appointment another way, that link is still live and still points at a world that no longer exists.
So whatever issues an intent owns expiring it: on use, on time, and on supersession by any other change to the same booking. In practice that means sweeping for superseded intents at the moments someone is most likely to act on a stale one, when a conversation resumes or a new change begins. Unglamorous, and most of the work.
The short version
Before an assistant changes anything directly, I want four things settled: the action is reversible enough to be worth the risk, one place decides whether a given record may be touched, everything the change drags with it moves atomically, and stale intent expires on its own rather than waiting to be noticed. Where those hold, dropping the form is a genuine improvement. Where they do not, the form was never the problem.
If you are weighing that step on an operation where a wrong move costs someone a visit, I am happy to compare notes.
Related reading: When one appointment is actually several procedures on keeping a bundled booking coherent, and from answering to acting on what it takes for an assistant to own the consequences of an action.