医療向けBtoB営業のCRMデータ設計|販売店・医療機関・担当医をどう持つか

この記事の結論

医療向けBtoB営業のCRM設計の結論は、販売店と医療機関をどちらも会社オブジェクトで独立して持ち、1件の取引に「発注元」と「使用施設」の両方を関連付ける、という形に集約されます。 職位はコンタクトのプロパティーで持ち、その案件での役割(採用判断者・使用者・価格窓口)は関連付けラベルで持つと、人事異動に強い構造になります。そして直販と販売店経由はパイプラインを分けます。ステージの意味が揃わないと、受注率が読めなくなるためです。

ブログ目次

記事の内容を、そのまま実務に落とし込みたい方向け

HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。


医療向けBtoB営業のCRM設計の結論は、販売店と医療機関をどちらも会社オブジェクトで独立して持ち、1件の取引に「発注元」と「使用施設」の両方を関連付ける、という形に集約されます。 職位はコンタクトのプロパティーで持ち、その案件での役割(採用判断者・使用者・価格窓口)は関連付けラベルで持つと、人事異動に強い構造になります。そして直販と販売店経由はパイプラインを分けます。ステージの意味が揃わないと、受注率が読めなくなるためです。

「今月の売上は販売店に立っているが、実際に使っているのはどの病院なのか」——この質問に即答できる医療向けメーカーは、多くありません。

医療機器・医療材料・検査試薬のBtoB営業では、注文書を出すのは販売店(ディーラー)、製品を使うのは医療機関、採用を決めるのは特定の診療科の医師や部門長、価格交渉の窓口は事務長や購買部門、というように役割が完全に分かれています。しかもこの構造は取引先ごとに違い、直販のケースも混在します。

医療向けBtoB営業のCRMデータ設計とは、販売店・医療機関・診療科・キーパーソンという複数の単位を、それぞれ独立したレコードとして持ち、その関係を記録できる形にする作業です。営業担当者の頭の中にある「誰に会って誰が決めるか」を、組織が共有できる形に置き換える作業だと考えてください。

この記事では、HubSpotを例に、医療向けBtoB営業のデータ設計を整理します。医療機器・医療材料メーカーで営業管理の仕組みを作る立場の方、販売店経由の売上とエンドユーザーの動きが繋がらずに困っている方に向けた内容です。次の4点がわかります。

  • 販売店と医療機関を分けて持つ設計 ── 会社レコードをどう分け、どう繋ぐかを示します
  • 法人・施設・診療科の階層 ── 大規模法人をどこまで分解して持つかの判断軸です
  • キーパーソンの持ち方 ── 「決める人」と「使う人」と「払う人」を区別する方法です
  • 訪問記録をどこに残すか ── 活動記録とカスタムオブジェクトの使い分けを説明します

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


医療のBtoB営業が難しい理由

まず、なぜ一般的なCRM設計がそのまま当てはまらないのかを整理します。理由は3つあり、いずれも営業のやり方ではなく市場の構造に由来します。構造を言語化しておくと、後の設計判断がぶれません。

訪問対象の母集団が大きい

厚生労働省の医療施設動態調査によれば、令和8(2026)年5月末時点の医療施設の総数は178,696施設でした。内訳は病院が7,949施設(うち一般病院6,897、精神科病院1,052)、一般診療所が105,690施設(有床5,022、無床100,668)、歯科診療所が65,057施設です(医療施設動態調査(令和8年5月末概数)、令和8年7月31日公表)。

病院だけでも約8,000施設あり、営業担当者が個人で覚えきれる数ではありません。しかも各施設に複数の診療科があり、それぞれに採用の判断者がいます。母集団の大きさそのものが、CRMを必要とする理由になっています。

「買う人」「使う人」「決める人」が別

医療向けBtoB営業の構造は、次のように整理できます。

役割 誰か 営業活動での意味
発注する 販売店・卸 売上が立つ相手。価格と物流の交渉先
使う 医療機関の診療科・部門 製品評価が決まる場所
決める 診療科の責任者、部門長 採用の可否を左右する
承認する 事務長、購買、委員会 価格と契約条件を決める

一般的なCRMは「会社があり、担当者がいて、取引がある」という前提で作られています。医療ではこの4つが別々の会社・別々の人に分かれるため、そのままでは表現できません。

直販と間接販売が混在する

さらに厄介なのは、同じ製品でも取引先によって直販と販売店経由が混在することです。大学病院は直販、中小病院は販売店経由、というように分かれる会社が一般的です。

この2つを1本のパイプラインで管理しようとすると、ステージの意味が揃わなくなります。直販では見積提出が重要な節目ですが、販売店経由では販売店が見積を出すため、自社のステージには現れません。


販売店と医療機関を分けて持つ

ここからが設計の本体です。まず決めるのは、販売店と医療機関をどのオブジェクトに置くか、そして1件の取引にどちらを紐づけるかの2点です。ここさえ固めておけば、この後の階層やキーパーソンの設計は積み上げで決められます。

医療向けBtoB営業のCRMデータモデル図。左に販売店・卸(会社)と担当販売店の関連付け、右に医療機関(会社)と医師・事務長・購買のコンタクトを配置し、中央の取引に発注元と使用施設の両方の関連付けが伸びる構造を示した図。下部に患者情報を入れない・異動に強くなる・不明は空欄のままという3つの注意点を添えている

これは特定の企業の実装ではなく、医療向けBtoB営業でよく出てくる構造を一般化した設計例です。

どちらも会社オブジェクトで持つ

販売店と医療機関は、どちらも会社オブジェクトのレコードとして独立して持ちます。カスタムオブジェクトを新設する必要はありません。どちらも実在する法人であり、住所・電話番号・担当者という同じ構造を持つためです。

区別は、会社のプロパティーで「取引先区分=販売店/医療機関」を持たせる形で行います。ここは製造業の商流と違い、販売店が医療機関になることは基本的にないため、属性として固定して問題ありません。

取引には両方を関連付ける

1件の取引に対して、発注元の販売店と使用する医療機関の両方を関連付けます。この関係に名前を付けるのが関連付けラベルです。関連付けラベルはProfessional以上で利用でき、異なるオブジェクト同士だけでなく同じオブジェクト同士(会社と会社など)の関連付けにも使えます(レコードを関連付ける)。

関連付け ラベル例 意味
取引 ↔ 会社 発注元 注文書を出す販売店(直販なら医療機関)
取引 ↔ 会社 使用施設 実際に製品を使う医療機関
会社 ↔ 会社 担当販売店 この医療機関を担当している販売店
取引 ↔ コンタクト 採用判断者 採用の可否を決める医師・部門長
取引 ↔ コンタクト 使用者 実際に製品を使う医師・技師

こうすると、「この販売店経由の売上」と「この病院への納入実績」を、同じデータから両方取り出せます。片方だけをプロパティーで持つ設計にすると、もう片方が永久に取れません。同じ考え方で製造業の商流を整理した例は製造業のCRMデータ設計で扱っています。


法人・施設・診療科の階層をどこまで分解するか

医療機関側は、さらに階層を持ちます。契約の主体と、納入先と、採用が決まる場所が、それぞれ別の粒度で存在するためです。どこまで分解して持つかは、自社が主戦場にしている施設規模で答えが変わります。

医療機関の階層構造を示した図。法人(医療法人・学校法人・自治体)の下に病院A・病院B・クリニックCが施設として並び、その下に手術室・内視鏡室・検査部などの診療科と部門が配置された3階層の構造を示し、下部に診療科をコンタクトのプロパティー・会社レコード・カスタムオブジェクトのどれで持つかの判断基準を表で並べた図

3つの階層

医療機関は、次の3階層で捉えられます。

  • 法人:医療法人、学校法人、自治体。契約や与信の主体になる
  • 施設:個々の病院・クリニック。納入先であり、訪問先になる
  • 診療科・部門:手術室、内視鏡室、検査部、透析室など。採用の判断が起きる場所

このうち法人と施設は、必ず別の会社レコードとして分けてください。同じ医療法人が複数の病院を運営しているとき、法人1つにまとめてしまうと、どの病院に何が入っているかが分からなくなります。会社同士の関連付けで親子関係を表現します。

診療科をどう持つかは規模で変わる

診療科・部門については、扱いが分かれます。

持ち方 向いているケース 制約
コンタクトのプロパティー 診療科ごとの数字を追わない。担当者が誰の所属かだけ分かればよい 診療科単位の集計ができない
会社レコード(施設の子) 大規模病院が主戦場で、診療科ごとに採用状況が違う 会社レコードの件数が増える
カスタムオブジェクト 診療科ごとに設置台数・稼働状況など固有の情報を多数持つ Enterprise が必要

中小規模の医療機関が主戦場なら、コンタクトのプロパティーで足ります。大学病院や大規模総合病院を相手にしていて、診療科ごとに採用が分かれるなら、会社レコードとして分けるほうが管理しやすくなります。

カスタムオブジェクトの作成には、Marketing Hub・Sales Hub・Service Hub・Data Hub・Content Hub・Smart CRM・Revenue Hub のいずれかの Enterprise が必要です(カスタムオブジェクトを作成する)。判断の考え方はHubSpotでカスタムオブジェクトを作るべきかの判断基準にまとめています。

階層を細かくするほど正確になりますが、入力する側の負担も増えます。訪問のたびに診療科まで選ばせる設計にするなら、その粒度で見たいレポートが実際にあるかを先に確認してください。レポートに使わない粒度は、入力されなくなります。


キーパーソンを区別して持つ

医療の営業では、会うべき人が複数います。しかも、同じ人が製品によって違う立場になります。この動きをどこに記録するかで、人事異動が起きたときの手当ての量が大きく変わります。

役割はコンタクトの属性ではなく関係で持つ

同じ医師が、ある製品では採用判断者で、別の製品では単なる使用者ということがあります。そのため役割は、コンタクトのプロパティーではなく取引とコンタクトの関連付けラベルで持ちます。

一方で、「診療科部長」「事務長」といった職位はコンタクトのプロパティーで持ちます。職位は製品によって変わらないためです。

  • 職位・所属診療科 → コンタクトのプロパティー
  • この案件での役割(採用判断者・使用者・価格窓口) → 取引との関連付けラベル

この使い分けを間違えると、人事異動のたびに全案件を直す羽目になります。

異動を前提に設計する

医療機関の人事異動は頻繁です。医師が別の病院へ移ったとき、これまでの関係を失わない設計にしておくことに価値があります。

コンタクトの所属会社を新しい病院へ付け替えると、過去の取引との関連付けは残ります。つまり、「以前この製品を採用してくれた先生が、いまはどの病院にいるか」を追えます。これは医療の営業で非常に効く情報です。

そのために必要なのは、訪問の記録を会社ではなくコンタクトに紐づけて残すことです。会社にだけ残すと、人が移ったときに履歴が切れます。


訪問記録をどこに残すか

医療の営業では、情報提供活動の記録が営業活動の中心になります。訪問件数そのものより、何をどの診療科に伝えたかの蓄積が資産になるためです。ここでの分岐は、標準のアクティビティーで足りるか、構造化されたレコードが要るかの一点です。

訪問記録の持ち方を比較した図。左に標準のアクティビティー(ミーティング・メモ・通話)で残す方式、右にカスタムオブジェクト(営業報告・活動報告)で残す方式を配置し、向いているケース・できること・制約の3観点で対比し、下部に標準機能から始めて困ってから移行するという推奨の順番を添えた図

標準のアクティビティーで足りる場合

訪問1件ごとに「いつ・誰に・何を話したか」だけを残すなら、標準のミーティングやメモで足ります。コンタクトと会社の両方のタイムラインに自動で表示され、追加の設定が要りません。

訪問件数を数えたいだけなら、これで十分です

カスタムオブジェクトが要る場合

一方、訪問記録に対して次のような要求があるなら、カスタムオブジェクトを検討します。

  • 訪問ごとに提供した資料・製品・提案内容を構造化して残したい
  • 訪問の結果(反応、次回アクション、競合の状況)を選択肢型で集計したい
  • 訪問記録そのものを一覧・フィルタ・レポートの対象にしたい

メモの本文に自由記述で書かれた内容は、後から集計できません。「どの製品の話題が何回出たか」を数えたい瞬間に、構造化が必要になります

迷ったときの起点

判断の起点は、「その記録を数えたいか、読みたいだけか」です。読むだけならメモ、数えたいならカスタムオブジェクト。この一点で決められます。

最初からカスタムオブジェクトを作ると、入力項目が多すぎて記録されなくなるリスクがあります。まず標準のアクティビティーで運用し、集計できないことに困ってから移行する順番をおすすめします。

デモ機・試用の貸出をどう記録するか

医療向けの営業では、機器を一定期間貸し出して評価してもらう工程が採用の分かれ目になります。ところがこの貸出は、訪問記録にも取引にもうまく収まりません。1台の機器が複数の施設を順に回り、1件の案件に複数回の貸出が発生するためです。

持ち方の選択肢は、次のとおりです。

  • 取引のプロパティーで持つ:「貸出開始日」「貸出終了日」「評価結果」を取引に持たせる。案件ごとに貸出が1回だけなら、これで足ります
  • カスタムオブジェクトで持つ:貸出そのものを独立したレコードにし、機器・施設・期間・評価結果を紐づける。同じ機器の稼働状況を追いたい場合はこちらになります

判断の起点は、「機器の側から見たいか、案件の側から見たいか」です。「この機器はいま誰のところにあるか」を知りたいなら独立したレコードが必要ですし、「この案件は試用まで進んだか」を知りたいだけなら取引のプロパティーで足ります。

いずれの場合も、評価結果は選択肢型で持ってください。「良好」「操作性に課題」「既存機と差がない」といった値で集計できるようにしておくと、失注の理由が製品側にあるのか価格側にあるのかを切り分けられます。自由記述だけでは、この切り分けができません。


パイプラインを直販と間接で分ける

最後に、パイプラインの設計です。データ構造が整っていても、案件の進み方を1本のボードに押し込むと、ステージ別の数字が読めなくなります。ここでは分ける理由と、長期案件の置き場所を扱います。

分ける理由

直販と販売店経由では、営業プロセスの節目が違います。1本のパイプラインに両方を入れると、ステージの意味が案件ごとに変わり、ステージ別の受注率が意味を持たなくなります。

直販のステージ例 販売店経由のステージ例
情報提供・関心喚起 販売店への製品説明
評価・試用 販売店同行での医療機関訪問
見積提出 評価・試用
院内承認・委員会 販売店からの見積提出
受注 販売店からの受注

見たい人が違うプロセスは分けるのが原則です。パイプラインは契約プランに応じて複数作成できます(パイプラインを設定・カスタマイズする)。パイプライン設計の全体像はHubSpotのパイプライン設計ガイド、代理店チャネルの管理設計はパートナーセールスの設計とCRM活用をあわせてご覧ください。

長期案件をどう扱うか

医療機関の設備更新は、検討開始から導入まで1年以上かかることがあります。この間、取引が同じステージに留まり続けると、パイプラインが動かない案件で埋まります。

対策は、「検討中」と「進行中」を別のパイプラインに分けることです。次年度以降の更新候補は情報管理用のパイプラインに置き、予算化されたタイミングで営業用のパイプラインへ移す。こうすると、営業のボードには今期の勝負案件だけが並びます。


よくある質問

医療向けBtoB営業のCRM設計について、ご相談の場でよくいただく質問をまとめました。

Q1. 医療機関の情報は、どこまでCRMに入れてよいですか。

患者に関する情報は一切入れないでください。CRMに入れるのは、医療機関という法人の情報と、そこで働く医師・職員の業務上の連絡先に限ります。この線引きは設計の前提として社内で明文化し、入力項目そのものを患者情報が入らない形に設計してください。項目がなければ入りません。取り扱う情報の範囲は、自社の規程と関係法令に照らして必ず事前に確認してください。

Q2. 販売店が最終納入先を教えてくれません。どう記録すべきですか。

使用施設の関連付けを空欄のままにしてください。「不明」という値で埋めると、後から集計から除外できなくなります。空欄なら「まだ分かっていない」という事実がそのまま残ります。そのうえで、販売店との関係が深まった段階で埋めていく運用にします。全体の何割が空欄かを可視化しておくと、販売店ごとの情報開示度も分かります。

Q3. 医師の異動情報は、どうやって追えばよいですか。

CRMの中だけで自動的に追う方法はありません。訪問時に確認して更新する、という人手の運用が基本になります。ただしメールの不達(バウンス)は異動の有力なサインです。バウンスが発生したコンタクトを一覧化するビューを作り、定期的に確認する運用にすると、更新の起点が作れます。

Q4. 診療科を会社レコードで分けると、件数が増えすぎませんか。

増えます。そのため、分けるのは主戦場となる診療科だけにしてください。全診療科を機械的にレコード化すると、使わないレコードが大量に生まれます。自社製品が使われる診療科(たとえば手術室と内視鏡室だけ)に絞って作り、それ以外はコンタクトのプロパティーで持つ、という混在の設計で構いません。

Q5. 既存の顧客マスターが販売店と医療機関で混在しています。何から手を付けるべきですか。

取引先区分のプロパティーを1つ作り、直近1年に取引のあった会社だけを分類するところから始めてください。全件を分類しようとすると着手できません。長く運用してきた顧客マスターほど、休眠したままのレコードが積み上がっており、直近で動きのある会社はその一部にとどまります。まずは動いている範囲だけを分類すれば、レポートは実用的な精度になります。残りは動きが出たときに分類すれば足ります。


関連記事


まとめ

医療向けBtoB営業のCRM設計は、役割の分離をそのまま写し取る作業です。要点を整理します。

  • 販売店と医療機関はどちらも会社オブジェクトで持ち、取引に両方を関連付ける。片方だけを持つと、もう片方が永久に取れません
  • 法人と施設は必ず分ける。医療法人1つにまとめると、どの病院に何が入っているか分からなくなります
  • 診療科の粒度は規模で決める。レポートに使わない粒度は入力されなくなります
  • 職位はプロパティー、案件での役割は関連付けラベル。この使い分けで異動に強くなります
  • 訪問記録は「数えたいか、読みたいだけか」で持ち方を決める。最初から構造化しすぎると記録されません
  • 直販と販売店経由でパイプラインを分ける。ステージの意味が揃わないと受注率が読めません
  • 患者情報は入れない。項目そのものを作らないのが最も確実な対策です

最初の一歩としておすすめしたいのは、「直近1年の受注案件を10件選び、発注元・使用施設・採用を決めた人の3つを書き出す」ことです。書き出せない案件があるなら、それが今の管理で失われている情報です。10件書き出すだけで、自社の営業構造が何パターンあるのかが見えてきます。

そのうえで、関連付けラベルを「発注元」「使用施設」の2つだけ作り、新規案件から付け始める。ここから始めるのが現実的です。

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


株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化(ERP/CRM/SFA/MAの導入)」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。

関連キーワード:

サービス資料を無料DL

著者情報

7-1

今枝 拓海 / Takumi Imaeda

株式会社StartLink 代表取締役。累計150社以上のHubSpotプロジェクト支援実績を持ち、Claude CodeやHubSpotを軸にしたAI活用支援・経営基盤AXのコンサルティング事業を展開。
HubSpotのトップパートナー企業や大手人材グループにて、エンタープライズCRM戦略策定・AI戦略ディレクションを経験した後、StartLinkを創業。現在はCRM×AIエージェントによる経営管理支援を専門とする。