--- title: "予約システムの顧客管理｜予約と顧客を同じIDで持つか分けるかの設計判断" url: "https://www.issoh.co.jp/column/details/16975/" published: 2026-08-26 updated: 2026-08-26 categories: ["Webシステム"] publisher: "株式会社一創" --- # 予約システムの顧客管理｜予約と顧客を同じIDで持つか分けるかの設計判断 予約が1件入るたびに、氏名とメールアドレスと電話番号が新しく1行増えていく。同じ人が3回予約すれば3行になり、名寄せをしない限り「3人の初回客」として集計されます。この記事では、予約データと顧客データを1つのIDにまとめる統合型と、顧客マスタを分離してCRMへ連携する型のどちらを選ぶかを、規模と施策の条件から決められるように整理しました。顧客管理システム単体の機能や脱Excelの判断は[顧客管理システムの機能とExcelとの違いを整理した記事](https://www.issoh.co.jp/column/details/12809/)で扱っています。 ## まとめ｜予約と顧客を1つのIDで持つ条件と、分けてCRM連携する条件 結論から書きます。予約システムに付属する顧客管理で足りるのは、顧客への連絡と過去履歴の参照までです。来店回数や最終来店日を条件にして配信を出し分ける段階に入ると、付属機能では組めなくなります。 分ける基準は規模ではなく施策の複雑さに置きます。顧客を一意に決めるキーを自社で発番し、予約側にはそのIDを外部キーとして持たせる。この形にしておけば、CRMを後から差し替えても顧客の履歴は切れません。逆に、予約システムとCRMの双方で顧客を別々に登録する二重管理型は、初期費用がかからない代わりに最も早く行き詰まります。 判断の分岐は4つです。予約経路が2つ以上ある、来店履歴を条件に施策を出し分ける、カルテや施術記録のように保存年数が決まった情報を持つ、顧客ごとに見せてよい範囲を分ける。1つでも該当すれば分離設計へ寄せ、いずれも当てはまらないうちは統合型のまま動かします。 ## 予約データと顧客データの性質差と、同じ表に混ぜたときに壊れる場所 予約と顧客は、データとしての寿命が違います。この差を無視した設計が、後年の名寄せ作業を生みます。 ### 予約は1件ごとの出来事、顧客は積み上がる台帳という性質の違い 予約は日時と対象が決まった1回きりの出来事で、実施が終われば内容が変わりません。顧客はその逆で、引っ越しで住所が変わり、機種変更で電話番号が変わり、転職でメールアドレスが変わる。書き換わり続ける前提のデータです。この2つを1つの表に押し込むと、過去の予約に当時の連絡先が固定で残るか、書き換えたときに過去の予約の連絡先まで一緒に変わるかの、どちらかが起きます。前者は現在の連絡先が分からず、後者は当時どこへ確認メールを送ったのかが追えません。予約システムそのものの機能と種類は[予約システムの全体像と開発判断を整理した記事](https://www.issoh.co.jp/column/details/12829/)で扱っています。 ### 予約テーブルへ氏名と連絡先を直接持たせたときに起きる3つの不整合 不整合は3種類に分かれます。1つ目は表記ゆれで、「山田 太郎」「山田太郎」「ヤマダタロウ」が別行として並ぶ。2つ目は連絡先の世代差で、同じ人の古い予約に旧アドレス、新しい予約に新アドレスが入り、どちらが現在の値か判定できない。3つ目は集計の水増しで、顧客数を数えると予約件数に近い数字が出てしまいます。 3つ目が実害として一番早く出ます。新規顧客の獲得単価を出そうとして分母が膨らみ、広告の評価そのものが狂う。件数が数百のうちは目視で気づけますが、数千件を超えると誰も気づかないまま数字だけが独り歩きします。 ### 同一人物が別人として増える3パターンと、その発生源の見分け方 別人化の発生源は、入力の主体で切り分けられます。 - 顧客本人がフォームへ毎回入力する場合：会員登録を挟まない予約フォームでは、同じ人が入力するたびに新しい行が生まれる - スタッフが電話を受けて代理入力する場合：担当者ごとに姓名の分かち書きや全角半角の癖が出て、表記ゆれが積み上がる - 外部の予約媒体から取り込む場合：媒体側が発行する転送用アドレスが入り、自社に登録済みの顧客と結びつかない 見分け方は単純で、顧客一覧を電話番号の下4桁で並べ替えると、同一人物の重複が固まって現れます。並べ替えて塊が見えるうちは手作業で吸収できる段階、塊が数十を超えたら設計を変える段階だと考えてください。 ## 予約システムに付属する顧客管理機能の到達点と、そこで止まる場面 予約システムの多くは顧客管理を標準で持っています。どこまで持っているかは、製品の値段ではなく設計思想で決まります。 ### 予約が入ると顧客レコードが自動生成される標準動作と、その粒度 STORES 予約のように、予約が確定した時点で顧客カルテを自動作成する製品が一般的です。自動作成されるレコードは、予約フォームで受け取った項目そのままの粒度になります。氏名とメールアドレスと電話番号だけを聞くフォームなら、顧客レコードもその3項目で始まる。ここに後から生年月日や来店きっかけを足したくなったとき、既存の顧客には空欄が残り続けます。 フォーム項目は顧客マスタの初期スキーマそのものになる、と考えて先に決めておくほうが安く済みます。項目を足す作業自体は数分ですが、埋まっていない過去分を埋め直す作業は人の手に落ちます。 ### 付属機能で足りるのは連絡と履歴の参照まで、という線引きの根拠 付属の顧客管理が確実にこなすのは2つです。予約に紐づく連絡（確認・リマインド・お礼）と、その顧客の過去の予約履歴を1画面で見ること。この2つは予約データの中だけで完結するため、どの製品でも動きます。 線が引かれるのは、予約以外の接点を顧客に紐づけたくなった瞬間です。問い合わせフォームからの相談、来店時の物販、キャンセルの経緯。これらは予約テーブルに居場所がなく、備考欄へ書き込むしかない。備考欄に入った情報は検索も集計もできず、担当者が辞めた時点で失われます。製品タイプごとの機能差は[予約管理システムを3タイプに分けて比較した記事](https://www.issoh.co.jp/column/details/16964/)に整理してあります。 ### メール配信・LTV集計・チャネル横断の名寄せで止まる3つの理由 止まる理由はそれぞれ別です。メール配信では、来店回数や最終来店日を条件にした抽出ができても、配信停止の意思表示を顧客単位で保持する仕組みを持たない製品が多い。LTV集計では、予約の売上は取れても物販や回数券の売上が別システムにあり、合算できません。チャネル横断では、Webからの予約と電話予約と媒体経由の予約が、それぞれ別の顧客レコードとして並びます。 3つ目が最も根が深く、名寄せの設計を先に決めていないと後から機械的には直せません。会員番号を発行して顧客に持たせる形が採れるなら、[会員管理システムの機能と顧客管理との違いを整理した記事](https://www.issoh.co.jp/column/details/12830/)の考え方がそのまま使えます。 ## 同一IDの統合型と分離してCRM連携する型の、費用と運用負荷の比較 形態は3つに割れます。統合型、分離型、そして意図せずそうなる二重管理型です。 ### 統合型・分離型・二重管理型の3形態を運用負荷と初期費用で比較 同じ「顧客管理をしている」状態でも、日々の手間と行き詰まる時点が違います。 | 形態 | 顧客の同定 | 日々の手間 | 初期費用 | 先に詰まる場面 | | ----- | ----------- | --------- | -------- | -------- | | 統合型 | 予約時の入力で自動生成 | 追加作業なし | 月額のみ | 条件付きの施策 | | 分離型 | 顧客IDを発番して連携 | 例外の名寄せのみ | 連携の開発が必要 | 反映の遅れ | | 二重管理型 | 両方で別々に登録 | 二重入力が常時発生 | 実質ゼロ | 件数が増えた時点 | 二重管理型は初期費用をかけずに始められるため、選んだ自覚がないまま入り込みます。予約システムを導入した後にCRMを別途契約し、連携を後回しにした組織はほぼここに落ちる。困るのは費用ではなく、入力の手間が件数に比例して増え続ける点です。 ### API同期・CSV定期取り込み・iPaaSの3方式と反映の遅れ幅 分離型を選んだ場合、連携の実装方式は3つです。予約確定時にWebhookやAPIで即時に顧客側へ書き込む方式は、反映の遅れが秒単位に収まる代わりに、失敗時の再送設計を自前で持つ必要があります。CSVを日次で書き出して取り込む方式は、開発をほとんど伴わない代わりに、当日中の来店対応には間に合わない。ZapierやMakeのようなiPaaSを挟む方式は、初期構築が数日で済み、実行回数に応じた月額が積み上がります。 反映の遅れが許容できるかは、施策の性質で決まります。誕生月クーポンの配信なら日次で足り、来店直後のフォロー配信を狙うなら即時が要ります。LINEを配信経路に使う場合の実装差は[予約管理システムのLINE連携を4方式で比べた記事](https://www.issoh.co.jp/column/details/16971/)にまとめました。 ### 先に詰まるのは二重管理型だという結論と、そこから抜ける移行手順 二重管理型は、顧客数が数百を超えた時点で人手の入力が追いつかなくなります。抜け方は決まっていて、どちらを正とするかを先に決めるところから始まる。順番を守らずにデータを寄せると、統合の途中で判断基準が揺れます。 1. 予約システムとCRMのどちらを顧客マスタの正とするか決める（施策を回す側を正にする） 2. 正でない側の顧客レコードを書き出し、電話番号の下4桁と姓で突き合わせて重複候補を抽出する 3. 突き合わせで残った例外だけを人が判定し、正側へ統合する 4. 正側で顧客IDを発番し、従側のレコードへ外部キーとして書き戻す 5. 以降の新規登録は正側だけで行い、従側へは連携で流し込む 工程2で機械的に処理できる範囲には限りがあり、同姓同名と家族での連絡先共有は必ず例外として残ります。ここは人が判断を引き受けるほかない部分です。 ## 顧客を一意に決めるキーの設計と、メールや電話で名寄せが崩れる条件 顧客を一意に決めるキーをどれにするかで、名寄せの精度は決まります。多くの設計はここで一度つまずきます。 ### メールアドレスを一意キーに置いた場合に現場で起きる取り違え3例 メールアドレスを一意キーにする設計は、CRM製品の側では標準です。HubSpotはメールアドレスをコンタクトの識別子として扱い、既存コンタクトと同じアドレスで登録された情報は、新規レコードを作らず既存レコードへ上書きされます。 予約の現場では、この前提が3か所で崩れます。家族が代表者のアドレスで別々に予約を取る場合、母と子が同一人物として統合される。会社の代表アドレスで複数の担当者が予約する場合も同じことが起きる。そしてメールアドレスを持たない顧客層は、そもそもキーを持ちません。 統合が一度走ると戻せない点も効いてきます。HubSpotの公式ヘルプは、レコードをマージ解除することはできないと明記し、レコードが合計で250回以上のマージに含まれている場合はそれ以上マージできないとも記しています。誤って統合した親子の予約履歴は、手作業で分離するほかありません。 ### CRM側の照合仕様が決める名寄せ精度と、完全一致だけの落とし穴 Salesforceの標準の取引先責任者一致ルールは、項目ごとに照合方法が決まっています。Email は Exact、つまり完全一致のみ。Last Name は Exact に加えて Keyboard Distance と Metaphone 3、First Name は Exact・Initials・Jaro-Winkler Distance・Metaphone 3・Name Variant といった、あいまい照合が併用できます。 読み替えると、メールアドレスは1文字違えば別人として扱われ、氏名側は表記ゆれをある程度まで吸収できるという非対称になっています。大文字小文字の混在、末尾に付いたエイリアス、前後に紛れ込んだ空白。予約フォームで受け取ったアドレスをそのままキーにするなら、小文字化と空白除去は取り込み側で必ず通す設計にします。 ### 自社側で顧客IDを発番し、予約側に外部キーとして持たせる設計 一番壊れにくいのは、外部サービスの識別子に依存しない自社発番のIDを1本持つ形です。顧客マスタ側で連番なりUUIDなりを発番し、予約システムには顧客ID欄を1つ追加してそこへ書き込む。予約側の顧客情報はあくまで写しで、正はマスタ側に置きます。 この形の効きどころは、差し替えのときに出ます。予約システムを別製品へ乗り換えても、CRMを別ベンダーへ移しても、顧客IDが残っていれば履歴は繋ぎ直せる。逆に、予約システムが内部で振った顧客番号を正にしていた場合、その製品をやめた瞬間に過去の紐づけが失われます。 ## 来店履歴・カルテ・リピート施策へ広げる設計と、保存期間の決め方 顧客データを来店履歴やカルテへ広げるとき、先に決めるのは項目ではなく保存年数です。年数が決まると、どこに置くかも自動的に絞られます。 ### リピート施策を条件で組むために予約側へ持たせておく5つの項目 配信の条件式は、持っている項目の範囲でしか書けません。予約テーブルに次の5つが揃っていれば、たいていの施策は組めます。 - 実施フラグ（来店したのか、無断キャンセルだったのか） - 担当スタッフID（指名の有無と、担当者別のリピート率を出すため） - メニューまたはサービスID（次回提案の条件に使うため） - 実売上金額（予約時の見込み額ではなく、当日の会計額） - 流入元（自社サイト・電話・媒体・紹介のいずれか） このうち抜けやすいのが実施フラグです。予約が入った記録だけを残し、来なかった人の行を消してしまう運用では、無断キャンセル率が測れず、前日リマインドの効果検証もできません。顧客が自分で予約履歴や登録情報を見られる窓口を用意する場合は、[顧客ポータルに必要な機能と構築方式を整理した記事](https://www.issoh.co.jp/column/details/16649/)が設計の下敷きになります。 ### カルテを扱う業種で先に決める保存年数と、外部保存の場所の要件 医科・歯科の診療録は、5年間の保存が義務づけられています。厚生労働省の通知（平成14年3月29日 医政発第329003号・保発第329001号）は、医師法第24条および歯科医師法第23条に規定する診療録について5年間これを保存しなければならない、と記しています。 同じ通知は保存場所も縛ります。電子媒体で外部保存する場合、サーバ等の情報処理機器を置ける場所は、医療法上の病院・診療所その他これに準ずるものとして医療法人等が適切に管理する場所、行政機関等が開設したデータセンター等、医療機関等が民間事業者等との契約に基づいて確保した安全な場所に限られる。あわせて、診療録等は診療の用に供するものであり、必要に応じて直ちに利用できる体制の確保が求められる、とも書かれています。 予約システム側の話に落とすと、カルテ相当の情報を予約テーブルの備考欄へ書くのは避けるべき、という結論になります。予約データは製品を乗り換えれば消える前提で扱い、保存義務のある記録は別の入れ物へ置く。エステや整体のように法定の保存義務がない業種でも、施術内容と使用製剤の記録は事故対応の証跡になるため、同じ扱いにしておくほうが安全です。 ### 消去の努力義務から逆算する保持期間ルールの決め方と運用の回し方 個人情報保護法は、保存期間そのものを定めていません。個人情報保護委員会は、法第22条により、取扱いに係る個人データを利用する必要がなくなったときは当該個人データを遅滞なく消去するよう努めなければならない、と説明しています。性質は義務ではなく努力義務ですが、不要なデータを持ち続けることは漏えい時の被害を膨らませます。 実務では、業種ごとの保存義務年数を下限に置き、そこへ施策上の必要期間を重ねて決めます。診療録なら5年が下限、法定義務のないサロンなら最終来店から3年程度を目安にし、その先は氏名と連絡先を消して来店回数と売上だけを統計として残す。この「識別できない形にして残す」処理を先に設計しておくと、消去のたびに集計値まで失う事態を避けられます。 ## 分離設計が過剰になる事業条件と、CRM連携へ踏み切る4つのサイン ここまでを踏まえて、どちらを選ぶかを条件付きで言い切ります。玉虫色にせず、見送るべき場面から先に置きます。 ### 統合型のままでよい規模条件と、分離を見送るべき3つの具体的場面 統合型のままでよいのは、予約経路が自社サイト1本、スタッフが数名、施策が全員一斉の配信で足りる場合です。この条件下でCRMを別途契約して連携を組むのは、費用の面でも運用の面でも過剰になります。 分離を見送るべき場面は3つあります。1つ目は年間の予約件数が数百件に届かない場合で、名寄せの手間が人手で吸収できる範囲に収まる。2つ目は顧客との接点が予約だけで完結する場合、たとえば設備の貸出のように継続的な関係を作らない業態。3つ目は、連携を保守する担当者を社内に置けない場合で、連携が壊れたまま放置される事態のほうが、二重入力よりも損害が大きくなります。 ### 分離へ踏み切る境界線と、既製品の組み合わせか自社開発かの決め方 踏み切る境界は4つのサインで判断します。予約経路が2つ以上に増えた、来店履歴を条件に配信を出し分けたい、保存年数の決まった記録を扱う、顧客ごとに閲覧できる範囲を分ける必要が出た。1つでも当てはまれば、顧客マスタを予約システムの外へ出す時期です。 そのうえで既製品の組み合わせで足りるか、開発に踏み込むかは、名寄せの例外率で決めます。媒体経由や電話からの予約が全体の2割を超え、その多くが既存顧客の再来である場合、汎用CRMの標準の重複ルールでは吸収しきれず、自社の判定ロジックが要る。ここまで来たら、予約と顧客を最初から1つのデータモデルとして設計するほうが総額は安く収まります。[予約管理システムの開発](https://www.issoh.co.jp/service/system/reservation/)では、顧客マスタの持ち方と既存CRMとの連携方式を含めて設計から引き受けています。料金体系ごとの費用の積み上がり方は[予約管理システムの費用を3年総額で比べた記事](https://www.issoh.co.jp/column/details/16967/)にまとめました。 ## よくある質問 予約と顧客のデータ設計について、検討の初期に出やすい質問を5つ挙げます。 ### 予約システムの顧客管理機能だけでCRMは不要になりますか？ 顧客への連絡と履歴の参照までなら、付属機能で足ります。CRMが要るのは、来店回数や最終来店日を条件にして配信内容を変える段階からです。判定の目安は、施策を組むときに条件式を書きたくなるかどうか。「3か月来ていない指名客だけに」といった絞り込みを口に出した時点で、付属機能の範囲を超えています。逆に全員へ同じ案内を送るだけの運用なら、CRMを増やしても管理する画面が1つ増えるだけになります。 ### 予約データと顧客データを同じIDにまとめると何が困りますか？ 困るのは、顧客側の情報が書き換わったときです。予約1件ごとに氏名と連絡先を持たせていると、引っ越しや機種変更で連絡先が変わった際、過去の予約に古い値が残るか、過去分まで一括で書き換わるかのどちらかになります。前者では現在の連絡先が分からず、後者では当時どこへ通知を送ったのかが追えない。予約は起きた事実の記録、顧客は現在の状態、と役割を分けて、予約側には顧客IDだけを持たせる形が安全です。 ### メールアドレスがない顧客はどう識別すればよいですか？ 電話番号を第一のキー、氏名のカナ表記と生年月日を補助キーに置く形が現実的です。電話番号は家族で共有されることがあるため、単独では一意になりません。カナ氏名を併用すると同一世帯の別人を分けられます。加えて、来店時に会員番号を印字したカードやLINEの友だち登録を渡し、次回以降はその番号で照合する運用に寄せると、キーの欠損が減っていく。自社発番の顧客IDを持たせておけば、後からメールアドレスを取得した際に紐づけ直すだけで済みます。 ### 予約システムとCRMの連携はどのくらいの頻度で同期すべきですか？ 施策の時間感覚に合わせます。誕生月クーポンや月次のニュースレターが目的なら、日次のCSV取り込みで間に合う。来店直後のお礼配信やキャンセル後のフォローを自動で出したいなら、予約の状態が変わった時点で送る即時連携が要ります。中間としてiPaaSを1時間おきに回す構成もありますが、実行回数に応じた課金が積み上がるため、連携の対象を予約の新規と変更に絞る設計にしておくと費用を抑えられます。 ### 過去の予約データから顧客マスタを作り直すことはできますか？ できますが、機械的に処理できるのは一部にとどまります。予約テーブルから氏名・電話番号・メールアドレスを抜き出し、電話番号の下4桁と姓で突き合わせれば重複候補は絞り込めます。残るのは同姓同名と、家族で連絡先を共有しているケースで、ここは人が1件ずつ判定するほかありません。作り直すと決めたら、統合の判断基準を先に文書化し、判定した結果を元データへ書き戻しておくこと。やり直しの効かない統合を、基準なしで進めないようにします。 ## 関連記事 - [予約システムとは？主な機能・種類と、既製サービスで足りない場合の開発判断を解説](https://www.issoh.co.jp/column/details/12829/)：予約システム側の機能と種類から入る場合 - [顧客管理システムとは？機能・Excelとの違い・脱Excelの判断基準を解説](https://www.issoh.co.jp/column/details/12809/)：顧客管理システム単体の機能と選び方 - [会員管理システムとは？機能・顧客管理との違いと、Excelから移行する判断基準を解説](https://www.issoh.co.jp/column/details/12830/)：会員番号を発行して識別する業態の設計 - [予約管理システムの比較｜3タイプ別の選び方と既製品で足りなくなる境界線](https://www.issoh.co.jp/column/details/16964/)：製品タイプ別の比較と選定の順番 - [予約管理システムのカレンダー連携｜Googleカレンダー運用の限界と同期方式3つの選び分け](https://www.issoh.co.jp/column/details/16973/)：カレンダー運用から移行する場合の同期方式 --- 出典: [予約システムの顧客管理｜予約と顧客を同じIDで持つか分けるかの設計判断]()（株式会社一創）