An AI booked the table but two parties got the same slot

How the same slot gets sold twice

A typical booking flow asks what the caller wants, checks availability, reads back what is free, collects details, then writes the booking. The gap between “check” and “write” can be a minute or more while the caller spells their name or asks about parking.

If another booking arrives in that gap (a second caller on another line, a web booking, a host writing in a walk-in reservation), both can see the slot as free. If the system does not reserve the slot during the conversation, both can confirm.

The weakness exists without AI too; an AI simply handles more calls at once and sounds more certain.

An illustrative example: Friday night at a restaurant

Consider a hypothetical 70-cover restaurant in Bandra, Mumbai, that takes bookings by phone (answered by an AI receptionist), through its website and through a dining app. Its system holds tables by size: on Friday at 8:30 pm there is one table for six left.

1. 8:02 pm, Wednesday. Caller A phones and asks for a table for six on Friday at 8:30. The AI checks the booking system and sees the table is free. It replies, “Yes, we have a table for six at 8:30 on Friday,” and starts collecting the name and phone number.

2. 8:03 pm. On the website, Guest B books the same table for six at 8:30. The booking system records it.

3. 8:04 pm. The AI finishes with Caller A and writes the booking. In a badly designed setup, the system accepts it because the AI’s write does not re-check availability. Two parties now hold the same table.

4. Friday, 8:30 pm. Both parties arrive. One waits at the bar for forty minutes.

The same sequence, designed properly:

1. At 8:02, the AI checks availability and immediately requests a hold on the table for a few minutes. The booking system grants it and marks the table as held.

2. The AI says, “A table for six at 8:30 on Friday is available. I am holding it for you while I take your details.”

3. At 8:03, Guest B’s website search does not show the held table, so it offers 8:00 or 9:15 instead.

4. At 8:04, the AI converts the hold into a confirmed booking and only then says, “Your table is booked,” and sends a confirmation by SMS or email.

If the hold fails (for example, the website took the table a moment before the AI’s request), the AI should not pretend. A good message: “I am sorry, that table has just been booked. I can offer a table for six at 8:00 or 9:15, or put you on the waiting list for 8:30 and call you if it frees up. Which would you prefer?” Anything it cannot offer, such as joining two tables, goes to the manager with the details.

Suggested versus committed

Write these definitions into the agent’s rules:

• Suggested slot: shown as available from a lookup. Language allowed: “looks available”, “I can check”.

• Held slot: reserved by the booking system for a short, fixed time. Language allowed: “I am holding it for you”.

• Committed booking: written and confirmed by the booking system, with a reference. Language allowed: “your table is booked”, plus the reference.

The AI moves from one state to the next only when the booking system says so.

Human recovery and overrides

Some collisions will still happen: a host overriding a hold for a regular, a system outage, a cancelled booking that was not released. Decide in advance:

• Who can override a hold or confirmed booking, and whether the AI is told.

• How cancellations release slots, and how quickly.

• What the restaurant offers when a collision reaches the guest, and who decides.

• Who is alerted when the booking system rejects a write, and how fast they act.

A pre-launch collision test

Run these on a test copy of the booking system:

1. Two simultaneous phone requests for the last table. Does only one get confirmed?

2. A phone request and a web booking for the same table within a minute. Does the hold block the second?

3. A caller who goes silent mid-booking. Is the hold released after the time limit?

4. A hold that fails. Does the AI say so honestly and offer alternatives?

5. A cancellation. Does the slot reappear to the AI and the website promptly?

6. A manual override by a host. Does the AI stop offering that table?

7. A booking system outage. Does the AI stop confirming and offer a callback instead?

If any of the first four fail, the agent is not ready for a Friday night.

Where SolvTree fits

This maps to our receptionist AI: agents that take bookings by phone and chat, hold and confirm through your booking system, and hand edge cases to a person. The same rules apply to villas, clinics and salons. We start with one booking flow and its collision tests.

Next step: Bring one appointment or table-booking flow to a free 30-minute operational audit and review its confirmation rules with us. The report is yours to keep.