検証ファクトの記録と社内共有──経営判断に使える報告の設計

POC営業を進めている担当者に「今の検証状況を教えてください」と聞くと、口頭では説明できるが記録がない──このケースは非常に多い。

検証ファクトが担当者の頭の中にしかない状態は、事業にとってリスクだ。担当者が異動すれば知見が消える。経営層に報告する際に毎回ゼロから整理し直す必要がある。本記事では、検証ファクトを記録し社内共有するための具体的な仕組みを整理する。

なぜ記録が残らないのか

記録が残らない原因は怠慢ではない。仕組みの不在だ。

多くの場合、商談後に担当者がやるのはCRMにステータスを更新する程度だ。「商談済み」「フォロー中」「失注」。このステータス管理は既存事業の営業には十分でも、POCの検証には全く足りない。

POCで記録すべきは行動事実だ。顧客がいつその課題に直面したか、どう対処しているか、いくらかけているか。これらの情報は、ステータス管理の枠組みでは記録できない。

必要なのは、POC専用の記録フレームだ。

商談後5分で記録を完了できるフレームを用意する。以下の4項目を埋めるだけだ。

一つ目は「確認できた行動事実」。この商談で得られた事実を箇条書きで記録する。「課題が先月発生し、対応に2日かかった」「年間で外部サービスに80万円支払っている」など。意見ではなく事実だけを書く。

二つ目は「どのレイヤーまで進んだか」。課題認識・解決策の受容性・価格条件・意思決定プロセスの4段階のうち、どこまで確認できたかを記録する。

三つ目は「止まったポイントと理由」。進まなかった場合、どのレイヤーで何が理由で止まったかを記録する。「課題は認識していたが、解決策の方向性がニーズと合わなかった」など。

四つ目は「次のアクション」。この商談の結果を受けて、次に何をすべきかを書く。フォローの連絡をする、別の担当者を紹介してもらう、解決策の方向性を修正して再提示する、など。

商談ごとの記録が溜まったら、週次で集計する。集計のポイントは3つだ。

一つ目は定量データの更新。今週のアプローチ数、商談実施数、各レイヤーまで進んだ企業数の累計。これを一つの表で管理する。

二つ目はパターンの抽出。止まったポイントの理由を分類し、最も多いパターンを特定する。「解決策のレイヤーで止まるケースが今週3件。いずれも既存の対処法で十分と判断されている」──このパターンが見えれば、対処法の優先度が変わる。

三つ目は仮説の更新。週次の結果を踏まえて、当初の仮説に修正が必要かどうかを判断する。修正が必要な場合は、何をどう変えるかを記録する。

記録と集計ができたら、経営会議で使える報告の形に整える。

月次または隔週の報告に含めるべきは、検証の全体像と現在地、累計の定量データ、成功基準との照合、今月見えたパターン、次月のアクション計画の5点だ。

この報告が仕組みとして回っていれば、経営層は常に検証の最新状況を把握できる。「で、売れるの？」と聞く代わりに、具体的な論点について議論できるようになる。

記録のツールは凝る必要はない。Googleスプレッドシートで十分だ。

商談記録シート、週次集計シート、月次報告シートの3つを一つのスプレッドシートにまとめる。商談記録シートに入力すれば、集計シートが自動更新される程度の関数を組んでおけば、集計の手間はほぼゼロだ。

CRMやSFAに無理に組み込もうとすると、既存営業のワークフローとの衝突が起きる。POC専用のシンプルなシートを別途用意する方が現実的だ。

記録の仕組みを作っても、使われなければ意味がない。記録が習慣化するかどうかは、最初の1週間で決まる。

POC開始の初週に、担当者と一緒に2〜3件の商談記録を実際に書いてみる。フレームに沿って入力し、5分で完了することを体感してもらう。「面倒だ」と思われた時点で使われなくなるため、簡潔さが命だ。

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

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