チェーン・リゾート向けホテルCRM：一つの顧客プロフィール、複数の施設

第1部：施設ごとに顧客名簿を分けて持つことがなぜ損失なのか

各施設が自分の顧客名簿を個別に管理していると、チェーンは同時に四つのものを失います——そしてその四つはいずれも金額に換算できます。

測定できる四つの損失

• ポートフォリオ内でのクロスセル機会の喪失。ある施設の常連客は、別の施設にとって最も質の高い見込み客です。すでにブランドを知り、品質を信頼しているからです。施設同士が見えていなければその機会は活かされず、たいていは他ブランドに奪われます。
• 二回目の滞在でのサービス品質の喪失。常連客がチェーン内の新しい施設を訪れて一見客として扱われる——これは最初から知られていない場合より強い失望を生みます。ブランド自身が作った期待を裏切るからです。
• 顧客価値を正しく把握する力の喪失。先の例の顧客が三施設で支出していても、各施設が三分の一しか見ていなければ、どこも彼を特別対応が必要な層に分類しません。チェーンは誰も気づかないまま大口顧客を抱えていることになります。
• 方針の一貫性の喪失。同じ顧客がA施設では無料アップグレードを受け、B施設では追加料金を全額請求される。誰かが間違えたからではなく、その顧客が何者かという共通の定義が存在しないからです。

この損失がすでに発生している三つの兆候

• 次の問いに誰も答えられない。「ポートフォリオ全体で、二施設以上に滞在した顧客は何人か」。答えを得るのに手作業の集計で数日かかるなら、実質的に答えは存在していません。
• 営業部門がキャンペーンのたびに各施設へ顧客名簿を依頼している——しかも施設ごとに異なる形式で返ってくる。
• VIP顧客リストが表計算ファイルとして存在している。数人が抱え、記憶を頼りに更新され、その人が退職すると消えてしまいます。

第2部：複数施設で共有する一つの顧客プロフィール

設計原則はごく短いものです。顧客プロフィールはチェーンに属し、滞在は施設に属する。一人の人物はポートフォリオ階層で唯一のプロフィールを持ち、その下に滞在履歴、支出、対応履歴のすべてが並び、各行はそれが発生した施設に紐づきます。当たり前に聞こえますが、多くのシステムはまさにここを逆にやっています——施設ごとに顧客データベースを持ち、後から同期しようとするのです。

統合プロフィールに含めるべきもの

• 識別情報：証明書上の氏名と本人が呼ばれたい名前、身分証番号、国籍、顧客が提供した場合は生年月日。
• 連絡チャネル——顧客が利用に同意したもの。目的ごとの同意状況を併せて記録します。
• ポートフォリオ全体の滞在履歴：各滞在について、どの施設か、どの客室区分か、どの料金か、どの予約経路か、何泊か、同行者は何名か。
• 宿泊料以外の支出：飲食、スパ、宴会、その他サービス——低単価で多泊する顧客と高額支出の顧客を最もはっきり分けるのがこの部分です。
• 嗜好と繰り返される要望。顧客自身が述べた嗜好か、サービス部門が観察した内容かを明確に区別します。
• 関係性：どの企業に属するか、どの団体に同行したか、予約者か宿泊者か。高級セグメントでは、これが商業的に最も価値ある情報です。
• 不具合の履歴と対応内容——次の施設が同じ失敗を繰り返さないため、そしてすでに解決済みの件を蒸し返して謝らないためです。

統合前に決めておくべき四つの事項

• 主たる識別キーを何にするか。身分証番号が最も厳密ですが、代理予約では常に得られるとは限りません。電話番号は柔軟ですが家族内で共有されます。実務では組み合わせたルールを文書で確定し、施設ごとの解釈に委ねないことが必要です。
• どの施設を正とするか——同じ顧客について二施設の記録が食い違う場合。通常は直近の滞在がある施設です。そこの情報が最新だからです。
• 過去データをどこまで遡るか。大半のチェーンでは直近24〜36か月あれば運営上も販促上もすべての判断に足ります。それ以前は保管領域へ移します。
• 誰が新規プロフィールを作成できるか。すべてのフロント担当アカウントが自由に作成できると、統合が追いつかない速さで重複が生まれます。

この統合が現実的になるのは、顧客管理が運営と同じ基盤の上にある場合だけです。別システムを定期同期する形ではうまくいきません。DiHotelエコシステムにおける顧客関係管理モジュールDiCRMはそのように設計されています。顧客プロフィールはポートフォリオ階層に置かれ、滞在と支出は各施設の業務から手作業の書き出し・取り込みを経ずに直接積み上がります。

第3部：同一顧客が複数チャネルで予約した際の重複統合

これは最も負荷が重く、最も語られない作業です。長年運営してきたチェーンでは、顧客ファイル内の重複率はほぼ必ず経営陣の想定より高く、そして処理が終わるまでリピーターに関するあらゆる指標は実態より低く出ます。

重複が生まれる理由

• 仲介チャネルが実際の情報を隠す。多くのオンライン販売チャネルは顧客の実際の情報ではなく中継用の連絡先を提供するため、同一人物が二つのチャネルで予約すると別々のプロフィールが二つできます。
• 氏名の表記が複数ある。声調記号の有無、姓名の順序の入れ替わり、ミドルネームの略記、外国語氏名の転写違いなど。
• 予約者と宿泊者が別人。秘書が役員のために予約する、旅行会社が団体のために予約する——システムがこの二つの役割を分けていなければ、プロフィールは誤った人物に紐づきます。
• 繁忙時の急いだ入力。満室の夜、フロントにとっては既存プロフィールを探すより新規作成のほうが速い。これが最も多い原因であり、探すことを作ることより速くする以外に解決策はありません。

統合ルールの立て方

• 二段階ではなく三段階に分ける。確実な重複（身分証番号が一致）は自動統合、疑わしい重複（電話番号は一致するが氏名が違う、または氏名と生年月日が一致）は人が承認する待ち行列へ、それ以外はそのまま。疑わしい段階でシステムに自動統合させては絶対にいけません。別人を一人にまとめる被害は、重複を残すより遥かに大きいからです。
• 統合は取り消せること。すべての統合操作は直前の状態を保存し、再分離できる必要があります。この工程の誤りは数か月後に苦情という形で初めて表面化するからです。
• 完全な履歴を残す：誰がいつ、どの根拠で統合したか、元の二つのプロフィールは何か。
• 期間を区切り、責任者を置いて実施する。顧客ファイルの整理は範囲と終了日を定めたプロジェクトとして行い、その後は毎週の待ち行列で維持します。「手の空いた人がやる」仕事にしてはいけません。
• フロントで重複の発生源を止める。新規作成の前に検索を必須にし、電話番号でも、声調記号の有無を問わない氏名でも、身分証番号でも検索できるようにする——そして結果は一瞬で表示されなければなりません。でなければフロントは検索を飛ばします。

第4部：生涯価値による顧客階層化

プロフィールが統合できたら、次の問いは対応を変えるためのグループ分けです。要点は今回の滞在の客室料金ではなく、生涯価値で階層化すること。下位客室区分を予約していても毎年戻ってきて宴会契約を二件持ち込む顧客は、スイートに一度だけ泊まった顧客よりはるかに価値があります。

顧客価値を構成する四つの要素

• 累計支出額——ポートフォリオ全体で、宿泊料とその他サービスの双方を含みます。
• 頻度と規則性——直近24か月で何回か、そして間隔が安定しているか。
• 連れてくる影響力：団体を伴うか、企業の予約窓口になっているか、他者を紹介しているか。
• 対応コスト：キャンセル率、苦情の頻度、これまでに付与した優遇。売上は高くても要求が過大でキャンセルが多い顧客は、見た目より実質価値が低い場合があります。

チェーン・リゾート向けの階層化参考表

階層化でよくある三つの誤り

• 階層を作りすぎる。五階層が運営チームの記憶し運用できる上限に近い水準です。十階層は、どの階層も使われないという意味になります。
• 階層化したのに対応を変えない。最上位と最下位が同じ扱いなら、階層は意味のないデータ列にすぎません。
• 階層を固定したままにする。顧客価値は時間とともに変わります。階層は定期的に再計算し、顧客の階層が変わるたびにその理由を記録する必要があります。

第5部：VIP顧客データと施設ごとの閲覧権限

データを統合することは、全員が全部を見られることを意味しません。チェーンでは社内で最も議論になりやすい点です。A施設は何年もかけて築いた顧客基盤にB施設が触れることを望まず、一方で経営陣はポートフォリオ全体を見る必要があります。解き方は、存在を知る権限と詳細を見る権限を明確に分けることです。

三層の権限モデル

• 識別層——チェーン全体に開放。すべての施設が、この人物がポートフォリオ内に滞在歴を持つこと、どの階層に属するか、どんな特別要望があるかを見られます。常連客を初対面の客として扱わないための最低限の水準です。
• 運営詳細層——施設単位。詳細な支出履歴、内部メモ、不具合記録は、発生した施設とポートフォリオ管理層にのみ開きます。他施設が閲覧したい場合は理由が必要で、履歴が残ります。
• 機微データ層——厳格に制限。身分証の画像、決済情報、健康に関わる要望は、その業務を実行している必要な役割にのみ開き、すべてのアクセスを記録します。

併せて守る四つの原則

• 権限は個人ではなく役割に付与する。職位に権限を紐づければ、担当者が変わっても権限は職位に従い、アカウントを一つずつ手作業で直す必要がありません。
• VIP顧客データにはアクセス記録が必須。誰が、いつ、何を見たか。これは顧客を守る手段であると同時に、誠実な従業員を守る手段でもあります。
• 退職・異動と同時に権限を回収する。四半期ごとに点検し、有効なアカウント一覧が在職者の一覧と一致している必要があります。
• 外部へのデータ書き出しは統制下に置く。顧客名簿を単体ファイルに出力する行為はこのモデル全体で最大のリスクです。実行できる役割を限定し、記録を残し、定期的に点検します。

このモデルはすでに顧客関係管理モジュールDiCRMに組み込まれています。顧客プロフィールはチェーン全体で共有しつつ、各施設の運営データとレポートは施設ごとに権限分離されます——ある施設が他施設の詳細な消費履歴や内部メモ、レポートを自動的に見られることはなく、一方でポートフォリオ管理層は全体像を把握できます。これが、施設間の責任の境界を損なわずにチェーンで顧客データを統合するための条件です。システム選定時に見落とされがちで、後に各施設が顧客ファイルの共有を拒む理由になります。

上記の義務に対応する三つの具体的な仕組みもDiCRMモジュールに含まれます。第一に、顧客の電話番号やメールアドレスの照会はすべて、照会理由とともに記録されます——後から検証する際に、誰が何をどの業務のために見たのかまで分かります。第二に、個人データはAES-256で暗号化して保存され、検索に使う項目は秘密鍵でハッシュ化されるため、フロントは電話番号で顧客を検索できる一方で、システムはデータをそのまま読める形で保持しません。第三に、顧客からの個人データ削除要求は2025年個人データ保護法が定める削除権に沿った専用の手続きで処理され、施設ごとではなくポートフォリオ全体で実行されます——上記(3)そのものであり、実際の要求を受けたときにチェーンが最もつまずく箇所です。

第6部：フロント・営業・顧客対応部門の連携

顧客データの取り組みが失敗する原因の多くはツールではなく、顧客ファイルの品質について最終的に責任を負う人がいないことです。三つの部門が顧客プロフィールに触れ、それぞれ異なる視点で顧客を見ています。役割を明確に分けなければ、結果として誰もが使うが誰も手入れしないデータになります。

明確な役割分担

• フロント——記録する人。チェックインとチェックアウト時点の正確性に責任を持ちます。新規作成前に検索する、連絡先を確認する、観察した嗜好を記録する。ほぼすべてのデータの源であり、ここの品質が後段のすべてを決めます。
• 営業部門——活用する人。法人顧客、旅行パートナー、宴会顧客の対応にプロフィールを用い、フロントが持ち得ない関係性情報や商業的背景を補います。
• 顧客対応部門——リズムを保つ人。ライフサイクルに責任を持ちます。滞在後の連絡、フィードバック対応、再訪案内の実施、そして最も重要なのが顧客ファイルを清潔に保つこと——統合待ち行列の承認と定期点検です。
• ポートフォリオ階層で顧客データを所有する一人。定義、統合ルール、権限方針を確定する権限を持ちます。この役割がなければ、数か月で各施設が独自の基準を作り始めます。

備えておきたい三つの連携の仕組み

• 記録の残る案件引き継ぎ。フロントが対象企業の顧客に気づいたとき、営業部門への引き継ぎは個人的な連絡ではなく、受け手が明示されたシステム上の操作であるべきです。
• 固定した点検リズム。毎週：統合待ち行列の承認。毎月：データ品質の点検。四半期ごと：階層の再計算とアクセス権限の見直し。
• 公開された共通定義。「リピーター」とは何か、滞在回数で数えるのか泊数で数えるのか、団体の同行者は数えるのか——チェーン全体で一度確定して文書化します。でなければ報告のたびに違う数字が出ます。

この「ポートフォリオ全体で一つの定義」という原則は、USALI基準によるホテルP&Lを論じた際に示したものと同じです。統合データが価値を持つのは、各施設が同じ理解を共有しているときであって、データが同じ倉庫に置かれているときではありません。

第7部：リゾートと宴会型ホテルに固有の事情

リゾート、保養施設、そして宴会・婚礼部門を持つホテルでは、顧客データの課題に都市型ホテルにはない層がいくつか加わります。

個別対応が必要な四つの違い

• 宿泊料以外の支出が大きな比率を占める。多くのリゾートでは宿泊料は総支出の一部にすぎず、飲食、スパ、体験型アクティビティこそが顧客間の差を生みます。顧客プロフィールがこれらの発生源をまとめられなければ、階層化は入力段階から誤ります。
• 一つの予約に複数の宿泊者。家族、友人グループ、企業の団体——予約名義人が最も支出の大きい人物とは限りません。代表者だけでなくグループ全体を記録し、グループ内の役割を区別する必要があります。
• 再訪サイクルが長く季節性がある。保養目的の顧客は十二か月後に戻ってくることがあります。つまりあらゆる測定を年単位のサイクルで読み、再訪案内はホテルの閑散月ではなく顧客の季節に合わせる必要があります。
• 宴会・婚礼契約は独自のライフサイクルを持つ。締結前に何度も接触があり、支払いも複数回、顧客側の関係者も複数です。個人の顧客プロフィールではこれを表現できません。個人と紐づく組織プロフィールの層を並行して持つ必要があります。

これらの特性はリゾート・保養施設の管理の記事でより詳しく扱いました。ここで覚えておくべき点は、この分野に対応するAIホテル管理システムは、あらゆる発生地点の支出を正しい顧客プロフィールへ集約できなければならないということです。でなければ、どの階層も部分的な事実の上に立つことになります。

第8部：リピーター売上比率で測る

この取り組み全体を左右する指標は、システム内のプロフィール件数でもなければ、キャンペーンの開封率でもありません。リピーターからの売上比率です。そしてチェーンではもう一段階あります——ポートフォリオ内の別の施設に再訪した顧客からの売上比率です。

経営陣向けの最小限の指標群

• リピーターからの売上比率——施設別とポートフォリオ全体で。これが主要指標であり、複数四半期の傾向として読みます。
• 二施設以上に滞在した顧客の比率。データ統合の価値を直接測る指標です。統合前は、この数字はそもそも存在しないのが普通です。
• 顧客階層別の平均支出——宿泊料と宿泊料以外を分けて。最上位階層の支出が突出していなければ、階層化の基準が誤っています。
• リピーターにおける直販予約の比率。経済的な効果が最も明確に現れる場所です。仲介チャネルから直販へ移った客室一泊ごとに、手数料が手元に残るからです。
• 顧客ファイルの品質：使える連絡先を持つプロフィールの比率、推定重複率、統合待ち行列の件数。この一群がなければ、上の四指標は信頼できません。

数字を読むときの二つの注意

• 重複統合の実施後にリピーター率が急上昇するのは営業成績ではありません——データが清潔になった結果です。誤読を避けるため、実施時期を注記してください。
• 種類の異なる施設間でリピーター比率を比べないこと。都市型のビジネスホテルと保養リゾートでは再訪のリズムがまったく異なります。そのまま比較すると、チームについて誤った結論に至ります。

この指標群が四半期ごとに安定して回るようになると、オーナーと経営陣は顧客ファイルの価値を定性的な概念ではなく追跡可能な資産として見られるようになります。これはオーナー向け報告アプリケーションが目指す視点でもあります——ポートフォリオ全体を一つの定義体系の上で統合することです。同じポートフォリオ内の小規模施設はクラウドAIホテル管理システムDiCloudを使いながら同じ場所へ統合されるため、二つの製品階層の間で全体像が割れることはありません。