営業プロセスの設計手法|構造化・段階化・型化の3ステップで再現可能な型を作る
営業プロセスを設計しようとしたものの、何から手をつければよいかわからずに止まった経験はないでしょうか。あるいは、設計したはずなのに「現場が入力してくれない」「フェーズの使い方が担当者によってバラバラ」という状況に直面したことがあるかもしれません。こうした問題の多くは、設計の前提や設計作業の途中で必要なステップが抜けていることに原因があります。
本記事では、営業プロセスの設計を「構造化・段階化・型化」という3つのステップに分けて解説します。このフレームを使うことで、「フロー全体を描く」「フェーズと移行条件を定義する」「アクションレベルまで型に落とす」という3つの作業を、どのような順序で、何を目的に進めるのかが明確になります。
営業プロセス設計とパイプライン管理では、営業プロセスとパイプライン管理の体系的な全体像を整理しています。本記事では設計手法そのものに絞って解説します。
営業プロセス設計とは何か
営業プロセスの「設計」とは、リード獲得から受注・顧客維持に至る一連の活動を、再現可能な手順として整理する作業です。
設計という言葉はやや抽象的に聞こえますが、やることはシンプルです。「成果を出している担当者が何をしているかを観察し、それを誰でも追えるかたちで文書化する」作業です。個人の頭の中にある勝ちパターンを組織の共有財産にすることが、設計の主な目的です。
営業活動との違い:「やっていること」と「設計されたプロセス」
営業担当者が日々行う個々のアクション(電話・メール・商談・資料送付など)は「営業活動」です。一方、設計されたプロセスとは、それらの活動を「どの順序で」「どのタイミングで」「何を確認した上で」行うかを定めたフローとフェーズの体系を指します。
設計がない状態では、担当者Aは「最初に課題ヒアリングの商談を設定する」、担当者Bは「まず資料を送ってから商談する」という具合に、進め方が個人ごとに異なります。新人がどのやり方を参考にすればよいか分からず、マネージャーも「この案件は今どこにいるのか」を担当者に聞いて回らなければ把握できません。設計されたプロセスがあると、営業の進め方や案件の状態を共通の基準で管理できるため、マネージャーはデータで全体を把握できるようになります。
設計が必要になるタイミング
少人数のチームでは、担当者どうしが毎日会話しているため、暗黙知の共有が自然に成立しやすく、設計がなくても大きな問題にならないことがあります。しかし次のようなタイミングで設計の必要性が一気に高まります。
- チームが拡大し、日常的な会話だけでは営業ノウハウや案件状況を共有しきれなくなったとき
- 担当者の離職・異動が発生し、引き継ぎが必要になるとき
- マネージャーが個別指導から組織レベルの指導に移行するとき
- 新人の立ち上がりを早めるため、オンボーディングを整備するとき
設計を「問題が起きてから」始めると、属人化がすでに進んだ状態から再構築することになるため、こうした兆候が見えた段階で着手することが望ましいでしょう。
設計が機能しない典型的な失敗パターン
設計のステップを説明する前に、失敗パターンを整理しておきます。「手順どおりに設計したのにうまくいかなかった」というケースの多くは、設計の手順だけでなく、その前提に問題があります。以下の4つを先に把握しておくことで、設計作業中の見落としを防ぎやすくなります。
パターン①:売り手の行動を起点に設計している
「提案→デモ→見積→クロージング」という自社の活動でフェーズを作ると、顧客の検討状況と合わないフェーズが生じることがあります。顧客がまだ課題を認識していない段階でも、営業担当者が「提案書を送った」という理由で「提案フェーズ」と記録されてしまいます。
こうなると、フェーズ別の集計は数字として出ますが、「提案フェーズにある案件のうち何割が受注に進むか」という指標が実態を正しく反映しにくくなります。フェーズ名と顧客の状態がズレているためです。
改善するには、顧客の購買ステップを先に確認し、それに対応するかたちで自社の活動を配置することです。詳細はステップ1(構造化)で扱います。
パターン②:フェーズを設けたが移行条件を定義していない
フェーズの名前は決まっているが、「いつ次のフェーズに進むか」が担当者の主観に委ねられているケースです。同じ状況の案件でも、Aさんは「提案中」、Bさんは「検討中」と入力します。データとしては案件数が出るものの、フェーズ別の転換率は、担当者ごとに異なる判断基準をもとにした数字となり、意思決定の根拠になりません。
移行条件(EXIT条件)の設計は、フェーズ定義と同じくらい重要であるにもかかわらず、多くの設計で省略されています。本記事ではステップ2でこの手順を具体的に示します。
パターン③:フェーズが多くなりすぎている
フェーズを細かく設定しすぎると、どのフェーズを選ぶべきか判断しにくくなり、担当者の入力・更新負荷が高まります。「フェーズを細かくすれば管理精度が上がる」と考えがちですが、入力されないデータはどれだけ精緻に設計しても機能しません。
BtoB営業では5〜7フェーズ程度が一つの目安ですが、適切な数は商材や営業サイクルによって異なります。フェーズ数を増やすことより、各フェーズの移行条件を明確にすることが重要です。
パターン④:設計を一度やって終わりにしている
営業環境・商材・組織規模・競合状況が変われば、プロセスも見直しが必要になります。設計を「一回完成させるプロジェクト」として扱うと、時間の経過とともに現場の実態と設計がズレていく可能性があります。定期的なレビューをあらかじめ運用に組み込んでおくことが、プロセスの形骸化を防ぐうえで重要です。
お役立ち資料
営業管理を「型」にする
属人化しがちな営業管理を、誰が担当しても回る仕組みに変える設計手順をまとめました。
資料をダウンロードするステップ1:構造化:顧客の購買フローに合わせたプロセス全体の設計
設計の最初の作業は、自社の営業活動をリード獲得からアフターフォローまで一本の流れとして書き出すことです。重要なのは「売る側の都合」ではなく「顧客がどう検討を進めるか」を起点にすることです。顧客の検討プロセスに沿って整理することで、実際の商談の動きに合ったフローを設計しやすくなります。ここでは細部の定義よりも、まず全体構造の把握を優先します。
顧客の購買ステップを確認する
BtoBの顧客は、おおむね「課題認識→情報収集→比較検討→意思決定→購入」というステップを経て購買に至ります。設計の出発点は、このステップのどこで自社が初めて接触し、どのように最終意思決定まで関与するかを整理することです。
BtoBでは、購買に複数の関係者が関与することも少なくありません。実際の購買場面では、現場担当者・情報収集担当者・予算承認者・最終決裁者がそれぞれ異なるタイミングで関与します。「誰がどのタイミングで関与するか」を可視化するDMUマップは、構造化の段階で用意しておくと、後のフェーズ設計に役立ちます。
既存の営業活動を洗い出す
構造化の実作業は、自社の受注実績から始めます。受注実績のある複数の担当者に「直近の受注案件で何をしたか」をヒアリングし、活動を時系列で書き出します。
この作業で特に重要なのは、「言語化されていない暗黙のステップ」を拾うことです。担当者は意識していないが成果に直結している行動があります。例えば「提案書を出す前に必ず競合他社の状況を確認している」「決裁者に会う前に現場担当者と1対1で事前調整している」といった行動です。こうした行動を見落とすと、成果につながっていた行動が標準プロセスから抜け落ちる可能性があります。
ヒアリングの対象は1名ではなく、受注率の高い複数の担当者に広げることで、個人特有のスタイルと組織として再現できる共通パターンを区別しやすくなります。
フロー全体を1枚に整理する
ヒアリング結果を整理し、「リード獲得→ナーチャリング→初回接触→ニーズ確認→提案→クロージング→受注→アフターフォロー」という大きな流れに配置します。
この段階では、フェーズの細かい定義や数よりも「どこで何が起きているか」の全体像を把握することを優先してください。後のステップ2でフェーズを定義しますが、全体像がないままフェーズを設計しようとすると、プロセスの途中が抜け落ちたり、前後のつながりが不自然になったりする可能性があります。
例えばIT業界では、「ウェビナーや問い合わせをきっかけに初回接触し、課題ヒアリング商談→提案→デモ→見積り提示→契約」と進むケースがあります。また製造業では、「展示会や取引先からの紹介を起点に、技術要件の確認商談→試作品の評価→価格交渉→発注」という流れが多く、意思決定プロセスが長く複数部門が関与します。業種によってフロー全体の長さや関与者の構成が異なるため、一般的な事例をそのまま当てはめるのではなく、自社の受注実績をもとに設計することが重要です。
ステップ2:段階化:フェーズの定義と移行条件の設計
全体のフローを書き出したら、次はそれをSFAやパイプライン管理で使えるように「フェーズ」として段階化します。フェーズの定義と並んで、「いつそのフェーズに進んだとみなすか」という移行条件(EXIT条件)の設計が、段階化の成否を分ける最重要ポイントです。移行条件を曖昧にしたまま運用を開始すると、フェーズ別のデータが担当者の主観で記録され、意思決定の根拠として使いにくくなります。フェーズを定義するだけでなく、どのような状態になったら次のフェーズへ進むのかまで設計することが必要です。
フェーズ数の決め方
BtoB営業では5〜7フェーズ程度が一つの目安ですが、適切な数は商材やセールスサイクルによって異なります。フェーズが増えるほど入力負荷が上がり、運用が複雑になる可能性があります。フェーズを設けるかどうかの判断基準は一つです。「そのフェーズの転換率が低かった場合、独立した改善施策を打つ必要があるか」を確認します。打ち手が変わらないなら、隣のフェーズと統合することも検討します。
受注までの期間が短く、営業プロセスが比較的シンプルな商材ではフェーズを少なくし、大型案件や複数部門が関与する案件では、必要に応じて細かく設定します。
各フェーズの定義の詳細や業種別の設計例については、営業フェーズの定義と移行条件で解説しています。
フェーズの定義テンプレート
各フェーズについて、次の4項目を定義します。この4項目が揃うことで、「フェーズの名前だけが存在する設計」から「誰が使っても同じ意味で運用できる設計」に変わります。
- フェーズ名 担当者が直感的に理解できる名前
- 定義 このフェーズにある案件とはどういう状態か
- 代表的なアクション このフェーズで行う主な活動
- 移行条件(EXIT条件) 次のフェーズに進んでよいと判断する客観的な条件
「ニーズ確認フェーズ」を例に示します。
| 項目 | 内容 |
|---|---|
| フェーズ名 | ニーズ確認 |
| 定義 | 顧客と初回商談が完了し、課題・予算・検討時期の確認に入っている状態 |
| 代表的なアクション | ヒアリング商談、社内稟議フロー確認、競合調査 |
| 移行条件(EXIT条件) | 自社で定めた必要な確認項目を満たし、顧客から提案を受ける意向が確認できた状態 |
移行条件の設計手順
移行条件を担当者の感覚ではなく、自社の受注実績をもとに設定する手順は次のとおりです。
- 受注案件を分解する 直近の受注案件を複数選び、「いつ、どんな出来事があって次のフェーズに進んだか」を時系列で書き出す。
- 失注・停滞案件と比較する 受注案件と比較し、「受注案件では起きていたが、停滞・失注案件では起きていなかった出来事」を抽出する。これが移行条件の候補になります。
- 顧客側の行動を条件にする 「提案書を送付した」(売り手の行動)ではなく、「顧客が提案書のレビューを終え、次回の検討会議に自社担当を呼ぶと確認できた」(顧客側の行動)のように設計します。売り手の行動を条件にすると、顧客の検討状況にかかわらずフェーズが進んでしまうためです。
- チームで合意する 条件の解釈が担当者によって揺れないよう、具体的な事例を使ってチームで認識を合わせます。「次回の商談日程が決まった状態を、次のフェーズへの移行条件とするか」といった細部まで確認することが重要です。
SFAへの落とし込み
フェーズと移行条件を設計したら、SFAのフェーズ設定に組み込みます。ポイントは、移行条件の確認を「担当者の記憶に任せる」のではなく、日々の運用に組み込むことです。
フェーズを変更する際に移行条件を確認できるよう、必要な確認項目や入力ルールをSFA上の運用に反映します。
ツール選定の詳細や、営業パイプラインの可視化への落とし込み方は、あわせて参照してください。
ステップ3:型化:アクションレベルの標準化と再現可能な営業の型
フェーズの定義が終わったら、最後は各フェーズで「誰が・何を・どの順序で行うか」をアクションレベルまで落とし込む作業です。これが「型化」です。フェーズごとに必要な行動を具体化することで、担当者が次に何をすべきかを判断しやすくなります。
「型」に盛り込む3つの要素
型として整備する内容は次の3つです。
- アクションの定義 各フェーズで行うべき営業活動(電話・メール・商談・資料送付・デモなど)を列挙し、優先順位を明示する。「やってもいいことのリスト」ではなく、「この順序でやる」という基本的な行動の流れとして定義します。
- ツール・テンプレートの整備 トークスクリプト・メールテンプレート・提案書のひな型など、担当者が迷わず使える素材を型に組み込む。「何を言うか・どう書くか」という判断にかかる負担を減らすことで、担当者はアクションの質を高めることに集中できます。
- KPIの設定 各フェーズに対して必要なKPIを設定する。例えば「ニーズ確認フェーズ」であれば「初回商談から2週間以内のヒアリング完了率」、「提案フェーズ」であれば「提案から1週間以内の顧客フィードバック取得率」といった形です。KPIの詳細な設計については、営業パイプライン指標の設計と選び方を参照してください。
成果が出ている営業担当者の行動を型に抽出する方法
型化の素材は、社内の成果データです。受注率の高い担当者の商談記録やSFAのアクション記録を分析し、共通パターンを見つけます。
具体的には、受注率の高い複数の担当者のSFA上のアクション履歴を確認し、「初回商談後の次回アポ取得までの日数」「提案前に送付している資料の種類」「クロージング前に行っている確認事項」などの共通行動を書き出します。次に、受注率が平均的な担当者と比較し、「受注率の高い担当者だけが行っている行動」を抽出します。
発見した共通パターンを型として文書化するとき、「何をするか」だけでなく「なぜそのアクションが有効か」という仮説も一緒に記録します。型の「理由」が分かると、担当者が状況に応じて応用できるようになります。例えば「提案前に競合比較資料を顧客に送る」という型には「顧客が比較検討する際の評価軸を整理しやすくする」という仮説を添えます。
設計で活用できるフレームワーク
型化の各フェーズで使える代表的なフレームワークを、「どのフェーズで使うか」と紐づけて整理します。フレームワークは使うこと自体が目的ではなく、「型に具体性を持たせるための方法」として活用してください。
- BANT (Budget / Authority / Need / Timeframe):ニーズ確認フェーズのヒアリング設計に活用します。顧客の購買意思決定に必要な4要素を確認する軸として使い、BANTが揃った状態を「提案フェーズへの移行条件」に設定できます。
- SPIN (Situation / Problem / Implication / Need-payoff):初回商談からニーズ確認フェーズの質問設計に活用します。状況・問題・影響・解決欲求の順で質問を組み立てることで、顧客自身が課題やその影響を整理し、解決策の必要性を検討しやすくなります。
- DMUマップ 提案フェーズの意思決定者把握に活用します。誰が最終決裁を行い、誰が影響を与えるかを可視化することで、提案先と内容の優先順位を明確にします。
- FABE (Feature / Advantage / Benefit / Evidence):提案・クロージングフェーズの提案書設計に活用します。機能→優位性→顧客便益→証拠の順で構成することで、顧客にとっての価値が伝わりやすい提案内容になります。
これらのフレームワークは、ステップ1・2で設計したフローとフェーズの中に「アクションの質を高める具体的なやり方」として組み込むことで活用しやすくなります。フレームワークだけを導入しても、実際の営業プロセスと結びついていなければ、担当者の行動は変わりません。
設計後の運用と改善サイクル
設計は一度完成させれば終わりではありません。営業環境・商材・チーム構成が変わると、設計したプロセスも見直しが必要になります。定期的なレビューをあらかじめ設計に組み込むことが、プロセスの形骸化を防ぐ上で重要です。「設計したプロセスを守らせる管理」ではなく、「プロセスが現実に合っているかを定期的に問い直す仕組み」が、継続的な改善につながります。
改善の起点は「フェーズ別転換率」の確認
設計後のプロセス改善は、「全体の受注率が上がった・下がった」ではなく、「どのフェーズで転換率が変化したか」を起点にします。全体の受注率だけを見ていると、問題がどこで発生しているかが特定できず、対策が「モチベーション向上」や「活動量増加」といった抽象的なものになりやすいからです。
フェーズ別転換率の確認は、SFAのファネル分析レポートや案件ボードを使い、フェーズごとの案件数の推移と停滞案件数を週次または月次で確認します。「ニーズ確認フェーズから提案フェーズへの転換率が先月比で10ポイント下がった」という事実が確認できれば、「ヒアリングの質か、競合対策か、担当者スキルか」という観点に絞って原因を確認できます。
問題となっているフェーズが特定できたら、そのフェーズの移行条件・アクション定義を見直します。改善の進め方の詳細については、パイプライン改善と売上予測の方法を参照してください。
チームで設計を育てる仕組み
定期的に「プロセスレビュー会議」を設定します。参加者は営業担当者とマネージャーを基本とし、案件の発生源を担うマーケティング担当者が加わることで、リード獲得から受注までの一貫した視点でプロセスを評価できます。
議題として設定するのは2点です。「今のフェーズ定義・移行条件に、現場で使っていて違和感はないか」「勝ちパターン・負けパターンが変わってきていないか」。設計をマネージャーだけが管理・更新するのではなく、現場の意見を定期的に取り込む仕組みにすることで、担当者もプロセスの改善に関わりやすくなります。現場が「このフェーズ定義は実態に合っていない」と感じながら入力を続けていると、データが実態から乖離し、改善のサイクルそのものが機能しなくなります。
データ蓄積が改善精度を上げる
プロセス設計とSFAへの入力を連動させることで、改善に必要なデータが蓄積されます。フェーズが定義され、移行条件が統一されてはじめて、蓄積されたデータを同じ基準で比較できるようになります。
設計とデータが揃った状態では、AIを活用した案件管理にもデータを活かしやすくなります。例えば、Mazrica SalesのようなSFA/CRMでは、Growthプラン以上でAIインサイトが案件の進捗リスクや類似案件のパターンを提示する機能があります。しかし、フェーズの使い方が担当者によってバラバラで、移行条件も不統一なままでは、AIが参照するデータ自体が不正確になり、示唆の精度は低いままです。設計とデータの整備は、AIを実務に役立てるうえでも重要です。
まとめ
本記事では、営業プロセスの設計を「構造化→段階化→型化」という3つの階層に分けて解説しました。この順序には意味があります。フロー全体の構造が描けていない状態でフェーズを定義しようとすると、プロセスの途中が抜け落ちます。フェーズの移行条件が定義されていない状態で型化しても、データが統一されず改善に活用しにくくなります。3つを順番に積み上げることで、現場で運用しやすい営業プロセスを設計できます。
設計のどこから着手すればよいか迷う場合は、まず既存の受注案件を複数選び、営業担当者がどのような行動を取ったかを時系列で書き出してみましょう。ヒアリングと記録の手間はかかりますが、「何が勝ちパターンか」を自社データから導き出す以上に確実な出発点はありません。外部のフレームワークはその整理を補助するものとして活用します。
設計後は定期的なレビューを運用し、現場の意見を仕組みとして組み込み、現場の感覚とデータの両方から継続的に更新していくことが、プロセスを長期にわたって機能させるうえで重要です。
営業プロセスの改善・パイプライン管理の全体像については、営業プロセス設計とパイプライン管理を参照してください。
よくある質問
Q 営業プロセスとはどのようなものですか?
営業プロセスとは、リード獲得から受注・顧客維持に至るまでの一連の営業活動を、再現可能な手順として整理した体系のことです。個々の担当者が日々行うアクション(電話・商談・提案など)を「フェーズ」という段階に分け、どの順序で何を行うかを組織として定義したものです。設計されたプロセスがあると、成果の出ている行動を組織全体で再現しやすくなり、属人化の解消や新人の早期立ち上がりに役立ちます。
Q 営業プロセスの例を教えてください。
BtoBの典型的な営業プロセスは「リード獲得→ナーチャリング→初回接触→ニーズ確認→提案→クロージング→受注→アフターフォロー」という8つのステップで構成されます。IT業界ではウェビナーや問い合わせからのリードが起点となり、ヒアリング商談・デモ・見積りへ進むケースがあります。製造業では技術要件の確認や試作品評価が中間に入るなど、商材・業種によってフロー全体の長さと関与者の構成が異なります。自社の受注実績をもとに複数の担当者にヒアリングし、実態に即したフローを書き起こすことが設計の出発点です。
Q 営業プロセスにおけるKPIの例は何ですか?
フェーズごとに必要なKPIを設定します。代表的な例を挙げます。「初回接触フェーズ」ではアポ取得率、「ニーズ確認フェーズ」ではヒアリング完了率、「提案フェーズ」では提案書提出日までの日数・顧客からのフィードバック取得率、「クロージングフェーズ」では受注率・見積り提出から受注までのリードタイムなどが使われます。
Q 営業プロセスの可視化はどうすれば実現できますか?
可視化は3つの段階で進めます。まず、フェーズを定義してSFAに案件を登録し始める(データの蓄積)。次に、ファネル分析レポートや案件ボードを使い、フェーズごとの案件数と転換率を定期的に確認できる状態にする(指標の確認)。最後に、停滞案件・フェーズ別の案件数の変化から問題を特定し、改善につなげる(意思決定への活用)。
Q 営業プロセスを設計するとき、何から始めればよいですか?
まず、直近の受注案件を複数選び、成果を出している複数の担当者に「その案件で何をしたか」をヒアリングすることから始めます。活動を時系列で書き出し、フロー全体の構造を1枚の紙に整理します。この「構造化」が最初のステップです。設計ツールや複雑なフレームワークより、まず自社の受注実績を確認することで、実態に合ったプロセス設計につながります。







