BtoBスタートアップのCRM設計では、まずリード獲得・MQL化・商談化・受注を、流入経路別に追える状態を目指します。

本記事では、少人数で運用を始めるための管理項目と、施策の評価につながるダッシュボードの設計例を紹介します。

1. スタートアップのCRM設計で最初に決める管理項目

CRMを設計するときは、「どこから獲得し、どこで止まり、何が受注につながったか」を確認するための項目から整理しましょう。

HubSpotなどの有料のCRMであれば事前に定義された項目があるので、そちらをベースに自社専用の項目を作成しましょう。

スプレッドシートやnotionなどで管理をする場合は、項目を一から考える必要があるので、本記事を参考に作成をしてみてください。

関連記事：HubSpotとスプレッドシートを連携する方法｜自動転記・商談更新・チャネル別分析まで解説

リード・MQL・商談・受注の定義と記録する日付

最初に追いたいのは、リード獲得→MQL化→商談化→受注の流れです。

本記事では、リードを見込み顧客の担当者、MQL（有効リード）を自社の条件を満たし、優先して営業フォローしたいリードとして扱います。

MQLの条件は、対象業種や企業規模、相談内容などをもとに、マーケティングと営業ですり合わせて下さい。

関連記事：MQL（有効リード）とは?リード・SQLとの違いとCPAで見る運用のコツ

現在の状態だけでなく、獲得日、初回MQL化日、商談作成日、受注日を残します。日付があれば、獲得から商談までの期間や、施策ごとの進み方を比較できます。

リード情報と商談情報の分け方・紐づけ方

リードは担当者単位、商談は案件単位で分け、関連する会社・担当者・案件を紐づけます。最初に整理したい項目は次のとおりです。

管理対象	主な項目
リード・担当者	作成日、連絡先、関連会社、リードソース、対応ステータス、アポ獲得日、MQL判定・判定日
商談	関連会社・担当者、ステージ、金額、作成日、受注日、失注理由
フォロー予定	対象のリード・商談、担当者、次の対応内容、対応予定日

同じ商談に複数の担当者が関わっても、商談数は重複させません。流入経路別に商談を集計する場合は、どの担当者の獲得元を採用するかも決めます。

以下の分類やステージは設計例です。実施していない施策は後から追加し、営業プロセスが短ければステージをまとめるなど、自社で更新できる範囲から始めます。

2. リードソースの設計｜大・中・小の分類例

リードソースは「どこから獲得した人か」を表します。

大分類は獲得活動の区分、中分類は施策の種類、小分類は具体的な媒体・獲得元として、3階層で設計しましょう。

インバウンド・アウトバウンド・アライアンスの分け方

大分類には、顧客からの流入、自社からの働きかけ、他社との連携という区分を置きます。

大分類	中分類	小分類の例
インバウンド	検索連動型広告	Google検索広告、Yahoo!広告、Bing広告
インバウンド	SNS広告	Meta広告、LinkedIn広告、X広告
インバウンド	比較サイト	BOXIL、ITトレンド
アウトバウンド	架電、手紙	細分化が不要なら「該当なし」
アライアンス	共催ウェビナー、紹介	共催先・紹介元の名称

中分類には、オーガニック、ダイレクト、AIリファラル、SNS自然流入、交流会、展示会、自社ウェビナー、ペイドメディア、コミュニティなども、実施施策に合わせて加えましょう。

共催ウェビナーをアライアンスに置くのは、共催先から獲得した場合の例です。同じ企画でも、自社広告から申し込んだ人は広告経由として扱います。

獲得経路とウェビナーなどの参加履歴を分ける

Google検索広告からウェビナーに申し込んだ人を、一律に「ウェビナー経由」にすると、広告からの獲得が見えなくなります。

この場合、リードソースは「インバウンド／検索連動型広告／Google検索広告」とし、参加したウェビナー名は別に記録します。媒体と企画を分けて振り返るためです。

最初の獲得元は、その後の参加履歴で上書きせずに、追加していく形式を推奨しています。

3. リードステータスの設計｜ISの対応状況と更新基準

リードステータスは、担当者への対応がどこまで進んだかを表します。インサイドセールス（IS）が、次の対応を判断するために更新します。

リードステータス	状態
01. 未対応	獲得後、まだ連絡していない
02. 未接続	連絡したが、担当者とやり取りできていない
03. 担当者接続	担当者とやり取りできた
04. ニーズ特定	課題や関心を確認できた
05. 商談設定合意	商談には合意し、日程を調整している
06. アポ獲得・商談中	日程が確定し、商談対応に進んでいる
07. ナーチャリング	今すぐ商談には進めず、継続して接点を持つ
08. 対象外	自社の対象条件に合わない
09. 既存顧客	取引のある企業の担当者である

電話がつながらない相手を「ニーズがない」と扱うと、未確認の人と、確認したうえで今は検討しない人が混ざります。未接続とナーチャリングを分けるのは、この違いを残すためです。

商談設定合意とアポ獲得を分ければ、日程調整で止まっている相手も見つけやすくなります。

MQL・リードステータス・商談ステージの違い

MQLは「優先してフォローする対象か」、リードステータスは「担当者への対応状況」、商談ステージは「案件の進行状況」を示します。

MQLの条件を満たしていても、まだ連絡がついていない場合はあります。MQL判定と対応状況は別項目にすると、この状態を表現できます。

運用例は、リードステータスの定義とISの仕組み化を支援した事例でも紹介しています。

4. 商談ステージの設計｜商材に合わせた段階と移行条件

営業プロセスが短ければ、「初回商談→提案→条件調整→受注／失注」から始めてもよいと思います。

社内稟議などの複数の段階がある商材などでは、次のように分けることが多いです。

商談見極め→課題特定→担当者の賛同→上申の合意→意思決定者の導入合意→契約の条件調整→契約手続き→受注

これに失注を加え、どの段階で失注したかもを記録できるようにすることで、落ちやすいところを特定することができます。

ステージ名とあわせて、「何を確認したら次へ進めるか」も決めます。例えば以下のような条件です。

• 担当者の賛同なら、説明を終えた状態ではなく、導入を進めたい意向を確認できた
• 上申の合意なら、誰に、いつ、何を相談するかを確認できた
• 契約前の検証が必要なら、その段階を追加
• 受注後の納品・オンボーディングは、受注までの進捗と分けて管理（あくまで例）

また、アポ確定時に商談を作るのか、初回商談の実施後に作るのかを揃えます。アポ獲得と商談実施を別々に見たい場合は、それぞれの日付を残し、ダッシュボードの指標名も分けます。

5. CRMダッシュボードの設計｜流入経路別に商談・受注を追う

ダッシュボードは「その期間の実績」と「獲得したリードのその後」を分けて設計します。

期間ごとの実績と、獲得したリードの追跡を分ける

期間実績では、リードは獲得日、商談は作成日、受注は受注日で集計します。

※数値・分類名はサンプルです。

画像ではリード12件、商談6件、受注3件ですが、この商談6件が同じ期間に獲得した12件から生まれたとは限りません。

獲得リードの追跡では、指定期間に獲得した人を対象に、その後のMQL化・商談化・受注を確認します。

※数値・分類名はサンプルです。実運用では、自社で設計した獲得時点のリードソースで集計します。

商談化率の分母・分子と観測期間を揃える

リードの商談化率は、「対象リードのうち商談に進んだ人数÷対象リード数」で計算します。

画像のように獲得後30日間で比較するなら、30日を経過した人と、まだ観測中の人を分けます。直近の獲得者まで未商談として比較すると、最近始めた施策が低く評価されやすくなるためです。

集計値から対象者・判定日・関連商談まで確認できると、数字の違和感を調べやすくなります。

6. CRM運用の始め方｜入力担当と更新タイミングを決める

設計後は実際のリードや受注・失注案件で、入力から集計まで一度やってみて、分類に迷った箇所を定例会議などで判断を仰いで直してから、運用を広げていきましょう。

更新の役割は、流入経路をマーケティング、対応ステータスをIS、商談ステージを営業、というように決めます。少人数で兼務する場合も、リード取込時、顧客への連絡後、商談後など、更新するタイミングを揃えます。

CRM設計では、項目を増やすことより、数字を見て定例会議で次の対策を決めるための土台となるものでありそこを念頭に置いて設計しましょう。

リードファクトリーでは、BtoBマーケティング・IS支援とあわせて、HubSpotの導入・活用支援を行っています。