Why your channel manager still oversells you

You are sold out. The calendar is full, every room has a name against it, and the channel manager says zero availability. Then an email lands from Booking.com or Expedia confirming a two-night stay you cannot possibly house.

Most hoteliers assume this is a sync failure — that the channel manager was slow, or the PMS pushed the wrong number. Usually it is neither. The most common cause of an OTA overbooking is a gap built into how availability works, and it will keep happening until someone closes it deliberately.

Your channel manager sells a number. Your guest needs a room.

Every channel manager works the same way: for each room type, for each date, you publish a count. "Standard Double, 23rd September: 1 available." The OTA takes that number and sells against it.

A guest does not book a count. A guest books one physical room for every night of their stay. Those are not the same thing, and the difference is where overbookings live.

A worked example

Say you have two Standard Doubles in play across a Tuesday and a Wednesday:

• Room 1 is free on Tuesday night. It is blocked from Wednesday for a radiator repair.
• Room 23 has a guest on Tuesday night who checks out Wednesday morning. It is free on Wednesday night.

Now count availability the way a channel manager does:

Both numbers are correct. You publish 1 and 1. An OTA looks at a two-night stay covering Tuesday and Wednesday, sees at least one room available on every night, and sells it.

But there is no single room that covers both nights. Room 1 dies on Wednesday, Room 23 is occupied on Tuesday. The stay is unsellable, and nothing in the availability feed could have said so. Meanwhile a one-night booking for Tuesday would have been perfectly fine — which is why these incidents look so random from the front desk.

We call this a split-room gap. It is most likely when you are nearly full, which is exactly when an overbooking hurts most.

Three more causes worth knowing

1. Cancellation drift

A cancellation frees a night. If that release reaches the OTA but the corresponding room-level change does not reach your PMS cleanly — or the two happen seconds apart — the two systems disagree for a window. Most oversells that look like "bad luck" happened inside a drift window of a few minutes.

The fix is not a faster push. It is a reconciliation loop that compares PMS and channel manager continuously and corrects the difference, rather than a nightly sync that only pushes one way.

2. Stop-sell and availability are different switches

Setting availability to zero is not the same as closing a date. Many systems keep a separate stop_sell restriction per rate plan, and the two can disagree. A date can show zero availability while a rate plan stays open, or stay closed after you meant to reopen it.

If you have ever reopened dates and seen no bookings arrive, check stop-sell — not just the availability number. Reopening usually needs the availability push first; clearing stop-sell on its own often does nothing.

3. Rooms that are free on paper but not in practice

A room in maintenance, a room held for an arriving VIP, a housekeeping block that was entered as a note rather than a block — each one is a room your PMS counts as sellable and your team knows is not. Whatever the channel manager publishes is only as honest as the blocks in your calendar.

What actually closes the gap

Publish a maximum length of stay, not just a count. If the only free Standard Double on Tuesday is free for exactly one night, publish max_stay = 1 for arrivals that day. The OTA then cannot sell a two-night stay it could never have housed. This is the single most effective fix for split-room gaps, and most properties never switch it on.

Decide in advance what happens when a booking cannot be housed. There are only two sane options: refuse it outright, or accept it and immediately hold a room. The worst option — and the common default — is to park it on a placeholder room where nobody sees it until the guest walks in. If your system parks bookings, find out today where that queue lives.

Hold the inventory of a refused booking. If a booking is rejected because no room fits, your PMS still thinks those rooms are free and will re-advertise them on the next push. We have watched a rejected stay reopen and resell within half an hour. A refused booking should freeze its nights until a human resolves it.

Reconcile in minutes, not days. A daily sync check finds yesterday's problem. A loop running every few minutes finds it while the guest can still be moved, and before a second booking lands on the same room.

What to ask your provider

• Do you publish length-of-stay restrictions, or only availability counts?
• What happens to an OTA booking that arrives when no single room covers the stay?
• How often do you compare PMS availability against what the channel manager is actually showing — and does anyone get told when they disagree?
• When a booking is refused, what stops the same nights being sold again five minutes later?

An overbooking is rarely one system failing. It is usually two systems being individually correct about slightly different questions. Close the gap between the question the OTA is answering and the question your front desk has to answer, and most of them disappear.

InnCloud syncs rates and availability to Booking.com, Expedia and 200+ other channels through Channex, with continuous PMS reconciliation rather than a nightly push. If you want to see how your current setup would handle the Tuesday-Wednesday example above, book a demo.