オンライン商談が決まると、会社案内、製品資料、提案書、価格表、導入事例、技術資料まで、先にすべて送っておきたくなるものです。しかし、受け手はどこから読めばよいのか判断できません。当日は40枚のスライドを追うだけで質問の機会を逃し、商談後には別の資料一式が届きます。
非対面の営業活動で、資料は商談の代わりをするものではありません。事前に背景をそろえ、当日は対話の順序を支え、商談後は合意事項と未解決の論点を社内検討へつなぐ。それぞれに役割があります。
資料の数ではなく、相手の「次の判断」を決める
詳しい提案書を早い段階で送ると、相手は説明を聞く前に価格、機能、事例をそれぞれ解釈しなければなりません。一方、何も送らなければ、商談時間の多くを基本説明に使うことになります。
基準にしたいのは資料の量ではなく、その段階で相手が何を判断するかです。事前は「この商談は自社に関係があるか」、当日は「さらに確認すべき条件は何か」、商談後は「社内で何を検討し、次に何をするか」が分かれば十分です。
事前：短い要約資料で商談の範囲をそろえる
事前資料には、長い提案書より短い要約が向いています。相手が置かれている状況、商談で一緒に確認したい問い、提案の方向性、簡単なアジェンダに絞ります。機能一覧や価格の詳細、事例集を最初からすべて並べる必要はありません。
この要約資料は、すべての答えを載せるのではなく、相手が質問を準備できる状態をつくるものです。現在の資料共有方法、社外レビューに参加する人、導入前に確認すべき運用・セキュリティ要件などを示しておけば、必要な担当者や情報をそろえやすくなります。
当日：スライドは台本ではなく、対話の目次にする
画面共有するスライドに、商談の内容をすべて詰め込む必要はありません。課題、現状、提案の方向性、運用イメージ、判断が必要な条件という順で、対話を進められれば十分です。
詳しい機能一覧、長い事例、技術構成、セキュリティ項目は補足資料として用意し、質問が出たときに開きます。デモも、言葉だけでは伝わりにくい一つの動作に絞ります。これなら、説明担当者はスライドを最後まで進めることに縛られず、相手の質問に合わせて順番を変えられます。
商談中は、合意した要件、未回答の質問、追加確認が必要な条件を分けて記録します。このメモが、商談後に何を送るかを決める基準になります。
商談後：短い要約を先に送り、必要な資料だけを添える
商談直後に再び大量のファイルを送るのではなく、まず短い要約を作ります。確認した課題、合意した方向性、残っている質問、担当者、次の日程が一目で分かるようにします。
そのうえで、次の検討に必要な資料だけを添えます。範囲と日程を詰めるなら詳しい提案書、近い導入プロセスを知りたいなら関連する事例を1本、セキュリティ確認が始まったなら技術・セキュリティ資料を送ります。順序は 背景の共有 → 詳細の検討 → 根拠の補強 が自然です。
資料が、商談に参加していない人へ転送されることも想定します。最初の画面だけで、話し合った背景と次のアクションが分かることが大切です。「ご不明点があればご連絡ください」ではなく、「セキュリティ確認の担当者をご紹介ください」「範囲を確認後、次回の日程を選んでください」のように依頼を具体化します。
FeatPaperで、商談前後の受け渡しをつなぐ
要約資料、提案書、導入事例をFeatPaperのリンクで共有すれば、相手はブラウザやモバイルから読み返せます。内容を修正するときは社内で確認したうえで、既存の共有リンクに紐づく資料を更新できます。必要なページには、問い合わせや次回商談につながるリンクを置きます。
アクセス、ページごとの閲覧時間、再閲覧、リンククリックなどの記録は、次の質問を考える補助材料になります。事例ページを再び見ていたら「この事例に近い条件をご検討ですか」と尋ねられます。技術資料まで到達していなくても、関心がないと決めつけず、「セキュリティ資料は別途お送りしたほうがよいですか」と確認します。
記録から分かるのは、起きた行動までです。閲覧を関心度や購入判断の証明にせず、相手が状況を説明できる問いへつなげることが重要です。
送信前のチェックリスト：5つの確認事項
- 事前資料から、商談の目的と準備する質問が分かるか
- 説明スライドは、対話を支える分量に絞られているか
- 商談後の要約で、合意事項・未決事項・次の行動を分けているか
- 事例や技術資料を、実際に出た質問に合わせて選んだか
- 閲覧記録を結論ではなく、フォローアップの質問に使っているか
要約資料、スライド、提案書、導入事例は、多いほど役立つわけではありません。相手が事前に背景を理解し、当日は一緒に判断し、商談後は社内検討を続けられるよう、必要な資料を必要なタイミングで届けることが一つの流れをつくります。