%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
製造業のCRMデータ設計とは、商流上の登場人物をそれぞれ独立したレコードとして持ち、その間の関係に役割の名前を付ける作業です。 商社・販売店・エンドユーザーはすべて会社オブジェクトで持ち、「発注元」「施工販売店」「使用者」といった立場は、会社の属性ではなく関連付けラベルで表します。 この形にしておくと、商社経由の売上とエンドユーザー別の納入実績を、同じデータから両方取り出せます。
製造業のCRMデータ設計とは、商流上の登場人物をそれぞれ独立したレコードとして持ち、その間の関係に役割の名前を付ける作業です。 商社・販売店・エンドユーザーはすべて会社オブジェクトで持ち、「発注元」「施工販売店」「使用者」といった立場は、会社の属性ではなく関連付けラベルで表します。 この形にしておくと、商社経由の売上とエンドユーザー別の納入実績を、同じデータから両方取り出せます。
「請求書を送る相手」と「実際に製品を使っている会社」が違う——製造業でCRMを入れると、必ずここで設計が止まります。
一般的なCRMの解説は、会社が1つ、担当者が数名、取引が1件、という前提で書かれています。ところが製造業の商流では、自社の直接の取引先は商社で、その先に販売店があり、さらにその先に実際に機械を据え付けて使うエンドユーザーがいます。引き合いはエンドユーザーから来るのに、見積書の宛先は商社です。この構造を「会社」という1つのオブジェクトだけで表現しようとすると、必ずどこかで破綻します。
つまり製造業のCRM設計は、項目を並べる作業ではありません。誰が誰に何をしているのかを、データの形で表現する作業です。ここを飛ばして項目定義から入ると、後から関係を張り直せなくなります。
この記事では、HubSpotを例に、製造業の3層構造をCRM上でどう設計するかを整理します。代理店経由の販売を行っているメーカーで管理の仕組みを作る立場の方、SFAを入れたが商流が表現できずに困っている方に向けた内容です。次の4点がわかります。
- 3層をどのオブジェクトで持つか ── 会社レコードを分けるべき理由と、分けたあとの繋ぎ方を示します
- 関連付けラベルで役割を表す ── 「商社」「販売店」「エンドユーザー」を関係の側に持たせる設計です
- 取引をどの単位で作るか ── 引き合い単位・年間単位・図番単位のどれを選ぶかの判断軸です
- 見えなくなりがちな数字の取り方 ── エンドユーザー別の売上をどう集計するかを説明します
読み終える頃には、自社の商流をCRM上でどう写し取るかのたたき台が作れる状態になります。ぜひ最後までご確認ください。
製造業のCRMが難しい本当の理由
まず、なぜ一般的なCRMの設計がそのまま当てはまらないのかを整理します。難しさの原因は営業のやり方ではなく、製造業の商流そのものにあります。
ここを言語化しないまま設計に入ると、項目は揃っているのに知りたい数字が取れない、という状態になります。
- 商流の多様さ ── 業種ごとに商流が違うため、共通のひな形では写し取れません
- 買う人と使う人の分離 ── 購買の意思決定者、発注元、使用者が別々の会社に分かれています
- 入口の複数化 ── 同じ案件が、複数の経路から別々に入ってきます
事業所の数だけ商流のパターンがある
総務省・経済産業省の集計によれば、2025年6月1日現在の製造業の事業所数は214,719事業所（個人経営を除く、前年比3.4%減）、従業者数は7,612,095人（同1.6%減）でした。
産業中分類別の上位は次のとおりです（2025年経済構造実態調査二次集計結果 製造業事業所調査 結果の概要、2026年7月29日公表）。
- 金属製品製造業 ── 29,549事業所（構成比13.8%）で最も多い
- 食料品製造業 ── 23,820事業所（同11.1%）
- 生産用機械器具製造業 ── 22,562事業所（同10.5%）
製造業と一口に言っても、金属加工と食料品と生産用機械では商流がまったく違います。
「製造業向けのCRMテンプレート」が存在しないのは、この多様さが理由です。だからこそ、自社の商流を自分で写し取る設計作業が必要になります。
「買う人」と「使う人」の分離
製造業のCRM設計を難しくしている構造は、突き詰めると1つです。購買の意思決定者、発注元、実際の使用者が別々の会社に分かれているという点です。
| 登場人物 | 役割 | CRMで見たいこと |
|---|---|---|
| 商社・卸 | 発注と支払いの窓口 | 年間の取引額、与信、担当者 |
| 販売店・代理店 | 提案と据付、保守の実行 | 販売実績、認定ランク、教育状況 |
| エンドユーザー | 実際の使用者 | 設置台数、更新時期、稼働状況 |
| 設計事務所・ゼネコン | 仕様を決める側 | どの案件で自社製品が指定されたか |
このうち売上が立つのは商社との間ですが、次の受注を生むのはエンドユーザー側の動きです。片方だけを管理していると、必ず読み違えます。
引き合いはどこから来るか分からない
同じ製品でも、引き合いの入口は複数あります。
- エンドユーザーからの直接の問い合わせ
- 販売店からの相談
- 設計事務所の指定として降りてくる案件
入口が複数あるということは、同じ案件が別々のレコードとして二重に登録される可能性があるということです。
この重複を防ぐには、案件そのものではなく「どの現場・どの設備の話か」を軸にレコードを整理する必要があります。
商社・代理店・エンドユーザーの3層をどう持つか
ここからが設計の本体です。商社・代理店（販売店）・エンドユーザーの3層を、どのオブジェクトに、どういう関係で持たせるかを決めていきます。
手順は次の2段階で、この順番を逆にすると作り直しになります。
- レコードの置き場所を決める
- 関係に名前を付ける
これは特定の企業の実装ではなく、製造業でよく出てくる商流を一般化した設計例です。
3層はすべて「会社」で持つ
結論から書くと、商社・販売店・エンドユーザーは、すべて会社オブジェクトのレコードとして独立して持ちます。カスタムオブジェクトを新設する必要はありません。
理由は3つあります。
- 同じ構造の情報を持つ ── どれも実在する法人であり、住所・電話番号・担当者という同じ構造の情報を持ちます
- 立場は固定ではない ── ある案件では販売店、別の案件ではエンドユーザーになる会社が存在します
- 後から情報が集まりやすい ── 会社オブジェクトには標準でコンタクト・取引・チケットが紐づきます
ここで「エンドユーザー」というカスタムオブジェクトを作ってしまうと、同じ会社が2つのオブジェクトに重複して存在する状態になります。
管理する対象が実質的に同じなら、オブジェクトは分けないほうが安全です。
カスタムオブジェクトを新設すべきかどうかは、「その情報が独立したレコードとして生まれ、消え、数えられるか」で判断してください。会社の中の一属性にすぎないなら、プロパティーで足ります。判断の詳しい考え方はHubSpotでカスタムオブジェクトを作るべきかの判断基準にまとめています。
立場は「関連付けラベル」で表す
3層をすべて会社で持つとすると、次の問題は「どれが商社でどれがエンドユーザーか、どう区別するか」です。
ここで会社のプロパティーに「区分＝商社」と入れる設計をよく見かけますが、これは詰まります。
同じ会社が、案件によって立場を変えるからです。ある現場では販売店として動く会社が、自社工場向けの案件ではエンドユーザーになります。
正しくは、会社の属性ではなく、会社と取引の「関係」の側に役割を持たせます。
- 同じオブジェクト同士でも使える ── HubSpotの関連付けラベルは、会社と会社、コンタクトとコンタクトの関連付けにも使えます
- 利用条件 ── 関連付けラベルの利用にはProfessional以上のサブスクリプションが必要です（レコードを関連付ける）
ラベルの例を挙げると、次のような形になります。
| 関連付け | ラベル例 | 意味 |
|---|---|---|
| 取引 ↔ 会社 | 発注元 | 見積・請求の宛先になる会社 |
| 取引 ↔ 会社 | 施工販売店 | 据付・保守を実行する会社 |
| 取引 ↔ 会社 | 使用者 | 実際に製品を使う会社 |
| 取引 ↔ 会社 | 仕様指定者 | 設計・仕様を決めた側 |
| 会社 ↔ 会社 | 取引ルート | 販売店がどの商社の下に付いているか |
このように持つと、「この商社経由の売上」も「このエンドユーザー向けの累計」も、同じデータから両方取り出せます。区分をプロパティーで固定していると、片方しか取れません。
会社同士の親子関係も併用する
グループ会社や、本社と工場の関係は、会社と会社の関連付けで表現します。本社が契約主体で、実際の納入先は各工場、というケースは製造業では珍しくありません。
このとき、次のようにすると、納入先ベースの分析ができるようになります。
- 取引の「使用者」ラベル ── 工場のレコードに向けます
- 契約主体 ── 本社に向けます
同じ案件の二重登録をどう防ぐか
冒頭で触れた「入口が複数あるために同じ案件が二重登録される」問題は、ここまでの設計だけでは解決しません。
エンドユーザーの技術者から直接問い合わせが来た案件と、数週間後に商社から降りてきた同じ現場の引き合いが、別々の取引として作られてしまうためです。対策は2つあります。
- 重複判定の軸を「会社」ではなく「現場・設備」に置く ── 取引に「現場名」「設備の呼称」「納入予定場所」といったプロパティーを持たせ、新規作成前に同じ値の取引がないかを検索させます。会社名で探すと、商社経由とエンドユーザー直の案件が別の会社に紐づいているため引っかかりません
- 取引の重複を潰す担当を1人決める ── システムで完全に防ぐことはできません。週次で「同じ使用者の会社に、直近3か月で作られた取引が複数ないか」を確認する運用を置くほうが確実です
重複したまま両方を進めると、受注時に片方が失注として残ります。失注理由の集計が歪むため、受注率が実態より低く見える原因になります。
統合するときは、活動履歴が多いほうを残し、もう一方は「重複」という失注理由でクローズすると、後から集計から除外できます。
取引をどの単位で作るか
3層の次に迷うのが、取引レコードの粒度です。1件の取引が何を指すのかは、業態によって答えが変わります。
ここを決めないまま運用を始めると、件数も受注率も他社どころか自社の前年とも比較できない数字になります。
3つの選択肢
| 粒度と1件の意味 | 向いているケース | 注意点 |
|---|---|---|
| 引き合い単位 1つの引き合いから受注までが1件 |
受注生産・個別見積が中心 | 小口の引き合いが多いと件数が膨らむ |
| 年間包括単位 1顧客の年間取引が1件 |
継続的な部品供給・リピート受注 | 個別案件の勝ち負けが見えなくなる |
| 図番・機種単位 1つの製品仕様が1件 |
図面ベースの受注が中心 | 同じ図番の再受注をどう数えるかが問題になる |
多くの製造業では、引き合い単位が出発点として扱いやすい設計です。受注確度・見積金額・失注理由といったパイプライン管理の基本が、そのまま機能します。
見積が何度も出る場合
製造業では、1つの引き合いに対して仕様変更を繰り返し、見積を5回、10回と出し直すことがあります。
このとき取引を作り直さないでください。
- 取引 ── 1件のままにします
- 見積レコード ── 複数ぶら下げる形にします
取引を作り直すと、リードタイムも失注率も正しく取れなくなります。
リピート受注をどう数えるか
同じエンドユーザーから同じ製品の追加発注が来た場合、新しい取引を作るのが原則です。
「更新」「増設」といった取引種別のプロパティーを持たせ、新規受注とリピート受注を後から分けられるようにしておきます。
この区分を後から追加すると、過去分は取れません。最初から持たせておく価値が高い項目です。
パイプライン全体の設計思想についてはHubSpotのパイプライン設計ガイドもあわせてご覧ください。
商流を跨いだ数字を取る
設計が正しいかどうかは、必要な数字が取れるかで判定できます。ここでは、商流を跨いで初めて見えてくる数字を3つ取り上げます。
あわせて、この設計でも取れない数字を先に明示しておくことが、運用の信頼を保つうえで効きます。
- エンドユーザー別の累計 ── 「使用者」ラベルから会社側で集計します
- 販売店の実績 ── 「施工販売店」ラベルから年間の実績を集計します
- 取りづらい数字 ── 取れない数字を先に明示します
エンドユーザー別の累計を出す
「このエンドユーザーに、これまで何台納めたか」は、製造業で最もよく聞かれる数字です。取引に「使用者」ラベルの関連付けがあれば、会社側から関連レコードを集計できます。
HubSpotの計算プロパティーには、関連レコードの値を集計するロールアップ機能があります。取得できる値は次のとおりです。
- 最小値・最大値
- 件数・合計・平均
- 最早の日付・最新の日付
計算プロパティーの利用にはProfessional以上が必要です（計算プロパティーを作成する）。
これを使うと、エンドユーザーの会社レコードに次の3つを自動で持たせられます。
- 累計納入金額
- 初回納入日
- 最終納入日
この3つがあるだけで、更新提案のリストが作れます。
販売店の実績を見る
販売店ごとの販売実績も、同じ仕組みで取れます。「施工販売店」ラベルの関連付けを集計すれば、販売店の会社レコードに年間の実績が乗ります。
代理店チャネルの管理設計は製造業の代理店管理をCRMで行う方法で詳しく扱っています。
取りづらい数字もある
正直に書くと、この設計でも取りづらい数字は残ります。
- 商社が誰に売ったかが分からない案件：商社が最終ユーザーを開示しない取引では、使用者ラベルが空欄になります。空欄のまま残し、「不明」という値で埋めないでください。不明を値として入れると、集計から除外できなくなります
- 設計事務所での指定から受注までのリードタイム：仕様が決まってから発注が来るまでが数年になる業界では、CRM上の追跡が途切れます。この場合は仕様指定の時点で別のレコード（引き合いではなく「仕様採用」）として残す設計を検討します
取れない数字を取れるように見せないことが、設計の信頼性を保つうえで重要です。
展示会からの引き合いをどう繋ぐか
製造業の新規接点は、展示会が中心という会社が多くあります。
ここまでの設計が効くのは、既存の商流だけではありません。展示会で得た接点をどう繋ぐかにも、同じ考え方が使えます。
展示会で名刺交換した相手は、多くの場合エンドユーザーの技術者です。ところが実際の受注は商社経由になります。この「入口と出口が違う」構造を、CRM上で繋いでおく必要があります。
具体的には、次の2つを行います。
- コンタクトの紐づけ ── 展示会で獲得したコンタクトを、エンドユーザーの会社レコードに紐づけます
- 取引へのラベル付け ── そこから生まれた取引には「発注元＝商社」「使用者＝エンドユーザー」の両方のラベルを付けます
こうすると、展示会の投資対効果を「商社経由で立った売上」まで含めて評価できます。
展示会リードの運用は製造業の展示会リード管理で扱っています。
よくある質問
製造業のCRMデータ設計について、ご相談の場でよくいただく質問をまとめました。
Q1. エンドユーザーをカスタムオブジェクトで作ってはいけませんか。
作ること自体は可能ですが、おすすめしません。エンドユーザーは実在する法人であり、会社オブジェクトと属性が完全に重なるためです。カスタムオブジェクトで持つと、同じ会社が会社レコードとエンドユーザーレコードの両方に存在する状態になり、どちらを更新すべきか分からなくなります。同じ実体を2つのオブジェクトに置かないのが原則です。
Q2. 関連付けラベルを使うにはEnterpriseが必要ですか。
いいえ、関連付けラベルはProfessional以上で利用できます（レコードを関連付ける）。Enterpriseが必要になるのはカスタムオブジェクトの作成のほうで、こちらはMarketing Hub・Sales Hub・Service Hub・Data Hub・Content Hub・Smart CRM・Revenue Hubのいずれかの Enterprise が要件です（カスタムオブジェクトを作成する）。3層構造の表現だけならProfessionalで足ります。
Q3. 生産管理システムに顧客マスターがあります。二重管理になりませんか。
役割を分ければ二重管理にはなりません。生産管理システムが持つべきは確定した受注・出荷・在庫であり、CRMが持つべきは受注前の商談経緯と、受注後の関係性です。境界の目安は、「会計や納期の正確性が問われるものは基幹側、判断と経緯はCRM側」です。両方に持つ項目（会社名・受注金額など）は片方向の同期にしてください。双方向にすると、衝突が起きたときに原因を追えなくなります。
Q4. 商社の担当者と、エンドユーザーの技術者を、同じコンタクトのリストで扱っていいですか。
同じコンタクトオブジェクトで扱って問題ありません。ただし、送るメールの内容がまったく違うため、リストで分けられる状態にしておく必要があります。所属会社の関連付けラベルで分ける方法と、コンタクト側に「接点の種類」というプロパティーを持たせる方法があります。技術情報の配信と価格改定の案内が混ざると、どちらの相手からも読まれなくなります。
Q5. すでに会社レコードが商社とエンドユーザーで混在しています。どこから直せばよいですか。
一度に直そうとせず、今後の新規案件から正しい形で作るところから始めてください。過去分は、売上上位のエンドユーザーから順に関連付けを張り直します。全件を整理してから運用を始めようとすると、着手できないまま終わります。整理の順番は、金額の大きい順ではなく「次に提案する予定がある順」で決めると、作業がそのまま営業活動になります。
関連記事
- 不動産CRMのデータ設計 ── 同じ考え方で不動産の商流を整理した設計例です
- 建設業のHubSpot活用ガイド ── 元請・協力会社の構造をCRMでどう持つかを扱っています
- 製造業のHubSpot活用法 ── 製造業でのHubSpot活用の全体像をまとめています
- 見積の承認フローをCRMで組む ── 見積の承認プロセスと価格マスターの設計を扱っています
- 製造業の代理店管理をCRMで行う方法 ── 代理店チャネルの実績管理と教育の設計です
- 製造業の展示会リード管理 ── 展示会で得た接点を受注まで繋ぐ運用です
まとめ
製造業のCRMデータ設計は、商流をそのまま写し取る作業です。要点を整理します。
- 商社・販売店・エンドユーザーはすべて会社オブジェクトで持つ。実体が同じものを別オブジェクトに分けないのが原則です
- 立場はプロパティーではなく関連付けラベルで表す。同じ会社が案件によって役割を変えるためです
- 取引は引き合い単位が出発点。見積を出し直しても取引は作り直さず、見積レコードをぶら下げます
- 新規とリピートの区分は最初から持たせる。後から追加すると過去分が取れません
- エンドユーザー別の累計はロールアップで自動化する。累計金額・初回納入日・最終納入日の3つで更新提案のリストが作れます
- 取れない数字は取れないままにする。「不明」を値として入れると集計から除外できなくなります
最初の一歩としておすすめしたいのは、「直近1年の受注案件を10件選び、発注元・施工販売店・使用者の3つを紙に書き出す」ことです。書き出せない案件があるなら、それが今の管理で失われている情報です。10件書き出すだけで、自社の商流が何パターンあるのかが見えてきます。
そのうえで、関連付けラベルを3つだけ作り、新規案件から付け始める。ここから始めるのが現実的です。
自社の商流に合わせたCRM設計を具体的に検討したい場合は、StartLinkの無料相談でご相談ください。現在の商流と管理方法をうかがったうえで、設計の方向性をご提案します。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
