1. 正常に機能するホテルPMSとBooking.comの連携では、空室状況、料金、制限事項、ゲストの予約詳細、決済ステータスという5つのデータカテゴリが自動的に同期されます。
2. 各カテゴリには特定の同期方向があります。PMSからBooking.comへプッシュされるものもあれば、Booking.comからPMSへプルされるものもあります。それぞれの方向での失敗は、異なる業務上の問題を引き起こします。
3. 同期エラーに対する手動での回避策は、単に不便なだけではありません。タイムラグが発生し、オーバーブッキングのリスクや料金パリティ違反の原因となります。
4. 連携の品質は、PMSがBooking.comのAPIを直接利用しているか、サードパーティのチャネルマネージャー・アグリゲーターを経由しているかによって決まります。
ホテルPMSとBooking.com連携の実際の仕組み
ホテルPMSがBooking.comと連携すると、PMSとBooking.comエクストラネットの間に双方向のデータ接続(双方向同期)が構築されます。この接続により、エクストラネットにログインして空室状況を更新したり、客室ごとに料金を変更したり、予約の詳細を手作業でPMSにコピーしたりする手動プロセスが不要になります。
連携が正常に機能している場合、PMSで行われた変更は自動的にBooking.comに反映され、Booking.comで行われた予約は自動的にPMSに表示されます。どちらの方向においても、フロントデスクのスタッフが日常業務でエクストラネットを操作する必要はありません。
どのデータカテゴリがどの方向に同期されるのか、またそれぞれの正しい自動処理がどのようなものかを理解することで、現在の連携が正しく機能しているかを確認し、新しいホテル管理システム(PMS)を評価する際に何を質問すべきかを確実に判断できるようになります。
1. 空室状況の同期(PMS → Booking.com)
空室状況の同期により、PMSからBooking.comへ客室の在庫状況がリアルタイムでプッシュされます。客室が予約されると、PMSは空室数を減らし、更新された在庫をBooking.comに送信して、同じ客室が二重に販売されないようにします。
この同期はバッチ処理ではなく、リアルタイム同期である必要があります。Booking.comを15分周期で更新するチャネルマネージャーでは、15分間のオーバーブッキングの空白時間が生じます。もしこの時間内にBooking.comとAgodaの両方から同じ客室に2つの予約が入った場合、1つ目の予約による空室数の減少がチャネルに反映される前に、2つ目の予約が確定してしまいます。
空室状況の同期は、客室の閉鎖、メンテナンスによるブロック、販売停止の指示などもカバーします。フロントデスクの担当者がPMSで客室を故障中とマークした場合、その客室は次の同期サイクルを待つことなく、数秒以内にBooking.comの在庫から消えなければなりません。
テスト方法: 稼働率の低い日にBooking.com経由でテスト予約を行います。PMSにどれくらい早く予約が反映されるか、またBooking.comの空室数がどれくらい早く更新されるかを確認します。60秒以上の遅延がある場合は調査が必要です。
すべてのプランで空室状況のリアルタイム同期に対応
Smart Orderのチャネルマネージャーは、空室状況の変更をBooking.comや接続されているOTAにリアルタイムでプッシュします。バッチサイクルやエクストラネットでの手動更新は一切不要です。
2. 料金の同期(PMS → Booking.com)
料金の同期では、PMSの料金管理モジュールからBooking.comへ価格がプッシュされます。PMSで料金プランが作成または変更されると、更新された料金はわずかな遅延(直接のAPI接続であれば通常5分以内)でBooking.comに反映されます。
料金の同期は、標準の客室料金、マスター料金のパーセンテージとして計算される派生料金、連泊料金、特定の期間に適用されるプロモーション料金など、さまざまな料金タイプをカバーします。これらはそれぞれ、エクストラネットで個別に入力することなく、Booking.comの対応する料金プランに同期される必要があります。
すべての販売チャネルで一貫した価格を維持する料金パリティは、料金の同期が正しく機能しているかどうかにかかっています。PMSでの料金変更がBooking.comにプッシュされなかった場合、宿泊施設は気付かないうちにチャネルごとに異なる料金を提示してしまう可能性があります。Booking.comは料金パリティ違反を監視しており、違反を検出するとリスティングの表示を抑制したり、アカウントにフラグを立てたりすることがあります。
テスト方法: PMSで、将来の日付の特定の客室タイプの料金を10ドル変更します。5分以内にBooking.comの該当料金が更新されるか確認してください。更新されない場合は、連携が直接のAPI接続を使用しているか、それともアグリゲーター層を経由しているかを確認してください。
3. 制限事項の同期(PMS → Booking.com)
制限事項とは、特定の客室タイプや期間に対して、Booking.comがどの予約を受け付けるかを制御するルールのことです。一般的な制限事項には、最低宿泊日数、最大宿泊日数、チェックイン不可、チェックアウト不可、販売停止などがあります。
制限事項の同期は収益管理において非常に重要です。例えば、需要の高い週末に最低宿泊日数の制限(1泊だけでなく金曜日と土曜日をセットで予約するよう求めるもの)を設ける場合、該当日の予約が入る前にその制限がBooking.comに反映されていなければ機能しません。
制限事項の同期エラーは、視覚的なエラーがすぐに表示されないため、空室状況や料金の同期エラーよりも検知が困難です。最低宿泊日数の制限がBooking.comにプッシュされなかった場合、収益戦略で避けたかったはずの1泊の予約を受け入れてしまう結果になります。この損失は、オーバーブッキングの警告としてではなく、逸失利益として現れます。
テスト方法: PMSで特定の日付に対して最低2泊の宿泊日数制限を設定します。5分以内にBooking.comエクストラネットの料金カレンダーに同じ制限が表示されるか確認してください。制限が有効であることを確認するために、Booking.comで直接その日付の1泊のテスト予約を試みてください。
4. ゲスト予約詳細の同期(Booking.com → PMS)
ゲストがBooking.comで予約すると、ゲスト名、連絡先、到着日と出発日、客室タイプ、料金プラン、宿泊人数などの予約の詳細は、予約が確定してから数分以内に自動的にPMSに取り込まれるはずです。
この同期はBooking.comからPMSへ行われます。フロントデスクのスタッフが、エクストラネットからPMSのホテル予約管理システムに予約の詳細を手動でコピーする必要はありません。手動での予約入力は、転記ミスを引き起こし、空室状況の更新にタイムラグを生じさせ、ゲスト対応に使うべきフロントデスクの時間を奪ってしまいます。
同期されるゲスト情報のレベルは、ゲストのプライバシー設定やBooking.comのデータ共有ポリシーによって異なります。ゲストの同意設定によっては、メールアドレスがマスキング(Booking.comの転送アドレスに置き換え)される場合があります。PMSを通じて送信された到着前のメッセージが確実にゲストに届くよう、PMSは転送アドレスを正しく受信し、保存する必要があります。
テスト方法: Booking.com経由でテスト予約を行います。フロントデスクのスタッフが手動で入力することなく、5分以内にPMSに正しい客室、日付、料金、ゲスト名で予約が表示されることを確認してください。
5. 決済ステータスの同期(Booking.com → PMS)
決済ステータスは、さまざまなPMSとBooking.comの連携設定において最も変動しやすい同期カテゴリです。何が同期されるか、そしてそれがどれほど確実かは、ホテルがBooking.comの予約にどの決済モデルを使用しているかによって異なります。
Booking.comのバーチャルクレジットカード(VCC)決済モデルを利用しているホテルの場合、Booking.comは到着日に請求可能となる予約ごとのバーチャルカードを提供します。フロントデスクが手動でカード情報を取得するためにエクストラネットにアクセスすることなく請求処理を行えるよう、PMSは予約の同期の一部としてVCCの詳細を受信する必要があります。
Booking.comペイメント(Booking.comがゲストから代金を回収し、ホテルに送金する仕組み)を利用しているホテルの場合、ゲストがBooking.comに直接支払い済みかどうかを示す決済ステータスフラグをPMSが受信する必要があります。これにより、フロントデスクはチェックイン時に二重に代金を請求するのを防ぐことができます。
施設でゲストから直接代金を回収するホテルの場合、チェックイン時の未払い残高がPMSのフォリオ(明細書)に反映され、フロントデスクのスタッフが通常通りに回収できるようにする必要があります。
これら3つのすべてのケースにおいて、PMSに届く予約には決済ステータスインジケーターが含まれており、エクストラネットにログインして確認しなくても、何が支払い済みで何が未払いかをフロントデスクに正確に伝える必要があります。
テスト方法: テスト予約がPMSに届いた後、フロントデスクがBooking.comエクストラネットを確認しなくても、予約フォリオ(明細書)に決済モデル(該当する場合はVCCの詳細、または決済ステータスフラグ)が明確に表示されていることを確認してください。
直接のAPI接続 vs アグリゲーター:接続タイプが重要な理由
ホテルPMSは、APIを介してBooking.comと直接接続する(PMSがBooking.com独自の接続レイヤーと通信する)ことも、2つのシステムの間に介在するサードパーティのチャネルマネージャー・アグリゲーターを通じて接続することもできます。
直接接続は、同期が速く、障害点が少なく、トラブルシューティングがシンプルです。問題が発生した際に診断すべき接続が1つだけで済むからです。一方、アグリゲーター接続は変換レイヤーを追加するため、責任の所在が不明確なまま遅延やエラーが複合的に発生する可能性があります。
PMSベンダーに、Booking.comとの接続が直接接続かアグリゲーター接続かを確認してください。アグリゲーター接続の場合は、どのアグリゲーターを利用しているか、稼働率のSLA(サービスレベル合意書)はどのようになっているか、アグリゲーターの障害時にはどうなるかについて質問してください。
ホテルPMSとBooking.comの連携に関するよくある質問
ホテルPMSとBooking.comの間で同期されるデータは何ですか?
機能している連携では、空室状況、料金、制限事項(PMSからBooking.comへ)、およびゲストの予約詳細、決済ステータス(Booking.comからPMSへ)の5つのカテゴリが同期されます。各カテゴリには明確な同期方向があり、エラー発生時の具体的な障害パターンも異なります。
ホテルPMSからBooking.comへ、空室状況はどのくらい早く同期されるべきですか?
空室状況の変更は、バッチサイクルではなく、直接のAPI接続により数秒以内にBooking.comに同期されるべきです。同期の遅延が60秒を超えると、同じ客室が複数のチャネルで同時に予約されてしまうオーバーブッキングの空白期間が生じます。PMSベンダーに同期方法を確認し、Booking.com接続の過去の稼働率データを提供するよう求めてください。
ホテルPMSとBooking.comの連携が切断されるとどうなりますか?
5つの同期カテゴリすべてが手動のプロセスに戻ります。つまり、空室状況の更新、予約の入力、料金の変更を、エクストラネットとPMSで別々に行う必要があります。空室状況のタイムラグはオーバーブッキングのリスクを生み、料金の同期エラーはBooking.comが監視しペナルティを科す料金パリティ違反の原因となります。
ホテルPMSとBooking.comの連携はバーチャルクレジットカードに対応していますか?
対応しているはずです。Booking.comのバーチャルクレジットカード(VCC)モデルでは、予約ごとに到着日に請求可能な固有のカードが提供されます。適切に連携されたPMSは、予約の同期の一部としてVCCの詳細を受信するため、フロントデスクのスタッフはエクストラネットにログインすることなく請求処理を行うことができます。対応していない場合は、現在ご契約のプランにVCCサポートが含まれているか、PMSベンダーにご確認ください。
Booking.comとの連携において、直接のAPI接続はチャネルマネージャー・アグリゲーターより優れていますか?
一般的にその通りです。直接のAPI接続は、窓口が1つで同期が速く、トラブルシューティングもシンプルです。アグリゲーター接続はサードパーティのレイヤーを追加するため、遅延や変換エラーが発生する可能性があり、また、アグリゲーターの障害解決については、PMSベンダーもBooking.comも責任を負いません。PMSを評価する際は、Booking.comとの接続が直接接続なのかアグリゲーター接続なのかを明確に質問してください。
Booking.comとの直接連携 — アグリゲーター層なし
Smart Orderは、直接のAPIチャネルを通じてBooking.comや主要OTAと接続します。リアルタイム同期が可能で、障害発生時のサポート窓口も一本化されています。