Two requests for the last room: what reservation software does in that second
Reservation software protects the last room by keeping one shared count of available room-nights. Learn how this works, where protection ends, and what to check.
Contents
Key takeaways
- A double sale of the last room is usually a timing problem, not a counting problem: two requests read the same availability before either one writes.
- The fix is one shared count where the check and the reduction happen together, so the second request finds the room already gone.
- A hold is inventory spent, not a promise: if it is not inside the count, it protects nothing.
- No reservation system can close the gap between its own count and an agency's copy of that count; it can only shorten it.
- Overbooking can be a deliberate policy with a cost; selling the same room-night twice is not.
Reservation software protects the last room by keeping one shared count of available room-nights and checking and reducing it in a single step, so one request wins and the other is refused. A short hold sets the room aside while a guest pays. Protection stops where a channel, a manual entry or an allotment sits outside that count.
Two guests, two channels, one room left. Both requests arrive within the same second, and both screens say the room is free. What happens next is decided by a few lines of logic that most hotels never see. After reading this, you will know what those lines should do, how to ask a vendor about them, and where any system's protection ends.
What happens when two requests arrive for the last room at the same time?
One request takes the room and the other is refused, provided both requests are checked against the same count. If they are not, both can succeed and the hotel has sold one room twice.
Start with the unit being sold. It is not the room; it is the room-night. A three-night stay spends three units, one for each night, and each night has to be checked separately. A hotel can have the last standard room free on Friday and fully sold on Saturday, and a Friday-to-Sunday request must fail on the Saturday check.
Every reservation request does three things in order: read the count, decide, write the new count. The danger lives in the space between the read and the write. If both reads happen before either write, both requests see one room free and both proceed. This is the classic race, and it has nothing to do with how fast the software is. Two requests for the last room at the same time will collide in any system that separates the check from the reduction.
The losing request needs a clear answer, not a silent failure: a refusal, a waitlist entry or an alternative date the front desk can offer. A refusal before payment costs an apology. A refusal after payment costs a guest, a refund and a review. A confirmation is a promise, and the system should only make promises it can keep.
Speed still matters, but it is not the deciding factor. A system that answers in a second and occasionally sells the same room twice costs more than a slower one that never does.
Key pointThe room-night is the unit
A request for three nights is three separate checks, and any one of them can fail. Ask your vendor how the system handles a request where the first night is available and the second is not.
One count, one check: how does a shared room count stop a double booking?
A shared count is a single record of how many room-nights are still for sale, and every request the hotel controls has to pass through it. The protection comes from making the check and the reduction one indivisible step.
In plain words: read the number, decide, write the new number. If those three happen as one step, no other request can slip in between them. Databases can do this. A conditional write only succeeds if the value is still what was read a moment earlier; if another request already changed it, the write fails and the request is refused. This is a standard database capability, not a special feature, and a vendor who cannot describe it in these terms should be asked again.
The count has to be the same one for the front desk, the hotel's own website, the agencies and any assistant booking on the hotel's behalf. Two counts are two chances to sell the same room. Availability also has to be per room type and per date, not one headline figure: a single "rooms left" number hides which night is actually gone.
The second request should learn why it failed, so the front desk can offer another room type or another date instead of guessing. A refusal with a reason is a service recovery; a refusal without one is a shrug.
For example: one standard room is left for the night of 12 September. Two requests arrive together. The first reduces the count to zero and confirms; the second finds zero and is refused with the reason shown.
The three steps, side by side
| Moment | Request A | Request B | Count for the night |
|---|---|---|---|
| Start | waiting | waiting | 1 |
| Step 1 | reads 1 | waiting | 1 |
| Step 2 | waiting | reads 1 | 1 |
| Step 3 | writes 0, confirms | waiting | 0 |
| Step 4 | done | writes, finds 0, refused | 0 |
Both reads happened at count 1, so both requests believed the room was theirs. Now the same sequence with the check and the write combined into one step:
| Moment | Request A | Request B | Count for the night |
|---|---|---|---|
| Start | waiting | waiting | 1 |
| Step 1 | checks and writes 0, confirms | waiting | 0 |
| Step 2 | done | checks, finds 0, refused | 0 |
Request B's check now returns zero, because A's check and write were one step. The same mechanism covers a hotel group: one login, many properties, still one count per property and per night. AI Otel's reservation system is built on this principle, with one room inventory feeding the website, booking sites, agencies and AI assistants rather than separate counts per channel.
What is a reservation hold, and when does it end?
A hold sets a room aside for a short time while a guest completes payment, and it must be counted as sold for that time. When the hold expires without payment, the room returns to the count automatically.
Holds exist because payment takes time: card authorization, a bank redirect, a slow connection. Without a hold, a guest can pay for a room that was sold while they were typing. The hold is the system's way of spending the inventory before the money arrives.
A hold that lives only in the booking screen protects nothing. The room has to leave the count at the moment the hold is created, not when the payment clears. Expiry has to be automatic and defined by the hotel: a room that returns only when someone remembers to release it is a room that stays blocked all weekend. Abandonment matters as much as expiry; a guest who closes the browser must not keep the room for an hour.
The awkward case is payment succeeding just after expiry. Decide the rule in advance: refuse the payment, or find another room and tell the guest before they arrive. Either is defensible; discovering the case for the first time at 11 at night is not.
The trade-off is real. A long hold protects the paying guest and blocks inventory. A short hold frees inventory and raises the chance of a failed payment. Holds also apply to agency requests a hotel confirms by hand, where the request waits for a person rather than for a card.
Watch outA hold outside the count is not a hold
A hold that is not inside the shared count is a promise the system cannot keep. Count it, or do not offer it.
Where does that protection end?
It ends at the edge of the hotel's own count. An agency or a booking site keeps its own copy of availability, and a booking made there is real before the hotel's system hears about it.
Channel delay is the first gap. Availability travels out and bookings travel back, and anything sold inside that window is sold twice unless the hotel manages the gap, usually by keeping the window short and the outbound updates frequent. A channel manager shortens this window; it does not remove it, a point we return to in the FAQ and in double bookings across channels: causes and prevention.
Manual entries are the second gap. A room blocked on paper, a stay extended at the desk without updating the system, a room taken out of sale for maintenance and never returned: each one breaks the count quietly. Walk-ins and same-day sales are where the count is most often stale, because that is when people work fastest and check least.
Allotments are the third gap. Rooms committed to an agency sit outside free sale, and the count has to show what is committed, what has been picked up and what comes back, and on which date. How much to commit in the first place is its own decision, covered in allotment versus free sale: how much inventory to commit to agencies.
The working rule: if the same availability exists in two places, one of them is wrong, and you do not know which until you reconcile. Reconciliation is a routine, not an emergency. Compare the system against each channel on a fixed schedule and write down every difference and its cause.
ChecklistFour checks for your own setup
- Does every channel write into one count, or does each keep its own?
- How often does availability leave your system, and how long is the gap?
- Who can change availability by hand, and is every change logged with a name and a time?
- When did you last reconcile the system against each channel, line by line?
What about room assignment and groups?
Selling a room-night and assigning a specific room are two separate decisions, and mixing them up causes most of the confusion at the front desk.
The count sells room-nights by type. Assignment picks a physical room number, either in advance or at check-in, and it happens after the sale, not during it. Two guests can hold perfectly valid reservations for the same room type and still be sent to the same room number. That is an assignment error, not an inventory error, and it needs a different check.
Groups add a third layer. A block reserves a number of rooms for a period. Pick-up is what the group has actually taken. Unreleased rooms must return to sale on a stated date, or the block quietly eats the hotel's best nights.
Overbooking can be a deliberate policy: a hotel may choose to sell more room-nights than it has, expecting cancellations. That is a business decision with a cost, and it should be recorded as one. What to verify in any system: it should refuse to assign two active reservations to the same room on the same night, and it should show the block, the pick-up and the release date in one view.
What does AI Otel's reservation system do here?
AI Otel's hotel operating system keeps reservations, groups and room assignment in one system, built to protect against selling the same room twice. The status is built: working software, ahead of launch.
That line should be read exactly as written. It does not promise zero double bookings, and no system can. The count protects what passes through it; the gaps described above still belong to the hotel's channels and habits. The same inventory is built to feed the hotel's own website, booking sites, travel agencies and AI assistants from one place. Booking sites are in pre-production testing through our Channex integration, and no agency is connected to the distribution hub yet. The wider picture, including what is built and what is not, sits on the platform pages and in AI Otel's hotel operating system: what is built and what it covers rather than in a sales claim.
What to do next
Pick one room-night next week and trace every place its availability is written: the front desk screen, your website, each booking site, each agency allotment. Count the copies. That number tells you how much protection your current setup can actually give, and the sections above tell you what to do about each copy you find. If you want to see how a single count behaves under two simultaneous requests, request a briefing at https://ai-otel.com/contact.
Frequently asked questions
Can two people book the last room at exactly the same time?
Only if the two requests are not checked against one shared count, or if the check and the reduction are not a single step. With one count and a combined step, one request wins and the other is refused. The refusal should carry a reason so the front desk can offer an alternative.
How long should a reservation hold last?
There is no correct number; it is a trade-off the hotel sets. A long hold protects the guest who is paying and blocks the room from everyone else. A short hold frees inventory and raises the chance that a slow payment fails. The hold must expire automatically and must be counted as sold while it lives.
Does a channel manager prevent double bookings?
It shortens the window, it does not remove it. A channel manager sends availability out and brings bookings back; a booking made at the other end is real before your system hears about it. Frequent updates, one source of truth and regular reconciliation reduce the gap. They do not close it.
Is overbooking always a software error?
No. A hotel can deliberately sell more room-nights than it holds, expecting cancellations, and that is a policy decision with a cost attached. A software error is different: the same room-night sold twice while the count said it was gone. The two need different responses, so record which one happened.
What should a hotel check in its reservation software before trusting it?
Ask four things: whether every channel writes into one count, how long availability takes to leave and return, who can change availability by hand and whether those changes are logged, and whether the system refuses to assign two active reservations to the same room on the same night. Ask for a demonstration rather than a description.