Skip to content
Български

Double bookings: prevent and resolve

This content is not available in your language yet.

WhyUnderstand why double bookings still happen despite automatic synchronization, what the system does to prevent them, and where to go when a conflict occurs.
WhoHotel administrators with connected channels.
What you’ll getSober expectations — double bookings cannot be ruled out entirely — plus the knowledge of where a conflict is visible and how it gets resolved.
LimitationsThis is the channels side: why a collision is possible and what keeps the risk down. The step-by-step resolution lives in the calendar article, linked above.

Resolve it in the calendar — If a double booking appears. Prevent it in the channels — this article and the Channel Manager overview.

A double booking is an accidental sale of the same room twice: for example, a channel sold the room at the very moment the front desk placed it. Availability for all channels in HotelsCalendar is computed from a single calendar, and yet such collisions do happen now and then. This article covers why they are possible, what the system does to keep them away, and where to go when the conflict is already on the grid.

The cause is a race: a channel sold the room at the very moment it was sold in the PMS or in another channel. At the moment of sale, neither side knew about the other: each honestly believed the room was free. It is a collision of two sales, not a mistake by a particular person — there is no one to blame, there is a conflict to resolve.

Such collisions are rare, but not zero, which is why double bookings cannot be ruled out entirely. A sale beyond availability does not go unnoticed, though: both bookings reach the system and go to handling, so no guest is lost. The other side of the story is just as honest: the system does not hide the collision — it shows it on the grid and gives you the tools to resolve it.

The risk is kept down not by a separate setting but by the very design of the system — one calendar for all channels:

  • Availability for all channels is computed from a single PMS calendar: every sale — in the PMS, on the hotel website, or in any channel — recalculates it everywhere. The typical cause of double bookings goes away.
  • Changes travel to the channels automatically — there is no separate “send” button: the system sends them on its own, without a manual push.
  • Sales restrictions — minimum and maximum stay, arrival and departure closures — go to the channels together with prices and availability. A channel does not sell what must not be sold.
  • Closing a date for sale zeroes its availability in all channels: the date goes off sale everywhere at once.

Once the mapping is saved, the price and availability feed runs two years ahead: for all that time the channel lives by the same calendar as the PMS. The front desk does not have to think about the channels: the grid and the channels live in one calendar, and a sale in one place changes availability everywhere.

If a race does happen, the conflict does not stay unnoticed on the calendar: the room’s row gets framed in red, and in the calendar legend (“On-bar icons”) it is listed as the “Overbooking” alert. The frame marks the whole room row, not a single date, and stays in sight as you scroll the grid — a double sale never hides in the system until the guest arrives.

A channel booking that sold over a taken room is not lost: it reaches the system without an assigned room and with an overbooking flag — and waits to be resolved on the calendar. Each of the two bookings shows its source on the bar as an icon — “Direct (at the desk)”, “OTA channel”, and others — but the signs of a conflict do not depend on the source.

A glance in the morning, before the day’s check-ins begin, is enough: a conflict found early is resolved without a guest standing at the desk.

The red frame is not the only alert in the legend: next to it live “Unpaid” and the booking status icons. If you haven’t studied the legend yet, open “On-bar icons” on the calendar panel — in a minute it teaches you to read the grid.

Both bookings in a conflict are real, with live guests inside, so the cure is not cancellation but a move. One of the two relocates to a free room of the same category on the calendar grid, and both bookings stay in force. The step-by-step walkthrough — including the scenario where the guest is already standing at the desk — is in If a double booking appears.

The conflict is rare, and the habits that drive the risk down even further are simple:

  1. Keep the mapping up to date. An unmapped channel category is a source of needless manual handling: check the category and rate pairs before the season and after changes to your inventory. How to pair them up — in Mapping: match channel categories and rates.
  2. Do not sell outside the system. A phone booking is a booking in the PMS all the same: place it on the calendar like any other (Create a booking in 4 clicks). Everything the property sells should pass through the single calendar: a sale outside it does not recalculate availability in the channels.
  3. Switching from another system and running both at once — close sales in the old one before opening them in the new one. Two systems with sales open reproduce the same race, only every day.

Result: one calendar for all channels, up-to-date mapping, and no sales outside the system — and even a rare conflict will be visible on the grid and resolved with a move, not a cancellation.