Customer appointment rescheduling without double booking: a Hong Kong SME workflow

Decide what a change request can do

A reschedule is a change to an existing commitment, not a fresh booking with a new label. A Hong Kong service business should define who may request it, how close to the appointment a change is allowed, which staff or room must remain available, and what happens to any deposit or service add-on. These are the business’s own terms; do not infer a universal cutoff or refund right from software. Put the current booking, proposed new slot and any changed conditions on one review screen so the customer can understand the decision before confirming.

The entry route matters. A signed-in customer can be matched to the booking through the account, while a link in an email may need a short-lived, single-purpose token and a separate check for sensitive changes. The public page should avoid revealing appointment details to anyone who merely guesses a booking number. Staff-assisted changes need the same state transition and audit trail as self-service ones, with the staff member identified. Decide whether the request is immediately confirmed or awaits staff approval; an “request received” screen must never look like a confirmed new slot if approval is still pending.

A useful policy names the old slot’s fate. In a direct confirmed change, it becomes free only when the new slot is securely assigned. In an approval flow, the business must decide whether to hold the old slot while the proposal is reviewed. Releasing it too early can leave a customer with neither appointment; holding both indefinitely can block capacity. Set a bounded hold and a visible expiry where the business actually implements one. When the request fails, retain the original appointment unless the customer separately cancels it under the stated terms.

Check real capacity, then protect the change

A list of apparently open times is only a starting point. Check the staff member, room, equipment, service duration and any preparation or travel buffer needed for the specific booking. Google Calendar’s FreeBusy endpoint returns busy intervals for chosen calendars, which can support an availability display when Calendar is part of the system. It does not by itself enforce a booking policy or reserve a resource. The authoritative booking system must make a final capacity decision when the customer confirms, because another customer or staff member may claim the slot after the list was displayed.

Treat the change as one business operation. Confirm that the old booking belongs to this customer and is still eligible, reserve or allocate the new capacity, update the booking’s time and resource assignment, and release the old capacity only after success. If any step fails, leave a recoverable state with a clear owner rather than showing two confirmed appointments or none. A calendar event may be a copy of the business record rather than the source of truth; document which system wins when they disagree. A slot check and a final write separated by time need concurrency protection.

For a Calendar integration, Google documents event etags and an If-Match condition for updates. If the event changed since it was read, the API returns 412 rather than silently overwriting it. Google also warns that a full event update replaces the resource, so reading the current event and updating with its etag protects fields changed by someone else. This protects one event version; it does not automatically prevent two different events from claiming one staff slot. That broader capacity rule belongs in the booking application, possibly with a transaction or resource-level lock.

Walk one customer through a conflicting change

Imagine a customer has a confirmed ninety-minute consultation on Thursday afternoon and chooses a Saturday morning slot. The business requires the same consultant and room. When the list first loads, Saturday appears free. Another customer then books the room before the first customer presses Confirm. The reschedule must recheck both resources, reject the unavailable slot in text, and show the original Thursday booking as still confirmed. It may offer fresh alternatives, but it should not invent a temporary Saturday reservation. The confirmation screen must report only the state that the server actually committed.

Now imagine the staff member changes the original appointment duration while the customer is reviewing Saturday. If the business uses Calendar events, an etag check can reveal that the event changed, but the application must still decide how to resolve it. Present the new current booking and ask the customer to review again; do not apply a ninety-minute move to a booking that staff extended to two hours. This is an example of a conflict, not evidence that Google Calendar supplies a complete reservation transaction. The same principle applies if a deposit, service type or assigned provider changes.

A second edge case is a customer who taps Confirm twice because the network stalls. The first request may have succeeded while its response was lost. The second should recover the committed booking state instead of creating another appointment or charging a second change fee. Show a waiting state while the request is in progress, then fetch the authoritative record before displaying success. If the system cannot determine the outcome immediately, say it is being checked and provide a route to support. Do not tell the customer to book again until the existing attempt has been reconciled.

Send one clear record of the new commitment

After a successful change, the screen and confirmation message should identify the service, new date and time, time zone, location or meeting route, staff member where relevant, and any changed payment condition. State that the old slot is no longer booked. If the change is only requested, use different wording and leave the old booking status explicit. Google’s Calendar update method includes a sendUpdates option for guest notifications, but that is an integration choice, not a substitute for the business’s customer confirmation. Test whether the customer actually receives the intended notice on the chosen channel.

Notifications can arrive out of order or be opened days later. Give each message a booking reference and a visible status, and link to a current authenticated booking view where the customer can check the latest arrangement. Avoid putting sensitive consultation details into an unprotected subject line or public link. If staff later edits the appointment again, issue a new update that clearly supersedes the earlier one. Support staff should see the same history: who changed what, when it was confirmed, which notice was sent and whether an exception remains unresolved.

Customer-facing errors should be specific enough to support recovery. W3C’s error-identification guidance calls for text that identifies an automatically detected input error; “Something went wrong” does not help a customer choose another time. Distinguish an ineligible change under the shop’s stated policy, a slot that became unavailable, and a temporary system problem. Preserve the original booking while giving the correct next action for each. If new options appear on the same page without a full navigation, make their status accessible to screen-reader users and keep keyboard focus predictable.

Prove the policy with real workflow tests

A release test should start with a booked appointment, not an empty calendar. Try an eligible change, a change outside the stated window, two simultaneous claims on the same room, a staff edit during customer review, a repeated Confirm action, and a calendar or notification outage. For each case, inspect the booking record, resource allocation, customer screen and message history. The expected result must name whether the old appointment remains, whether the new one is confirmed, and whether money or staff action is pending. A passing unit check on the date picker alone cannot establish this.

Before opening self-service rescheduling, ask staff to explain one failed case and one successful case in plain English and Traditional Chinese using the actual screens. If the words “requested,” “held” and “confirmed” collapse into the same message, fix the state labels. If the system cannot resolve two customers choosing one resource, keep that part staff-assisted until capacity handling is sound. The goal is a clear answer to a practical question: after pressing Confirm, which appointment does this customer truly have, and what will happen next?