Why an available appointment can disappear before an AI books it

An assistant finds an open slot. The customer approves it. By the time the booking goes through, someone else has taken it. Here is how to make that handoff clearer and safer.

Reviewed October 18, 2026 · 9 min read

Imagine a customer asking an AI assistant to book a two-hour cleaning appointment for Friday afternoon.

Your booking page shows a 2 p.m. opening. The assistant presents the service, price and time. While the customer checks with their partner, another customer books the same opening by phone.

The assistant returns to complete the original request. What happens next?

A reliable system checks again and explains that the time has gone. A weaker one accepts the request, sends a cheerful confirmation and leaves your team to untangle two customers expecting the same cleaner.

This problem already exists in ordinary online booking. An assistant adds another place where a customer may pause, compare options or approve a purchase. Your business needs to be clear about what an availability result promises, when anything is set aside, and what counts as a confirmed booking.

Give each stage a clear meaning#

Use three distinct descriptions in your customer messages and booking tools:

• Available: the item or time can currently be offered, subject to your booking rules.
• Held: it has been temporarily set aside for this customer, under stated conditions and until a stated deadline.
• Confirmed: your booking system has accepted the reservation and created a record the customer can refer to.

These are useful explanations, rather than a universal set of software status names. Your platform may use different labels or have additional stages, such as a request awaiting staff approval.

The important question is what each label actually does. If choosing a time only submits an enquiry, call it a booking request. If nothing is set aside while the customer pays, explain that availability will be checked again.

Google’s booking interface explicitly allows for a slot becoming unavailable after the initial availability check. Its CreateBooking method returns either a booking or details of the failure. A successful lookup is only one step in that process. Google: CreateBooking

Connect availability to the things you need to deliver#

A free space in a calendar can be useful evidence. A cleaning appointment may also require a particular employee, travel time, equipment and enough notice to prepare.

Google Calendar’s free/busy method returns busy time ranges for specified calendars. It does not create a reservation. Treating the remaining gaps as bookable appointments requires your own service rules. That distinction follows from what the API returns and what it does not do. Google Calendar: free/busy query

For the cleaning business, write down what must be true for that Friday appointment:

• The assigned cleaner is working and free for the full visit.
• Travel and preparation fit around neighboring appointments.
• The address is within the service area.
• The customer is booking before your cutoff.
• Any shared equipment is available too.

Ask your booking provider which of those conditions it checks. Identify anything your team still handles manually. A useful public description might say, “Friday appointments available in selected areas; enter your postcode to check.” That gives the assistant an honest next step.

Check again when the customer commits#

Refreshing your website or product feed helps customers see recent information. You also need a decision at the moment a booking is accepted.

Google’s restaurant-reservation documentation describes availability checks when a booking page loads and when the customer selects a slot. The final booking request can still fail if that slot has been taken. Its separate guidance on advance booking limits says the booking server must enforce the cutoff when the request arrives, even when the same rule was already included in the feed. Google: booking-server flow · Google: advance booking limits

For your own system, ask a concrete question: “If two customers try to take our last appointment together, can both receive a confirmation?”

Your provider should be able to demonstrate how it prevents that outcome. The final check and allocation need to work together so two competing requests cannot take the same remaining capacity. Developers often call this an atomic operation.

When the answer is that the slot has gone, give the customer useful choices. Show the next available times or offer a clearly labelled enquiry. An assistant should return those choices rather than silently choosing a different day, employee or price.

Decide whether a temporary hold helps#

A hold is optional. Some systems accept or reject the booking in one final step. A hold can give someone time to approve the purchase or finish checkout. It also takes capacity away from other customers, so its duration and release rules matter.

Shopify offers a concrete retail example. Inventory in a draft order remains available to other buyers unless it is reserved. Reserving it prevents those units from being purchased elsewhere in the store, and the merchant can choose when the reservation expires. Shopify: reserve draft-order inventory

For appointments, discuss the equivalent behavior with your scheduling provider. Ask what is held, how long it lasts, and what happens if the customer abandons the process.

If your system supports a ten-minute hold, the customer message could say:

That is example wording, not a recommended duration for every business. Use a deadline your system actually enforces, with the date and time zone where needed. Avoid a countdown that resets on every visit or claims to protect a slot when it does not.

Keep the hold and payment process in step#

An expired reservation and an open payment page can create a difficult situation: the customer may pay after you have made the capacity available again.

Stripe supports expiring an open Checkout Session. Its hosted Checkout guidance documents scheduled expiration from 30 minutes to 24 hours after creation, with 24 hours as the default. It also provides an expiration event that your integration can use to release reserved inventory. Those timings are specific to this Stripe feature, not a general rule for appointment holds. Stripe: limited inventory

If your reservation expires sooner, ask the integration developer how the payment path is closed or otherwise made safe. A timer on your own page does not establish what a separate checkout will accept.

There is another timing issue: Stripe documents that a Checkout Session can be complete while payment processing is still underway. Your order handling should use the appropriate payment status and fulfillment rules. Stripe: Checkout Session status

Ask your provider to show what happens when payment is delayed, fails, or arrives near the hold deadline. Decide who handles any exception and what the customer will hear. A cancellation or refund may resolve a failed purchase, but it cannot deliver the appointment the customer expected. Preventing that mismatch deserves its own test.

Make the outcome easy to check#

Include in your booking confirmation a reference, the service, date, time zone, location, relevant payment status, and a way to view or change the booking.

For an enquiry, explain when a person will respond. For a pending payment, explain what remains pending. If the result is unknown because a connection failed, retrieve the booking status before starting again.

The last case also connects to our guide to duplicate orders. Retrying a request should not accidentally create another purchase.

Behind the scenes, updates need care too. Stripe warns that webhook notifications can arrive out of order and recommends tracking event IDs to identify duplicate deliveries. Your integration should reconcile the actual booking and payment records rather than assume the latest message received describes the latest state. Stripe: webhook event ordering

Where Nexez fits#

Nexez’s platform documentation describes availability, capacity and lead-time controls, along with resource pools, temporary pre-checkout holds, post-payment commitment, expiration and reconciliation. It also describes Google Calendar free/busy-derived availability as an integration for Pro and higher plans. Check the configured offer and connection before assuming a particular booking follows that path. Nexez platform documentation

Nexez’s buyer-approval guidance treats reserving time as an action requiring approval. A dry-run check can happen first, but passing that check does not itself create a reservation. Nexez buyer approval

Try this before relying on the booking flow#

Ask your provider to run these checks in a test environment, using test capacity and payments:

1. Two customers try to take the last slot together.
2. Someone selects a slot, waits past the booking cutoff, then submits.
3. A customer abandons a hold and returns after it expires.
4. Payment finishes close to the hold deadline.
5. The confirmation is interrupted and the same request is retried.

For each test, inspect the actual booking record and the message shown to the customer. Record who owns any fix.

Start with one popular service. Make its availability rules explicit, verify how the final reservation is accepted, and give customers a clear result they can check later. That makes the booking easier to trust wherever the customer started.