スタートアップ分析
営業DXのその先へ: SFA導入後の営業設計メモ
このページは、SFAやCRMを入れたあとの営業設計を点検するためのメモです。
ツール名、公開ページの数値、料金、データ件数は変わります。この記事ではそれらを前提にせず、入力、部門間の受け渡し、購買シグナル、改善会議をどう置くと営業の動きが変わるかに絞ります。
SFAが日報置き場になっているなら、問題はツールの良し悪しだけではありません。入力した情報が営業へ返らない、マーケから渡るリードの意味がそろわない、蓄積した記録を読んで次の行動へ戻す役割がない。この3つの詰まりを外すことが、SFA導入後の最初の仕事です。
この版の前提
- 冒頭は長く使える営業設計に絞ります
- ツール別の公開数値や料金は後半の「2026年5月19日時点の確認」に分けます
- インテントデータや AI GTM は、単品ツールではなく営業運用の部品として読みます
この記事でわかること
- SFA が日報置き場になるときの3つの詰まり
- 営業DXを、記録、分析、検知、設計、半自律運用の5段で読む視点
- Stage 1 から Stage 2 へ進むための3か月計画
- 公開データと紹介チャネルを、営業シグナルとしてつなぐ考え方
- GTMエンジニアリングを、ツール操作ではなく改善の仕組みとして置く視点
基本情報
| 項目 | 内容 |
|---|---|
| 主題 | SFA/CRM導入後の営業設計 |
| 読み筋 | ツール導入の成否ではなく、入力から行動までの loop を点検する |
| 想定読者 | 営業責任者、RevOps、営業企画、founder、GTM lead |
| ゴール | 記録、分析、検知、設計、AI 補助の役割を分けて、次の一歩を決めること |
SFA が日報置き場になる3つの詰まり
SFAを入れても営業が変わらないとき、まず見るべきなのは現場の根性ではなく営業の流れです。多くの場合、次の3つの詰まりが同時に起きています。
| 詰まり | 起きていること | 先に直す所 |
|---|---|---|
| 入力と見返りの断絶 | 営業は記録するが、次に触るべき企業が返ってこない | 入力項目を減らし、営業が見る通知や会議資料へ返す |
| 受け渡しの断絶 | マーケと営業で「良いリード」の意味がずれている | MQLの条件を共同で決め、受け取り後の担当者を置く |
| 改善の断絶 | データは貯まるが、次週の行動に戻す場がない | 週次でシグナル、商談停滞、失注理由を読む時間を作る |
この3つは、ツールの追加だけでは解けません。むしろ画面が増えるほど、誰も見ないダッシュボードが増えます。先に必要なのは、記録された情報がどの会議、どの通知、どのタスク、どのメッセージに戻るかを決めることです。
営業DXを5段で読む
営業DXは「紙をデジタルに置き換えること」だけではありません。営業の判断、優先順位、メッセージ、改善会議の流れを組み替えることです。ここでは5段に分けて見ます。
営業DXの5段階進化モデル
| Stage | 読み方 | 主な問い | よくある落とし穴 |
|---|---|---|---|
| 1 | 記録する | 商談、活動、企業の記録は残っているか | 入力の手間だけが増える |
| 2 | 分析する | 記録から次の行動を決められるか | ダッシュボードが増え、営業の動きが変わらない |
| 3 | 検知する | 自社接点の外にある買う兆候を拾えるか | alert は来るが、誰が動くか決まっていない |
| 4 | 設計する | シグナルからリスト、メッセージ、タスク、改善会議までつながるか | ツール担当者だけに閉じる |
| 5 | 半自律運用に寄せる | AI が下書きや優先順位を作り、人が境界を確認できるか | 自動化範囲が先に広がり、監査が遅れる |
この5段は一直線の成熟度表ではありません。Stage 3のツールを先に入れても、Stage 2の定義が弱いと通知が積まれるだけです。Stage 5のAIを試しても、誰が承認し、どの履歴を残すかがなければ現場では使われません。
大事なのは、次の段へ進む前に「営業が今日使う動線」へ戻すことです。
2026年5月19日時点の確認
ここから先は、読み方を支える時点メモです。会社の最新状態として固定せず、導入検討時は出典を見直してください。
| 出典 | 2026-05-19に確認した内容 | 記事での扱い |
|---|---|---|
| Sales Marker corporate page | Sales MarkerはWeb検索行動の可視化とAIを前面に出し、インテントセールスを案内している | ベンダー主張として扱い、成果条件は運用設計で見る |
| Salesforce company story | Salesforce は worldwide company count を公式 company page で案内している | CRM 普及の例として扱い、数字そのものは固定しない |
| HubSpot investor filing | HubSpot は顧客関連の記述や事業指標を investor filing で開示している | 公開会社の時点情報として読み、導入判断は機能と運用に戻す |
| 6sense Sales Alerts | 6senseは購買ステージ、Web訪問、競合調査などを営業通知へつなげる機能を案内している | 通知そのものではなく、営業がどう使うかを見る |
| EDINET FAQ / API | EDINETはAPI利用にAPIキーが必要で、書類情報の取得に関するFAQを公開している | 公開開示データを扱う際の出典として読む |
| Gビズインフォとは | gBizINFOは検索、REST API、ダウンロードで法人関連情報を扱えると説明している | 国内の公開データ層の代表例として扱う |
Stage 1→2: 記録を営業の見返りへ変える
SFA 活用の最初の壁は、入力率そのものではありません。入力された情報が、営業担当者にとって意味のある形で返ってくるかです。
1か月目: 入力項目と見返りを絞る
まず、SFA の入力項目を棚卸しします。必須項目が多すぎると、入力は埋まっていても中身が薄くなります。最初にやるべきことは、項目を増やすことではなく、次の行動に効く項目だけを残すことです。
| 見る項目 | 残す理由 | 返し方 |
|---|---|---|
| 次の行動 | 営業とマネージャーが同じ案件を見られる | 週次アジェンダとタスクに入れる |
| 停滞理由 | 商談段階が止まった原因を後で読める | 停滞案件の見直しに戻す |
| 相手の役割 | 誰の不安を解くべきかを分けられる | メッセージと商談準備に戻す |
| 流入元 | マーケ施策と商談のつながりを見られる | MQL条件の見直しへ戻す |
| 失注理由 | 次の顧客セグメントや反論処理を変える材料になる | 月次の学習メモに戻す |
ここで重要なのは、「記録したら何が返るか」を1つだけでも実装することです。たとえば、過去の接点が増えている企業を朝の営業アジェンダに出す。停滞日数が長い案件をマネージャーの確認対象に入れる。これだけで、入力は事務作業ではなく営業の道具になります。
2か月目: マーケと営業の受け渡しをそろえる
次に、マーケと営業で MQL の条件をそろえます。マーケ側の「関心あり」と営業側の「動く価値あり」は別物です。このずれを放置すると、リードは渡されても動かれません。
MQL定義は、単なる点数ではなく、マーケと営業の受け渡し条件として置きます。
| 項目 | 決めること |
|---|---|
| 条件 | どの行動、属性、出典を重ねたら営業へ渡すか |
| 担当者 | 受け取った後、誰が最初の接点を持つか |
| SLA | どれくらいの時間内に動くか |
| 返却理由 | 営業が動かない場合、どの理由をマーケへ戻すか |
| 見直し周期 | どの会議で条件を直すか |
この条件があると、「質が悪い」「フォローされない」という感情論から、条件と反応の見直しへ移れます。
3か月目: 分析を営業会議に組み込む
Stage 2の目的は、立派なダッシュボードを作ることではありません。営業会議で次の行動を変えることです。週次で見るものは3つに絞ると運用しやすくなります。
- 今週シグナルが強くなった企業
- 商談段階の間で停滞している案件
- 失注理由と、次に変えるメッセージ
この3点を営業会議のアジェンダに入れると、会議は「数字を報告する場」から「行動を変える場」へ寄ります。
Stage 2→3: 自社接点の外にあるシグナルを拾う
自社サイト訪問、資料請求、セミナー参加は、自社とすでに接点を持った相手のシグナルです。Stage 3では、その外側にある検討の兆候を見ます。
インテントデータを使うときは、ツール名より先に次の3点を決めます。
| 論点 | 決めること |
|---|---|
| 何をシグナルと読むか | 検索、求人、競合閲覧、資料閲覧、公開資料更新などのどれを使うか |
| 誰が動くか | SDR、AE、パートナー、マネージャーのどこへタスクを出すか |
| 何を言うか | シグナルからメッセージへ変換する文脈をどこまで持たせるか |
Sales Marker、FORCAS、6sense、Bomboraのようなツールは、このシグナルを拾うための部品です。導入すれば自動で成果が出るわけではありません。どのシグナルを、どの基準で、どの行動に変えるかを決めないと、高価な通知箱になります。
詳しくは → インテントセールスとは？Sales Marker・FORCAS・6senseの実力と限界
Stage 3→4: GTMエンジニアリングで営業の流れを設計する
GTMエンジニアリングの価値は、単一のツールを上手に使うことではありません。データ取得、リスト、メッセージ、タスク、配信、改善会議を1本の営業の流れとしてつなぐことです。
5段階進化モデルの詳細
同じツールでも差が出る理由
同じCRM、同じインテントデータ提供会社、同じ外部データ補完ツールを使っても、成果はそろいません。差が出るのは、次の設計が違うからです。
| 設計項目 | 弱い例 | 強い例 |
|---|---|---|
| ICP | 業界と規模だけで切る | 課題、導入障壁、決裁構造まで仮説化する |
| シグナル | ツールが出した通知をそのまま使う | 自社商材に近い変化だけを重ねる |
| メッセージ | 一斉テンプレートを送る | シグナルと相手の役割に合わせて文脈を変える |
| 改善 | 返信率だけを見る | リスト、メッセージ、受け渡し、失注理由を同時に見直す |
| 担当 | ツール管理者だけが触る | 営業、RevOps、マネージャーがそれぞれ反応を戻す |
この意味で、GTMエンジニアは「Clayが使える人」ではなく、営業の流れを継続改修する人です。
詳しくは → GTMエンジニアとは？営業の仕組みを設計する役割の読み方
国内の公開データ層をどう使うか
日本のBtoB営業では、EDINET、gBizINFO、建設業許可、登記情報など、公開データを営業シグナルに変えられる場面があります。ただし、公開データを集めること自体は目的ではありません。
日本市場の独自データソース
| データ層 | 使い所 | 注意点 |
|---|---|---|
| EDINET | 上場企業の開示文書から課題テーマを読む | APIキー、縦覧期間、提出タイミングを出典で確認する |
| gBizINFO | 法人情報、補助金、調達、表彰などを見る | 出典元と更新頻度を確認し、万能な営業リストにしない |
| 建設業許可 | 建設業向けの企業分類に使う | 許可情報だけでは購買意図にならない |
| 登記情報 | 役員変更や所在地変更の背景を調べる | 取得コスト、権利、利用目的を確認する |
| 既存接点 | 顧問、紹介、過去案件、パートナーを重ねる | 接点のない営業だけで完結させない |
公開データは、単体ではリストを長くするだけです。価値が出るのは、自社の理想顧客像と営業の次の行動へ結びつけたときです。
「紹介」をデータで狭くする
日本の BtoB 営業では、紹介や顧問ネットワークが強く残ります。GTMエンジニアリングはそれを否定するものではありません。むしろ、紹介依頼を狭くできます。
従来は「製造業で困っている会社を紹介してください」という広い依頼になりがちです。営業の流れが整うと、「この課題テーマが開示に出た企業の、情報システム部門につながる人を知っていますか」と聞けます。
これは、人脈頼みから抜け出すというより、人脈の使い所を明確にする動きです。
詳しくは → 日本のBtoB営業はなぜ「顧問頼み」なのか？データ × 関係性のハイブリッドGTM
Stage 5: AI GTM は自動化範囲より guardrail を先に置く
AI GTMは、リスト作成、メッセージ草案、商談準備、フォロー、要約、次の行動の提案をAIが補助する運用モデルとして読む方が安全です。
ここで先に決めるべきなのは、どこまで自動送信するかではありません。
| guardrail | 決めること |
|---|---|
| 承認 | どのメッセージは人が読むか |
| data | どの顧客情報を prompt に入れてよいか |
| 監査 | AIが作ったリスト、メッセージ、判断の履歴をどこに残すか |
| exception | 苦情、法務、契約、価格の論点を誰へ渡すか |
| 改善 | AIの提案が外れたとき、どのシグナルを直すか |
AIを入れても、基礎は同じです。入力、受け渡し、シグナル、改善会議が弱いままだと、AIは営業の詰まりを高速化するだけです。
よくある失敗パターン
1. ツール先行で始める
「競合が入れたから」「展示会で良さそうだったから」で導入すると、目的と指標が後付けになります。先に決めるべきなのは、どの商談行動を変えたいかです。
2. 全社一斉で始める
全社導入は、要件定義だけで時間が溶けやすい。まずは1チーム、1顧客セグメント、1本の営業の流れで試し、うまく回った型だけ横展開します。
3. 分析が目的になる
ダッシュボードが増えても、営業が次に何をするか決まらなければ価値は出ません。分析の出口は、企業、メッセージ、タスク、会議アジェンダのどれかに固定します。
4. 設計する人がいない
GTMエンジニアをいきなり外部採用できなくても、営業企画やRevOpsの人がAPI、表計算、LLM、CRM自動化を少しずつ扱えるだけで前に進みます。重要なのは、コード量より仮説と改善の質です。
段階別チェック
自社の状態は、次の問いで見ます。
Stage 1: 記録
- SFA/CRM に商談と活動が残っている
- 必須項目が多すぎず、現場が埋められる
- manager が同じ記録を見て会話できる
Stage 2: 分析
- MQL、SQL、商談 stage の定義がそろっている
- 停滞案件と失注理由を週次で見ている
- ダッシュボードの数字が次の行動に変わっている
Stage 3: 検知
- 自社接点の外側にあるシグナルを少数選んでいる
- シグナルごとに担当者とメッセージが決まっている
- 通知の数ではなく、動いた結果を見直している
Stage 4: 設計
- 複数データを企業の優先順位へ重ねている
- リスト、メッセージ、タスク、改善会議が同じ営業の流れに入っている
- 営業からの反応でシグナルを直している
Stage 5: AI 補助
- AI が作る草案と、人が承認する境界が決まっている
- prompt に入れる情報と入れない情報が分かれている
- AIの出力履歴を見直せる
営業DX診断チャート
まとめ
SFAを入れたのに営業が変わらないなら、見るべきなのは「次のツール」ではなく営業の流れです。
入力した情報は営業へ返っているか。マーケから渡るリードの意味はそろっているか。シグナルからメッセージとタスクまでつながっているか。AIを入れる前に、承認と改善会議の境界は決まっているか。
この問いに答えられるようになると、営業DXはツール導入プロジェクトではなく、営業の動きを継続改修する仕組みになります。
関連記事
本記事はネクサフローのGTMエンジニアリングシリーズの一部です。
