OTA・PMS・予約情報の移行

OTA、公式予約、PMS、サイトコントローラー、決済会社の契約主体を一覧にします。宿の屋号と契約法人名が一致するとは限らず、運営受託者の名義も確認します。[1][2]

サービス名だけでなく、施設ID、契約者、請求先、入金先、管理者、契約更新日を記録します。複数の宿を一つのアカウントで管理する場合は、今回の取引に関係しない施設や予約まで移してしまわないよう、対象範囲を明確にします。

株式譲渡でも、代表者や口座、支配の変更等が契約上の届出に関係する場合があります。事業譲渡なら契約主体自体が替わるため、譲渡承諾や新規契約、本人確認等を各社の手続で確認しましょう。取引当事者の合意だけで利用権を保証しません。

掲載ページ、写真、レビュー、販売実績の扱いを、一括して資産として移せるとは断定できません。各サービスで、何を継続利用できるかを確認します。[1]

Booking.comの公開標準条項7.6には、所有者や運営者が変わる場合の掲載情報・レビュー等の利用と、変更前の義務に関する規定があります。しかし、これだけで施設の変更申請が完了したり、別のOTAでも同じ扱いになるものではありません。

施設が合意した契約の版と適用範囲を確認し、管理画面や窓口の案内に従って変更を進めます。レビューを残せること、施設IDを保てること、管理者が替わることは別の確認項目です。掲載順位や予約数まで引き継げるという保証もできません。

予約データの移行と、誰が宿泊契約を履行し、返金を負うかは別の問題です。予約番号、宿泊日、入金、キャンセル条件、対応者を組にして整理します。[1][2]

OTA事前決済、現地決済、公式サイトからの前払、団体契約などで、入金の流れは違います。旧口座へ入った前受金と、新営業者が提供する宿泊をどう精算するかを契約で決め、システム上の表示だけに任せないことが必要です。

日程をまたぐ予約、既発生の苦情、取消しや返金、クーポンや預り金の扱いも確認対象です。変更後の連絡先や宿の案内が顧客へ正しく届くか、メールの差出人とテンプレートも合わせて点検し、誰から説明するかを決めましょう。

事業承継に伴う顧客データの提供は、一定の場合に第三者提供の制限の例外となります。それでも、承継前の利用目的や安全管理を無制限に変更できるわけではありません。[3]

宿泊の履行に必要な予約情報と、過去の販促用データ、健康や配慮に関する情報を分け、必要な範囲を確認します。PMSから出力できることだけを理由に、すべての履歴を別の用途へ流用する説明はできません。

交渉段階で個人データを提供する場合には、利用目的、取扱方法、漏えい時、不成立時の措置を含む契約と安全管理を整えます。国外の事業者やクラウドへの提供・委託等が関わる場合も、実際の取扱いに応じて個別に確認しましょう。

PMSが使えるようになっても、カード決済やOTAとの接続が同時に移るとは限りません。入金先、在庫と料金、通知先を、それぞれ確認します。[2]

SuperControlの公式ヘルプは、アカウントの引継ぎと決済サービス、接続する販売経路の手続を分けています。これは同社の例であり、日本のすべてのPMSに同じ移行条件を当てはめるものではありません。使っている各サービスへ確認する材料になります。

切替えの前後では、在庫の二重販売、料金の誤送信、入金先の残存を避けるため、実施する時刻と担当を決めます。顧客に影響しない確認方法を各社と決め、結果を記録しましょう。実際に予約や課金を行うテストは、必要な権限と合意の下で行います。

移行の終了は、新しい管理者が操作できることに加え、旧権限と必要な記録が整理されたことまで確認します。契約終了とデータ削除も同じ時点とは限りません。[3][2][4]

旧営業者に必要な会計資料と、新営業者が管理する予約を分け、保管する根拠、範囲、期間を確認します。管理者ログイン、API接続、外部委託先の権限、問い合わせメール、決済の接続情報を一覧にして見直します。

旅館業の承認書、許可図面、営業上の記録は、OTA画面の移行だけでは引き継がれません。行政手続、システム、入金、顧客対応をそれぞれ完了確認し、未確認事項には担当と確認先を残すことが、営業開始後の安定した運営につながります。