本文へ移動
おもてなしOS

PMS・サイトコントローラー・OTA・CRMの違い|宿泊施設のシステム整理

PMS、サイトコントローラー、OTA、CRMの役割を、予約が届いてから滞在後までの情報の流れに沿って整理します。

宿泊施設では、PMS、サイトコントローラー、OTA、CRMなど、似た言葉が同じ会話に登場します。いずれも予約やお客様に関係しますが、目的は同じではありません。役割を混同すると、「どこを直せば情報が更新されるのか」「この数字はどこから来たのか」が分からなくなります。

製品名や画面名で覚えるより、予約が生まれ、施設へ届き、滞在し、次の関係へつながるまでの流れで整理すると、各システムの境界が見えやすくなります。

OTAはお客様と宿泊施設が出会う販売流れ

OTAは、宿泊プランを探すお客様へ施設情報や在庫、料金を提示し、予約を受け付ける外部の販売流れです。予約内容、変更、キャンセル、メッセージなどが届きますが、どの情報を取得できるか、どの操作が許されるかはOTAや契約によって異なります。

OTA上の表示と施設内の運用は分けて考えます。たとえば施設で客室を調整しても、販売側へ正しく反映されなければ、同じ在庫を別の流れで受け付けるおそれがあります。

サイトコントローラーは販売流れの在庫・料金をつなぐ

サイトコントローラーは一般に、複数の販売流れへ在庫や料金を反映し、予約情報を取り込む役割を担います。ただし、対応するOTA、反映方向、更新間隔、プランのひも付け方はサービスごとに違います。

「連携済み」という言葉だけで安心せず、何が自動で動き、何が手作業で残るかを一覧にします。エラー時の通知先と、復旧までの一時運用も決めておく必要があります。

PMSは施設内の宿泊運営を支える

PMSは、取り込まれた予約をもとに、宿泊者、客室、滞在状況、料金や会計など施設内の業務を管理する基準点です。基本はホテルPMSとは何かで解説しています。

OTAの予約番号とPMS内の予約番号が異なる場合もあるため、両者を結ぶ見分けるための情報が重要です。画面に同じ氏名があるだけで同一予約と判断せず、宿泊日、流れ、予約番号など確アクセス権限の確認能な情報を使います。

CRMは滞在を越えた関係を考える

CRMは、問い合わせ、宿泊履歴、希望、反応などをもとに、お客様との関係を継続するための考え方や仕組みです。ただし、PMSにも顧客管理機能があることがあり、境界は製品構成によって変わります。

大切なのは名称ではなく、今回の予約を処理する情報と、次回の提案に使う情報を分けることです。配信や提案へ使う場合は、目的、同意、配信停止、利用範囲など自施設のルールも確認します。

また、CRMへ渡した情報がPMSで更新されたとき、どちらへ反映するのかを決めます。古い連絡先やキャンセル済み予約をもとに案内しないよう、取得時点と更新責任をはっきりさせます。

現場で確認してみましょう

  • 各システムが受け持つ情報と更新方向を説明できるか
  • 在庫・料金・予約の最新情報の置き場所がそれぞれ決まっているか
  • 外部予約番号と施設内予約番号を結び付けられるか
  • 自動連携の対象外と、エラー時の手順が見えるか
  • 同じ情報を複数画面へ無目的に入力していないか

四つのシステムは、同じ予約を違う目的で扱う

OTAは販売の入口、サイトコントローラーは料金・在庫と予約通知の橋渡し、PMSは施設内の予約・滞在運営、CRMは顧客関係の継続管理という役割が基本です。ただし実製品は機能が重なります。重なっているから一つに見えるのではなく、項目ごとに責任と更新方向を決めることが重要です。

OTAで人数変更が行われ、サイトコントローラーには届いたもののPMS反映が失敗した場合、販売画面と当日名簿で人数がずれます。どのシステムが正しいかをその場の印象で決めず、通知時刻、エラー、予約番号を確認し、正式な更新手順を使う必要があります。

迷わないための考え方

在庫・料金の責任範囲を決める

どこで在庫を増減し、どこから料金を配信するかをはっきりさせます。OTA管理画面での個別変更がサイトコントローラーやPMSへ戻るかも確認します。

予約番号を複数残す

OTA番号、サイトコントローラー番号、PMS番号が異なる場合があります。どの番号で照らし合わせ・問い合わせするかを残し、片方だけを上書きしません。

顧客同意と販売情報を混ぜない

予約に含まれる連絡先を、そのまま販促配信へ使えるとは限りません。CRMへ渡す目的、同意、配信停止、保存期間を別途確認します。

重複機能の主従を決める

各システムに顧客メモやメール機能があっても、すべてを使うと履歴が分散します。日常の入力先と参照先を一つに決め、他は必要な範囲で連携または閲覧にします。

システム間の役割を整理する手順

  1. 項目一覧を作る日程、人数、部屋、料金、在庫、連絡先、メモ、支払、手配、配信同意などを縦に並べ、各システムでの作成・編集・参照できるかどうかを記録します。
  2. 最新情報の置き場所と更新者を決める各項目について最終的に信頼するシステムと、変更を許可する担当を決めます。例外変更時の戻し方も定めます。
  3. 連携方向と頻度を確認する片方向か双方向か、リアルタイムか定期か、失敗時に再送されるかを実機と仕様書で確認します。「連携あり」だけで判断しません。
  4. 代表シナリオを通す新規予約、変更、キャンセル、ノーショー、部屋変更、返金などを検証環境で通し、各画面と通知が一致するか確認します。
  5. 障害時の手順を決める連携停止時にどの画面を正として手動更新し、復旧後にどう照らし合わせるかを定めます。二重更新を防ぐ停止ルールも必要です。

システムごとの責任者をはっきりさせる

販売先担当

OTAの商品、料金、在庫、予約通知を管理し、サイトコントローラーとの配信・受信結果を確認します。個別OTA変更が最新情報の置き場所にも反映されるかを把握し、例外操作を記録します。

宿泊運営担当

PMSの予約、客室、滞在、会計を正しい状態に保ちます。OTA番号とPMS番号を照らし合わせます。変更・キャンセル・ノーショーを当日業務へ確実に反映します。

顧客関係・管理担当

CRMへ渡す顧客情報の目的、同意、配信停止、保存期間を管理します。予約連絡先を販促へ無条件利用せず、顧客履歴と予約履歴の関係を確認します。

四システムの対応表に残す内容

機能の有無ではなく、項目単位で作成、編集、参照、連携方向を記録します。同じ名称の「顧客メモ」でも、誰が更新し、どこへ反映されるかが違うためです。

  • OTA予約番号とPMS予約番号:両方を残し、問い合わせ時に対応表で照らし合わせる。
  • 料金:配信元、OTA個別上書きのできるかどうか、PMS表示、障害時の一時最新情報の置き場所を決める。
  • キャンセル:OTA受付、サイトコントローラー通知、PMS反映、関連手配キャンセルを別々に確認する。
  • 顧客連絡先:予約連絡目的と販促配信同意を分け、CRM取込の条件を記録する。
  • 障害:最終成功時刻、未反映予約、手動更新先、復旧後の突合担当を記録する。

30日で役割と連携を可視化する

  1. 第1週利用中のOTA、サイトコントローラー、PMS、CRMと契約・担当・番号体系を一覧化します。
  2. 第2週主要項目の最新情報の置き場所、更新者、連携方向、頻度、失敗通知を対応表へ記入します。
  3. 第3週新規、変更、キャンセル、部屋変更、返金を検証し、全システムの実画面と通知を照らし合わせます。
  4. 第4週不一致、連携エラー、例外手入力を振り返り、主従と障害手順を修正します。

責任者が見ておきたいこと

責任者は「連携済み」という言葉だけで判断せず、項目、方向、頻度、失敗時の動きを確認します。重複機能があれば入力先を一つに決め、他画面での自由編集を減らします。販促利用は予約業務と別の同意・停止管理で扱います。

よくある失敗と防ぎ方

  • すべて双方向連携だと思い込む。項目と操作ごとに方向を確認します。
  • OTA管理画面で個別修正し、最新情報の置き場所へ反映されない。例外変更の正式な手順を決めます。
  • CRMへ予約者情報を無条件に移す。利用目的と配信同意、停止管理を確認します。
  • 障害中に複数画面を同時更新する。最新情報の置き場所を一時固定し、復旧後の照らし合わせ手順を使います。

改善できたかを数字で確かめる

システムを入れただけで終わらせず、現場の仕事がどう変わったかを定期的に確認します。

システム間不一致件数
人数、料金、キャンセル状態など主要項目の不一致を分類し、連携と運用のどちらが原因かを特定します。
連携エラーの発見時間
エラー発生から担当者が把握するまでを測り、通知先と監視方法を改善します。
例外手入力の発生数
通常流れを外れた修正を記録し、頻発する例外を連携や仕事の流れの改善候補にします。

よくある質問

サイトコントローラーがあればPMSは不要ですか?

サイトコントローラーは主に販売先の料金・在庫・予約通知をまとめます。客室割当、チェックイン、滞在、会計など施設内業務が必要なら、PMSまたは同等機能の確認が必要です。

CRMはリピーター管理だけのシステムですか?

顧客履歴、同意、セグメント、配信、関係性管理などを扱いますが、製品差があります。宿泊現場では、販促だけでなく会話や配慮を安全に引き継ぐ目的も含めて要件を整理します。

機能が重なる製品は一つに統合したほうがよいですか?

統合には利点がありますが、移行リスク、専門機能、障害時影響、契約を比較します。まず重複入力の主従を決め、運用で整理してから入れ替えの必要性を判断できます。

まとめ

OTAは販売流れ、サイトコントローラーは販売情報の調整、PMSは施設内の宿泊運営、CRMは滞在を越えた関係づくりを主に支えます。ただし実際の機能は製品ごとに重なります。名称だけで判断せず、情報の発生元、最新情報の置き場所、更新方向、例外処理を書き出すことが、重複入力と確認漏れを減らす第一歩です。全体の記事はおもてなしOSジャーナルから確認できます。

OMOTENASHI OS

一人ひとりの記憶を、
次のおもてなしへ。

予約・会話・約束・手配を、誰かの大切な一日としてつなぐ。
自施設での始め方を一緒に整理します。