提案書が長ければ信頼される？顧客の判断に必要な説明を選ぶ

顧客に提案書を渡すとき、「薄い資料では準備不足と思われそうだ」「多くの情報を載せた方が信頼されるのでは」と考えることがあります。詳しい資料が必要な商談もありますが、ページ数の多さだけで信頼や提案の妥当性を判断することはできません。大切なのは、顧客が今回の取引について判断するための説明と根拠がそろっているかです。

まず顧客が何を決めようとしているか、どの条件を重視しているか、誰が確認・承認するかを確かめます。そして、課題と提案内容の対応、効果を見込む根拠、費用、導入負担、制約を分かる順に示します。技術仕様や詳細な検証資料が必要な場合は、省略せず参照できるように残します。最適なページ数を先に決めるのではなく、判断に必要な情報と、後から詳しく確かめる情報を分けることが出発点です。

提案書を長くすると、顧客は納得しやすくなるのか

説明用の仮の場面です。営業担当者が、問い合わせ対応の負担に困っている企業へ業務システムを提案します。提案書は30ページで、機能の一覧、会社沿革、導入事例、画面の説明が詳しく書かれています。しかし顧客が知りたいのは「問い合わせの引き継ぎミスを減らせるか」「今の業務に導入できるか」「年間でいくらかかるか」の３点です。説明量は多くても、その問いに対する答えは探しにくい状態です。

人は説明を読むとき、必ずしもすべての根拠を同じ深さで検討するわけではありません。PettyとCacioppo（1984）は、大学生168人を対象とする実験で、説得の文章に含まれる主張を３個または９個にし、根拠の強さと、話題が本人にどれほど関係するかも変えて意見を調べました。話題の自分への関係が比較的弱い条件では、主張の数の影響が比較的大きくなりました。一方、関係が強い条件では、主張の数よりも根拠の強さによる影響が大きくなりました。Petty・Cacioppo（1984）の原著論文

この研究で測ったのは、文章への賛同の程度です。企業が提案書を信頼するか、契約するかを直接測定したわけではありません。また「たくさん書くほど必ず逆効果」と示した研究でもありません。情報の数が手がかりになる場合と、根拠の質がより重要になる場合があるという違いが、商談を考えるうえで参考になります。

さらにMeyvisとJaniszewski（2002）は、商品が期待する利点を実現するかを評価する実験を行いました。最初の実験では、大学生36人が８種類の商品・サービスについて、望む利点を支持する情報だけを見た場合と、それに明らかに関係の薄い情報を３つ加えた場合を比べました。関係の薄い情報を加えた条件では、商品が望む利点をもたらすという評価が弱くなりました。後続の実験では、情報を読むときに望む利点を意識しているかなどによって、この影響が変わることも示されています。Meyvis・Janiszewski（2002）の原著論文

こちらも顧客向け提案書の長さや信頼感を直接調べたものではありません。研究でいう「関係の薄い情報」は、評価する利点との関係が薄い情報であり、すべての場面で不要な情報という意味ではありません。顧客が知りたい点が明確な商談では、説明を増やす前に、それぞれの情報がどの問いに答えているかを確かめる意義があります。

また、営業担当者は自分が知っている製品の特徴を、顧客も同じように理解できると考えてしまう場合があります。このような前提知識のずれは、知識の呪いの解説でも扱っています。資料が長いか短いかだけでなく、相手が理解するための前提が書かれているかも確認が必要です。

提案書を作る前に、顧客の何を確認するか

以下は研究で直接効果が検証された提案書の作り方ではなく、研究を参考にした実務上の確認方法です。資料の量を決める前に、顧客へ４つの点を確かめます。

1. 今回、何を判断したいのか。複数社の比較候補を絞る段階なのか、予算を取る段階なのか、契約承認の直前なのかを聞きます。候補選定なら課題との適合や違い、契約承認なら費用・責任範囲・リスクなど、先に示すべき情報が変わります。
2. どの問題を解決したいのか。「業務を効率化したい」だけでは、どの作業が困っているかが分かりません。「問い合わせが担当者間で引き継がれない」「月末の集計に手間がかかる」など、顧客から聞いた実際の問題を確かめ、提案内容と結び付けます。聞いていない課題を事実として書かないことも大切です。
3. 誰がどの項目を確認するのか。利用部署、情報システム担当者、経理・購買担当者、決裁者などで確認事項は異なることがあります。利用部署は操作方法、情報システム担当者は接続や情報管理、決裁者は費用と導入判断の理由を重視するかもしれません。担当者本人に確認し、肩書きだけで関心を決めつけないようにします。
4. どの条件が満たされれば前に進めるのか。予算の上限、開始時期、必須機能、既存システムとの連携、セキュリティや契約上の条件を確かめます。まだ決まっていない条件があれば、推測で補わず「確認中」として、いつ誰が判断するかを整理します。

質問する時間が限られる場合もあります。そのときは把握できている課題と未確認事項を分けて記載し、顧客との次回の打ち合わせで優先順位を確かめます。特に顧客から必須と伝えられた条件は、ページ数を減らすために削るべき情報ではありません。

顧客の判断に使う説明と、詳しく調べる資料を分ける

先ほどの業務システムの仮の商談なら、30ページを機械的に半分にするのではなく、最初に読む部分で判断の筋道が追えるようにします。たとえば、次のような分け方が考えられます。

これは提案書の完成形を示す決まった型ではありません。規制への対応、情報管理、技術審査などが重要な案件では、詳細な証拠や契約条件を最初の判断段階から提示する必要がある場合もあります。短くするために不利な条件を隠すのではなく、判断に必要な条件を見つけやすくすることを優先します。

導入実績を示す場合も、会社名を多く並べるだけで終えず、顧客の用途に近い事例について「どの仕事で、何を比較し、どこまで確認できたか」を明確にします。成果が見込みの数字なら「試算」と示し、確認済みの実績と混同させません。根拠がない効果を、提案書の見栄えのために作らないことも重要です。

説明を増やすか迷ったら、顧客の次の判断に照らす

追加ページを作る前に、顧客に何が不足しているかを尋ねます。たとえば、次のように伝えられます。これは説明用の仮の会話例です。

「今回のご提案では、引き継ぎミスへの対応、導入時のご負担、費用を最初にまとめました。社内で比較・承認される際に、これ以外で確認が必要な項目はありますか。技術仕様やセキュリティの詳しい資料は別に用意できますが、最初の判断から必要であれば本文にも入れます」

相手の返答によって、取る行動を変えます。

• 判断に必要な根拠が不足している場合：ページを減らさず、比較資料や検証結果を追加します。分からない条件は分からないまま明示し、確認する相手と時期を決めます。
• すでに知っている説明が多く、重要な点を探しにくい場合：重複や関係の薄い説明を整理し、顧客の問いと回答を近くに置きます。必要な詳細は別紙に残し、参照先を示します。
• 複数部署が異なる資料を必要としている場合：共通の提案内容と条件を一つにそろえ、部署ごとに確認する資料や見出しを用意します。別々の資料で金額・適用範囲・前提条件が食い違わないようにします。

提出前には、提案書だけを見た人が「何が解決される想定か」「その根拠は何か」「費用と負担は何か」「未確認のことは何か」を追えるか点検します。質問が残ったときに、詳細へ進めるかも確かめます。この確認方法は、研究から直接保証された信頼獲得策ではなく、顧客が判断に使える説明かどうかを点検するための提案です。

長い提案書でも必要な内容が整理されていれば意味がありますし、短い提案書でも根拠や注意点が足りなければ十分ではありません。顧客の信頼をページ数だけで測ろうとせず、何を判断するための説明かを明確にして、必要な根拠を確かめられる状態にすることを目指します。

参考文献・出典

• Petty, R. E., & Cacioppo, J. T.（1984）“The Effects of Involvement on Responses to Argument Quantity and Quality: Central and Peripheral Routes to Persuasion.” Journal of Personality and Social Psychology, 46(1), 69–81. 著者公開の原著論文PDF。説得の文章の主張数・根拠の強さと、話題の個人的な関係の深さによって賛同の仕方が異なる研究の根拠。
• Meyvis, T., & Janiszewski, C.（2002）“Consumers’ Beliefs about Product Benefits: The Effect of Obviously Irrelevant Product Information.” Journal of Consumer Research, 28(4), 618–635. 著者公開の原著論文PDF。特定の利点を評価する際に、関係の薄い商品情報を加えた場合の評価と、その影響が変わる条件を調べた研究の根拠。