ナレッジ › インポーター
インポーター

ディーラー間の顧客二重化を防ぐ｜同一顧客の複数登録をグループで統制する

📖 約10分更新 2026-06-22
重複スキャンで同一会社内の重複顧客を類似度スコア付きで一覧化するRibbonの画面
同一会社内の重複候補を類似度スコアと一致根拠つきで一覧化し、手動で確認しながら名寄せする（重複スキャン）

この記事の要点

  • グループの顧客二重化は「同じ会社の中の重複」と「別ディーラー間の重複」の2層に分けて考える。対策の打ち手がまったく違う。
  • Ribbonの重複検出・名寄せは1社（テナント）の中で完結する。会社をまたぐ自動マージ機能は持たない。
  • 同一会社内なら、重複スキャンで類似度0.7以上の候補ペアを最大300件提示し、顧客マージで手動統合できる。
  • 取り込み時は電話・メール重複行を自動検知して既定で除外し、新規登録時も重複ガードで保存前に警告する。加えて登録前検索と名寄せキーの統一で固める。
  • 二重化防止はツールだけでは解けない。名寄せキー・登録手順・残す基準を本社が標準として定めることが先決。

この記事で分かること

  • グループ傘下の複数ディーラーで顧客が二重化する仕組みと、それが現場・本社にもたらす実害
  • Ribbonの重複検出・名寄せでできること／できないこと（会社の境界という壁）
  • 取り込み・登録の段階で二重化を抑える運用ルールの作り方
  • 本社が「グループ標準」として定めるべき名寄せキーと判断基準

対象読者：販売会社グループの本社・営業企画・営業事務、複数店舗を束ねる管理職｜読了目安：約10分

はじめに：2通のDMが届いた家

金曜の夕方。神奈川のとある住宅に、同じ輸入車ブランドの販売会社から封筒が2通、ほぼ同時に届いた。差出人は片方が横浜の店、もう片方が川崎の店。中身はどちらも初夏のキャンペーン案内で、宛名は同じ「滝沢（仮名）」様。

受け取った滝沢さんは、別に怒鳴り込んだりはしない。ただ、こう思う。「この会社、左手と右手が連携してないんだな」と。

本社で販売企画を担当する内海さん（仮名）がこの一件を知ったのは、滝沢さんが横浜店の営業に何気なく漏らした一言からだった。調べてみると、滝沢さんは3年前に川崎店で1台、去年横浜店で1台を購入していた。当然、同じ人。ところがグループの中では、川崎店の顧客カードと横浜店の顧客カードという、別々の2件として存在していた。

「お客様から見れば1社なのに、社内では2人の別人として動いていた。DMが2通届いて初めて気づくなんて、遅すぎる」

これはレアケースではない。複数の販売会社を傘下に持つグループでは、むしろ日常的に起きている。そして厄介なのは、二重化が「ミス」というより「構造」だという点にある。

なぜグループでは顧客が二重化するのか

グループの顧客二重化は、担当者の不注意ではなく、販売会社が法人として分かれている構造から生まれる。 同じブランドを扱っていても、横浜の会社と川崎の会社は別法人。顧客データも別々に管理されているのが普通だ。だから同じ人が両方で買えば、両方にカードができる。

要因を分解すると、だいたいこの4つに収まる。

最初の「会社の分離」が一番根が深い。これはシステムの設定や担当者の努力でどうにかなる話ではなく、組織のかたちそのものだからだ。後述するが、ここを取り違えると「ツールを入れれば自動で名寄せされる」という誤解に陥る。

二重化が放置されると、実害はじわじわ効いてくる。DMの重複送付でコストが二重にかかる。同じ顧客に2店が別々にアプローチして商談を食い合う。買い替え1回・整備5回・紹介2件といった顧客の生涯価値が、2枚のカードに分断されて見えなくなる。本社の集計では「顧客数」が水増しされ、実態より多く見える。どれも、経営判断の土台を静かに歪める。

二重化は「2層」で考える

対策を考えるときは、二重化を「同じ会社の中の重複」と「別ディーラー（別会社）間の重複」の2層に必ず分けること。 この2つは原因も打ち手もまったく違うのに、現場では一緒くたにされがちだ。ここを混ぜると話が噛み合わなくなる。

層 どこで起きるか 主な原因 有効な打ち手
第1層：会社内の重複 1つの販売会社の顧客データの中 表記ゆれ・登録前無検索・接点の多さ 重複スキャン＋名寄せ（システムで支援可）
第2層：会社間の重複 グループ傘下の別ディーラー同士 法人・データベースの分離 運用ルール・データ統合・本社の標準化（システムだけでは解けない）

第1層は、ツールが得意とする領域だ。同じデータベースの中で似た者同士を探し、人が確認してまとめる。第2層は、そもそもデータが別の箱に入っているので、システムが勝手に横断して名寄せすることはできない。ここを正直に押さえておくのが、現実的な対策設計の出発点になる。

筆者の意見を言えば、多くのグループは第1層の対策すら手付かずのまま「グループ横断の自動名寄せ」を夢見て止まっている。まず自社1社の中をきれいにする。話はそれからだ。

同一会社内の重複を見つけて名寄せする

同じ会社の中の重複なら、Ribbonの重複スキャンで候補を洗い出し、顧客マージで1件に統合できる。 ここが、システムが最も力を発揮する場面だ。

Ribbonの重複対策は2つの機能で構成されている。

1. 重複検出（重複スキャン） — 顧客一覧の「重複スキャン」ボタンから、全顧客を横断してスキャンする。氏名・電話・メールを正規化したキーで照合し、類似度を計算。閾値0.7以上の候補ペアを、似ている順に最大300件まで提示する。氏名の表記ゆれや電話番号のハイフン有無は正規化で吸収するので、「滝沢」と「瀧沢」のような揺れも拾いやすい。

2. 顧客マージ — 候補ペアを開くと、どちらを正（残す側）にするか、各フィールド（氏名・住所・電話など）をどちらから採用するかを1項目ずつ指定できる。統合前に「この顧客に商談が何件、活動履歴が何件ぶら下がっているか」も表示される。実行すると、統合元のカードは論理削除され、関連データは残す側に集約される。

顧客マージのフィールド選択画面。項目ごとにどちらの値を残すかラジオで選ぶRibbonの画面
顧客マージ。氏名・フリガナ・電話などを項目ごとに「どちらを残すか」選ぶ。値が異なる項目には警告が付き、別人の誤統合を防ぐ

ここで強調したいのは、マージは必ず人が確認する設計だということ。完全自動の無人統合は、意図的に備えていない。理由はシンプルで、顧客データの統合は不可逆に近く、間違えると別人を1人にまとめてしまうからだ。「自動でやってくれない」のは欠点ではなく、安全側に倒した判断だと捉えてほしい。

💡 無料相談受付中：グループの顧客二重化（どこで・どのくらい重複しているか、名寄せキーの整備状況）を、重複スキャンの実画面を交えた無料デモでご案内します。Ribbon導入の有無にかかわらずご相談ください。 → お問い合わせはこちら

運用の段取りはこうなる。月初など決まったタイミングで重複スキャンを回す。出てきた候補を営業事務が確認し、明らかな同一人物だけをマージ。判断に迷うペア（同姓同名で住所が違う、家族で電話が同じ等）は無理にまとめず、保留にして担当者に確認を回す。この「迷ったらまとめない」が地味に効く。

取り込み・登録の段階で二重化を抑える

Ribbonは取り込み時の重複行の自動除外と、新規登録時の重複ガードを備えている。それでも、完全自動のマージはしない設計なので、二重化を本当に抑えるには「入口」の運用ルールが効く。 システム任せにせず大量のCSVを無整備で取り込むと、ガードをすり抜けた表記ゆれの重複が増える。

CSVインポートで既存データを取り込むとき、システムは「似ている顧客がいます」と止めてはくれない。同じ人が2行あれば、2件登録される。新規顧客を画面から登録するときも、入力途中で「同じ電話番号の顧客がいます」と警告は出ない。つまり、入口の防波堤は人が担う。

現実的に効く入口ルールは3つだ。

  1. 取り込み前にキーを揃える：電話は数字のみに統一、法人は法人番号で寄せる、姓名の前後スペースや旧字を整える。取り込み元のExcel段階でここを済ませておくと、後の重複スキャンの精度が段違いに上がる。
  2. 登録前に必ず検索する：新規登録の前に氏名か電話で一度検索する、を全店の絶対ルールにする。郵便番号→住所、法人番号→企業情報の自動入力を使えば、入力のついでに既存照合の意識も働く。
  3. 取り込み直後にスキャンを回す：移行や一括取り込みの直後は重複が増えるタイミング。取り込んだら必ず重複スキャンを実行し、その回でまとめて名寄せする運用にする。

データ移行そのものの進め方は専門の記事に譲るが、ひとつだけ。移行は「とりあえず全部入れて後で消す」が一番危ない。汚いまま入れたデータは、汚いまま二重化する。

別ディーラー間の二重化は運用で統制する

別会社（別ディーラー）にまたがる二重化は、システムが自動で名寄せすることはできない。グループの運用ルールとデータ統合の設計で統制する。 ここがこの記事の核心であり、最も誤解されやすいところだ。

なぜ自動でできないのか。Ribbonは会社（テナント）ごとに顧客データを分離して管理する。横浜の販売会社のデータと川崎の販売会社のデータは、別々の箱に入っている。これは情報保護とテナント分離のための正しい設計で、だからこそ「他社の顧客を勝手に覗いて名寄せする」ようなことは起きない。裏返せば、グループ横断の自動マージという機能は存在しない。

では、別ディーラー間の二重化はどう統制するか。打ち手は3方向ある。

冒頭の滝沢さんのケースは、まさにこの第2層だった。横浜店と川崎店は別会社。システムが自動で気づくことはなく、人が運用で拾うしかなかった。だからこそ、本社が「同じ顧客に2店からDMが重ならない仕組み」を運用として設計しておく価値がある。

本社が決めるべきグループ標準

二重化防止で本社が最初にやるべきは、ツール選定ではなく標準づくりだ。 名寄せキー・登録手順・統合判断の3点を文書化し、全販売店に同じものを使わせる。これがないと、どんなシステムも力を出せない。

決めておきたい標準を、優先度順に並べる。

決めること 具体例 これがないと起きること
名寄せキーの正規化 電話は数字のみ／法人は法人番号／姓名の旧字・スペース統一 同一人物が照合で一致せず、重複が温存される
登録前検索の義務化 新規登録の前に氏名か電話で必ず検索 入口で重複が増え続ける
残す側の判断基準 取引が新しい方を正にする等のルール 名寄せのたびに担当者の判断がブレる
スキャンの実施頻度 月初に重複スキャン、移行直後は必須 重複が溜まってから慌てて対処する

順番が大事だ。いきなりシステムの機能比較から入ると、たいてい「自動で名寄せできるか」ばかり気にして、肝心の入口ルールが後回しになる。逆に、入口さえ揃っていれば、第1層の名寄せはシステムでほぼ片付く。

よくある失敗パターンを2つ挙げておく。ひとつは、移行のときにキー整備を飛ばして「後でまとめてやる」と先送りし、結局そのまま運用が始まってしまうケース。もうひとつは、重複スキャンの候補を全部まとめようとして、同姓同名の別人や家族をうっかり1人に統合してしまうケース。前者は入口、後者は出口の事故で、どちらも「ルールが曖昧」が共通の根っこにある。

Ribbonが備える顧客重複対策の機能

Ribbon（リボン）は、自動車ディーラー向けの統合管理SaaSです。顧客の二重化対策に直接・間接に関わる機能を、実在するものだけ挙げます。**会社をまたぐ自動名寄せ機能はありません。**以下はいずれも1つの会社（テナント）の中で機能します。

よくある質問（FAQ）

グループ内の複数ディーラーで同じ顧客が二重に登録されるのは、なぜ問題なのですか？

同じ顧客に複数の販売店から同時にDMや見積が届くと顧客の心証を損ない、社内では商談の食い合いや実績の二重計上が起きるためです。さらに買い替え・整備・紹介を含む顧客の生涯価値が分断され、本社の集計が実態より膨らみます。

Ribbonは複数の会社（ディーラー）をまたいで顧客の重複を自動で名寄せできますか？

いいえ。Ribbonの重複検出・名寄せは1つの会社（テナント）の中で機能します。会社ごとに顧客データは分離されており、別会社の顧客カードへ自動でマージする機能はありません。グループ横断の二重化対策は、運用ルールとデータ統合の設計で行います。

同じ会社の中でダブった顧客カードはどうやって見つけますか？

顧客一覧の「重複スキャン」で全顧客を横断し、氏名・電話・メールの類似度が0.7以上の候補ペアを類似度の高い順に提示します。担当者が候補を確認し、顧客マージ画面でフィールド単位に統合します。マージは必ず手動確認を挟む設計です。

CSVで顧客を取り込むとき、自動で重複を弾いてくれますか？

取り込み時は、電話番号やメールが既存顧客やCSV内の他行と一致する行を自動で検知し、既定で取り込み対象から除外します。新規登録時も、電話・メール・氏名が似た既存顧客があれば保存前に確認を挟む重複ガードが働きます（別人と確認できれば承知のうえ作成も可能）。完全自動のマージは行わないため、残った候補は取り込み後の重複スキャンで人が確認して統合します。

二重化を防ぐために、まず決めておくべきルールは何ですか？

名寄せキー（電話番号は数字のみ、姓名の表記ゆれ、法人は法人番号）を統一すること、登録前に氏名か電話で必ず検索する習慣、重複が見つかったときに「どちらを残すか」の判断基準を文書化することの3つです。ツール導入より先に決めます。

本社は各販売店の顧客情報をどこまで見られますか？

Ribbonは会社→店舗→ユーザーの階層と権限ロールで見える範囲を制御します。会社をまたぐ閲覧は権限と承認の設計次第で、初期状態では各社のデータは分離されています。本社集計はインポーターBIのように承認済みの範囲で横断する仕組みを使います。

まとめ

グループの顧客二重化は、放っておくと静かに経営判断を歪める。最後に要点を、別の言い方で整理しておく。

滝沢さんの家に2通のDMが届かない仕組みは、機能のスイッチを1つ入れれば完成するものではない。本社の標準と、各店の地道な入口運用と、月初の名寄せ。その積み重ねの先にある。

あわせて読みたい関連記事

Ribbonの導入相談・無料デモ

Ribbon（リボン） は顧客データの一元管理を中核に据えた、自動車ディーラー向け統合管理SaaSです。グループの顧客二重化の見つけ方から、無料デモで実際の画面をご覧いただけます。

株式会社DM and Tについて

自動車ディーラー向け統合管理SaaS「Ribbon」を開発・提供する株式会社DM and Tが運営。営業・整備・車検・アフターサービスの実務改善、ディーラーDX、CRM／SFA選定といったテーマで、現場と経営の両方に役立つ記事を発信しています。

公式サイト ｜ Ribbon無料デモのお申し込み

Ribbonを実際の画面で見てみませんか

自動車ディーラー向け統合管理SaaS「Ribbon」を、無料デモで実際の画面とともにご案内します。

無料デモ・ご相談はこちら