エンタープライズセールスとは？体制・審査・撤退基準まで営業組織の実務ガイド

「エンタープライズをやろう」と決まったあと、多くの営業組織が最初にやることは、ターゲット企業リストの作成と、担当者の再配置です。そして半年後、パイプラインには数字の大きい案件がいくつか並んでいるのに、どれも動いていない、という状態になります。

エンタープライズセールスの解説記事は、たいてい「ICPを決めよう」「アカウントプランを作ろう」「複数部署にアプローチしよう」で終わります。どれも正しいのですが、実行の一段手前で止まっています。実際に商談を止めるのは、誰がどのタイミングで出ていくかが決まっていないこと、顧客側で走る3つの審査の順番を設計していないこと、そして降りる基準がないことです。

この記事は、エンタープライズ営業を「個人の力量」ではなく「組織の設計」として回すための実務ガイドです。定義から入りますが、本体は体制・審査・パイプライン・撤退の設計にあります。

この記事の要点（先に結論）

• 日本の大企業は1万364社しかない（2021年6月時点、中小企業庁）。母集団が有限だという事実が、撤退基準とパイプライン設計の両方を規定する。
• 「大企業」を横断的に定義した法令はない。中小企業基本法が定義しているのは中小企業者だけで、しかもその範囲は「おおむね」「施策ごとに定める」とされている。大企業は基本的に「中小企業に該当しない企業」という消極的な定義しかない。だからエンタープライズの基準は各社が自分で決めるしかない。
• エンタープライズ商談が止まる主因は個人のスキル不足ではなく、AE・SE・CS・マネージャー・経営の出番が条件で決まっていないことにある。
• 顧客側では稟議・取引先登録／与信・情報セキュリティ審査の3つが並行して走る。セキュリティ審査と取引先登録を稟議より前に着手させるのが、商談期間を縮める最短の打ち手。
• 商談期間が期の長さに近づくほど、今期の受注は前期の活動で確定済みになる。期中の挽回は物理的に効かないため、KPIとインセンティブの設計を先に変える必要がある。

エンタープライズセールスとは｜定義と「1万364社」という母集団

この定義そのものは、どの解説記事を読んでもほぼ同じです。実務で効いてくるのは、その次にある事実のほうです。

日本の企業数は337.5万者で、そのうち大企業は1万364者（構成比0.3%）、中小企業が336.5万者（99.7%、うち小規模事業者285.3万者）です（2021年6月1日時点。中小企業庁が2023年12月13日に公表した「中小企業・小規模事業者の数（2021年6月時点）の集計結果を公表します」。総務省・経済産業省「令和3年経済センサス-活動調査」の再編加工で、会社以外の法人および農林漁業は含まれません）。なお統計上の単位は「者」で個人事業者を含みますが、本記事では読みやすさのため「社」と表記します。

この「1万364」という数字は、エンタープライズ営業のあらゆる設計の前提になります。自社のターゲットが業種や規模でさらに絞られることを考えれば、実際に狙える企業は数百社から数千社です。リストは有限で、しかも使い減りする。一度雑に当たって断られたアカウントは、次に当たるまでのコストが上がります。だからこそ、後述する撤退基準と、アカウントに残す情報の設計が必要になります。

「大企業」を横断的に定義した法令はない

エンタープライズの解説では「従業員1,000名以上」「売上100億円以上」といった規模基準が語られることがあります。しかし法令を当たると、その根拠は見つかりません。

中小企業基本法（昭和38年法律第154号）第2条第1項が定義しているのは、あくまで中小企業者です。しかもその基準は業種によって4通りに分かれます。

（中小企業基本法第2条第1項各号。同条第5項では小規模企業者を、従業員20人以下、商業またはサービス業では5人以下と定めています。なお中小企業庁の統計上の区分では、関連法令にもとづく業種別の例外が設けられており、ゴム製品製造業は従業者900人以下、ソフトウェア業・情報処理サービス業は資本金3億円以下または従業者300人以下、旅館業は従業者200人以下が中小企業として扱われます）

さらに重要なのは、この第2条第1項の柱書が「おおむね次の各号に掲げるものとし、その範囲は…施策ごとに定めるものとする」と書いていることです。つまり中小企業者の定義自体が、確定した線ではなく施策ごとに動く「原則」として置かれています。

では「大企業」はどうか。大企業を横断的に定義した法令はありません。 個別法に「大企業者」の定義規定は存在しますが（中小企業の事業活動の機会の確保のための大企業者の事業活動の調整に関する法律（昭和52年法律第74号）第2条第2項など）、その中身は「中小企業者に該当する者以外の者」という消極的な定義に、大企業者に議決権の2分の1以上を単独で握られている等、事業活動を実質的に支配されている会社を大企業者とみなす規定（いわゆる「みなし大企業」）を足したものです。中小企業庁の統計上の区分でも、大企業は「中小企業および小規模企業に該当しない企業」とされています。

つまり大企業とは基本的に「中小企業ではない企業」であって、規模そのものを積極的に定めた横断的な基準は存在しないのです。

これは言葉遊びではありません。実務上、次の2つの帰結を生みます。

1. 社内で「エンタープライズ」の意味がそろわない。 営業は従業員数で、マーケは売上で、CSは契約金額で見ている、という状態が起きます。ターゲットリストと予算配分とKPIが、それぞれ別の母集団を指すことになります。
2. 従業員数だけでは線を引けない。 上の表は「資本金または従業員数」のいずれかを満たせば中小企業者、という構造です。つまりサービス業で従業員が150人でも、資本金が5,000万円以下なら法令上は中小企業者に該当します。さらに統計上の区分では業種ごとの例外も置かれています。「従業員300人以上をエンタープライズとする」という単純な線引きは、資本金要件と業種をまたいだ瞬間に意味を失います。

自社の「エンタープライズ基準」を決める3つの変数

基準が外部に存在しない以上、自社で決めるしかありません。決めるときに見るべき変数は3つです。世間の数字を借りてくるのではなく、自社の実績から逆算します。

1. ARPU（顧客単価）が跳ねる規模を実測する。 既存顧客を従業員規模で並べ、契約金額の分布を見ます。単価が段階的に上がるのではなく、ある規模を境に不連続に跳ねる点があれば、そこが自社にとっての境界線です。跳ねる点がなければ、そもそもエンタープライズを別セグメントとして扱う必要がありません。
2. 意思決定者と現場の間に何階層あるかを数える。 使う人と決める人が同じならSMB型の営業が機能します。間に2階層以上（例：現場 → 部門長 → 本部長 → 役員）が入ると、提案は必ず「自分がいない場所」で説明されることになり、後述する体制設計が必要になります。
3. 導入に第三者の審査が入るかどうかを確認する。 情報システム部門のセキュリティ審査、購買部門の取引先登録、法務の契約審査。このいずれかが必須なら、商談は現場の合意だけでは終わりません。審査の有無は商談期間を数か月単位で変えるため、基準として最も実務的です。

この3つのうち2つ以上に該当する顧客群を「エンタープライズ」と定義する、といった形で線を引くと、営業・マーケ・CSで同じ母集団を指せるようになります。ターゲット企業の選定手順そのものは、ABM（アカウントベースドマーケティング）のICP定義と共通です。

エンタープライズセールス／エンプラ営業／大企業向け営業の呼び分け

現場では複数の呼び方が混在しますが、指しているものはほぼ同じです。

本記事では「エンタープライズセールス」と「エンタープライズ営業」を同義として扱います。

SMB営業と何が違うのか｜7つの相違点

違いを「金額が大きい」「時間がかかる」の2点で理解していると、打ち手が「粘り強くやる」に収束してしまいます。実際には、営業プロセスのほぼ全工程が別物です。

特に実務を狂わせるのが最後の2つです。エンタープライズ商談は、明確に負けるのではなく静かに止まります。担当者は「社内で調整中です」と言い続け、パイプラインには金額の大きい案件が残り続け、四半期ごとに「来期には決まりそうです」と報告される。この状態を判定する仕組みがないと、パイプラインは実態のない数字で膨らみます。

The Model型の組織のまま、エンタープライズを狙えるのか

結論から言えば、The Model型の分業をそのまま適用するのは難しいが、捨てる必要もありません。分業の単位を変えることで両立できます。

The Modelは、マーケティング → インサイドセールス → フィールドセールス → カスタマーサクセスと、案件を工程で受け渡す設計です。1件あたりの処理コストを下げ、量をさばくことに最適化されています。母集団が大きく、検討期間が短いSMBでは、この分業が効きます。

一方エンタープライズでは、同じ設計が3か所で詰まります。

1. 受け渡し基準が機能しない。 BANT（予算・決裁権・必要性・導入時期）が揃ってからフィールドセールスへ渡す運用は、大企業では成立しません。予算は課題が承認されてから初めて確保されるため、「予算がない」状態で商談を進める必要があります。
2. 工程で切ると関係が切れる。 インサイドセールスが作った現場との関係が、引き継ぎで一度リセットされます。関係構築に数か月かけている商談では、この損失が大きくなります。
3. カスタマーサクセスが契約後にしか登場しない。 大企業の稟議では「導入後の体制」が論点になるため、CSは契約前に出ていく必要があります。

現実的な解は、工程ではなくアカウントで束ねることです。ひとつのアカウントに対して、AEを中心とした固定のチームを組み、そのチームが接点創出から導入後の横展開までを通して担当します。インサイドセールスやマーケティングは、案件を「渡す」のではなく、そのアカウントチームに対して継続的に情報と接点を供給する役割に変わります。ターゲット企業を先に決めて全社で当てにいくABMの考え方と、実質的に同じ構造です。

つまり、The Modelを捨てるのではなく、SMBセグメントにはThe Model型を残し、エンタープライズセグメントにはアカウント型を並置する、という二重構造になります。

エンタープライズ商談の体制設計｜AE・SE・CS・マネージャー・経営の役割分担

多くの解説記事は「チームで動くことが重要」「部門間の連携が鍵」と書きます。しかし現場で起きているのは連携意識の不足ではなく、出番が条件で決まっていないことです。その結果、「呼べば来てくれる人」に依存し、AEの人望と社内政治力で商談の進み方が変わります。

ここでは商談を6フェーズに分け、5つのロール——AE（アカウントエグゼクティブ＝商談の責任者）、SE（セールスエンジニア／プリセールス）、CS（カスタマーサクセス）、営業マネージャー、経営層——の責任を割り付けます。◎が主担当、○が支援、空欄は出さないことを意味します。

重要なのは表そのものではなく、空欄の理由です。各ロールについて「出す条件」と「出してはいけない場面」を決めておかないと、表はすぐに形骸化します。

SE（プリセールス）を初回商談に出さない

SEの主担当は③要件詰めと④審査対応です。②課題合意には支援として入りますが、①接点創出には出しません。

初回からSEを同席させると、商談の論点が「何ができるか」に固定されます。相手はできることの確認に時間を使い、こちらは機能の説明に終始し、課題そのものの合意が飛ばされる。さらに、初期段階で個別要望に対して「対応可能です」と答えてしまうと、後の要件定義で撤回できなくなります。

SEを出す条件は、「顧客側の課題認識が言語化され、それが自社の提供価値と接続できると双方が確認できたとき」です。

CSを契約前に出す条件を決める

CSの主担当は⑥導入・横展開ですが、④審査対応から支援として登場させます。理由は、大企業の稟議で「導入後に誰が面倒を見るのか」が必ず論点になるためです。導入体制が空白のままだと、承認者は「入れたあとに現場が困る」というリスクを取れません。

一方で、CSを早く出しすぎると、まだ売れていない案件にCSの工数が張り付きます。**契約前にCSを出す条件は「顧客側で稟議の起案が始まったとき」**と決めておくと、線が引けます。稟議で問われる導入体制やスケジュールをどう用意するかは、顧客の稟議を通す5つの材料で詳しく扱っています。

経営を出すカードは3条件でのみ切る

最も設計が甘くなるのが経営層の登場です。「役員に同席してもらう」が場当たり的に使われると、カードとしての価値が失われます。経営を出す条件は次の3つに限定します。

1. 相手の経営層が出てくるとき。 階層をそろえるのは礼儀であると同時に、相手の社内で「これは経営マターだ」と位置づけてもらうための手続きです。
2. AEの権限を超えるコミットメントが必要なとき。 ロードマップへの反映、専任体制の確約、契約条件の例外。これらはAEが約束できないため、約束できる人が出る必要があります。
3. 担当者レベルでは動かせない理由で案件が止まっているとき。 部門間の力関係や過去の経緯など、現場では触れない論点が原因の場合です。

逆に、表敬訪問、初回商談での同席、AEが説明できる内容の代弁では出しません。特に初回で経営を出してしまうと、後半の決裁局面で切るカードがなくなります。

マネージャーは同席者ではなくレビュアー

営業マネージャーの役割を「重要商談への同席」と定義すると、案件数が増えた瞬間に破綻します。マネージャーの主戦場は商談の場ではなく、アカウントプランのレビューと、撤退・保留の判定です。後述する撤退基準をAE単独で運用させないために、マネージャーは判定者として設計に組み込みます。

マルチスレッドは気合いではなく組織図からの逆算

エンタープライズ営業で「複数の関係者と接点を持つ（マルチスレッド）」ことが重要だ、という指摘はどの記事にもあります。しかし多くの場合、それは「担当者に紹介をお願いする」という一本道の運用になっています。紹介が出れば進み、出なければ止まる。これは戦略ではなく運任せです。

設計として組み立てるなら、順序は逆になります。先に「誰と会っている必要があるか」を組織図から定義し、そのうち会えていない人を欠落として管理するのです。

手順は3つです。

1. 決裁に必要な役割を洗い出す。 使う人（現場）、決める人（予算権限者）、止められる人（情報システム・法務・購買）、推してくれる人（チャンピオン）の4種類。役職名ではなく役割で定義します。
2. 役割ごとに実名を埋める。 埋まらないマスが、そのまま商談のリスクです。特に「止められる人」が空欄のまま提案が進んでいる商談は、審査の段階で必ず止まります。
3. 接触状況を色分けする。 会ったことがある／名前だけ知っている／存在も把握していない、の3段階。2段階目以下の人数が、そのアカウントで残っている作業量です。

このマップを埋める作業をAEの記憶ではなくドキュメントで管理すると、担当交代時の引き継ぎコストが大きく下がります。ステークホルダーのマッピング方法や、未接触者へのアプローチ手順といった戦術面は、マルチスレッド営業の実践方法で個別に解説しています。

3つの審査を通す順序設計｜稟議・取引先登録／与信・情報セキュリティ審査

エンタープライズ商談が「止まる」とき、その多くは顧客社内の審査で止まっています。そして重要なのは、走っている審査は1つではないという点です。

大企業でツールやサービスを導入する場合、典型的には次の3つが並行して、あるいは直列に走ります。それぞれ起点も主管部署も別です。

直列に流すと商談が伸び切る

営業が自然にやってしまうのは、稟議を先に進めることです。担当者と一緒にROI試算と比較表を作り、稟議を起案してもらう。ここまでは正しい動きです。

問題はその先で、稟議の承認ラインに情報システム部門が入っていた場合、あるいは稟議の添付資料としてセキュリティ審査の結果が求められる場合、稟議はそこで止まります。そこから初めてチェックシートが送られてきて、回答して、審査部門のレビューを待つ。取引先登録が未了なら、稟議が通っても発注が出せません。

つまり3つの審査は、依存関係が次のようになっています。

• 稟議は、金額と効果が固まらないと起案できない（見積の確定に依存する）
• 取引先登録・与信は、稟議とは独立に着手できる（多くの企業で発注の前提条件であり、稟議の可否とは無関係）
• 情報セキュリティ審査も、稟議とは独立に着手できる。ただし審査結果が稟議の添付資料になることが多く、稟議より後ろに置くと稟議を待たせる

したがって設計上の結論はひとつです。情報セキュリティ審査と取引先登録は、稟議より前に着手させる。 この2つは稟議の可否に依存しないため、課題合意ができた段階で並走を始められます。

着手トリガーを言葉で決めておく

「早めに着手する」という方針は、具体的な合図に落とさないと実行されません。次の3つを、AEが商談中に拾うべき合図として共有します。

• 「情シスに確認します」と言われた瞬間に、その場でチェックシートの様式と、審査部門の名前、想定される回答期限を聞く。持ち帰って待つと、様式が届くまでに数週間が消えます。
• 見積の話が出た段階で、「新規のお取引先の登録手続きはありますか」と確認する。必要書類（決算書、登記簿、取引基本契約の雛形）は、その時点で自社の管理部門に依頼を出せます。
• 課題と効果の合意が取れた段階で、稟議の起案時期と承認ラインを聞く。承認ラインに情報システム部門が入っているかどうかで、上の2つの緊急度が変わります。

セキュリティチェックシートに実際にどう答えるかはセキュリティチェックシートの回答実務に、ツール側が満たすべき要件はDSRのセキュリティ要件チェックリストにまとめています。

審査の所要時間は「相場」ではなく自社実測で持つ

「セキュリティ審査は平均◯週間」といった相場を提示する記事もありますが、審査の重さは顧客の業種・規模・過去のインシデント経験によって大きく変わり、業界横断で信頼できる公開データは見当たりません。本記事では相場を提示しません。

代わりに、自社の過去案件から2つの区間を分けて実測することを推奨します。

• 区間A：審査依頼を受け取ってから、自社が回答を返し切るまで。 これは自社の制御下にあります。ここが長い場合、原因は準備不足です。過去の回答を再利用できていない、SEの工数が確保できていない、法務確認がボトルネックになっている、のいずれかです。
• 区間B：回答を返してから、顧客が審査を完了するまで。 これは顧客の制御下にあります。ここが長い場合、原因は着手の遅さか、顧客側の体制です。区間Bは短縮できませんが、着手を前倒しすることで商談期間からは外せます。

AとBを合算して「審査に3か月かかった」と記録している限り、打ち手は決まりません。分けて測ることで、投資すべき先が自社の準備なのか、着手タイミングの設計なのかが判別できます。

商談期間が長い前提のパイプライン逆算

「リードタイムが長い」という特徴は、単に「待つ時間が長い」という話ではありません。パイプラインをいつ積んでおくべきかを変えるという話です。

必要なパイプラインの総額は、基本的には次の式で求まります。

必要パイプライン総額 = 目標受注額 ÷ 受注率

エンタープライズで追加されるのは、そのパイプラインが「いつまでに」存在している必要があるかという制約です。商談期間の分だけ、締め切りが前倒しになります。

今期に受注できる商談の生成期限 = 期末 − 平均商談期間
期首時点で必要なパイプライン比率 = 平均商談期間 ÷ 期の長さ

たとえば、期間12か月・目標受注額5億円・受注率20%・平均商談期間9か月の組織を考えます（数値は計算例であり、業界平均ではありません。また下の比率は、受注が期内におおむね平準化していると仮定した場合の目安です）。

• 必要パイプライン総額 = 5億円 ÷ 0.2 = 25億円
• 期首時点で必要な比率 = 9か月 ÷ 12か月 = 75%
• したがって、期首の時点で18.75億円分の商談が既に存在していなければならない

そして商談期間が12か月まで伸びると、比率は100%になります。つまり今期の受注は、期が始まった時点ですべて確定していることになります。期中に新しく作った商談は、原理的に今期には効きません。

この帰結は、運用に3つの変更を要求します。

1. 期中の挽回策が無意味になる。 「今期の達成が厳しいので、来月から新規開拓を強化する」という指示は、商談期間が期の長さに近い組織では効果を生みません。強化すべきは来期以降の生成量であり、今期に効くのは既存商談の前倒しと失注防止だけです。
2. 見るべき先行指標が変わる。 今期の受注額を追いかけても、それは過去の活動の結果でしかありません。マネジメントすべきは「来期の受注につながる商談を、今期どれだけ生成したか」です。
3. 平均ではなく分布で見る。 エンタープライズでは1件の大型案件が平均を大きく歪めます。平均商談期間だけで設計すると、大半の案件が想定より早く、少数が極端に遅い、という実態を見落とします。中央値と、最も遅い層がどこで詰まっているか（多くは審査工程）を併せて確認します。

SMBからエンタープライズへ移行するとき、先に壊れる7つのもの

すでにSMB向けの営業組織が回っている会社がエンタープライズに手を伸ばすとき、壊れるのは営業手法だけではありません。周辺の仕組みが先に壊れます。しかもその多くは、壊れてから半年ほど経たないと症状が表面化しません。

先に把握しておくべき7つを、症状と対策の形で整理します。

このうち、最も見落とされやすいのが②と③です。

②単年インセンティブ：合理的な担当者ほど長期案件を避ける

単年評価が放置されると、合理的な担当者ほど長期案件を避けます。今期の評価に効かない活動に時間を使う理由がないからです。結果として、エンタープライズ開拓は「やれと言われているが誰もやらない」状態に落ち着きます。これは意識の問題ではなく、設計の問題です。

③CRMのステージ定義：パイプラインが実態を映さなくなる

ステージ定義が古いままだと、パイプラインが実態を映さなくなります。「提案済」のまま4か月動いていない案件が、セキュリティ審査で正常に進んでいるのか、担当者が離脱して死んでいるのかを、データから区別できません。前節のパイプライン逆算も、ステージが実態を反映していなければ機能しません。

なお、SMB向けとエンタープライズ向けでは商談の進め方そのものが変わります。SaaS商談でDSRが要る理由はSaaSエンタープライズ営業でDSRが必須な理由で扱っています。

撤退基準｜降りる判断を、いつ・誰が・何を見て下すか

エンタープライズ営業の解説記事で、ほぼ例外なく書かれていないのが「降り方」です。しかし母集団が1万364社という有限のリストである以上、どのアカウントに資源を張り続けるかの判断は、営業戦略そのものです。

「撤退」と「保留」を分ける

まず、ひとつの言葉で扱わないことが重要です。

撤退を判定する条件は、次のいずれかに該当したときです。

• 課題そのものの合意が一定期間取れない（相手が課題だと認識していない）
• チャンピオンが不在で、かつ新しいチャンピオンを作る経路が見つからない
• 予算の出どころが特定できない（誰の予算で買うのかが最後まで不明）
• 競合または内製での方針が既に決まっており、比較検討の当て馬であることが判明した
• 自社が要件を満たせないことが確定した（機能・セキュリティ要件・提供体制）

保留に回すのは、課題の合意はあるが時期の問題である場合です。この場合は必ず再接触トリガーを書き残します。

• 予算サイクルの都合で今期は動かない → トリガー：次年度の予算編成時期
• 組織改編や人事異動でカウンターパートが不在になった → トリガー：後任の着任
• 別の優先プロジェクトに押し出された → トリガー：そのプロジェクトの完了予定時期

トリガーのない保留は、名前を変えただけの放置です。

AE単独で決めさせない

撤退判断をAEに委ねると、2つの理由でうまくいきません。ひとつは、AEには自分のパイプラインを削るインセンティブがないこと。もうひとつは、撤退の理由が個人の中で完結し、組織に学習が残らないことです。

判定はマネージャーとの月次レビューで行い、撤退・保留のいずれの場合も理由を分類して記録します。分類を続けると、失注の原因が偏っていることが見えてきます。要件を満たせない案件ばかりならターゲット定義が間違っており、審査で落ちる案件ばかりなら自社側の準備に投資すべきだ、という判断につながります。

降りたあともアカウントをゼロに戻さない

撤退したアカウントで得た情報は、次に接触するときの初速を決めます。組織図、決裁ライン、審査の要件と様式、使っている既存ツール、担当者が語った課題。これらを失注と同時に捨てると、2年後に再挑戦するとき、また同じ調査からやり直すことになります。

母集団が有限であるということは、同じアカウントに何度も挑戦する前提で情報を蓄積すべきだということです。撤退は関係の終了ではなく、投資の一時停止として設計します。

必要なスキルを「個人の資質」から「体制の設計」に置き換える

エンタープライズ営業に必要なスキルとして、一般に挙げられるのは「情報収集・分析力」「多部門の調整・連携力」「計画管理力」「交渉力」の4つです。どれも正しいのですが、これを個人の要件として掲げた瞬間に、組織の再現性は失われます。該当する人材は市場に少なく、採用できても属人化し、退職とともに商談が消えるからです。

同じ4項目を、体制側で担保する設計に翻訳すると次のようになります。

この置き換えは、スキルが不要になるという意味ではありません。個人のスキルが「あれば加速する要素」に変わり、「なければ止まる要素」ではなくなる、という違いです。エンタープライズ営業を組織として立ち上げるとき、先に手をつけるべきは採用ではなく、この4つの仕組みのほうです。

エンタープライズ営業を立ち上げる最初の90日

ここまでの設計を、着手順に並べます。ターゲットリストの作成から始めないのがポイントです。

1〜30日：現状を測る

• 既存顧客を従業員規模で並べ、契約金額が跳ねる点を探す（自社基準の変数①）
• 過去の大型案件を、受注・失注の両方で棚卸しする。どこで何か月止まったかを記録する
• 審査の区間Aと区間Bを、過去案件から分けて実測する
• 現在のCRMで「審査中」を表現できているかを確認する

31〜60日：設計を決める

• 自社の「エンタープライズ」の定義を3変数で確定し、営業・マーケ・CSで合意する
• 6フェーズ×5ロールの役割分担表を作り、経営・SE・CSの出番の条件を明文化する
• CRMのステージに審査状態を追加する
• 撤退・保留の基準と、判定の場（月次レビュー）を設置する

61〜90日：回し始める

• ターゲットアカウントを選定する（数を絞る。最初から広げない）
• アカウントプランの様式を1枚に定め、決裁に必要な4役割の実名欄を必須にする
• 選定したアカウントで、セキュリティ審査と取引先登録の着手トリガーを実際に運用してみる
• 単年インセンティブの扱いについて、期をまたぐ案件のルールを人事・経営と握る

90日で受注は出ません。この期間に作るのは、受注が出たときにそれが再現可能になっている状態です。

審査と多部門合意の進捗を可視化する

エンタープライズ商談の設計をひととおり決めても、最後に残る問題があります。顧客の社内で何が起きているかが見えないことです。稟議がどこまで回ったのか、セキュリティ審査の資料が誰に共有されたのか、決裁者が提案を読んだのか。営業から見えるのは、担当者からの「調整中です」という報告だけになりがちです。

デジタルセールスルーム（DSR）は、提案資料・ROI試算・セキュリティ回答・導入計画といった審査と稟議に必要な資料を、顧客ごとのRoomに集約して共有する仕組みです。顧客は必要な資料を探さずに社内へ回覧でき、営業側は「誰が・どの資料を・どこまで見たか」という閲覧データから、商談が社内のどの段階まで進んでいるかを推測できます。前述のマルチスレッド設計で埋めた「まだ会えていない役割」の人が資料を開いた事実は、社内で共有が進んだシグナルになります。

Terasuは、この商談Roomを作成して資料を集約し、閲覧状況を確認できるDSRです。エンタープライズ商談で必要な要件からDSRを比較検討したい場合はエンタープライズ向けDSRの選び方を、SaaS商談での具体的な使い方はSaaSの長期商談を加速するDSR活用法をあわせてご覧ください。

よくある質問（FAQ）

まとめ

エンタープライズセールスを組織で回すために、この記事で扱った設計は次の6点です。

1. 母集団を直視する。 日本の大企業は1万364社。有限のリストであるという前提が、撤退基準と情報蓄積の必要性を生みます。
2. 基準は自分で決める。 「大企業」を横断的に定義した法令はありません。顧客単価が跳ねる規模、階層数、審査の有無という3変数から自社で線を引き、営業・マーケ・CSで同じ母集団を指せるようにします。
3. 出番を条件で決める。 AE・SE・CS・マネージャー・経営の役割を6フェーズに割り付け、特にSE・CS・経営については「出さない場面」まで明文化します。
4. 審査を並走させる。 情報セキュリティ審査と取引先登録は稟議より前に着手させます。所要期間は相場ではなく、自社の制御下にある区間Aと顧客側の区間Bに分けて実測します。
5. パイプラインは前倒しで積む。 商談期間が期の長さに近づくほど、今期の受注は前期の活動で確定しています。管理すべきは今期の受注額ではなく、来期に効く商談の生成量です。
6. 降り方を設計する。 撤退と保留を分け、保留には必ず再接触トリガーを置きます。判定はAE単独ではなくマネージャーとのレビューで行い、理由を分類して次のターゲット定義に還元します。

エンタープライズ営業がうまくいかない理由は、多くの場合「優秀な人がいないから」ではありません。何をいつ誰がやるかが決まっていないからです。90日で受注は出ませんが、受注が出たときにそれを再現できる状態は作れます。