CRMの取引先階層設計｜本社・支店・グループ会社をどう管理するか
CRMで同じ企業の本社、支店、子会社が別々に登録されていると、営業担当は「どの取引先へ商談を付けるか」「売上をどこへ集計するか」で迷います。反対に、すべてを本社の1レコードへまとめると、支店ごとの担当者、訪問履歴、契約、問い合わせが混ざり、現場の状況を追えません。
必要なのは、会社名が似ているレコードを機械的にまとめることではありません。法人として同じか、業務上は別拠点か、契約や請求を独立して持つかを判断し、親子関係と責任の境界をCRMへ残すことです。
結論として、CRMの取引先階層は「法人」「拠点」「取引単位」を分けて設計します。法人番号などで同一法人を確認し、本社・支店・子会社は契約主体、請求先、商談責任、活動履歴を独立管理する必要がある場合に別レコードへ分けます。そのうえで親取引先、階層種別、集計先、有効期間を持たせます。取引先階層は「見た目の組織図」ではなく、「どの単位で契約・請求・商談・売上を持つか」を再現できた時に完成します。
本記事のポイント
- 取引先レコードは、法人番号で確認する法人、訪問や利用を管理する拠点、契約・請求・商談の単位を混ぜずに設計する。
- 本社と支店を分けるかは住所ではなく、契約主体、請求先、商談責任、担当者、活動履歴を独立管理する必要があるかで判断する。
- 階層導入は親子リンクの設定で終えず、重複・循環・親なし・二重集計を検査し、組織再編や統廃合のたびに履歴付きで見直す。
取引先階層は法人・拠点・取引単位を分けて考える
取引先階層は、親会社を頂点に会社名を並べるだけの機能ではありません。CRM上の取引先レコードが何を表すかを決め、レコード同士の関係を親子リンクで表現する設計です。まず、次の3単位を分けて考えます。
| 管理単位 | 識別の例 | 主に持たせる情報 | 混ぜたときの問題 |
|---|---|---|---|
| 法人 | 法人番号、登記上の名称、本店所在地 | 契約主体、与信、法務確認、全社属性 | 別法人の契約や売上を同じ会社として扱う |
| 拠点 | 拠点ID、住所、電話番号、店舗・支店名 | 訪問先、利用場所、担当者、活動履歴 | 本社と支店の窓口や対応履歴が混ざる |
| 取引単位 | 契約番号、請求先コード、購買組織 | 商談、契約、請求、更新、売上 | 誰が決裁し、どこが支払うか分からなくなる |
国税庁の法人番号公表サイトでは、法人番号は法人等に付く13桁の番号で、商号または名称、本店または主たる事務所の所在地、法人番号の基本3情報が公表されています。したがって法人番号は「同じ法人か」を確認する軸として有効ですが、同じ法人の支店や店舗を区別する拠点IDにはなりません。CRMでは法人IDと拠点IDを別に持ち、支店レコードから法人レコードを参照できるようにします。
この分離は、会社マスタの正式名称・会社ID・支店管理を土台にします。会社マスタが「レコードを一意に識別する規則」なら、取引先階層は「識別済みのレコード同士をどの関係で結び、どこへ情報を集計するか」を決める規則です。
名寄せと階層管理は別の処理
名寄せは、同じ人物や同じ法人を重複登録していないかを判定する処理です。階層管理は、別レコードとして残す本社、支店、子会社の関係を表す処理です。子会社は社名やドメインが似ていても別法人であり、支店は名称や住所が違っても本社と同じ法人である場合があります。
そのため、名寄せの結果をそのまま統合へ使わないでください。同一法人の重複レコードなら統合候補ですが、本社と支店を業務上別管理しているなら、同一法人でも拠点レコードとして残します。人物・法人の同一性を判定する順序は、CRM名寄せの最小ルールと組み合わせると整理しやすくなります。
本社・支店・グループ会社を分ける判断表
住所が違うだけで取引先を増やすと重複が増え、法人番号が同じだからと1件へまとめると拠点運用が見えなくなります。分ける基準は、契約、請求、商談、担当、活動、権限のどれを独立管理する必要があるかです。
| 顧客の状態 | 推奨する持ち方 | 親子関係 | 判断理由 |
|---|---|---|---|
| 単一法人・単一拠点 | 取引先1件 | 不要 | 契約、請求、担当、活動を同じ単位で管理できる |
| 同一法人で支店ごとに訪問・担当が異なる | 法人レコード＋拠点レコード | 本社法人を親、各支店を子 | 法人は同じでも窓口と活動履歴を分ける必要がある |
| 同一法人で支店ごとに独立契約・請求 | 拠点ごとに取引先レコード | 法人または本社を親 | 契約、請求、更新、商談を拠点単位で管理する |
| 親会社と子会社が別法人 | 法人ごとに取引先レコード | 資本・企業グループ関係を親子で表す | 与信、契約、個人情報、売上責任を別法人として扱う |
| 持分法会社・共同出資先 | 別法人のまま関連付ける | 単純な親子にせず関係種別を持つ | 1社だけを親にすると実際の関係を誤って表す |
| ブランド・事業部だけが異なる | 原則は同一法人、必要なら事業単位を別オブジェクト化 | 法人階層へ無理に入れない | ブランド名を別法人と誤認すると契約と集計が崩れる |
| 販売代理店経由で利用企業が別 | 契約先と利用先を別レコード | 親子ではなく役割付き関連 | 商流と企業グループは異なる関係だから |
Salesforceの公式資料では、子会社を表す場合は子の取引先にParent Accountを設定し、同一企業の複数拠点はAccount Siteで区別する考え方が案内されています。HubSpotの標準Parent company／Child companyラベルでは、親は複数の子を持てますが、子は標準関係上1つの親にだけ関連付けられます。どのCRMでも、製品機能へ合わせる前に、自社が表したい関係が「法人の親子」「拠点」「販売関係」「契約関係」のどれかを確定してください。
子会社、支店、代理店、取引先をすべて同じ「親子」へ詰め込むと、親をたどっただけでは関係の意味が分かりません。最低でも階層種別、関係の開始日・終了日、集計対象か、契約を引き継ぐかを持たせます。循環参照を防ぐため、子から親をたどった先に自分自身が現れる関係は保存できないようにします。
契約・請求・商談・売上の集計責任を決める
階層を作っても、商談や売上が自動で正しく集計されるとは限りません。レコードを親子にしただけで、子会社の商談を親会社の実績として扱ってよいとは限らないためです。集計する数字ごとに、直接値と階層集計値を分けます。
| 情報 | 記録するレコード | 親へ集計するか | 確認する責任 |
|---|---|---|---|
| 基本契約・利用規約 | 署名した法人または契約拠点 | 参照は可、原本は移さない | 営業責任者・法務 |
| 請求・入金 | 請求書の宛先と債権を持つ単位 | 管理会計上の集計だけ別表示 | 経理・営業管理 |
| 商談 | 決裁と受注責任を持つ取引先 | グループ案件ビューで集計 | 商談オーナー |
| 活動履歴 | 実際に接触した法人・拠点 | 親から閲覧できるようにする | 顧客主担当 |
| 問い合わせ・障害 | 利用場所または契約窓口 | 重大度に応じて親へ可視化 | CS・サポート |
| グループ売上 | 各契約先の実績を保持 | 親の集計項目へ重複なく加算 | 営業企画・経理 |
「直接売上」と「子孫を含む売上」を同じ項目名で表示すると、親自身の売上と階層全体の売上を混同します。たとえば、親会社の直接売上が1,000万円、子会社2社の売上が各500万円なら、親レコードには直接1,000万円、階層集計2,000万円と分けて表示します。子の数字を親へコピーしたうえで全レコードを合計すると二重計上になるため、計算元と表示先を明示します。
商談をどこへ付けるかは、最終決裁者だけで決めません。契約する法人、請求を受ける法人、利用する拠点、提案を主導する本社を関連先として分け、商談の主取引先は受注責任の単位にします。全社提案では親取引先に「グループ案件」を置き、子会社・支店の個別商談と関連付ける方法もあります。
取引先レコードに何を直接持たせ、商談や活動を別データとして持たせるかは、顧客データ設計で列を増やす前に決めるルールと合わせて整理してください。階層項目を増やす前に、その項目がどの意思決定に使われるかを固定すると、形だけの親子リンクを減らせます。
CRMの取引先階層を6ステップで作る
既存CRMへ階層を導入するときは、いきなりParent Accountを一括設定しません。重複レコードを整理し、法人と拠点の区分、関係種別、集計ルールを決めた後、少数の企業グループで試します。
- 既存取引先を棚卸しする：取引先ID、正式法人名、法人番号、住所、ドメイン、契約番号、請求先、担当者、進行商談を抽出する。
- 法人と拠点を分類する：同一法人の重複、同一法人の別拠点、別法人のグループ会社、ブランド・事業部を分ける。
- 親子関係と関係種別を決める：親取引先、子取引先、法人・拠点・資本関係、開始日、終了日、根拠を登録する。
- 責任と集計を設計する：契約、請求、商談、活動、問い合わせ、売上をどの単位へ記録し、どこまで親へ見せるか決める。
- 試験移行して検査する：代表的な企業グループで、重複、親なし、循環、権限欠落、二重集計、検索性を確認する。
- 公開して維持する：新規登録、組織再編、合併、分社、支店閉鎖、担当変更の更新責任と定期点検を運用へ組み込む。
| 工程 | 完了条件 | 止める条件 |
|---|---|---|
| 棚卸し | 全レコードに判定根拠を付けられる | 会社名だけで同一法人と推測している |
| 分類 | 法人・拠点・取引単位を区別できる | 支店と子会社を同じ扱いにしている |
| 関係設定 | 関係種別、開始日、根拠がある | 親子リンクだけで意味が分からない |
| 集計設計 | 直接値と階層集計値を区別できる | 親子の売上を二重計上する |
| 試験移行 | 重複・親なし・循環・権限を検査済み | 本番全件へ一括反映している |
| 運用開始 | 更新担当、承認、点検周期が決まる | 組織変更を営業担当の気付きに任せる |
既存データの整理では、法人番号、正式名称、所在地を照合し、候補を機械抽出しても最終判断を残します。Salesforce取引先データのクレンジング事例で扱うように、更新前には照合根拠、既存値との差分、上書き範囲、レビュー担当を確認してください。
階層を壊さない登録・変更ルールを決める
取引先階層は、導入時より変更時に壊れます。支店の新設、社名変更、本店移転、合併、会社分割、事業譲渡、持株会社化が起きたとき、現在の親を上書きするだけでは過去の商談や売上を当時の組織で説明できません。
関係には有効開始日と終了日を持たせ、変更前の関係を履歴として残します。合併で法人が消滅した場合も、旧レコードを削除して新会社へ商談を移すのではなく、閉鎖日、承継先、移したデータ、残した履歴を記録します。国税庁法人番号公表サイトでは名称・所在地の変更履歴や、合併による解散等の情報も確認できるため、変更の根拠を照合できます。
| 検査項目 | 検出する状態 | 対応 |
|---|---|---|
| 親なし | 子会社・支店なのに親取引先が空 | 根拠を確認し、期限付きの確認キューへ入れる |
| 循環 | Aの親がB、Bの上位にAが現れる | 保存を拒否し、関係の根拠を再確認する |
| 重複 | 同じ法人・拠点が複数レコードに存在 | 活動・商談・契約への影響を見て統合する |
| 種別不明 | 親子関係に法人・拠点・商流の区別がない | 関係種別と集計可否を補完する |
| 二重集計 | 親の直接値へ子の値をコピーし、さらに合計 | 計算元を固定し、直接値と階層値を分ける |
| 権限欠落 | 親は見えるが子の商談が見えない | 階層表示とレコード共有を別々に点検する |
| 期限切れ | 統廃合後も旧関係が有効 | 終了日と承継先を登録する |
階層が表示できることと、関連レコードを閲覧できることも同じではありません。Salesforceの公式資料では、階層には閲覧権限のない取引先が表示されないと説明されています。Microsoft Dynamics 365の公式資料でも、管理者が階層を設計・公開し、利用者は関連会社、地域拠点、支店を階層表示します。表示列、検索、編集、共有権限を分けてテストしてください。
月次では親なし、循環、重複、種別不明、二重集計を確認し、四半期では主要グループの契約・請求・商談責任を営業企画と経理で見直します。合併、分社、支店閉鎖、大型契約、担当組織の変更があれば定例を待たずに更新します。
製品ごとの現行仕様と法人情報の確認方法は、次の公式情報で確認できます。
- Salesforce Help: Guidelines for Creating Accounts：子会社のParent Accountと、同一企業の複数拠点を区別するAccount Siteの考え方を確認できます。
- Salesforce Help: Considerations for Using Account Hierarchy：階層表示、権限、件数、拠点の扱いに関する現行仕様を確認できます。
- HubSpot Knowledge Base: Add a parent or child company：親会社・子会社ラベル、手動設定、一括インポート、親子関係の制約を確認できます。
- Microsoft Learn: View and use a visual hierarchy：関連会社、地域拠点、支店を含む階層の表示と管理者設定を確認できます。
- 国税庁法人番号公表サイト: 法人番号とは：法人番号の対象、基本3情報、検索・API・ダウンロード機能を確認できます。
よくある質問
CRMの取引先階層とは何ですか？
本社、支店、子会社などの取引先レコードを親子関係で結び、企業グループ全体と各法人・拠点の情報を行き来できるようにする設計です。組織図の表示だけでなく、契約、請求、商談、活動、売上の記録先と集計先を決める必要があります。
本社と支店は別取引先にすべきですか？
支店ごとに担当者、訪問履歴、商談、契約、請求、問い合わせを独立管理する必要があるなら別レコードにします。法人として同一で、すべて本社一括管理なら1つの取引先に拠点情報を持たせる方法もあります。住所だけで分割せず、業務責任の単位で判断します。
グループ売上や商談をどう集計しますか？
商談と売上は契約・受注責任を持つ法人や拠点へ記録し、親では子孫を含む階層集計値を別項目で表示します。親の直接売上と階層合計を分け、子の実績を親へコピーしてから再集計する二重計上を避けます。
名寄せと階層管理はどう分けますか？
名寄せは同じ人物・法人の重複を見つけて統合候補にする処理、階層管理は別レコードとして残す法人・拠点の関係を表す処理です。同じ法人の支店を業務上別管理する場合は統合せず、法人レコードの子として関連付けます。
子会社の商談を親会社の商談として登録してよいですか？
契約主体が子会社なら、主取引先は子会社にします。親会社が全社交渉を主導する場合は、親にグループ案件を置いて子会社の個別商談を関連付ける方法があります。決裁者だけでなく、契約・請求・受注責任を確認してください。
取引先階層は何段まで作るべきですか？
製品上の上限まで深くするのではなく、営業が関係を説明でき、契約・集計に使う段数に限定します。持株会社、事業会社、地域会社、拠点のように4段以上になる場合は、表示性能、検索性、権限、集計時間を実データで試験してください。
まとめ
CRMの取引先階層は、法人、拠点、取引単位を分け、別レコードとして残す本社・支店・グループ会社を親子関係で結ぶ設計です。本社と支店を分けるかは、住所ではなく、契約主体、請求先、商談責任、担当者、活動履歴を独立管理する必要があるかで判断します。
既存取引先を棚卸しし、法人と拠点を分類し、関係種別と有効期間を付け、契約・請求・商談・売上の記録先と集計先を決めてから試験移行します。運用開始後も親なし、循環、重複、種別不明、二重集計、権限欠落を点検すれば、企業グループ全体の把握と各拠点の営業活動を両立できます。
