「解決策の受容性」を検証する──お金を払う意思の確かめ方

課題の実在が確認できた。ターゲット企業の多くがその問題を認識し、対処にコストをかけている事実が揃った。次のステップは「この解決策は受け入れられるか」の検証だ。

ここで多くの担当者が犯す間違いは、完成したプロダクトを見せて反応を確かめようとすることだ。本記事では、コンセプト段階で解決策の受容性を検証する方法を整理する。

完成品は不要──コンセプトで十分検証できる

解決策の受容性を確かめるのに、完成したプロダクトは必要ない。確かめたいのは「この方向性の解決策に対して、顧客が具体的な関心を示すか」であり、プロダクトの完成度は関係ない。

むしろ、完成品を見せるとリスクがある。細部の仕様に議論が移り、本来確かめたい「方向性への関心」が見えなくなる。「この機能はこうした方がいい」「UIはこうすべきだ」──こうしたフィードバックは改善には有益だが、受容性の検証とは別の話だ。

コンセプト段階で確かめるべきは「この方向性の解決策があれば、現在の対処法から切り替える理由になるか」という一点だ。

Step 1の課題検証で「現在どう対処しているか」は把握できている。受容性検証では、その対処法に対する不満を深掘りする。

「現在の対処法で、最も手間がかかっている部分はどこですか」「その方法に変えようと思ったことはありますか」──これらの質問で、現状に対する不満の具体的な中身がわかる。

不満が明確であればあるほど、代替手段への関心は強い。逆に「今のやり方で特に困っていない」なら、どれだけ良い解決策を提示しても切り替える動機がない。

コンセプトの説明は短くする。5分以内が目安だ。「こういう課題に対して、こういうアプローチで解決する」という骨格だけを伝える。

詳細な機能説明は不要だ。方向性が伝わればよい。むしろ詳細を省くことで、相手の反応が「方向性への関心」なのか「特定機能への関心」なのかを切り分けやすくなる。

受容性が高いと判断できる行動事実は以下の通りだ。社内の関係者に共有する動きが出た。「うちの〇〇部門にも聞かせたい」と社内展開の話になった。類似サービスを比較検討している事実が明かされた。導入に向けた具体的な質問（技術要件、セキュリティ、導入期間）が出た。

逆に受容性が低いと判断すべき反応は「面白いですね、検討します」で終わり、次のアクションが出ないケースだ。社交辞令と具体的関心の差は、次のアクションが発生するかどうかで判断できる。

検証ポイントを段階的に確かめる原則に従い、受容性の成功基準を設定する。

例えば「課題が確認できた10社にコンセプトを提示し、6社以上で以下のいずれかの行動事実が確認できた場合、受容性を認定する」。

行動事実の定義は、社内の関係者への共有、比較検討の事実の開示、技術要件等の具体的質問、次回商談の自発的な設定、のいずれかとする。

この基準を満たせばStep 3（対価の意思）に進む。満たさなければ解決策の方向性を修正し再提示するか、ピボットを検討する。

受容性が基準を下回った場合、即撤退ではない。まず「なぜ響かなかったか」を構造化する。

方向性自体がズレていたのか。方向性は合っているが表現が伝わらなかったのか。タイミングが合わなかっただけか。これらを分解して次のアクションを決める。

方向性がズレている場合は、課題検証で得られたデータに立ち戻り、顧客が本当に求めている解決の形を再検討する。伝え方の問題であれば、コンセプトの説明方法を変えて再度提示する。

新規事業の営業に課題を感じている方は、こちらからお気軽にご相談ください。

新規事業の営業に課題を感じている方へ