On this page
What an overbooking actually is
Two confirmed guests, one room. It feels like bad luck; it is always the same mechanism: two systems held different availability counts long enough for both to sell the last room. The gap might be the hour between extranet updates, the sync interval of a bolt-on channel manager, or the delay before somebody typed the walk-in into the sheet.
The three classic causes
Manual extranet management. Updating each OTA by hand means availability is wrong on every other channel until you finish. The window is however long your rounds take — hours, sometimes a whole night.
Loosely-coupled channel managers. A separate channel manager synced to a separate PMS narrows the gap but keeps the seam: two databases, one sync, and every sync failure is a silent divergence.
The forgotten local booking. The phone reservation written in the diary but not in the system sells the room that an OTA sells ten minutes later.
The architectural fix
Make availability one number in one database, and make every seller — OTAs, the booking engine, the front desk — read and write that number. A booking anywhere decrements it everywhere in the same cycle. This is what a PMS with a native channel manager does, and it is why the seam-free design matters more than any feature list.
Verifying, not hoping
Whatever system you run, demand a sync log: every push and pull, timestamped, with its result. A failure that announces itself costs you a refresh; a failure that hides costs you a Saturday-night walk. And keep room-level protection on: even with counts correct, the desk should be physically unable to assign two stays to one room.
When it happens anyway
Have the playbook ready before you need it: comparable or better room first, own-property upgrade second, walked guest last — with the taxi and the first night covered. The property that handles a walk gracefully keeps the review above water; the one improvising at 11pm does not.