Rescheduling by text without the back-and-forth

A reschedule by text should take two messages: the customer says they need to move it, and the system offers two or three real alternatives from the live calendar; the customer picks one and it is done. The old slot is released, the new one held, the calendar updated everywhere, and a fresh confirmation sent. The six-message version ("what day works?" "Thursday?" "Thursday is full" "Friday?") is what happens when a person is doing it from memory.

Why rescheduling is worse than booking

A booking is a fresh conversation. A reschedule is a customer who has already committed once, now slightly inconvenienced, often on the day, and any friction pushes them toward "actually, just cancel". The reschedule flow has to be faster and easier than the original booking, and it usually is not.

The two-message flow

Customer: "I need to move Thursday's appointment."

System: "No problem. For your cleaning I have Friday at 9:00, Friday at 2:30, or Monday at 11:00. Which works?"

Customer: "Friday 2:30."

System: "Done. Your cleaning is now Friday at 2:30 with Maria at the Main Street office. Thursday's slot is released."

The system knew the appointment (from the customer's record), the service (so the duration), the staff member, and the live availability. It offered, not asked.

What the system has to know

Which appointment the customer means. Usually there is one upcoming; if there are several, it lists them. The service and duration, so the alternatives fit. The staff member, so the alternatives are with the same person unless the customer says otherwise. The location. And the cancellation policy, so it knows whether a move on the day has a fee and can say so before the customer chooses.

The policy, stated before the choice

"Moving with less than 24 hours' notice forfeits the deposit; would you still like to move it?" is a fair question if it comes before the customer picks a new time. Applying the fee afterwards is the kind of surprise that produces a review. Load the policy and let the system apply it consistently, with exceptions going to a person.

Releasing the old slot

The moment the new slot is confirmed, the old one is free and should be offered to the waitlist or the next customer immediately. Our post on waitlists and cancellations covers how that refills. A reschedule handled well is a cancellation that filled itself.

When the customer wants a person

Some reschedules are complicated: a series of appointments, a change of service, a move to another location. The system should recognise "can I talk to someone" and hand off with the context, and it should hand off on its own when the request does not fit a simple move.

From the reminder

Most reschedules start from a reminder: "Reply CHANGE to reschedule." That reply should drop straight into the two-message flow, with the appointment already identified. A reminder whose reply is handled the next morning is a no-show waiting to happen.

Frequently asked questions

Can a customer reschedule with a different staff member?

Yes, if they ask. The default is the same person; "anyone is fine" opens up the full availability.

What about rescheduling a group or a family?

Multiple appointments on one record should be movable together. If the system cannot, it should hand off rather than move one and leave the others.

Should rescheduling be limited?

A customer who moves the same appointment four times is a policy question, not a software one. Set a rule and let the system apply it, with exceptions to a person.

What Frontiva does here

In Frontiva your team reschedules by dragging an appointment on the calendar, the double-booking constraint still applies, and the appointment history records who moved it, when, and what it was before (bookings). Rescheduling by a text reply, and waitlists, are not built yet. Booking by text covers the original booking flow.