営業組織のスケール化｜勝てる組織をスケール可能にする4つの視点

チームが10名を超えたあたりから、「採用を重ねても成果が比例して増えない」「マネージャーの目が行き届かなくなった」という状態に陥る営業組織があります。その正体は、成長の仕組みが「人の頑張り」に依存したまま規模だけが大きくなったことにあります。

この記事では、営業組織のスケール化を「人員を増やすこと」ではなく「成果を再現可能な状態にすること」と定義し、スケール可能な組織を作るために取り組むべき4つの視点と、よくある失敗パターンを実務粒度で解説します。

なお、フェーズ全体の俯瞰図を先に把握したい方は、営業組織の成長と打ち手をあわせて参照してください。

営業スケールとは何か：「人数を増やす」こととの根本的な違い

営業スケールとは、人員やコストを比例的に増やすことなく、売上・商談数・受注率を継続的に拡大できる状態を指します。人数を2倍にして売上が2倍になるのは「スケール」ではなく「増員」です。スケール化の本質は、再現性のある勝ち筋を仕組みとして組み込み、誰が担当しても一定の成果が出せる組織を設計することにあります。本セクションでは、その前提となる定義と、スケール施策が必要になるタイミングの見極め方を整理します。

スケール化が求められるタイミング

スケール施策が必要になるのは、特定の人数を超えたときではなく、「属人的な成長が通用しなくなる兆候」が現れたときです。人数の閾値よりも、次の兆候が複数重なったときを目安にしてください。

• 新しく入ったメンバーが独り立ちするまでの期間が、以前より明らかに長くなった
• マネージャーが個別の商談フォローに追われ、組織全体の改善に手を付けられない
• トップセールスが担当を外れた案件の受注率が、他のメンバーと比べて大きく下がる
• 月間の商談数を増やしたいが、担当者の稼働数が上限になっていて増やせない
• 同じ失注理由が繰り返し報告されているが、対処策が個人の工夫にとどまっている

これらは、成果の源泉が「仕組み」ではなく「特定の人」にあることを示すサインです。営業の属人化解消が先行課題として残っている可能性もあるため、兆候を確認したうえで次のステップに進んでください。

「スケール」と「スケーラビリティ」の使い分け

ビジネス文脈では、次の3つの使い分けが一般的です。

• スケールする（動詞） 投入リソースを大きく増やさなくても、成果・売上・組織規模を拡大できている状態になること。「このモデルはスケールする」のように使います。
• スケール可能（形容詞的） 仕組みや構造として、拡大に耐えられる設計になっていること。「スケール可能な営業プロセス」のように使います。
• スケーラビリティ（名詞） 拡大可能性・拡張性そのものを指す概念。「スケーラビリティの高い組織設計」のように使います。

本記事では「スケール化」を「スケール可能な状態への移行」と定義し、主に「スケール可能」の意味で扱います。単純な規模拡大（増員・増資）とは区別して読んでください。

スケール化に取り組む前に確認すべき条件

スケール化の施策を始める前に、組織の現状が「スケールできる状態にあるか」を確認する必要があります。属人化が解消されておらず、勝ちパターンが言語化されていない段階でスケール施策を始めると、属人的な成果をただ急拡大するだけになります。本セクションでは、スケール化に着手するための3つの前提条件を確認します。これらが整っていない場合、先に取り組むべき課題は営業の属人化解消や勝ちパターンの抽出と横展開になります。

前提1：属人化の解消が一定程度進んでいること

トップセールス1人への依存度が高い状態でスケールしようとすると、組織の拡大とともに「依存先が不在のとき成果が大きく落ちる」という構造的なリスクが拡大します。採用・育成コストをかけても、新しいメンバーが「その人のやり方」を見よう見まねで習得しようとするだけでは、立ち上がりに時間がかかり、かつ再現精度も低くなります。

属人化の解消が一定程度進んでいるかどうかの目安は次のとおりです。

• 月間商談数のうち、トップセールス1名への集中度が50%を下回っている
• トップセールスが1週間不在でも、チーム全体の商談創出数が極端に落ちない
• 新規メンバーが入ったとき、「誰に聞けばいいか」ではなく「どのドキュメントを見ればいいか」が明確になっている

これらが整っていない場合、スケール施策より先に属人化の解消に取り組むことを優先してください。

前提2：勝ちパターンが言語化・共有されていること

暗黙知としての勝ちパターンがある段階でスケールすると、個人差がそのまま拡大します。「あの人はなぜ受注できるのか」が説明できない組織では、新しいメンバーが増えるほど受注率のばらつきが広がります。

次のチェック項目で状態を確認してください。

• 受注した案件と失注した案件を見比べたとき、勝因・敗因のパターンが言語化されているか
• トップセールスの「初回商談の進め方」が、他のメンバーが再現できる形でドキュメント化されているか
• 業界・課題別の提案のポイントが、担当者の記憶ではなくチーム共有の資料として存在するか
• 新規メンバーのオンボーディングに、勝ちパターンを学ぶプロセスが組み込まれているか

これらが整っていない場合は、勝ちパターンの抽出と横展開を先行させてください。

前提3：基本的な組織体制が設計されていること

役割分担（インサイドセールス・フィールドセールス・カスタマーサクセス等の分業）が定義されていない状態でスケールすると、増えたメンバー全員が「全部やる」ことになり、生産性が担当者の稼働量に制約されたままになります。誰が何を担うかが決まっていないと、プロセスの標準化もKPI設計も「誰のための基準か」が不明確になります。

営業組織化の設計については別記事で詳しく扱っているため、体制定義が先行課題として残っている場合はそちらを先に参照してください。

スケール可能な組織を作る4つの視点

スケール化は単一の施策で実現するものではなく、4つの視点を同時に機能させることで成り立ちます。プロセスの標準化、データを使った判断の仕組み化、組織設計の見直し、そして継続的な改善ループの構築です。この4つを整合させることで、担当者が変わっても・チーム規模が変わっても、一定の成果が再現できる組織になります。以下では視点ごとに、具体的な取り組み内容と着手の優先順を説明します。

視点1：プロセス標準化（誰でも動ける「型」を組み込む）

プロセス標準化の目的は、「マニュアルを作ること」ではなく、「誰が担当しても同じ動きができる状態を作ること」です。この2つは似ているようで全く違います。マニュアルは作成した時点で価値が止まりますが、標準化は現場に定着して初めて機能します。標準化の対象を3つの層に分け、層ごとに整備の手順と定着の仕組みを設計することが実務上のポイントです。

標準化の対象は次の3層に分けて考えます。

1. トークスクリプト（何を言うか） フェーズごとの会話の骨格。初回アプローチ・初回商談・提案・クロージングそれぞれに「冒頭の言い出し方」「聞くべき質問の順序」「よくある反論への応答」を整理します。
2. 商談の進め方（どの順序で進めるか） フェーズの定義・移行条件・各フェーズで確認すべき事項のチェックリスト。「提案フェーズに移行するのはどのタイミングか」が担当者ごとにばらついていると、受注率の改善が再現できません。
3. タスク・ドキュメント（何を用意・記録するか） 商談前の準備物・商談後の議事録フォーマット・SFAへの入力項目の定義。ここが不統一だと、データを集めてもKPIの比較ができません。

トークスクリプトの整備手順

トップセールスの商談録音や商談記録から共通フレーズを抽出するのが、最も実態に近いスクリプトを作る方法です。手順は次のとおりです。

1. 直近3か月の受注案件から商談録音・議事録を10件以上抽出する
2. 初回商談・提案・クロージングの各フェーズで「受注案件に共通して使われている言い回し・質問の順序」を書き出す
3. 失注案件と比較し、「受注案件にあって失注案件にない要素」を特定する
4. 抽出した共通要素をフェーズごとのスクリプトのたたき台として整理し、トップセールスにレビューしてもらう
5. 新規メンバーが1人で使えることを確認基準にして調整する

標準化が定着しない理由と対処

標準化が「マニュアルの作成」で終わり機能しない理由は、整備したものが現場の評価・育成ループに組み込まれていないからです。作成後に次の仕組みを追加してください。

• 商談レビューへの組み込み 週次または案件ごとの商談レビューで、スクリプトのどのステップがうまくいったか・どこで詰まったかを確認する場を設けます。
• オンボーディングへの統合 新規メンバーが入ったとき、最初の30日間でスクリプトをロールプレイする機会を設計に含めます。
• 更新サイクルの定義 四半期に1回、商談レビューの蓄積から「スクリプトのアップデートが必要な箇所」を確認する担当者と日程を決めます。

標準化進捗の確認表

このチェックを定期的に行うことで、「整備済みのつもりで実は空白だった」フェーズを発見できます。

視点2：データ活用と意思決定の仕組み化（感覚から数値へ）

データ活用の目的は、マネージャーの目が届かなくなる規模でも、ボトルネックを数値で発見・対処できる状態を作ることです。10名以下の組織ではマネージャーが個別の商談状況を把握できますが、それ以上の規模になると感覚での管理が限界を迎えます。KPIを正しく設計し、データを意思決定に使う仕組みを整えることが、スケール化の判断基盤になります。

KPIの設計方法

「受注金額」を単独のKPIにしても、何が原因で目標を達成できていないかは分かりません。受注に至るプロセスをKPIとして分解することで、改善の打ち手を特定できます。

起点になるのは、営業生産性の方程式です。

営業生産性 ＝（商談数 × 受注率 × 単価）÷ 工数

この方程式のどの変数が詰まっているかを特定することが、KPI設計の第一歩になります。

• 商談数 リード獲得数・商談化率・有効商談創出数に分解します。
• 受注率 初回突破率・フェーズごとの通過率・キーパーソン接触件数に分解します。
• 単価 初回受注単価・クロスセル率・アップセル率に分解します。
• 工数 顧客対応時間・社内業務時間・案件あたりの接触回数に分解します。

これらのサブKPIをフェーズごとに可視化することで、「どこで案件が止まっているか」「どのフェーズの通過率が低いか」を数値で把握できるようになります。

ボトルネックの見つけ方

KPIツリーのどの指標が目標を下回っているかを確認する手順は次のとおりです。

1. 受注金額の目標に対する実績の差分を確認する
2. 商談数・受注率・単価の3変数のうち、目標比で最も乖離が大きいものを特定する
3. 乖離が最大の変数をサブKPIに分解し、どの段階で詰まっているかを確認する
4. 詰まっているフェーズのデータを抽出し、「滞留日数が長い案件の共通点」「失注案件のフェーズ」を確認する

たとえば、商談数は足りているが受注率が低い場合、次の診断を行います。

• フェーズごとの通過率を確認し、どのフェーズで案件が滞留または失注しているかを特定する
• 該当フェーズの商談記録を抽出し、失注理由・滞留の原因を分類する
• 分類した原因に対して、プロセスの修正・スクリプトの改善・キーパーソンへのアクセス戦略の見直しを検討する

データを意思決定に使うための条件

データが判断に機能するには、次の2点が整っている必要があります。

• SFAへの入力が行われていること データが存在しない状態でKPIを追っても実態は把握できません。入力が現場のメリットになる設計（次のアクションのリマインドが届く・商談の引き継ぎが楽になる等）と組み合わせて、入力習慣を先に定着させる必要があります。
• 「商談」の定義が統一されていること 商談数を追っても、メンバーによって「商談」の定義が違えば、比較も改善も機能しません。「商談フェーズに移行するのはどの状態か（例：先方の課題と予算の概算が確認できた状態）」を組織で統一することが先決です。

Mazrica Salesのような営業管理ツールでは、案件ごとのフェーズ・リードタイム・フェーズ滞留日数を可視化し、どのフェーズで案件が滞留しているかをチーム単位で確認できます。こうした機能を持つSFA/CRMを活用することで、ボトルネックの発見サイクルを短縮できます。ただしツールの導入自体がボトルネックの解消につながるわけではなく、上記のKPI定義・入力習慣の整備が前提になります。

視点3：組織設計の見直し（分業と管理幅の最適化）

組織設計の見直しにおいて、スケールフェーズで特に重要なのは「管理幅の限界」と「採用・育成をスケール前提で設計すること」の2点です。プロセスとデータが整っていても、マネージャーが個別対応に追われる状態では改善のループが回りません。また、採用基準が「即戦力重視」のままだと、新規メンバーの立ち上がりが個人の経験量に依存し続けます。

管理幅の限界と分業の必要性

マネージャー1人が育成・管理できるメンバー数は一般的に5〜8名程度とされています。ただしこれは業務の複雑性・商談のサイクル長・組織のプロセス成熟度によって変わるため、人数だけで判断するのは適切ではありません。

管理幅の限界に近づいているサインは次のとおりです。

• マネージャーが個別の商談フォローに週の40%以上の時間を使っている
• 育成のための1on1が月1回以下になっている
• チーム全体の改善施策（スクリプトの見直し・プロセスの修正等）に手を付けられない

この状態を解消するには、管理幅を超えた分の役割を別のポジションに移す分業設計が必要です。

インサイドセールスとフィールドセールスの分業タイミング

インサイドセールス（IS）とフィールドセールス（FS）の分業を導入する目安は、人数ではなく次の状態で判断します。

• 商談獲得の工数（アポ取り・初回接触）が営業担当の稼働の40〜50%を占めるようになった
• 商談対応の質低下が受注率の低下として数値に現れ始めた
• フルサイクル営業のまま商談数を増やそうとすると、担当者の稼働が上限に達する

この状態を放置すると、スケールの天井が「担当者の物理的な稼働数」になります。ISがリード獲得・アポ取りを担い、FSが商談対応に集中できる構造に移行することで、商談数の上限を担当者の稼働から切り離せます。

採用基準をスケール前提で設計する

スケール施策を始める前の採用は「即戦力」に依存しがちです。しかしスケールフェーズでは、「オンボーディングプロセスで一定期間内に立ち上がれる人材」を採用対象にシフトする必要があります。

採用基準の変え方は次のとおりです。

• 「過去の実績（受注金額・在籍企業）」から「習得スピード・プロセスへの適応性」に評価軸を移す
• 選考プロセスにロールプレイを組み込み、「フィードバックを受けて動きを変えられるか」を確認する
• 採用定員を「現在の欠員補充」ではなく「オンボーディングキャパシティ（同時に立ち上げられる人数）」から逆算して設定する

オンボーディングの設計

スケールフェーズのオンボーディングは、「先輩に聞きながら覚える」ではなく「プログラムに従って立ち上がる」設計に移行します。90日間のマイルストーン設定が実務上の目安になります。

• 30日目 製品・業界・社内プロセスの理解確認。ロールプレイで初回商談スクリプトを一人で使えること。
• 60日目 単独での初回商談実施。商談後のSFA入力が定義どおりに行われていること。フィードバックを受けて商談の進め方を修正できること。
• 90日目 担当案件を持ち、週次の商談レビューで自分の案件状況を説明できること。受注率が組織平均の70〜80%以上に達していること。

各マイルストーンで確認項目が満たされていない場合の対処手順（追加トレーニング・担当案件数の調整等）も事前に定義しておくことで、オンボーディングの質が担当マネージャーの個人差に依存しなくなります。

視点4：継続改善のループを組み込む（スケールは一時点の達成ではない）

スケール化は「仕組みを作って完了」ではなく、作った仕組みを継続的に改善し続けることで維持されます。プロセスを整備し、データを集め、組織を設計しても、改善のループが止まれば仕組みは陳腐化します。このセクションでは、改善活動が属人的にならないための仕組みの作り方を説明します。

改善サイクルの回し方

営業現場の改善サイクルは、四半期・半期単位のPDCAより、週次・月次の観察と即応が現実的です。商談の結果は数週間後に出るため、速いサイクルで観察・仮説・検証を回すことがスケールフェーズでは有効です。

週次の商談レビューを「次の練習設計」に戻す仕組みとして、次の3ステップを組み込んでください。

1. 週次のチームレビューで「先週の商談のうち、うまくいった点・詰まった点」を1件ずつ具体的に確認する
2. 詰まった点がスクリプトの問題か・知識の問題か・プロセス定義の問題かを分類する
3. 分類した原因を翌週のロールプレイまたは資料更新に反映し、2週後の商談で確認する

このループを業務として組み込むことで、改善が「時間があるときにやる活動」から「定例の業務」に変わります。

改善が止まる組織の特徴

改善ループが機能しない組織には、次の2つのパターンが典型的です。

• データは集まるが誰も活用しない SFAに入力は行われているが、入力されたデータを誰が・いつ・何の目的で確認するかが定義されていない状態です。対処としては、週次レビューのアジェンダに「先週のKPIの確認と気づき共有」を定例で組み込み、確認する指標と担当者を決めます。
• マニュアルは作られたが更新されない 整備当初は機能していたが、現場の状況変化に追いつかなくなった状態です。対処としては、「マニュアルの更新権限と更新頻度の定義」を運用ルールに含めます。四半期に1回、商談レビューの蓄積から「スクリプトに反映すべき変化があるか」を確認する担当者と日程を最初から決めておくことが重要です。

改善を「業務」に組み込む

次の取り組みを定例として設計することで、改善活動がマネージャーの個人的な熱量に依存しなくなります。

• 学びの共有会（月次） 担当者が直近1か月の商談から「うまくいった提案の工夫・失注の原因と対処の仮説」を1件ずつ持ち寄る場を設けます。発表内容はドキュメントに残し、新規メンバーのオンボーディングで参照できるようにします。
• 商談レビューの定例化（週次） 録画・議事録をもとに1件の商談を全員でレビューする時間を設けます。評価の観点（スクリプトの使い方・ヒアリングの深さ・クロージングのタイミング）を事前に統一します。
• KPIレビューの定例化（月次） 前月のKPIを確認し、目標対比でのギャップ・原因・翌月の改善仮説を確認します。「誰が・何を・いつまでに」を決めて議事録に残します。

スケールが止まる3つの失敗パターン

スケール施策に取り組んでも途中で止まってしまう組織には、共通した失敗パターンがあります。施策そのものの問題ではなく、実行・定着の段階で起きる「構造的なつまずき」です。3つのパターンを把握しておくことで、施策の設計段階から回避できます。

パターン1：ツール先行で導入したが入力されない

• 症状 SFA/CRMを導入し、管理側はダッシュボードを整備したが、現場への入力が定着しない。データが集まらないため活用できず、結果としてスプレッドシートやメモへの並行管理が続く。
• 根因 入力が「管理側のメリット」にしか設計されていない状態です。現場担当者にとって、入力することで何が楽になるか・何が見えるようになるかが明確でないと、入力は「管理されるための作業」として受け取られます。
• 対処 入力が現場担当者のメリットになる設計に変えます。具体的には次の3点です。

• 入力した情報が「次のアクションのリマインド」や「商談準備の情報源」として返ってくる仕組みを作る
• 入力後に「類似案件の受注事例」や「このフェーズでよく使われる提案資料」が参照できる状態にする
• 入力項目を「管理に必要な全項目」ではなく「現場が入力できる最小限」からスタートし、定着後に追加する

ツールの定着は、現場が「入力することで自分の仕事が楽になる」と感じるかどうかで決まります。管理側だけが得をする設計では、定着は見込めません。

パターン2：マニュアルを作ったが守られない・更新されない

• 症状 スクリプト・チェックリスト・プロセス定義を整備したが、実際の商談では使われていない。更新のルールがなく、半年後には現場の実態と乖離した内容になっている。
• 根因 「マニュアルを作ること」が目的化した結果、運用設計が後回しになっています。守られないマニュアルの共通点は、「使わなくてもフォローアップされない」「更新する責任者と頻度が決まっていない」「現場の実態から作られておらず使いにくい」の3点です。
• 対処 整備時に次の3点をセットで定義します。

• マニュアルの使用状況を確認する場（商談レビュー・1on1）と確認頻度を決める
• 更新の担当者・更新のトリガー（四半期ごと・大型失注が起きたとき等）・更新後の周知方法を定義する
• 作成段階でトップセールスの実際の商談から内容を抽出し、「現場が使える」状態で公開する

マニュアルは「作った後のループ」を設計して初めて機能します。

パターン3：スーパープレイヤー依存から抜けられない

• 症状 スケール施策を進めているが、特定の担当者の受注金額が全体の50%以上を占める状態が続いている。その担当者が異動・退職した場合のリスクを認識しているが、依存から脱却できていない。
• 根因 スーパープレイヤーにとって「ノウハウを共有するインセンティブ」が設計されていないことが多い原因です。また、「その人の動きを再現可能な形で言語化する」作業が後回しにされ続けることも要因になります。
• 対処 次の2つのアプローチを組み合わせます。
• インセンティブ設計の見直し ノウハウの共有・後輩の育成実績を評価に組み込みます。「個人の受注金額」だけが評価される構造では、共有への動機が生まれません。「担当したメンバーの受注率の改善率」や「育成件数」を評価項目に加えることで、共有への動機を設計します。
• 録音・録画分析によるボトムアップの抽出 スーパープレイヤー本人の協力が得にくい場合でも、商談録音・録画から「うまくいっている商談の共通パターン」を外から抽出できます。録音が蓄積している場合は、受注案件と失注案件を比較し、「冒頭の導入の仕方」「ヒアリング中の質問の順序」「競合比較への応答の仕方」を書き起こして比較します。本人の協力がなくても、組織としてノウハウを資産化できます。

まとめ：スケール可能な組織は「状態」であり「ゴール」ではない

この記事では、スケール化を「人員を増やすこと」ではなく「成果を再現可能な状態にすること」と定義し、プロセス標準化・データ活用・組織設計の見直し・継続改善ループの4つの視点を整理しました。

どの視点から着手すべきかは、組織の現在地によって変わります。

• 受注率が低い場合 プロセス標準化（視点1）を先行させます。商談の進め方にばらつきがあることがボトルネックになっている可能性が高く、スクリプト整備と商談レビューの定例化から始めると改善が数値に現れやすくなります。
• 商談数が不足している場合 KPI設計とデータ活用（視点2）から着手します。どのフェーズで案件が止まっているかを特定し、商談化率・有効商談創出数のどこが詰まっているかを確認することが先決です。
• 新規メンバーの立ち上がりが遅い場合 組織設計とオンボーディング（視点3）を優先します。採用基準の見直しと90日マイルストーンの設計を組み合わせることで、立ち上がり期間の短縮が見込めます。
• 改善が一時的で継続しない場合 継続改善ループ（視点4）の整備が必要です。週次レビューの定例化と更新ルールの定義から始めてください。

最初の一歩として現実的な着手は、「今週の商談録音を1件確認し、受注案件と失注案件で共通する違いを書き出す」ことです。データが少なくても始められ、プロセス標準化・KPI設計・改善ループのいずれにも接続できる作業です。

営業組織のスケール化に限らず、成長フェーズごとの打ち手を体系的に把握したい方は、営業組織の成長と打ち手もあわせて参照してください。

よくある質問

Q ビジネスにおいて「スケール」と「成長」はどう違うのか？

A

成長は規模の拡大全般を指すのに対し、スケールは「投入リソースの増加率より成果の増加率が高い状態」を指します。10人採用して売上が10倍になるのは成長ですが、3人の増員で売上が10倍になるのがスケールです。コスト効率を維持しながら売上を伸ばせるかどうかが分岐点になります。

Q 営業組織がスケールするのに適した人数の目安はあるか？

A

人数よりも「管理幅の状態」と「プロセスの標準化状態」で判断することが適切です。マネージャー1人の管理下に8名超が入り始め、かつ勝ちパターンが未言語化のままであれば、規模にかかわらずスケール施策が必要なサインと見てください。「何名になったら」という閾値よりも、本文で挙げた兆候（管理幅の逼迫・立ち上がり期間の長期化・受注率のばらつき拡大）の方が実務上の目安になります。

Q スタートアップ・中小企業でもスケール化は実現できるか？

A

実現できます。むしろ人数が少ない段階でプロセスと型を整えるほうが、大規模化後に修正する工数が少なく済みます。10名以下であっても、初回商談のスクリプト整備と商談レビューの定例化は着手できます。スケール化を「規模が大きくなってから取り組むこと」ではなく「スケールを前提にした設計を初期から意識すること」として捉えることがポイントです。

Q SFA/CRMを導入すれば、営業組織は自動的にスケールするか？

A

スケールしません。SFA/CRMはスケール化の「基盤」であり、それ自体が成果を生むツールではありません。ツールが機能するのは、プロセスの定義・KPIの設計・現場の入力習慣が整った後です。ツールを先に導入し、プロセス定義が後回しになったままでは、「データが集まらず活用できない」状態が続きます（本文のパターン1を参照してください）。

Q スケール化にどれくらいの期間がかかるか？

A

組織の現在地と取り組む視点によって異なります。プロセス標準化であれば、スクリプトの初版整備に1〜2か月、現場定着に3〜6か月が目安として挙げられることが多いです。KPI設計は定義の統一から始めれば1か月で着手できますが、データが蓄積し判断に使えるようになるまでにさらに1〜3か月かかります。「完成」はなく、継続的な改善ループを回し続けることがスケール可能な状態の維持につながります。

Q インサイドセールスとフィールドセールスの分業はどのタイミングで行うべきか？

A

商談獲得の工数（アポ取り・初回接触）が営業担当の稼働の40〜50%を占めるようになり、かつ商談対応の質低下が受注率に影響し始めた時期が分業を検討する目安になります。フルサイクル営業のままでは商談数の上限が担当者の稼働数に制約されるため、スケールの天井になりやすい構造です。分業の導入は採用と同時に設計する必要があるため、受注率の低下が数値に現れる前に準備を始めることをお勧めします。