ホテルのフロントで最も恐れるのは、客室が不足することではなく、客室状況の同期不一致です：OTAでは既に予約済みなのに、ホテルのシステムにはまだ空室と表示されている；宿泊客が到着した際には「清掃中」と告げられるのに、清掃タスクは依然としてWeChatグループで呼び出されたまま。オーバーブッキング、予約漏れ、清掃遅延が重なると、空室よりもコストが高くなります。
業務をどのように分割するか：予約、客室割り当て、清掃、チェックイン・チェックアウト
実用的なホテルシステムとは、少なくとも四つのステートマシンを連携させることであり、「注文一覧」だけを作るのではありません：
- 予約による占用：チャネルからの注文が入力されると即座に在庫を確保し、キャンセルやノーショーの場合の明確な解放タイミングを定義します
- 客室割り当て：部屋タイプ、階層、連結室、メンテナンスロックに基づき、自動／半自動で割り当てます
- 清掃タスク：チェックアウト時に清掃が発動し、客室検査に合格して初めて販売可能に変更されます；メンテナンス注文と客室状況は相互にロックされています
- チェックイン／チェックアウト：デポジット、追加料金、レイトチェックアウトに関する基準はナイトセールスと統一されています
Excelでは今夜何部屋が空いているかは記録できても、「清掃中は販売不可」と「メンテナンスロック」の同時発生は把握できません。フロントでのもめ事を引き起こす真の原因は、複数チャネルで在庫を書き込む際に統一された占用ロックがないことです。
設計方法：役割とデータ
役割は次のように分けることを提案します：予約担当者、フロントスタッフ、客室係長、フロアサービススタッフ、メンテナンス担当、ナイトセールス。客室係員は自分のフロアのタスクのみ確認し、フロントはメンテナンス中の部屋を直接販売することはできません；ナイトセールスは締め切りと客室状況の日次切り替えを担当します。
- 部屋タイプと物理的部屋：販売可能属性、階層、連結室、喫煙／バリアフリーのラベル
- 在庫カレンダー：夜ごとに占用され、予約、確定、ロックされた部屋を含みます
- 客室状況：空室／清潔／汚染／居住中（清潔）／居住中（汚染）／メンテナンス中／使用停止
- 清掃タスク：発動源、責任者、開始／完了、客室検査結果
- 注文：チャネル、保証規則、特別要件、同行者
画面の境界は厳格に設定すべきです：OTA／公式サイトでの注文は「部屋タイプの在庫」のみを記録し、物理的な客室割り当ては後付けでも構いませんが、到着確認前には必ず具体的な部屋番号または明確な販売可能プールに落とし込まなければなりません。清掃が未完了の場合は、客室状況を「空室・清潔」と変更してはなりません。
開発と検収はどう行うべきか
チャネル連携には統一された在庫サービスを使用します：注文による在庫確保、支払い期限超過時の解放、キャンセル時のロールバック。プッシュ失敗には再試行可能かつ冪等性を確保し、同一注文で二部屋を占有しないようにします。清掃側では部屋番号をスキャンして作業を開始し、誤った部屋を指定するのを防ぎます。ナイトセールスのタスクは、当日未チェックアウト・未決済・異常な客室状況をリスト化し、人による巡回に頼らないようにします。
検収シナリオは繁忙期の汚いデータもカバーするよう提案します：
- 同一部屋タイプの二つのチャネルで同時に最後の一室を操作した場合、成功するのは一方の注文だけなのか
- チェックアウト後に清掃が未完了の場合、新たな予約客に割り当てることは可能なのか
- メンテナンスロック中でも、その物理的部屋をチャネルで販売できるのか
- レイトチェックアウトで翌晩の予約と重複する場合、どのように割り当ての変更を通知すべきか
- ナイトセールス後の客室状況とレジとの整合性は取れているのか
ホテルシステムの核心は「美しい色分けのカレンダー」ではなく、在庫確保、清掃、メンテナンスの三つのロックが互いに干渉しないことなのです。
現場でよく見られる失敗
オーバーブッキング戦略が明確でない：一部の店舗では、アップグレードで消化する形でオーバーブッキングを黙認している一方で、システムは物理的部屋単位で厳しく制限したり、逆に全く制限しないケースもあります。こうした「オーバーブッキング可能な部屋タイプ／上限／アップグレード経路」は口頭の慣習ではなく、設定として明文化する必要があります。清掃の出来高と品質の衝突：部屋数だけで評価すると、見落としが生まれる可能性があります；客室検査で不合格となった場合はタスクを返却し、出来高にも影響を与えます。会員の嗜好が失われる：高層階や連結室などの情報は備考欄に記載されても誰も見ないので、客室割り当てルールに構造化して組み込むべきです。
導入時にはまず何を優先すべきか
まずは「チャネルによる在庫確保→客室割り当て→清掃のクローズドループ→ナイトセールス」の流れを確立し、その後で収益管理やアップセルに取り組むべきです。稼働後二週間は特に以下の項目を重点的に確認します：オーバーブッキング／拒否件数、予約客の未割り当て比率、清掃の遅延によるチェックイン遅延件数、ナイトセールスによる異常な注文数。これら四つの指標を下げてから、スマートプライシングの議論を始めるのが基本です。
チャネル向け在庫サービスの導入方法はいかがでしょうか
在庫サービスは独立して運用し、注文システムとチャネル接続器は在庫確保／解放／照会のみを呼び出す形が望ましいです。在庫確保には有効期限を設定し、未決済の期限超過時には自動的に解放されるようにして、「ゾンビ占用」を防ぎます。物理的な客室割り当ては予約日前日まで延期可能ですが、部屋タイプ別の販売可能数はリアルタイムで正確である必要があります。チェーン展開の多店舗では、在庫キーに店舗IDを付与し、他店からの差し引きは厳禁です。
清掃とメンテナンスが在庫に与える影響はモデル化する必要があります：汚れた状態は販売可能とみなされません；メンテナンスロックは販売可能プールから差し引かれます；使用停止の部屋タイプはチャネル側で直接除外されます。フロントが手動で客室状況を変更する際には、理由コードを記録し、ナイトセールスによる異常事象の確認を容易にします。
収益管理と会員制度の境界線について
収益管理による価格改定は過去の注文には直接適用せず、将来の販売可能部分にのみ影響を与えます。会員特典（レイトチェックアウト、アップグレードなど）はルールエンジンの入力として設定し、客室割り当て時に読み込む形にし、当直マネージャーの記憶に頼らないようにします。初期段階ではダイナミックプライシングは不要ですが、「手動価格調整の承認」の手続きは残しておくことで、誰もが価格を変更する事態を防ぎます。
データ面では最低限、各部屋の夜間在庫確保の元となるチャネル、客室割り当て担当者、清掃完了時刻、チェックイン手続き時刻を蓄積する必要があります。これらの情報を活用すれば、遅延の原因が清掃の遅れなのか客室割り当ての遅れなのかを特定でき、感覚に頼る会議ではなく、データに基づいた判断が可能になります。
ナイトセールスとレジの整合性について
ナイトセールスは単に締め切りを行うだけでなく、以下を確認する必要があります：宿泊人数、未決済、ロックされた部屋、清掃未完了のまま割り当てられている異常な部屋。レジのレイトチェックアウト料金やミニバー消費はチェックアウト前に計上しなければならず、ナイトセールス後には昨日の帳簿を無理やり修正することは禁止されています。フロントの交代時のタスクリストは未完了のタスクを自動生成し、口頭での引き継ぎによる漏れを減らします。
複数チャネルでのキャンセルルールは異なるため、在庫を解放するタイミングはチャネルごとに設定する必要があります。無料アップグレードに消費された在庫は元の部屋タイプから解放し、目的の部屋タイプに確保する形で、報告書は別々に集計し、収益分析がアップグレードによって乱されることを防ぎます。
フロントスタッフの研修では、「最後の一室の同時注文」と「清掃未完了による誤った客室割り当て」という二つの演習シナリオを用いる方が、機能メニューの説明よりも効果的です。稼働開始のスイッチはまずチャネルによるオーバーブッキングを停止し、二週間安定させてから、部屋タイプごとにオーバーブッキングの上限を解除する形が望ましいです。
チェーングループが中央予約を導入する場合、まず部屋タイプコードとキャンセルポリシーの辞書を統一し、その後で在庫サービスを接続してください；辞書が統一されていない場合は無理に中央化しようとせず、単独店舗の誤りがネット全体に拡大するのを防ぎましょう。
コンシェルジュサービスの特殊なニーズ（サプライズ装飾、送迎）は追加タスクとして仕様化し、完了後に初めて「VIP予約準備完了」とマークを付け、通常の清掃タスクとは別に評価する形にします。