チェックインの列が、部屋の数を超えた

金曜の18時。チェックインの列が途切れない。PMSの画面には予約が81件。客室は80室。1室足りない。

最後にチェックインしたゲストに「お部屋のご用意ができておりません」と伝えなければならない。こちらの予約管理の不備で、今夜泊まる場所がないと告げる場面。フロントにとってもっとも重い瞬間です。

この状況を「オーバーブッキング」と呼ぶ。航空業界では座席の稼働率を最大化する手法として日常的に使われていますが、宿泊施設では事故です。なぜ起きるのか。起きたらどう動くか。どうすれば防げるか。

オーバーブッキングはなぜ起きるのか

OTA間の在庫連動の遅延

複数のOTAに同じ部屋を出しているとき、1つのOTAで予約が入ってから他のOTAの在庫が閉じるまでにタイムラグが生じます。数秒から数分。この間に別のOTAで同じ部屋が予約されると、ダブルブッキングになる。サイトコントローラーを使っていても、API連携の遅延は完全にはなくせません。

手動管理のヒューマンエラー

電話予約やウォークインをPMSに入力し忘れる。キャンセル処理を忘れて在庫が復活しない。「あとでまとめて入力する」運用はミスの温床です。手動操作の工程が多いほどリスクが高い。

キャンセル率を見込んだ意図的オーバーセル

「どうせ2〜3件はキャンセルが入るから」と、実際の部屋数より多く予約を受け付ける運用。航空業界では一般的ですが、宿泊施設はキャンセル率が季節やイベントで大きく変動します。読みが外れたときの代償が重い。

起きたときの対応 ── 最初の30分で決まる

オーバーブッキングが発覚した時点で、やるべきことには順序がある。間違えると事態が悪化します。

まず代替施設を確保する

ゲストに説明する前に、近隣の同等以上の施設に電話して空室を押さえる。代替先が決まっていない状態で「お部屋がありません」と伝えると、ゲストの不安は一気に増します。「代わりのお部屋をこちらで手配しました」と言える状態を先に作る。

ゲストに事実を伝え、代替案をセットで提示する

「予約管理の不備で、お部屋のご用意ができなくなりました。代わりに○○ホテルのお部屋をご用意しております」。事実と代替案を一文で伝える。「オーバーブッキング」という言葉は業界用語なので使わない。移動手段（タクシー手配）と費用負担もこの場で明示します。

費用をすべて負担し、記録を残す

代替施設との宿泊費差額、移動費、必要に応じた見舞い金。すべて自施設の負担です。ゲストに金銭的な負担をかけない。そして発生経緯・対応内容・費用をインシデントレポートとして残し、再発防止に使います。

対応する順序が重要
「まず謝罪してから手配」ではなく「まず手配してから説明」です。代替先がない状態での謝罪は、ゲストにとって「今夜どうなるかわからない」という不安を抱えたまま待たされることになります。手配を済ませてから説明に入れば、ゲストは「解決策がある」とわかった状態で話を聞けます。

予約の二重登録、手作業で防いでいませんか

予約管理の仕組み、見直しませんか

資料を請求する

再発を防ぐ ── 在庫管理の仕組みを見直す

サイトコントローラーで在庫を一元管理する

各OTAの管理画面を個別に操作しない。サイトコントローラーから一括で在庫を制御し、予約が入ったら自動で他チャネルの在庫を閉じる。手動操作をなくすだけで、ヒューマンエラー由来のダブルブッキングはほぼ消えます。

電話予約・ウォークインは即時入力を徹底する

電話を切った直後にPMSに入力する。「あとでまとめて」は事故の元。入力するまでその予約は存在しないのと同じです。ウォークインも同様で、部屋を割り当てたらその場で入力する。

繁忙期は在庫にバッファを持つ

稼働率が90%を超える日は、OTAに出す在庫を実際の部屋数から1〜2室引いておく。最後の数室は電話予約やウォークイン、トラブル対応用に残す。API連動の遅延が起きても、バッファが吸収してくれます。

意図的オーバーセルという選択肢

航空業界では、キャンセル率を予測して座席数以上の予約を受け付けるオーバーセルが一般的です。搭乗率の最大化が目的で、あふれた乗客にはボランティアを募って補償金と次の便への振り替えを提示します。

しかし宿泊施設と航空は前提が違います。

日本の宿泊施設で意図的にオーバーセルするなら、少なくともキャンセル率のデータが1年以上蓄積されていること、近隣に代替先との提携があること、が最低条件です。この両方が揃っていない限り、リスクが高すぎます。

オーバーブッキングは仕組みの穴から起きる

オーバーブッキングは「予約が多すぎた」のではなく、在庫管理に穴があって起きる事故です。OTAの連動遅延、手動入力の漏れ、バッファなしの在庫設定。原因はほぼここに絞れます。

起きたときの対応は、ゲストに説明する前に代替先を確保すること。発生後は原因を特定し、仕組みで塞ぐこと。フロントの注意力に頼る運用は、忙しい日ほど破綻します。