資料の出し分けは、経路別の二冊を作ることから始めない
SMB向け営業資料を出し分ける基準は、インバウンドかアウトバウンドかだけではありません。顧客が面談を受けた理由、今決めたいこと、すでに確認できた事実に応じて、必要な説明の単位を選びます。経路ごとに順番を変えても、顧客の判断状態を取り違えていれば、不要な説明や早すぎる提案は減りません。
本稿の読者は、多くのSMBへ販売・支援するエンタープライズ企業の営業責任者・営業企画・事業開発担当者です。個人営業のプレゼン技術ではなく、チームで使う資料の構造、選択条件、更新責任、評価方法を扱います。自社の事業成長支援で蓄積した知見をもとにした設計案であり、資料の変更による受注率改善を実証した調査ではありません。
営業資料は、説明すべき内容を漏らさないための資産です。しかし、すべての面談で全ページを読み上げることまで標準にすると、商材を理解している相手にも同じ導入説明を繰り返し、確認したい論点に時間を使えなくなります。共通化するのは説明量ではなく、何を根拠にどの資料を選ぶかという判断です。
経路を仮説にとどめ、面談で決めたいことを確認する
問い合わせは、比較検討の開始を意味するとは限りません。情報収集、社内説明の準備、現在の契約の見直しなど、同じフォームから異なる目的が入ります。外部からの打診に応じた相手も、課題がまだ具体化していない場合だけでなく、既存施策への不満や期限を持っている場合があります。
準備では、接点の経路、打診や問い合わせの記述、既存接点を材料として、面談目的の仮説を置きます。冒頭では、その仮説と異なっていないかを短く確かめます。「情報を集めたい」「社内で比較したい」「この条件で実行できるか知りたい」など、相手が持ち帰りたい判断を言葉にし、事前情報を既成事実として押し付けません。
状態は固定の顧客ランクにも置き換えません。同じ相手でも、課題の必要性は理解しつつ、自社との適合性や実行体制が未確認ということがあります。一つの成熟度スコアだけでは資料の選択が決まらないため、必要性、適合性、比較、実行条件のどこに未解消の問いがあるかを分けます。相手の説明が営業側の仮説と違ったら、一度要件を言い直して確認し、資料の順番を組み替えます。
資料の単位を、機能紹介から買い手の判断へ移す
資料は、会社紹介、機能、料金という製品側の区分だけでなく、買い手が判断する単位でも整理します。例えば、必要性を考えるための課題構造、今回の条件で使えるかを確かめる適合範囲、他の方法と比較する材料、導入後の作業と役割を確認する実行条件です。一枚の見た目ではなく、一つの判断に必要な前提・説明・限界の組を、ここではモジュールと呼びます。
各モジュールには、使う目的、先に確認する情報、説明できる範囲、次に確かめることを付けます。事例を選ぶなら、業種が同じかだけでなく、顧客の目的、利用条件、実行体制、観測期間のどこが近く、どこが異なるかを確認します。成果が出たという結論だけを切り出して、未確認の顧客にも当てはまる説明にはしません。
共通の事実や制約は、組み替えても落とさない設計にします。料金の適用条件、提供範囲、顧客側の作業、できないこと、例外の承認が必要な事項は、その説明を使う際の必須部分です。短縮版から都合の悪い条件だけが消えると、商談時間を短くしても契約後の手戻りを増やします。
資料を細かく分けすぎると、営業が組み合わせを管理できなくなります。まず、商談で繰り返し誤解が起きる判断に単位を絞り、製品説明の正本は一つに保ちます。同じ機能説明を複数の流入経路別資料へコピーするより、共通部分と選択部分を区別した方が、価格や仕様の更新時に影響を追いやすくなります。
| 残る問い | 提示する材料 | 説明後に確かめること |
|---|---|---|
| 今取り組む意味が分からない | 課題構造・現状維持を含む選択肢 | 自社の課題として扱う必要があるか |
| 今回の条件で使えるか分からない | 対象条件・提供範囲・似た条件の例 | 当てはまる点と未確認の点 |
| 他の方法との差が分からない | 同条件の比較・費用と顧客の作業 | 比較に不足している前提は何か |
| 始めた後の運用が見えない | 担当・作業・必要な権限と開始条件 | 誰が実行し、何を確認するか |
説明の区切りに、次へ進む条件と戻る条件を置く
資料を見せ終えたら提案へ進む、という工程にはしません。必要性の説明後には、相手が同じ課題を自社の問題として認めているかを確かめます。適合性の説明後には、今回の対象・運用条件で使えるか、未確認事項が何かを確かめます。価格を示す前には、何をどこまで提供する案かを共有します。
ただし、価格を知りたい相手に、必ず全段階を順番に通るよう求める必要もありません。前提が未確定なら、費用の範囲や概算の条件、確定に必要な確認をセットで示します。情報を意図的に出し惜しみして、営業が期待する順番に誘導することと、説明の前提をそろえることは別です。
仮説が否定された場合は、説明を追加する前に、課題や対象の定義へ戻ります。必要性はあるが顧客側の運用担当が決まっていない場合は、実行条件を確認する場へ進みます。適合しない場合は、その範囲を伝えて別案や見送りを扱います。各モジュールの出口を、次ページではなく、前進・確認待ち・前提の修正・見送りのどれかとして記録します。
個人の編集力に頼らず、使った版と選択理由を残す
営業が自由に資料を組み替えるだけでは、説明のばらつきと更新漏れが増えるおそれがあります。製品・価格の事実を持つ責任者、商談での選択条件を持つ営業企画、現場で反応と未解消事項を記録する担当を分けます。同じ人が兼務しても、正本と適用条件のどちらを変更しているかは区別します。
商談記録には、使ったモジュールと版、選んだ理由、顧客が確認できたこと、残った問いを必要な範囲で残します。全ページの閲覧時間を管理することより、なぜ提案へ進めたか、なぜ前提を直したかを引き継げることが重要です。顧客が閲覧したというログだけで、説明を理解・承認した証拠にはしません。
価格や提供条件を更新したら、影響するモジュールと商談中の案件を特定します。過去に提示した版は証跡として残し、現行版と取り違えないようにします。顧客との約束を、後から更新した資料で上書きしたことにもなりません。個別の例外は、共通資料の変更ではなく、権限を持つ担当への確認として扱います。
| 管理する対象 | 主に持つ責任 | 確認する記録 |
|---|---|---|
| 製品・価格・提供条件の正本 | 当該情報の責任者 | 適用日・版・説明できる範囲 |
| モジュールを選ぶ条件 | 営業企画と現場の運用責任者 | 前提・出口・例外と相談先 |
| 商談での使用 | 担当営業 | 選択理由・使った版・残る問い |
| 公開済み資料の変更影響 | 正本と商談の責任者が連携 | 提示済み案件・再説明の要否 |
資料の利用率より、判断の前進と手戻りを評価する
新しい資料をよく使う営業の受注率が高くても、資料が原因とは限りません。経験者や有望案件に利用が偏る、対象顧客や商品の条件が違うといった可能性があります。比較は、流入経路に加えて面談目的と確認済みの条件をそろえ、使わなかった理由も含めて行います。
初期の評価では、提案後に初めて判明した条件の欠落、不要な説明のやり直し、見積の再作成、提供部門への差し戻しを見ます。商談時間が短くなった一方で、必要な条件確認を省いていないかも点検します。準備工数、相談に必要な熟練者の時間、更新時の修正箇所も、標準化の運用負担として測ります。
変更を試す場合は、どの判断の説明を変えるのかを限定します。対象と割り当てを事前に決め、話法や価格、担当配分を同時に変えた結果を、資料だけの改善効果にしません。件数が足りなければ、録画や記録を利用可能な範囲で確認し、どの誤解が解けたか、逆にどの前提が抜けたかを整理します。成果指標を待つ間も、更新・廃止の判断材料を集めることはできます。
実務で迷う論点:共通資料、熟練者、説明しない判断
インバウンド用とアウトバウンド用の資料は不要でしょうか。入口の約束や説明順が継続して異なるなら、推奨する組み合わせを用意する価値はあります。ただし、二冊に分けたことを判断の代わりにせず、当日の面談目的に合わせて変更できるようにします。
熟練者なら資料を自由に変えてよいでしょうか。選び方には裁量を持てますが、事実・制約・価格条件の確認は共通です。現場の例外から新しいモジュールを提案する場合も、本人の成功談だけで全社へ展開せず、適用条件と後続の手戻りを点検します。
相手が課題を感じていない場合も必要性の資料を使うべきでしょうか。事例や問いで考える材料を示すことはできますが、無理に課題を認めさせることが目的ではありません。今回扱わないと合意する、別の論点を確認する、検討を見送ることも、適切な資料選択の結果です。


