顧客データの統合とは、フォーム、名刺アプリ、メールやチャットのやり取り、表計算シートなどに散らばった顧客の情報を、重複のない1つの台帳にまとめることです。Zoho CRMでは、見込み客・取引先・連絡先の3つのモジュールに、決めたルールで振り分けて名寄せ（同じ人・同じ会社のデータを1つにまとめること）をします。

この記事では、人事領域のIT運用支援を行う少人数のコンサルティング会社で当社が設計した統合の考え方を、技術担当の目線でまとめます。構築前の設計段階の内容なので、成果ではなく「どう決めたか」を中心に書きます。名刺管理ツールとの自動同期については「名刺管理ツールとZoho CRMを自動同期する設計」、既存データのクレンジングは「ZohoDataPrepでデータをクレンジング」もあわせてご覧ください。

よくある状態：データはあるのに、メールを送り分けられない

ご相談の時点では、顧客の情報が次のように分かれていました。

  • 資料請求や問い合わせのフォームで集めた見込み客のデータ
  • 名刺アプリに個人ごとに登録された名刺
  • メールやチャットで直接やり取りしているが、どこにも登録されていない顧客
  • 商談になった後の情報を管理している別のツール

困っていたのは、メール配信です。相手が顧客なのか、パートナーなのか、取引のない見込み客なのかを区別できないため、相手に合わせて内容を送り分けられません。同じ人が別々のツールに少しずつ違う形で入っているので、単純に合算すると重複だらけになります。

この状態を「ツールを1つにまとめれば解決する」と考えると、移した先で同じ問題が起きます。先に決めるべきは、データの置き場所の定義と、名寄せのルールです。

手順1：見込み客・取引先・連絡先はどう使い分ける？

Zoho CRMの3つのモジュールを、次のように定義しました。

モジュール 入れるもの
見込み客 取引先・連絡先のどちらにも当てはまらない個人。名刺交換した人、資料をダウンロードした人など
取引先 取引や契約がある企業。見込み客とははっきり分ける
連絡先 取引先に所属する担当者

あわせて、取引先に2つの項目を追加します。

  1. 取引先の属性：顧客、パートナー、ベンダーなど。メールの送り分けのセグメントに使います
  2. メールドメイン：その会社のメールアドレスの「@」より後ろ。名寄せのときに、見込み客をどの取引先につなぐかの判断に使います

なお、見込み客モジュールを使わず、取引先と連絡先だけで運用し、見込み客は取引先の分類として扱う案も検討しました。モジュールを減らすと画面が単純になる一方、名寄せ前のデータの受け皿がなくなります。どちらが合うかは、データが入ってくる経路の数で判断するのがよいと考えています。見込み客と連絡先を分けるか1つにまとめるかの判断軸は、「Zoho CRMの見込み客と連絡先は分けるべきか｜外国人材紹介で人材を1つの箱にした判断軸」でも別の業種の例で解説しています。

手順2：どの順で照合する？「メール→ドメイン→取引先」のルールを決める

取り込む顧客データを、まずメールアドレス、次にドメイン、最後に取引先の順で照合し、見つからなければ新規作成する判定の流れを示した図。

どの経路から入ったデータも、まずは見込み客に登録します。そして見込み客の登録をきっかけに、ワークフローで次の処理を動かします。

  1. メールアドレスで、既存の連絡先と見込み客を探す
  2. 同じメールアドレスがあれば、見込み客を「統合済み」にして、既存レコードを残す（空欄の補完は人が確認して行う）
  3. 同じメールアドレスがなければ、メールドメインで取引先を探す
  4. 同じドメインの取引先が1件だけあれば、その取引先の連絡先として関連付ける
  5. 同じドメインの取引先がなければ、見込み客のままにする
  6. 判断がつかないもの（候補が複数ある、メールがないなど）は、人が判定する

統合した結果と、作成・更新したレコードへのリンクは、表計算シートに出力します。自動処理に任せきりにせず、人が見直して、必要ならやり直せるようにするためです。重複の候補を自動で統合せず、人の判断に回す考え方は「CRMの重複チェックは「自動マージしない」設計にする」で詳しく扱っています。

メールドメインが同じなら、同じ会社と見てよい？

ドメインで取引先を探すときは、次の点に気をつけます。

  • フリーメールや携帯キャリアのドメインは使わない。別々の個人が同じドメインを使っているためです
  • 表記をそろえる。メールアドレスは小文字にし、取引先側のドメインは「https://」「www.」やパス部分を取り除いた形で持ちます
  • 同じドメインの取引先が複数ある場合は自動で決めない。グループ会社や部署ごとに取引先を分けているケースです

取引先そのものの重複は、メールドメインだけでは解消しきれません。検討の中では、取引先を作った後に法人番号（国税庁が法人ごとに付ける13桁の番号）を入力してもらい、その入力をきっかけに取引先を統合する案も出ました。法人番号は会社ごとに一意なので、社名の表記ゆれに左右されません。

Delugeの実装例

見込み客の作成時に動くワークフローの関数の例です。項目名は一般的な名前に置き換えています。取引先には Email_Domain、見込み客には Merge_Status（統合状態）と Merge_Note（メモ）のカスタム項目を用意する前提です。

void automation.MergeNewLead(String leadId)
{
	lead = zoho.crm.getRecordById("Leads",leadId.toLong());
	email = ifnull(lead.get("Email"),"").trim().toLowerCase();
	if(email == "" || !email.contains("@"))
	{
		zoho.crm.updateRecord("Leads",leadId.toLong(),{"Merge_Status":"要確認","Merge_Note":"メールアドレスがありません"});
		return;
	}
	// 1. 同じメールの連絡先
	contacts = zoho.crm.searchRecords("Contacts","(Email:equals:" + email + ")");
	if(contacts.size() == 1)
	{
		contactId = contacts.get(0).get("id");
		zoho.crm.updateRecord("Leads",leadId.toLong(),{"Merge_Status":"統合済み","Merge_Note":"連絡先 " + contactId + " と同じメール"});
		return;
	}
	if(contacts.size() > 1)
	{
		zoho.crm.updateRecord("Leads",leadId.toLong(),{"Merge_Status":"要確認","Merge_Note":"同じメールの連絡先が複数あります"});
		return;
	}
	// 2. 同じメールの別の見込み客
	leads = zoho.crm.searchRecords("Leads","(Email:equals:" + email + ")");
	otherLeads = List();
	for each l in leads
	{
		if(l.get("id").toString() != leadId)
		{
			otherLeads.add(l);
		}
	}
	if(otherLeads.size() > 0)
	{
		zoho.crm.updateRecord("Leads",leadId.toLong(),{"Merge_Status":"要確認","Merge_Note":"同じメールの見込み客があります"});
		return;
	}
	// 3. ドメインで取引先を探す（フリーメールは除外）
	domain = email.getSuffix("@");
	freeDomains = {"gmail.com","yahoo.co.jp","outlook.jp","outlook.com","hotmail.com","icloud.com","docomo.ne.jp","ezweb.ne.jp","softbank.ne.jp"};
	if(freeDomains.contains(domain))
	{
		zoho.crm.updateRecord("Leads",leadId.toLong(),{"Merge_Status":"見込み客のまま","Merge_Note":"フリーメールのため取引先照合なし"});
		return;
	}
	accounts = zoho.crm.searchRecords("Accounts","(Email_Domain:equals:" + domain + ")");
	if(accounts.size() == 1)
	{
		accountId = accounts.get(0).get("id");
		newContact = Map();
		newContact.put("Last_Name",lead.get("Last_Name"));
		newContact.put("First_Name",lead.get("First_Name"));
		newContact.put("Email",email);
		newContact.put("Phone",lead.get("Phone"));
		newContact.put("Department",lead.get("Department"));
		newContact.put("Title",lead.get("Designation"));
		newContact.put("Account_Name",{"id":accountId});
		created = zoho.crm.createRecord("Contacts",newContact);
		zoho.crm.updateRecord("Leads",leadId.toLong(),{"Merge_Status":"統合済み","Merge_Note":"取引先 " + accountId + " の連絡先 " + created.get("id") + " を作成"});
	}
	else if(accounts.size() > 1)
	{
		zoho.crm.updateRecord("Leads",leadId.toLong(),{"Merge_Status":"要確認","Merge_Note":"同じドメインの取引先が複数あります"});
	}
	else
	{
		zoho.crm.updateRecord("Leads",leadId.toLong(),{"Merge_Status":"見込み客のまま","Merge_Note":"一致する取引先なし"});
	}
}

zoho.crm.searchRecords の検索条件の書き方は、Zoho CRMのAPIドキュメント（Search Records）で確かめられます。この例では、同じメールの連絡先が見つかった場合も既存レコードの書き換えはせず「統合済み」の印を付けるだけにしています。空欄の補完や、統合済みの見込み客の削除は、統合結果を人が確かめてから行う運用にすると安全です。フリーメールの一覧は例なので、自社のデータに合わせて足してください。

手順3：一括取込の入口は「表計算シート＋ボタン」にする

営業担当や代表は、日ごろからCRMの画面を開く習慣がないことが少なくありません。そこで、メールやチャットでやり取りした顧客の情報や、名刺アプリから書き出したCSVは、使い慣れた表計算シートに貼り付け、メニューのボタンを押すとZoho CRMへ取り込まれる入口にしました。処理はGoogle Apps Script（GAS）で書きます。

シートの構成

  1. 入力シート
    • 入力する列：会社名、会社名カナ、法人番号、姓、名、部署、役職、メールアドレス、会社電話、携帯電話、FAX、郵便番号、番地、市区町村、都道府県、URL。必須は会社名・姓・メールアドレスの3つ
    • 自動で書き込む列：処理状態（未処理／処理中／完了／エラー）、処理結果（エラー内容など）、Zoho取引先ID、Zoho連絡先ID
  2. 処理ログシート：処理日時、会社名、氏名、成功かエラーか、エラーの詳細、作成されたレコードへのリンク
  3. 設定シート：まとめて処理する件数、エラーを知らせる宛先など

入力する列と自動で書き込む列をはっきり分けるのがポイントです。人が触る場所とスクリプトが書く場所が混ざると、上書き事故が起きます。認証情報はシートに書かず、スクリプトのプロパティに保存します。

取り込むときの検証と変換

取り込み前に、次の検証をします。エラーの行は処理状態を「エラー」にして内容を書き込み、次の行へ進みます。

  • 必須の3項目（会社名・姓・メールアドレス）が入っているか
  • メールアドレスの形式が正しいか
  • 法人番号がハイフンを除いて13桁か

表記もここでそろえます。メールアドレスは小文字に、法人番号はハイフンを除去、「（株）」は「株式会社」に、URLは「https://」付きにそろえます。

function validateRow(row) {
  const errors = [];
  if (!row[0]) errors.push('会社名が未入力');
  if (!row[3]) errors.push('姓が未入力');
  if (!row[7]) errors.push('メールアドレスが未入力');
  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  if (row[7] && !emailRegex.test(String(row[7]).trim())) {
    errors.push('メールアドレスの形式が不正');
  }
  if (row[2] && String(row[2]).replace(/-/g, '').length !== 13) {
    errors.push('法人番号は13桁で入力してください');
  }
  return errors;
}

function normalizeCompanyName(name) {
  if (!name) return null;
  return String(name).replace(/（株）|\(株\)/g, '株式会社').replace(/　/g, ' ').trim();
}

まとめて処理し、失敗に備える

行は小分けにして処理し（設計時は50件ずつを想定）、一時的なAPIエラーには間隔を倍にしながら3回まで再試行します。呼び出し回数の制限に当たったときは、しばらく待ってから再開します。処理が終わったら、設定したアドレスに完了の通知を送ります。

シートから入ったデータも、手順2のワークフローを通るので、名寄せのルールは経路によらず同じです。入口がいくつあっても、判断の基準を1か所にまとめておくことが重複を防ぐ一番の近道です。

経路ごとの入れ方の整理

経路 入れ方
資料請求・問い合わせフォーム CRMと連携するフォームから見込み客へ直接登録
名刺アプリ CSVで書き出して表計算シートへ貼り付け、ボタンで取り込み。件数が多い場合は自動同期も検討（連携方法の比較は「ZOHO CRMと名刺管理アプリの連携の比較３選」）
メール・チャットでのやり取り 表計算シートへ転記してボタンで取り込み。メールソフトのCRMアドオンから登録する方法もある
既存ツールの過去データ 項目をそろえてから、最初に一度だけまとめて取り込む

統合を始める前のチェックリスト

  • 見込み客・取引先・連絡先の定義を、社内で言葉にして共有したか
  • 取引先に属性（顧客／パートナー／ベンダーなど）とメールドメインの項目を用意したか
  • 名寄せの順番（メール→ドメイン→人の判定）を決めたか
  • フリーメールなど、ドメイン照合から外すドメインの一覧を作ったか
  • 自動で決めきれないときに「要確認」で止める条件を決めたか
  • 統合結果をシートに出力し、人が見直せるようにしたか
  • 入力シートで、人が書く列とスクリプトが書く列を分けたか
  • 認証情報をシートに書いていないか

顧客データの統合は、一度きれいにして終わりではありません。新しいデータが毎日入ってくる中で、重複を増やさない仕組みを先に作ることが、メールの送り分けや営業の引き継ぎを支える土台になります。

散らばった顧客データの統合設計は、Zoho導入支援・コンサルティングでご相談いただけます。

よくある質問

顧客データの統合は、どのモジュールから整えるべきですか？

取引先からです。取引先に「顧客・パートナー・ベンダー」などの属性とメールドメインの項目をそろえると、連絡先の関連付けと見込み客からの名寄せの両方がこの情報を基準に動けます。見込み客を先に整えても、つなぎ先の取引先が重複していると結局やり直しになります。

メールドメインが同じなら、同じ会社と判断してよいですか？

企業の独自ドメインであれば、多くの場合は同じ会社と判断できます。ただしフリーメールや携帯キャリアのドメインは別の個人が共有しているので、照合に使ってはいけません。また、グループ会社で同じドメインを使っている場合は取引先の候補が複数出るため、自動で決めずに人が判断する設計にします。

見込み客モジュールは必ず使う必要がありますか？

必須ではありません。当社が設計に関わった会社でも、運用を簡単にするため取引先と連絡先だけを使い、見込み客は取引先の分類として扱う案を検討しました。ただ、どの経路のデータもいったん受け止める「受け皿」として見込み客を使うと、名寄せ前のデータと整ったデータを分けて管理しやすくなります。

表計算シートから取り込む方法と、CRMの標準インポートはどう違いますか？

標準のインポートは一度に大量のデータを入れるのに向いています。一方、営業担当や代表が日々把握した顧客情報を少しずつ入れる場面では、使い慣れたシートに貼ってボタンを押すだけの入口のほうが続きます。処理状態や作成されたレコードIDをシートに書き戻せるので、入れた本人が結果を確かめられる点も違います。

自動で統合した結果が間違っていたらどうしますか？

統合した結果と対象レコードへのリンクを表計算シートに出力しておき、人が見直してやり直せるようにします。自動処理だけで完結させず、確認の場を必ず用意するのが前提です。