Zoho CRMの見込み客と連絡先の使い分けとは、「まだ取引が始まっていない相手」を見込み客に、「取引が始まった相手（会社の担当者）」を連絡先に入れ、見込み客から連絡先へ変換して移していく標準の考え方です。会社を相手にする営業ではうまく働きますが、外国人材の紹介・支援のように「会社」と「人材」の2種類を扱い、人材の側にも「候補者」と「支援中の人」という段階がある業務では、この使い分けをそのまま当てはめると迷いが生じます。
この記事では、中小の人材紹介企業でのZoho CRM構築支援（外国人材の紹介・支援の業務）で、データの持ち方を何度も見直した経緯と、そこから整理した判断軸を紹介します。この案件は構築中のため、成果ではなく「設計の考え方」と「試作して分かったこと」として書いています。
なぜ外国人材の管理で、データの持ち方に迷うのか
外国人材の紹介・支援では、CRMに入る「人」が大きく2種類あります。
- 受け入れ企業の担当者：求人の依頼を受け、紹介料や支援料を請求する相手です
- 外国人材：求人に応募する候補者で、内定後は入国や在留の手続きを経て、就業中も定期的な面談などの支援が続きます
さらに外国人材には、段階によって必要な情報が大きく変わるという特徴があります。応募の段階では、氏名・国籍・在留資格の種別・日本語能力・経験のある分野など、絞り込みに使う情報が中心です。支援が始まると、在留カード番号、旅券の有効期限、在留期間の満了日、雇用契約の期間、就業先の事業所といった、手続きと期限の管理に使う情報が加わります。
そして、人と求人をつなぐのが「選考」です。この案件では、選考を「人材×求人×ステータス」として持つカスタムモジュールにしていました。退職した方が別の会社で再び働く場合も、選考がもう1件増えるだけで、履歴として残ります。
この「2種類の人」「段階で変わる情報」「人にぶら下がる選考」の3つが、どこに箱を分けるかの判断を難しくします。
外国人材は見込み客・連絡先・カスタムモジュールのどれに入れるか：検討した3つの構造
支援の中で、実際に次の3つを比べました。
| 構造 | 内容 | 主な利点 | 主な弱点 |
|---|---|---|---|
| A. 見込み客→連絡先に変換 | 候補者を見込み客に入れ、支援が始まったら連絡先に変換する | 候補者と支援中の人が、画面の上ではっきり分かれる | 変換は元に戻せない。選考が見込み客側と連絡先側に割れる |
| B. 連絡先に集約 | 人材は最初から連絡先に入れ、ステータスで表示する項目を切り替える | 人材の情報が1か所にまとまり、検索・集計がしやすい | 企業の担当者と外国人材が同じ連絡先に混ざる |
| C. 人材専用モジュール | 人材をカスタムモジュールに1人1件で入れ、見込み客と連絡先は受け入れ企業専用にする | 人と会社が分かれ、人材の情報も1か所にまとまる | 標準の変換は使えない。連携機能が使えるか、事前の確認が必要 |
結論としては、Cの形で進めています。ただ、最初からCを選べたわけではありません。
判断が揺れた経緯と、それぞれで分かったこと
1. 候補者と支援中の人を箱で分ける案（A）を試作した
当社は当初、Bに近い「連絡先の中で一覧と画面の表示を分ける」形を提案していました。これに対しお客様は、応募しただけの人と支援中の人では入力する内容も探し方も違うので、箱を分けて管理したいとお考えでした。そこでAを、本番に影響しない検証用の環境（サンドボックス）に試作しました。
試作で確かめられたことは次の3つです。
- 見込み客のレイアウトごとに、変換先の連絡先レイアウトを指定できる。 外国人材の見込み客を変換すると、連絡先の「外国人材」用レイアウトに入り、国籍や在留資格の種別などの項目も引き継がれました
- 変換は元に戻せない。 変換すると元の見込み客は消えます。退職された方を見込み客の側へ戻す運用は、この構造ではできないと分かりました。公式ヘルプでも、連絡先や取引先に変換した見込み客は元に戻せないとされています（Converting Leads）
- 見込み客の「会社」欄は、レイアウトから外せない。 必須を外して空欄で登録することはできますが、画面には残ります。外国人材には不要な項目が、常に見えてしまいます
2. 選考を人に紐付けると、Aでは記録が2か所に割れる
次に効いてきたのが、選考の紐付け先です。Aでは、応募の段階の選考は見込み客に、退職後に再紹介する際の選考は連絡先に付くことになります。すると、同じ「選考」の記録が2つの箱に分かれ、「この分野の内定は何件か」のような集計や、条件での絞り込みが正しくできなくなります。
これは、箱を「状態」で分けたときに起きる典型的な問題です。状態が変わるたびに関連する記録の置き場所まで変わるので、後から横断して見ることができなくなります。
3. Bを推したが、人と会社が混ざることを避けたいというご意向だった
お客様に記入していただいたヒアリングシートを見ると、絞り込みの条件が非常に多いことも分かりました。人材の母集団を2つの箱に分けると、条件を組み合わせたレポートが正しく出せなくなる恐れがあります。そこで当社はBを改めて提案しました。
これに対し、お客様のご意向ははっきりしていました。連絡先に、受け入れ企業の担当者と外国人材が混ざる状態は避けたい。人と会社では、貯めていく情報も、入力する情報も、検索する情報も、今後カスタマイズしたいことも、まったく違うからです。
4. 「分けたいのは人と会社」と整理し直してCに落ち着いた
ここで、お客様が分けたかったのは「候補者と支援中の人」ではなく、根本的には「人と会社」だったと整理できました。一方、当社が守りたかったのは「人材の情報は1か所にまとめる」ことです。この2つは両立します。
- 人材は専用のカスタムモジュールに、候補者として登録してから支援が終わった後まで1人1件で入れる
- 選考・立替経費・学習履歴・メモや活動は、この人材のレコードに紐付ける
- 見込み客は受け入れ企業の見込み専用にし、取引が始まったら取引先（会社）と連絡先（企業の担当者）に変換する
振り返ると、短い期間に「分ける」「まとめる」「別の形でまとめる」と案が変わりました。構造の案を出す前に、次の章の判断軸を先にお客様と合わせておけば、往復は減らせたはずです。
見込み客と連絡先を分けるかどうかは、何で判断するか
同じような業務でデータの持ち方を決めるときは、次の6つを順に確かめることをおすすめします。
- 貯める情報・検索の条件・今後のカスタマイズが別物か。 別物なら、箱を分ける理由になります。この案件では「人」と「会社」がこれに当たりました
- 関連する記録（選考・請求・面談など）の紐付け先は1か所にできるか。 状態で箱を分けると、関連する記録の置き場所が割れます
- 状態は行ったり来たりするか。 退職して再び候補者になる、のような行き来がある境目に、元に戻せない変換を置かないようにします
- 一覧やレポートの母集団はどこか。 「候補者と支援中の人をまとめて条件で探す」ことがあるなら、両者は同じ箱にあるべきです
- 標準機能に何を頼るか。 見込み客の変換、メール、電話システムの通話記録の自動の紐付けなどが、カスタムモジュールでも使えるかを、移す前に確認します
- 不要な標準項目を消せるか。 見込み客の「会社」欄のように、外せない項目が画面に残ることを受け入れられるか
1と2がぶつかったときは、1で「誰と誰を分けるか」を決め、2で「分けた箱の中はまとめる」と考えると整理しやすくなります。
1つの箱の中で「候補者」と「支援中」を扱う作り方
Cの形では、候補者と支援中の人が同じ箱に入ります。そこで、状態は項目で持ち、表示と一覧で分けます。
支援ステータスは選考から自動で切り替える
支援ステータスを担当者が手で変える運用にすると、選考のステータスと食い違う二重管理が起きます。この案件でも、初期にはチェックボックスを手で付ける方式でしたが、早い段階で自動判定に切り替えました。作り方は次のとおりです。
- 選考に、人材モジュールへのルックアップ項目（候補者）を作ります
- 人材モジュールに、集計項目（関連するレコードの件数や合計を自動で計算する項目）を2つ作ります
- 支援中の選考数：選考ステータスが「内定／入管審査準備中／入管審査中／入国待ち／配属済み」の件数
- 退職の選考数：選考ステータスが「退職」の件数
- ワークフロールールを作り、実行条件に集計項目の更新を指定して、支援ステータスを書き換えます
- 支援中の選考数が1件以上 → 支援対象
- 支援中の選考数が0件（または空）で、退職の選考数が1件以上 → 退職
- それ以外 → 候補者
1人が複数の選考を持っていても、1件でも支援中のものがあれば「支援対象」になります。当社の検証環境（サンドボックス）では、選考のステータスを変えてから画面に反映されるまで数秒かかりました。
注意点が1つあります。当社が確認した時点では、集計項目は該当が0件のとき「0」ではなく空になりました。ワークフローの条件を「0件のとき」だけで書くと、空のレコードが漏れます。条件には「空」も含めてください。
表示する項目は、支援が始まってから増やす
支援が始まる前の方には、在留カードや雇用契約などの項目を表示しないよう、レイアウトルール（入力内容に応じて項目やセクションの表示を切り替える機能）で制御しています。入力する方が「今は何を入れればいいか」で迷わないようにするためです。退職された方には、次のお仕事を紹介するときに見返せるよう、支援開始後の項目も表示したままにする案でお客様に確認しています。表示しない設定にしても、入力済みのデータは消えません。
よく使う一覧を、ステータスで用意する
- 支援対象者一覧：支援対象の方だけ（退職された方は出さない）
- 候補者プール：候補者と退職された方（退職された方も、次の紹介の候補として出す）
- 退職者一覧：退職された方だけ
- 在留期限が近い方：支援対象の方のうち、在留期間の満了日が近い方
在留カードの情報は「1人1件」、履歴は選考に持たせる
検討の途中で、支援の情報を「1人1件」で持つか、「支援の案件ごとに1件」で持つかも論点になりました。在留カード番号や旅券番号は人に属する情報なので、案件ごとに複数持つと、片方だけ更新される事故が起きます。一方、「どの会社で、いつからいつまで働いたか」という履歴は、すでに選考が持っています。そこで、人に属する情報は人材モジュールに1件、会社ごとの履歴は選考で持つ、と役割を分けました。
構造を決めた後も、運用ルールで決めることが残る
データの持ち方が決まっても、次のような点は「どこに入力するか」を運用ルールとして決めておく必要があります。
- 支援の開始・終了を、必ず選考で記録するか。 転職の際に選考を通さず所属先だけを入れ替える運用があると、自動判定がずれます
- 支援が終わった方を「退職」として分けるか、「候補者」に戻すか。 支援したことがある方とない方を一覧で分けたいかどうかで決まります
- 人材に関する件で、受け入れ企業とやり取りした記録をどちらに残すか。 たとえば、本人に関する手続きの連絡が受け入れ企業から来る場合です。決めておかないと、担当者ごとに記録先がばらつき、二重管理になります
人材紹介業でZoho CRMを使う全体像は「【人材紹介業向け】専用ツールは高い？Zoho CRMで実現する「低価格×柔軟」な一元管理術」、人材と求人の組み合わせをCRMの中で探す仕組みは「人材紹介事業のためのZoho CRM内AIマッチングエンジンとは」で紹介しています。見込み客と連絡先・取引先をどの順で照合するかは「顧客データ統合の進め方」で解説しています。
また、連絡先を企業の担当者専用にすると、CRMからのメールの送り先も整理しやすくなります。CRMからメールを送り始める前には、送信ドメインの認証設定も必要です。設定の基本は「Zohoのメールセキュリティ設定」で紹介しています。
まとめ
外国人材の紹介・支援でZoho CRMを使うとき、見込み客と連絡先を分けるか、まとめるかで迷ったら、まず「何と何を分けたいのか」を言葉にしてください。この案件で分けるべきだったのは、候補者と支援中の人ではなく、人材と受け入れ企業でした。
状態で箱を分けると、元に戻せない変換と、関連する記録の分散という2つの問題を抱えます。人材は専用の箱に1人1件でまとめ、状態は選考から自動で判定し、表示と一覧で分ける。この形なら、人と会社を分けて管理することと、人材の情報を1か所で探せることを両立できます。
人材紹介業のデータ構造の設計は、Zoho導入支援・コンサルティングでご相談いただけます。
よくある質問
Zoho CRMで、外国人材を見込み客に入れて、支援が始まったら連絡先に変換する運用ではいけませんか？
変換そのものはできます。当社の試作でも、見込み客のレイアウトごとに変換先の連絡先レイアウトを指定でき、国籍や在留資格などの項目も引き継がれました。ただし変換は元に戻せず、変換元の見込み客は消えます。退職した方を再び候補者として扱うような行き来がある業務では、変換を境目にすると運用が苦しくなります。
連絡先1つにまとめ、ステータスで表示項目を切り替える方法の弱点は何ですか？
受け入れ企業の担当者と外国人材が同じ連絡先に入ることです。レイアウトで入力項目は出し分けられますが、一覧・検索・メール配信の対象・今後の機能追加のたびに、両者を区別する条件が必要になります。人と会社で管理の仕方がまったく違う業務では、この混在を嫌う方が多いと感じています。
カスタムモジュールにすると、使えなくなる標準機能はありますか？
あります。たとえば、Zoho CRMの見込み客の変換で作れるのは取引先・連絡先・商談で、カスタムモジュールへは変換できません（当社が確認した時点の仕様）。電話システムの通話記録やメールの自動の紐付けが、カスタムモジュールでも使えるかは、利用している連携ごとに移す前に確認してください。
支援ステータスを自動で切り替えると、どんな点に注意が必要ですか？
支援の開始・終了を、必ず選考のステータスで記録する運用が前提になります。選考を通さずに所属先だけを入れ替えるような運用があると、ステータスが実態とずれます。そうした例外があるなら、手でも直せる形にしておきます。また、集計項目は該当が0件のとき「0」ではなく空になることがあったため、ワークフローの条件で空も扱う必要がありました。
