「メモは取ってきました。かなり話してくれました」
「いいね。提案の一枚目、何を書く？」
「……まず会社概要からですかね」
初回商談が終わって、メモは画面いっぱい。なのに提案書を開くと、白いページに負ける。情報が足りないのか、整理が下手なのか、そもそも提案していい段階なのか。 そこが分からないままテンプレートの「お客様の課題」欄を埋め始めると、相手の言葉が、いつの間にかこちらの売りたい結論へ変わります。
この「メモを提案書に貼るだけ」の作業は、見た目こそ仕事をした気になります。でも相手が何を判断すればいいか、ますます見えなくなる。営業担当者の文章力を責めても解決しません。発言・解釈・未確認が一つの段落に混ざっている。 まずそれをほどきます。
この記事は、初回商談で持ち帰る5つの事実を取った後の話です。手元のメモを「提案の一枚目」へ変える手順、書かない方がいいこと、顧客へ確認を戻す方法まで扱います。次の一件で使える一枚目の型も置きます。
なぜ、メモが多いほど提案書が書けなくなるのか
たとえば、メモに「提案準備に時間がかかる」「AIに興味」「過去事例を探しづらい」とある。ここから「AIで提案書を自動生成する」と書きたくなる。でも、時間がかかるのは資料探しなのか、使ってよい事例の判断なのか、構成なのか。まだ分かりません。AIへの関心も、導入を決めたという意味ではありません。
メモが多いほど危ないのは、言葉が足りないからではなく、言葉の身分が見えなくなるからです。相手が話した事実、こちらが考えた原因、次に確かめる問いを分けなければ、流暢な提案ほど誤解を隠します。
もう一つ、提案書を「全部決める文書」と思うと止まります。初回商談で費用も対象範囲も合意していないなら、完成した実施計画は書けません。ただし、「ここまで分かり、ここから何を確かめるか」を示す骨子は書けます。提案する段階と、確認を提案する段階を混同しないことが大切です。
まず、メモを三色に分ける
一件のメモを複製し、文ごとに三つのラベルを付けます。色ペンでも表計算でも構いません。
- 発言：相手が実際に話したこと。誰が、どの仕事について、いつの場面を話したかまで残す。
- 仮説：営業側が考えた原因や改善策。別の説明があり得ることも書く。
- 未確認：答えによって提案の中身が変わる問い。確認する相手と場を決める。
「過去資料を探すのが大変」は発言です。「検索基盤がない」は仮説です。「どこに資料があり、見つかっても利用可否の承認で止まるのか」は未確認です。相手の言葉を勝手に専門用語へ翻訳しない。この小さな節度が、一枚目の品質を決めます。
発言も、ただ引用すれば正確とは限りません。「大変」という一言が、担当者の感想なのか、チーム全体で繰り返す事実なのかは別です。頻度や工程が分からないなら、その発言の横へ「範囲未確認」と書きます。空欄を残すのが怖くても、空欄を隠した提案の方が後で困ります。
同じメモから、違う提案が生まれる
ここからは説明用の架空の商談です。相手は、顧客ごとに個別提案を作るBtoB企業の営業責任者。相手企業の営業担当が、商談後に過去資料を探して提案書を作っています。私たちは、その仕事の改善を一緒に考える立場です。実在の顧客事例や成果ではありません。
相手の発言は「担当者が毎回、過去の提案を探す。顧客への次の連絡まで時間がかかる」。この時点では、少なくとも三つの可能性があります。
| 原因の候補 | 次に確かめること | 先に試し得ること |
|---|---|---|
| 保存場所が散らばる | 直近一件で、どこを何分探したか | 正本の置き場所と検索の入口を決める |
| 見つかっても利用判断で止まる | 事例を使ってよいか誰が決めるか | 利用条件と確認者を一覧にする |
| 構成に迷う | 資料を見つけた後、どこで筆が止まるか | 一枚目の構成と確認例を作る |
どれも似た「提案準備の遅れ」に見えます。でも打ち手は違います。最初の仮説だけを採用して製品機能を並べれば、相手は「話は分かるが、うちの詰まりと違う」と感じるはずです。提案書を書く前に、提案を分ける問いを一つ見つける。 それがこの表の役目です。
一枚目は、会社紹介より「判断の地図」にする
相手が社内で提案を回覧するとき、説明者が隣にいるとは限りません。一枚目で必要なのは、派手な約束より「なぜこの話をするのか」と「何がまだ決まっていないか」です。次の五行から書いてみてください。
対象の仕事：商談後、過去資料を参照して個別提案を作る工程。
確認できたこと：担当者が資料探しに負担を感じ、顧客への次の連絡が遅れると話した。
考えられる原因：保存場所、利用判断、構成のいずれか、または複数。現時点では未確定。
今回の提案：直近一件を一緒にたどり、止まる工程と試す範囲を決める。
次の判断：原因と確認者が分かれば、小さな試行の方法と評価の仕方を選ぶ。
これは架空例の骨子です。「弊社のAIで時間を半減」も「導入効果が見込める」も入れていません。まだ測っていないからです。相手の発言が弱いなら二行目を「先方の話では」にし、確認待ちを明記します。提案書に何を書くかより、何をまだ書けないかを示す勇気が必要です。
費用、実施時期、データの扱いが未確認なら「要確認」とする。未確認のまま見積もりや効果を確定しない。一枚目で相手が判断できるのは、今すぐ導入するかではなく、どの確認へ進む価値があるかです。
「書いてよい提案」と「まだ書かない提案」を分ける
すべての空欄が埋まるまで待つ必要はありません。判断の目安は、その空欄で打ち手が変わるかです。
原因が違っても次の行動が同じなら、確認付きの骨子を書けます。たとえば、どの工程が重いか未確定でも、「直近一件を時系列で見て、詰まりを特定する」は提案できます。対象、協力者、確認方法を限定して書けばよい。
原因によって打ち手が変わるなら、完成案を急がない。資料の置き場を直すのか、利用承認を設計するのかで必要な人も費用も変わるからです。その場合は「追加で確かめたいこと」を提案の中心に置きます。相手が動く理由を感じられなければ、次回確認の時期自体を相談します。
安全性や利用条件が不明なら、実データを使った試行を約束しません。公開情報や架空データで工程を確認し、実データの扱いは社内ルールと相手の許可を確かめる。AIを使う提案でも、最終判断を誰が行うかは空欄にしないでください。
この三つを、提案会議で「今ある事実で、ここまで書けるか」と問うだけで、見栄えのよい早合点を減らせます。
提案書を送る前に、相手へ返す一文
営業の仮説を固める前に、相手へ短く返します。以下も架空例の文面です。
「前回は、商談後の提案準備で過去資料を探す負担があると伺いました。資料の置き場所、利用可否の判断、構成のどこが最も止まりやすいかは、まだ確認できていません。次回、直近の一件を一緒にたどり、先に試す範囲を決められますか」
返答が「資料はすぐ見つかる。上長確認で止まる」なら、原因の仮説を直します。「今はそこまで考えていない」なら、提案を急がず、相手の時期を聞く。無反応なら「関心がない」と決めず、接点と優先度を未確認のまま残します。相手に直してもらえる提案は、こちらだけで完成した提案より強いことがあります。
結果は「提出できた」で終わらせない
この方法を一件で試したら、三つを記録します。第一に、相手が「現状の記述」を直したか。第二に、原因候補のうち何が残り、何が消えたか。第三に、次の確認について誰といつ話す合意ができたか。「提案書を送った」は行動であり、相手の判断が進んだ証拠とは別です。商談化や受注もさらに先の結果です。
うまく進まないときは、失敗を一語にまとめない。現状を直されたなら発言と解釈の境目へ戻る。原因候補を絞れないなら、直近一件の工程をもう少し聞く。次回の確認が決まらないなら、相手が今取り組む理由と時期を聞く。返答が得られなければ「未観測」と記録し、推測で成功・失敗を付けない。
次の一件で使う、メモから一枚目への変換シート
相手の発言と場面／発言者と日時／確認できた事実／自分の仮説／別の原因候補／提案を分ける未確認の問い／いま提案できる確認／実データの扱いと確認者／相手へ返す一文／次回の判断と時期。
まず手元の商談メモ一件から、最初の三欄を埋めてください。次に、仮説へ印を付け、「もし違っていたら一枚目の結論が変わるか」を見る。変わるなら、立派な提案書より先に、その問いを相手へ返します。変わらないなら、確認付きの骨子を書いてよい。一枚目は売り込みの入口ではなく、相手と同じ問題を見ているか確かめる紙です。
商談後の記録整理から次の提案準備までを毎回チームで回したい場合は、brewcrew Salesで考え方を紹介しています。まずはこのシートを一件に使い、どこで判断が止まるかを見つけてください。
