1. これ以上の再試行を停止し、両方のホテル管理システムのレコードが同じOTA予約であることを確認します。
2. 有効なOTAソースID、および将来の変更やキャンセルのメッセージにリンクされたレコードを保持します。
3. 余分なレコードを削除する前に、客室在庫、決済、フォリオ、ゲストメッセージ、および運用タスクを保護します。
4. 空室状況が1回だけ変更されることを確認し、サポートやナイトオーディットのために修正内容を記録します。
再試行後に重複したOTA予約は、似たようなレコードを2つ見つけて1つを削除するだけで簡単に解決できるように見えるかもしれません。しかし、それは危険です。一方のレコードは将来のOTAの変更を受け取る接続済みの予約であり、もう一方はフロントデスクがすでに完了した部屋割り、決済、メモ、またはチェックイン業務を含んでいる可能性があります。
安全な対応策は、自動化を一時停止し、レコードが重複していることを確認し、1つの正規の予約を選択し、運用データを移動または保持してから、ホテル管理システムで承認されたアクションを使用して余分なレコードを削除することです。レコードを削除すると部屋が解放されたり残高が変わったりする可能性があるため、直ちに在庫と決済の確認を行う必要があります。
OTAの再試行によって重複予約が発生する理由
通常、再試行ではOTAの外部予約IDが再利用されるため、ホテル管理システムは同じ予約として認識します。元のインポートが部分的に成功したもののエラーが返された場合、再試行時に同じ識別子が含まれていない場合、または遅延した自動予約がホテル管理システムに入る前に手動のプレースホルダーが作成された場合に、重複が発生する可能性があります。
もう1つのよくあるパターンは、手動でインポートされた将来の予約から始まります。手動のレコードに有効なソース予約IDが含まれていない場合、後続のOTAの変更が一致しない可能性があります。ホテル管理システムは、既存の手動レコードを更新する代わりに、新しい接続済みレコードを作成することがあります。
2つのホテル管理システムのレコードは、見た目は同じでも動作が異なる場合があります。OTAの変更、キャンセル、ゲストメッセージ、決済指示、またはバーチャルカードデータに引き続き接続されているのは、どちらか一方だけかもしれません。そのため、ゲストの名前と滞在日だけでは、どちらのレコードを削除するかを判断するのに十分ではありません。
重複が見つかったら、直ちにインポート、再送信、手動での空室状況の変更を停止してください。別のメッセージによって証拠が変更される前に、両方の予約番号、作成時間、ソースID、現在のステータス、および在庫への影響を記録します。
2つのレコードが実際に重複していることを確認する
同じゲストと同じ日付の2つの予約は、重複が疑われるだけに過ぎません。ゲストが意図的に2部屋を予約した可能性や、同じ姓の2人の旅行者が一緒に到着する可能性もあります。OTAの確認番号が異なる場合、OTAがそれ以外を証明しない限り、通常は2つの別々の予約を意味します。
両方のレコードを項目ごとに比較します：
- OTAの確認番号、およびチャネルマネージャーまたはCRSの参照番号
- ホテル管理システムの予約番号、作成時間、インポート方法、およびソース
- 施設、部屋タイプ、到着日、出発日、宿泊人数、および料金プラン
- 合計金額、税金、決済モデル、デポジット、およびキャンセルポリシー
- 最新の変更、キャンセル、メッセージ、および同期ステータス
- 部屋割り、フォリオ、メモ、タスク、およびチェックインのアクティビティ
OTAのエクストラネットを開き、有効な予約がいくつ存在するかを確認します。次に、チャネルマネージャーまたはCRSのキューを確認します。OTAと仲介業者が1つの予約を表示しているにもかかわらず、ホテル管理システムが同じ外部参照を持つ2つのレコードを表示している場合、そのホテル管理システムのレコードは重複の有力な候補です。
レコードのOTA確認番号が異なる場合は、操作を停止してください。OTAまたはゲストが両方とも意図した予約であることを確認するまで、マージ、キャンセル、または削除を行わないでください。在庫を一時的に保持するコストは、通常、有効な予約をキャンセルするよりも低くなります。
接続されたワークフローを使用すると、この比較が容易になります。Smart Orderのチャネルマネージャーは、受信したOTAの参照番号をホテル管理システムの空室状況とリンクさせるため、スタッフは再試行によって既存の予約が更新されたのか、それとも別の運用レコードが作成されたのかを追跡できます。
ソースIDでOTA予約を追跡する
受信した予約、マッピングされた在庫、および外部参照を1つのワークフローで管理することで、ゲストや部屋数に影響を与える前に再試行エラーを特定できます。
正規のレコードを選択し、重複を安全に解決する
正規の予約とは、ホテルが滞在の唯一のソースとして保持するレコードのことです。将来のOTAの変更を受信でき、チェックアウトまでに必要な運用および財務の履歴を保持できる必要があります。
判断の補助として、以下のマトリックスを使用してください。ベンダーによって動作が異なるため、レコードをマージ、削除、無効化、またはキャンセルする前に、スーパーバイザーまたはサポートの承認が必要になる場合があります。
多くの再試行インシデントにおいて、有効なOTAソースIDを持つ自動レコードは、後続の変更やキャンセルが一致できるため、より安全な正規のレコードとなります。そのソースIDを持たない手動のプレースホルダーは、多くの場合、削除する対象のレコードとなります。ただし、その有用なデータが保存された後に限ります。
以下の手順に従ってください：
- 両方のレコードに対する追加の再試行、編集、チェックインアクション、および決済の試行を凍結します。
- 有効なソースリンクと将来の更新パスに基づいて、正規のレコードを選択します。
- 部屋割り、ゲストのメモ、タスク、フォリオ項目、デポジット、および承認された決済の参照を保持または転送します。
- ホテル管理システムで承認されたステータス、マージ、無効化、キャンセル、または削除アクションを使用して、余分なレコードを重複としてマークします。
- システムが重複の履歴を保持している場合は、両方のレコードに相互参照のメモを追加します。
- OTA、チャネルマネージャー、およびホテル管理システムを再度開き、有効な運用の予約が1つだけ残っていることを確認します。
ホテル管理システムを整理するためだけにOTA予約をキャンセルしないでください。計上済みの収益、決済承認、チェックイン済みのステータス、部屋へのアクセス、または財務書類が含まれているレコードは、財務および管理部門の確認なしに削除しないでください。目に見える予約が非表示のトランザクションやメッセージのレコードにリンクされているため、安全にマージするためにサポートが必要なシステムもあります。
在庫、決済、およびフロントデスク業務の照合
ホテルの運用の合計が正しくなるまで、重複の削除は完了しません。両方のレコードが空室状況を減少させていた場合、一方を削除すると部屋が戻る可能性があります。一方だけが空室状況を減少させていた場合、手動で在庫を増やすと、販売用の余分な部屋が開かれ、オーバーブッキングが発生する可能性があります。
修正前の空室状況を記録し、承認された重複アクションを完了してから、ホテル管理システムの部屋数をチャネルマネージャーおよびOTAと比較します。最終的な数量は、確定した1件の滞借を反映している必要があり、0件でも2件でもいけません。
決済とフォリオのアクティビティを個別に確認します。いずれかのレコードに、デポジット、事前承認、請求、返金、OTA回収残高、バーチャルカードの指示、税金請求書、または手数料の基準が含まれているかどうかを確認します。完全なカード情報やセキュリティの詳細を、通常の予約メモやサポートメールに決してコピーしないでください。
また、各レコードによってすでにトリガーされた作業も照合します。ゲストメッセージ、到着前の自動化、部屋割り、ハウスキーピングのメモ、空港送迎、食事のリクエスト、アクセスコード、およびチェックインフォームを確認します。ゲストが2つの確認、2つの決済リクエスト、または矛盾する指示を受け取らないように、重複するワークフローを抑制します。
ナイトオーディットの前に、ゲスト名とすべての外部参照で再度検索します。1つの有効な滞在、1つの部屋割り、1つの運用残高、および正しいチャネル属性を確認します。どのレコードがなぜ保持されたかを示す監査証跡を保存します。
インシデントをエスカレーションし、再試行による重複の再発を防ぐ
チームが接続されたレコードを特定できない場合、両方のレコードにトランザクションが含まれている場合、または一方のレコードをキャンセルすると予期せず在庫が変更される場合は、エスカレーションします。ホテル管理システムまたは接続プロバイダーが、メッセージID、配信確認、インポートログ、および再試行の動作を調査する必要があるかもしれません。
サポートに送信する内容：
- 施設IDと接続プロバイダー
- OTA、チャネルマネージャー、および両方のホテル管理システムの予約参照
- 元のインポート、エラー、再試行、および重複作成のタイムスタンプ（タイムゾーン付き）
- 現在のステータス、客室と料金のマッピング、および前後の空室状況
- 機密の決済データを非表示にしたメッセージとエラーのスクリーンショット
- 決済、チェックイン、部屋割り、またはキャンセルなど、すでに実行されたアクション
恒久的な解決策は原因によって異なります。外部ソースIDが欠落している場合は、IDの保持を改善する必要があります。インポート成功後のタイムアウトの場合は、再試行前にステータスを確認する必要があります。手動のプレースホルダーには、照合フラグが必要です。同時実行の不具合や繰り返しのWebhookの場合は、別のフロントデスクの回避策ではなく、ベンダー側の重複保護が必要です。
「最初のメッセージで予約が作成されたかどうかをスタッフが確認するまで再試行しない」というルールをホテルのインシデント手順に組み込みます。新しいOTA接続を、新規予約、変更、およびキャンセルでテストします。変更は同じホテル管理システムのレコードを更新し、キャンセルは在庫を1回だけ戻す必要があります。
重複のクリーンアップは、フロントデスクが予約ソース、運用ステータス、および空室状況を一緒に確認できる場合により安全になります。Smart Orderのホテル予約管理システムは、接続された予約とその部屋への影響を示す1つのカレンダーをスタッフに提供し、一時的なプレースホルダーが2つ目の有効な滞在になる可能性を減らします。
再試行の例外をフロントデスクに見えるようにする
OTAのソース参照をホテル管理システムのカレンダーと接続し、スタッフが重複を分離し、正規の予約を保護し、ナイトオーディットの前に在庫を確認できるようにします。
よくある質問
ホテルはどの重複したOTA予約を保持すべきですか？
通常は、有効なOTAソースIDを持ち、変更やキャンセルリンクが有効なレコードを保持します。もう一方のレコードを削除する前に、そこに含まれている決済、フォリオ、部屋割り、メモ、タスク、およびチェックイン業務を保存してください。
フロントデスクは新しい予約を単に削除してもいいですか？
いいえ。新しいレコードは、回復したインポートによって作成された、自動化された接続済みの予約である可能性があります。それを削除すると、リンクされていない手動レコードが残されたまま、将来のOTA更新が機能しなくなる可能性があります。
ホテルはOTAのエクストラネットで一方の予約をキャンセルすべきですか？
OTAが1つの確定した予約のみを表示している場合はキャンセルしないでください。重複はホテル管理システムの内部にのみ存在している可能性があります。実際のOTA予約をキャンセルすると、ゲスト、決済、手数料、およびキャンセル条件に影響を与える可能性があります。
両方のレコードにすでに請求が含まれている場合はどうすればよいですか？
これ以上の決済アクティビティを停止し、スーパーバイザーまたは財務チームを関与させてください。どの請求が承認されたか、重複したキャプチャが発生していないか、およびホテル管理システムが無効化、返金、フォリオの転送、またはベンダー支援によるマージを必要としているかどうかを確認します。
なぜ再試行は最初のレコードを更新する代わりに新しいホテル管理システムのレコードを作成したのですか？
一般的な原因としては、外部予約IDの欠落または変更、元のインポートが成功したもののエラーを返した場合、ソース参照のない手動のプレースホルダー、再試行処理の重複、または最初のレコードと一致しなかった変更などが挙げられます。
ホテルはどのように修正を確認すべきですか？
ホテル管理システムでの1つの有効な予約、OTAでの1つの確定した予約、1つの接続された参照パス、1つの正しい部屋の差し引き、および1つの運用残高を確認します。その後、将来の変更が保持されたレコードをターゲットにすることをテストします。
安全な重複の解決策は、データベースをクリーンアップする前に、ゲストの実際の予約を保持します。接続されたレコードを特定し、資金と運用を保護し、在庫を1度だけ修正し、次の再試行が別のフロントデスクの緊急事態になるのを防ぐ監査証跡を残します。
