物流業のCRMデータ設計｜荷主・拠点・契約をどう持つか

物流業のCRMデータ設計とは、契約する相手（荷主の本社）と、荷物が実際に動く場所（工場・倉庫・店舗）を、別々のレコードとして持ち分ける作業です。 拠点は会社オブジェクトで持ち、集荷元・納品先・請求先といった立場は、拠点の属性ではなく関連付けラベルで表します。 この形にしておくと、荷主単位の年間取扱高と、拠点単位の稼働状況を、同じデータから両方取り出せます。

「契約書を交わした相手」と「毎日トラックが着けている場所」が違う——物流でCRMを入れると、必ずここで手が止まります。

一般的なCRMの説明は、会社が1つ、担当者が数名、取引が1件、という前提で書かれています。ところが物流の現場では、契約主体は荷主の本社で、実際の集荷は関東の工場、納品先は全国の店舗、請求は経理部宛て、というように1つの契約の裏に複数の場所が並走します。この構造を会社レコード1件に押し込もうとすると、住所が1つしか入らない時点で行き詰まります。

つまり物流業のCRM設計は、項目を並べる作業ではありません。荷物と契約と請求がそれぞれどこを向いているのかを、データの形で表現する作業です。ここを飛ばして項目定義から入ると、後から拠点別の数字が取れなくなります。

この記事では、HubSpotを例に、物流業のデータ構造をCRM上でどう設計するかを整理します。運送会社・倉庫会社・3PL事業者で管理の仕組みを作る立場の方、配車システムはあるが営業側の情報が個人任せになっている方に向けた内容です。次の4点がわかります。

• 荷主・拠点・契約をどのオブジェクトで持つか ── 分けるべき理由と、分けたあとの繋ぎ方を示します
• 関連付けラベルで場所の役割を表す ── 集荷元・納品先・請求先を関係の側に持たせる設計です
• 契約と単価をどの単位で持つか ── 年間契約・拠点別・品目別のどこで線を引くかの判断軸です
• 拠点別と荷主別の数字を両方取る方法 ── ロールアップ集計の使いどころを説明します

読み終える頃には、自社の荷主構造をCRM上でどう写し取るかのたたき台が作れる状態になります。ぜひ最後までご確認ください。

物流業のCRMが「会社1件」で収まらない理由

まず、なぜ一般的なCRMの設計がそのまま当てはまらないのかを整理します。原因は営業のやり方ではなく、物流という事業の構造そのものにあります。

業界の半分以上が小規模事業者

国土交通省物流・自動車局貨物流通事業課の集計によれば、令和6年度末時点の貨物自動車運送事業者数は62,383者でした。内訳は特別積合せ323者、一般56,954者、霊柩4,799者、特定307者で、前年度から467者の減少です（貨物自動車運送事業者数（推移））。

規模別に見ると構造がよくわかります。令和7年3月31日現在で、保有車両10両以下の事業者が34,164者と全体の54.8%を占め、従業員数10人以下の事業者は30,759者で49.3%にのぼります（貨物自動車運送事業者数（規模別））。

つまり業界の過半数は、専任の情報システム担当を置けない規模の会社です。だからこそ、大がかりな基幹システムではなく、まずCRM上で荷主と拠点を正しく持つところから始める価値があります。

1つの契約の裏に複数の場所が並走する

物流のデータ設計を難しくしている構造は、突き詰めると1つです。契約する相手と、荷物が動く場所と、請求書を送る先が、それぞれ別の住所を持っているという点です。

このうち契約更新の交渉相手は本社ですが、値上げの根拠になる数字は拠点側で発生します。片方だけを管理していると、交渉の材料がそろいません。

現場の情報が営業に戻ってこない

配車システムや倉庫管理システムには、日々の実績が細かく残っています。ところがそれは「どのトラックがいつどこへ行ったか」の記録であって、「その荷主が今どういう状態か」の記録ではありません。

待機時間が延びている、附帯作業が増えている、担当者が代わった——こうした契約更新の判断に効く情報は、たいてい現場のドライバーと営業担当の頭の中にしかありません。CRMに拠点のレコードがあれば、この情報の置き場所ができます。

荷主・拠点・契約の3つをどう持つか

ここからが設計の本体です。物流の3つの登場人物を、CRM上のどのオブジェクトに割り当てるかを決めます。

これは特定の企業の実装ではなく、物流業でよく出てくる構造を一般化した設計例です。

拠点は会社オブジェクトで持つ

最初の判断は、拠点をどう持つかです。結論から言うと、拠点は会社オブジェクトで持ち、荷主本社との間を会社同士の関連付けで繋ぐのが扱いやすい形になります。

理由は3つあります。

1. 拠点には固有の住所と担当者がいる。倉庫の所長、店舗のバックヤード担当者など、実在する人が紐づきます。会社オブジェクトならコンタクトをそのまま関連付けられます
2. 拠点が独立して発注してくることがある。本社契約とは別に、店舗単位でスポット配送を頼まれるケースは日常的に起きます
3. 後からカスタムオブジェクトへ移すのは難しいが、逆は容易です。まず標準オブジェクトで始めるほうが失敗が小さくなります

カスタムオブジェクトを使う判断もあり得ますが、HubSpotではカスタムオブジェクトの作成はMarketing Hub・Sales Hub・Service Hub・Data Hub・Content Hub・Smart CRM・Revenue Hubのいずれかの Enterprise が要件です（カスタムオブジェクトを作成する）。拠点構造を表現するだけなら、会社オブジェクトの親子関係で足ります。オブジェクトの選び方そのものはカスタムオブジェクトを作るべきかの判断基準で整理しています。

契約は取引で持ち、更新のたびに新しく作る

契約は取引オブジェクトで持ちます。ここで迷いやすいのが、年間契約を1件の取引としてずっと使い続けるか、更新のたびに新しい取引を作るかです。

更新のたびに新しい取引を作るほうを推奨します。 同じ取引を使い回すと、去年いくらで契約していたかが上書きされて消えます。物流は単価改定の交渉が定期的に発生する業界なので、過去の条件が残らない設計は致命的です。

迷ったときの判断軸

拠点や契約を「新しいオブジェクトにすべきか」で迷ったら、次の2つを確認してください。

• それは実在する法人・事業所か。実体があるなら会社オブジェクトが自然です
• それは時間とともに状態が変わるか。ステージが進むものは取引、状態が変わらない台帳はカスタムオブジェクトが向きます

場所の役割は関連付けラベルで表す

拠点を会社オブジェクトで持つと決めた瞬間に、次の問題が出てきます。同じ倉庫が、ある契約では集荷元で、別の契約では納品先になるという現実です。

属性ではなく関係に持たせる

拠点の会社レコードに「拠点種別＝集荷元」というプロパティーを作るのは、一見わかりやすい設計です。ただしこれは破綻します。同じ拠点が契約によって役割を変えるからです。

正しくは、契約（取引）と拠点（会社）の関連付けそのものに名前を付けます。HubSpotの関連付けラベルは、Marketing Hub・Sales Hub・Service Hub・Data Hub・Content Hub・Smart CRMの Professional 以上で利用でき、1つのオブジェクトペアにつき最大50個のラベルを作成できます。コンタクト対コンタクトのように同じオブジェクト同士の関連付けにも使えます（関連付けラベルを作成して使用する）。

ラベルの例を挙げると、次のような形になります。

ラベルは4つまでに絞る

ラベルは最大50個作れますが、最初は4つまでに絞ってください。細かく分けるほど付け忘れが増え、集計が信用できなくなります。「中継拠点」「一時保管先」といった区分は、運用が回ってから足せば十分です。

会社と会社の関係にもラベルは使えます。荷主本社と拠点の間に「本社」「事業所」のラベルのペアを設定しておくと、どちらが親かがデータ上で明確になります。関連付けラベルには、両側を同じ言葉で表す単一のラベルと、「マネージャー」と「従業員」のように両側で異なる言葉を使うラベルのペアの2種類があります。

契約と単価をどの単位で持つか

物流の見積は、1つの単価では表せません。方面別・車格別・重量帯別の料金表が、契約に紐づく形で存在します。

商品項目で料金表を持つ

契約（取引）に商品項目をぶら下げて、方面や車格ごとの単価を持たせます。この形にすると、契約単位の年間見込み額が自動で計算され、改定交渉のときに何をいくら上げるのかが明細で示せます。運賃の見積と改定の手順は物流の見積・運賃改定をCRMで管理するで詳しく扱います。

拠点ごとに条件が違う場合

同じ荷主でも、拠点によって条件が違うことは珍しくありません。この場合の選択肢は2つです。

• 拠点ごとに契約（取引）を分ける：条件がまったく違う場合はこちらです。拠点別の採算が直接見えます
• 1つの契約の中で商品項目を拠点別に持つ：条件の差が単価だけなら、こちらのほうが更新作業が軽くなります

判断の目安は、契約更新の交渉が拠点ごとに行われるかどうかです。本社で一括交渉するなら取引は1件、拠点長と個別に話すなら取引を分けます。

拠点別と荷主別の数字を両方取る

設計の目的は、最終的に数字を取ることです。物流で見たい数字は、荷主単位と拠点単位の2つがあります。

ロールアップ集計で自動化する

HubSpotの計算プロパティーは、各製品の Professional 以上で利用できます。関連レコードのプロパティーをもとに自動計算するロールアップ集計プロパティーでは、最小値・最大値・件数・合計・平均・最早の日付・最新の日付の7種類の集計が使えます。集計対象は全ての関連レコードにも、特定の関連付けラベルが付いた関連付けだけにも絞り込めます（計算プロパティーを作成する）。

この「ラベルで絞り込める」という点が、物流の設計では効きます。荷主本社のレコードに「契約主体として紐づく取引の金額合計」を持たせれば、拠点への配送実績と混ざらずに年間取扱高が出ます。

最初に作るべき3つの集計

いきなり多くの集計を作ると、どれが正しいのか分からなくなります。まずは次の3つから始めることをおすすめします。

• 荷主本社：年間取扱高（契約主体ラベルの取引金額の合計）
• 拠点：最終稼働日（納品先ラベルの取引の最新の日付）
• 荷主本社：契約件数（契約主体ラベルの取引の件数）

この3つがあるだけで、「取扱高は大きいのに最終稼働が古い荷主」という危険信号が一覧で拾えるようになります。プロパティーの設計方針そのものはHubSpotプロパティー設計のベストプラクティスにまとめています。

取りづらい数字もある

正直に書くと、この設計でも取りづらい数字は残ります。

• 1便あたりの実車率や積載効率：これは配車システムが持つべき数字で、CRM側で持つと二重管理になります。CRMには月次の集計値だけを取り込むのが現実的です
• 荷主の物流費全体に占める自社シェア：荷主が他社にいくら払っているかは、こちらからは見えません。推定値を入れると、根拠のない数字が独り歩きします

取れない数字を取れるように見せないことが、設計の信頼性を保つうえで重要です。

配車システム・請求システムとの境界

物流会社の多くは、すでに配車システムや請求システムを持っています。CRMを足すときに問われるのは、どこまでをCRMに持たせるかです。

境界の引き方

判断の目安は、「日々の運行と請求の正確性が問われるものは基幹側、判断と経緯はCRM側」です。

両方に持つ項目（会社名・契約金額など）は、片方向の同期にしてください。双方向にすると、値が食い違ったときに原因を追えなくなります。

荷主側の基幹システムに合わせない

もう1つ注意したいのが、大手荷主のシステムに引きずられないことです。荷主のポータルに入力する項目をそのままCRMのプロパティーにすると、荷主が変わるたびに項目が増え続けます。CRMは自社の管理のために設計し、荷主向けの入力は別作業として切り離すのが結果的に軽くなります。物流業の全体像は物流業のHubSpot活用ガイドにまとめています。

よくある質問

物流業のCRMデータ設計について、ご相談の場でよくいただく質問をまとめました。

Q1. 拠点をカスタムオブジェクトで作るのは間違いですか。

間違いではありませんが、多くの場合は会社オブジェクトで足ります。拠点は実在する事業所であり、住所と担当者を持つ点で会社と属性がほぼ重なるためです。カスタムオブジェクトが向くのは、車両や倉庫の棚のように「法人ではないが台帳として管理したいもの」です。またカスタムオブジェクトの作成には Enterprise が必要になるため、Professional で運用している場合は会社オブジェクトの親子関係が現実的な選択になります。

Q2. 荷主の本社と拠点で、同じ会社名のレコードが増えて困っています。

会社名の付け方をルール化してください。実務でうまくいきやすいのは、本社は正式社名のみ、拠点は「正式社名 ○○センター」のように後ろに拠点名を足す形です。あわせて、拠点レコードには必ず「事業所」の関連付けラベルで本社と繋いでおきます。名前だけで区別しようとすると、検索したときにどちらが本社か分からなくなります。

Q3. スポット配送しか受けていない荷主も、同じ設計で管理すべきですか。

同じ設計で問題ありませんが、契約（取引）の作り方だけ変えます。年間契約がない荷主は、受注のたびに取引を作る形にします。このとき取引パイプラインを契約案件用とスポット用で分けておくと、ステージの意味が混ざりません。パイプラインの分け方はHubSpotパイプライン設計ガイドで扱っています。

Q4. 関連付けラベルは後から追加できますか。

追加できます。ただし、過去のレコードに遡ってラベルが付くわけではありません。後から追加したラベルで集計を作ると、過去分が空欄のまま集計され、数字が実態より小さく出ます。運用開始後にラベルを足す場合は、集計を作る前に過去分をどこまで遡って付け直すかを決めてください。直近1年分だけ手当てして、それ以前は集計対象外と明示するのが現実的です。

Q5. 元請と下請が入り混じっています。協力会社もCRMに入れるべきですか。

入れて構いませんが、荷主とは別の関連付けラベルで区別してください。同じ会社オブジェクトに入れたうえで、「協力会社」のラベルを持たせる形です。荷主と協力会社をオブジェクトごと分けてしまうと、荷主でもあり協力会社でもある会社が現れたときに二重登録になります。物流業界では相互に仕事を融通する関係が普通にあるため、立場を固定しない設計にしておくほうが安全です。

関連記事

• 物流業のHubSpot活用ガイド ── 物流業でのHubSpot活用の全体像をまとめています
• 物流の見積・運賃改定をCRMで管理する ── 運賃の商品項目設計と改定交渉の管理を扱っています
• 製造業のCRMデータ設計 ── 同じ考え方で製造業の商流を整理した設計例です
• 卸売業のHubSpot活用ガイド ── 得意先と仕入先を両建てで持つ業界の設計です
• カスタムオブジェクトを作るべきかの判断基準 ── 標準オブジェクトで足りるかを判断する軸です
• HubSpotプロパティー設計のベストプラクティス ── 項目を増やしすぎないための設計方針です

まとめ

物流業のCRMデータ設計は、荷物と契約と請求がそれぞれどこを向いているかを写し取る作業です。要点を整理します。

• 拠点は会社オブジェクトで持ち、本社と親子の関連付けで繋ぐ。実在する事業所を別オブジェクトに分けないのが原則です
• 集荷元・納品先・請求先は関連付けラベルで表す。同じ拠点が契約によって役割を変えるためです
• 契約は更新のたびに新しい取引を作る。使い回すと過去の単価が消えます
• ラベルは最初4つに絞る。細かく分けるほど付け忘れが増えます
• 荷主別と拠点別の数字はロールアップで自動化する。年間取扱高・最終稼働日・契約件数の3つから始めます
• 配車と請求の正確な数字は基幹システムに置く。CRMには判断と経緯を残します

最初の一歩としておすすめしたいのは、「主要な荷主を5社選び、契約主体・集荷元・納品先・請求先の4つを紙に書き出す」ことです。書き出せない項目があるなら、それが今の管理で失われている情報です。5社書き出すだけで、自社の荷主構造が何パターンあるのかが見えてきます。

そのうえで、関連付けラベルを4つだけ作り、新規契約から付け始める。ここから始めるのが現実的です。

自社の荷主構造に合わせたCRM設計を具体的に検討したい場合は、StartLinkの無料相談でご相談ください。現在の契約形態と管理方法をうかがったうえで、設計の方向性をご提案します。