PMSに宿泊履歴が増えても、同じお客様が複数登録されていたり、古い要望が確定情報のように残っていたりすると、現場は安心して使えません。顧客情報の価値は件数ではなく、必要な場面で正しい背景や流れを確認できることにあります。
一方で、似た情報を安易に統合すると、同姓同名、家族、代理予約などを取り違える危険があります。整備では「きれいに一つへまとめる」ことより、根拠を持って扱うことが大切です。
予約単位の情報と顧客単位の情報を分ける
宿泊日、人数、プラン、部屋、今回の到着時刻は予約単位で変わります。連絡方法の希望や過去の対応経緯など、次回にも確認する価値がある情報は顧客単位で扱う候補です。ただし、以前の希望が今も同じとは限りません。
「前回は静かな部屋を希望」と「常に静かな部屋を希望」は意味が違います。いつ、どの予約で、本人が何を伝えたかを残し、次回は確認して使います。詳しくはリピーター対応の記録でも紹介しています。
重複候補は一致項目と不一致項目を両方見る
氏名、電話番号、メールアドレスが同じでも、同一人物と断定できない場合があります。逆に、表記や連絡先が変わっていても同じお客様の場合があります。統合は、一致した項目だけでなく、予約履歴や異なる項目も確認し、判断できる担当者が行います。
統合前には、元のID、変更内容、実施者、日時を追えるようにします。大量の自動統合を行う場合は、誤統合を戻せる方法と対象外条件を先に確認します。
メモには根拠・時点・利用範囲を持たせる
顧客メモへ印象や推測を書けば、後の担当者が事実として受け取るおそれがあります。「いつの会話で聞いたか」「施設は何と回答したか」「今回だけか、次回も確認するか」が分かる表現にします。
不要になった情報を更新・削除する手順も必要です。利用目的に対して過剰な情報を集めず、閲覧できる役割を決め、操作や変更の履歴を確認できるようにします。保存期間や取扱いは、自施設の規程と適用されるルールに合わせて判断します。
表記ルールは検索と引き継ぎのためにそろえる
全角・半角、旧姓、法人名の略称、電話番号の記号など、表記揺れは検索漏れの原因になります。ただし表示を統一するために原文を失う必要はありません。検索用の正規化値と、お客様が入力した表示を分けられるか確認します。
自由記述だけに頼らず、状態や種類を選択項目にする場合も、選択肢を増やしすぎないことが重要です。分類できない情報は原文と確認先を残します。
現場で確認してみましょう
- 予約ごとに変わる情報と、顧客単位で扱う情報を分けたか
- 顧客統合を一項目の一致だけで自動判断していないか
- メモに根拠となる予約・会話・時点があるか
- 古い情報を更新し、誤統合を戻せる手順があるか
- 閲覧範囲と変更履歴を確認できるか
顧客データの品質は、入力者の注意力だけでは保てない
PMSの顧客情報は、予約の受付先、表記、同行者、代理予約、入力時期によって重複します。重複をすべて機械的に統合すると別人を混ぜ、放置すると履歴が分散します。候補検出、確認、統合、キャンセル、監査という手順を用意し、スタッフが安全に判断できるようにします。
同じ「山田太郎」でも、家族の代理予約、法人予約、同姓同名の可能性があります。電話番号が一致しても共用番号かもしれません。複数項目の一致と過去予約の背景や流れを確認し、確信できない場合は統合せず候補として残す判断が必要です。
迷わないための考え方
一致項目に重みを付ける
氏名、ふりがな、生年月日、電話、メール、住所、会員番号の一致度を見ます。単一項目だけで自動統合せず、施設で取得している情報と誤統合の影響から基準を決めます。
代表者と宿泊者を混ぜない
法人担当者や家族が予約し、別の人が宿泊することがあります。連絡先の所有者、予約代表者、実際の宿泊者を関係として残します。
正規化と原文保存を使い分ける
電話番号や空白、全角半角は検索用に正規化できますが、氏名の正式表記は勝手に変更しません。検索キーと表示値を分け、元の入力を追えるようにします。
統合を取り消せるようにする
統合後に別人と判明する可能性があります。変更履歴、統合元ID、実行者を残し、影響範囲を確認して戻せる手順を用意します。
重複と表記揺れを整える手順
- 現状データを複製して検証する本番データを直接一括修正せず、適切に保護した検証用データで重複候補数と誤一致を確認します。
- 正規化ルールを決める電話番号、郵便番号、空白、メール大文字小文字など、検索・比較用の統一方法を定めます。氏名や住所の意味を変えない範囲にします。
- 候補を段階分類する高確度、中確度、低確度に分け、高確度でも影響が大きい情報は人が確認します。判断根拠を画面に表示します。
- 少量ずつ統合する一括処理の前に少数を統合し、予約、売上、履歴、配信同意、手配への影響を確認します。バックアップと戻し方を準備します。
- 新規重複を予防する登録時に候補を示し、代理予約や新規顧客として分ける理由を選べるようにします。月次で新規重複を確認します。
顧客データを整える役割分担
登録担当
新規登録前に重複候補を確認し、予約代表者、宿泊者、同行者、法人担当を分けます。候補が曖昧なら統合せず、判断理由を残します。
データ整備担当
正規化ルールで候補を抽出し、少量ずつ統合します。統合前後の予約、売上、履歴、同意を確認し、キャンセル可能な履歴を保ちます。
責任者・監査担当
誤統合、古い安全情報、主観メモ、配信同意の混在を監査します。一括修正の前に検証データとバックアップ、戻し方を承認します。
統合判断の根拠を残す例
重複候補の一致・不一致を項目別に記録し、同一人物と判断した理由を残します。自動スコアだけで確定せず、代理予約や共用連絡先の可能性を確認します。
- 候補AとB：氏名・メール一致、電話不一致。旧番号の証拠がないため自動統合しない。
- 法人予約：連絡先は会社担当、宿泊者は別人。会社担当の顧客履歴へ宿泊者の好みを移さない。
- 正規化：電話のハイフンと全角半角は比較用に統一。正式な氏名表記は原文を保つ。
- 統合実施：統合元ID、実行者、日時、理由、関連予約件数を記録し、戻し手順を確保する。
- 古いメモ：利用目的と確認日を見直し、必要な安全情報はその宿泊で再確認する。
30日で重複を安全に減らす
- 第1週適切に保護した複製データで、重複候補、表記揺れ、代理予約を受け取った場所ごとに確認します。
- 第2週比較用正規化、一致項目の重み、高・中・低確度、人の確認条件を決めます。
- 第3週少数を統合し、予約、売上、メモ、配信同意への影響とキャンセル手順を確認します。
- 第4週新規重複、誤統合、訂正を振り返り、登録時候補と入力元の主従を改善します。
責任者が見ておきたいこと
統合件数を成果にすると誤統合を促します。責任者は、誤統合ゼロを優先し、曖昧候補を残す判断を認めます。大規模処理は影響範囲、バックアップ、戻し時間を確認し、配信同意や要配慮情報が別人へ移らないことを重点監査します。
よくある失敗と防ぎ方
- 氏名と電話が一致しただけで大量統合する。共用・旧番号、代理予約を確認します。
- 古いメモを新しい顧客へ無条件に引き継ぐ。対象者、出所、更新日を確認します。
- 正規化で正式な氏名表記まで書き換える。検索用値と表示値を分けます。
- 統合前後の件数だけ確認し、予約・会計・同意への影響を見ない。関連データを代表シナリオで検証します。
改善できたかを数字で確かめる
システムを入れただけで終わらせず、現場の仕事がどう変わったかを定期的に確認します。
- 新規重複発生率
- 新しい顧客登録のうち、後から重複と判明した割合を受け取った場所ごとに見て、入力・取込ルールを改善します。
- 誤統合件数
- 別人を統合した事例を重大度とともに追い、基準を厳しくし、キャンセル手順を検証します。
- 古い重要情報の再確認率
- 安全や配慮に関する古い情報が、現在の宿泊で再確認されているかを確認します。
よくある質問
重複顧客は自動で統合できますか？
候補検出は自動化できますが、同姓同名、代理予約、共用連絡先があるため、影響の大きい統合は人の確認が安全です。どれくらい確かかと根拠を示し、キャンセル可能な処理にします。
古いメモは削除すべきですか？
利用目的、正確性、保存方針で判断します。古いから一律削除・保存ではなく、不要な一時情報は整理し、必要な履歴は更新日と状態をはっきり書きます。削除前に関連業務と法令・規程を確認します。
OTAごとに表記が違う場合はどうしますか？
取込元と原文を残しつつ、検索用にふりがな、空白、電話などを正規化します。正式表示は本人確認後に更新し、取込のたびに上書きされない主従を決めます。
まとめ
PMSの顧客情報を整える目的は、登録数を減らすことではなく、現場が根拠を確かめて判断できる状態をつくることです。予約と顧客を分け、重複は慎重に確認し、メモには時点と出所を残します。情報を増やすだけでなく、更新、訂正、利用範囲まで運用として決めることで、お客様の記憶を安全に次へ渡せます。基礎記事はこちら、一覧はおもてなしOSジャーナルです。
