「検討します」で終わらせない 各フェーズの「合格ライン」
前編で設計した「検証フェーズ」を実際に運用する際、もっとも難しいのは「顧客の反応の解釈」です。
「前向きな反応だったから合格」と甘く判断してしまうと、あとのフェーズでちゃぶ台返しに遭います。ここでは、各検証項目において、どのようなファクトを確認できれば「合格」とみなして次に進むべきか、その基準を解説します。
「実現性（How）」の合格ライン：根拠の確認
商流や法務などの「実現性」の検証において、担当者の口頭での「たぶん大丈夫だと思います」はNG判定です。担当者が自社の規定を完全に把握していないケースが多々あるからです。
合格ライン：
- セキュリティ規定集の該当ページが提示される
- 法務・知財担当者からのメール回答が得られる
- 「過去に類似のSaaSを導入した際の前例」が確認できる
運用ルール：ここが曖昧なうちは、どれだけ担当者が乗り気でも、具体的な提案書は作成しません。
また、実現不可能な理由がたまたまその会社だけの事情なのか、業界共通の壁なのかを見極めるためにも、根拠（規定やルール）は必ず確認する必要があります。これが特定できない商談は、検証データとして不十分なので、提案フェーズには進めません。
「課題（What）」の合格ライン：過去の出費（投資）事実
顧客の課題が「必須（Must have）」か「あれば良い（Nice to have）」かを見極める基準です。「困っている」という言葉は信用しません。
合格ライン：その課題に対して「過去に予算を使った」「コンサルを入れた」「人を採用した」という金銭的・労力的コストの支払い事実が確認できること
運用ルール：出費の事実がない「困りごと」は、「あれば良い（Nice to have）」と判定します。この場合、ターゲットリストから除外するか、別のより深刻な課題を探すピボットを行います。
「解決策（Solution）」の合格ライン：社内を動かす労力の発生
ソリューションの価値検証において、「良いですね」「便利ですね」は合格ではありません。
合格ライン：顧客の口から「これを導入するには、部長の説得が必要です」「技術部の〇〇さんの承認がいります」といった「導入の壁」が語られること。さらに、「来週、その部長を同席させます」「社内会議用の資料を一緒につくってくれませんか」といった、顧客自身が汗をかく約束が得られること
運用ルール：顧客が「自分事」として社内調整に動き出す合意がとれて初めて、次のステップ（受注活動）へ移行します。単なる「検討します」で終わった場合は、まだ価値訴求が足りていないか、キーパーソンに届いていない証拠です。
