次世代B2Bレベニュー戦略バイブル
受注予測が毎月外れるのは、営業の見立てが甘いからですか？
「先月から商談中です。今月中には決まると思います」
営業会議で、こういう報告を聞いたあと。
翌月、同じ案件がまた「今月中」に並ぶ。
そのたびに、見立てが甘い、押しが弱い、という話になる……。
支援の現場で見てきた場面があります。
担当者は、先方が来期の予算を待っていることを知っていました。会議でも、口頭で伝えていた。
それでも、営業支援ツール（SFA）には、フェーズと予定受注日しかないのです。
担当者は予定日を1ヶ月ずつ（手動で）後ろにずらし、その案件は毎月「今月受注予定」に数えられ、毎月外れていきます。
受注の時期をもっとも左右する重要な情報が、口にはされても、予測の数字の根拠として扱われる場所がどこにもない。
また、毎月外れても、何を理由に今月に数えたのかを結果と並べて振り返る場がなかったため、数え方は直りません。
問題は、外れた理由をあとから検証できないこと
予測が外れる理由は一つではありません。顧客の予算が変わる。競合が入る。社内の決定が遅れる。担当者が読み違える。どれも起こり得ます。
問題は、外れたあとに、そのどれだったのかを検証できないこと。
検証するには、今月の見込みに数えた時点の判断材料（顧客の承認はどこまで進んでいたか、予算はいつ決まる見込みだったか）が残っていて、その後に何が変わったのかと並べられる必要があります。
営業支援ツール（SFA）や顧客管理システム（CRM）の画面に見えるのは、通常、更新された最新の状態です。
変更の履歴を取れる機能があっても、「今月の見込みに数えたとき、何を理由にしたか」がまとまって残っていて、外れたあとの会議でそれを呼び出す、という運用になっている会社は多くありません。（貴社はありますか？）
理由が残っていなければ、顧客側の事情が変わったのか、もともとの見立てが違ったのかを区別できません。区別できないと、原因はいちばん目に見える担当者に向かうんですよね。
項目を足すだけでは、この問題は解けません。
項目を足しても、それを見て判断する会議がなければ、入力は続かないので。担当者にとって、使われない情報を入れる理由がないからです。
レベニューアーキテクチャは、記録から改善までを一つの循環として設計する
レベニューアーキテクチャ（Revenue Architecture）は、売上を、担当者や部門の成果としてより、顧客との一連のプロセスとして捉え、その中で記録・予測・判断・検証・改善が回るように設計する考え方です。
代表的なフレームワークの一つ、Winning by Designの「Bowtie」は、工程ごとに「次へ進む割合」と「かかる時間」を見ます。
受注予測について、設計するものは次の5つです。
1. 何を記録するか：顧客の承認の段階、予算が決まる見込みの時期、いまボールを持っているのは自社か、顧客の担当者か、顧客の承認者か。そして、それぞれが変わった日付
2. 予測にどう反映するか：どの条件を満たした案件を、今月の見込みに数えるか
3. 会議でどう判断するか：予測会議で判断材料を確認し、見込みを修正する。その時点の判断材料を、そのまま残す
4. 実績とどう比べるか：外れた案件について、予測した時点の判断材料と、その後の変化を並べる
5. 何を直すか：比べた結果から、数え方の基準や営業の打ち手を見直す
承認の段階やボールの持ち手が変わった日付を積み上げると、Bowtieでいう工程ごとの時間を、顧客の承認の段階ごとに見られるようになります。
どこで時間がかかっているのかが、案件をまたいで比べられるようになるんです。
ひとつひとつは目新しいものではないと思います。
違いは、これを一つの循環として設計することです。どれか一つが欠けると、残りも回りません。
日本の商談では、顧客ごとの予算と承認の予定を予測に組み込む
この枠組みは世界共通なのですが、違いが出るのは、何を記録し、どう判断するかという運用です。それは、売る相手の購買の進み方によって決まります。
私が支援してきた日本のB2B企業では、顧客の社内の稟議や予算編成の時期が、受注の時期を左右することが少なくありませんでした。
しかも稟議は、決裁する人が商談の場に出ないまま、顧客の社内で何段階も進みます。売り手の活動だけを区切りにしていると、その進み具合は見えません。
予算編成の時期も、期中に予算を使えるかどうかも、会社によって違います。だから、一般的な暦を当てはめるより、顧客ごとに次のことを確認し、予測に組み込みます。
・予算は、いつ、どの会議で決まるのか
・承認は、誰を経て、いまどの段階にあるのか
・それらを、いつの時点の情報として確認したのか
予測会議では、たとえば、予算が来期に決まると分かっている案件は、今月の見込みには数えず、来期の見込みとして持ちます。
判断の根拠が、担当者の申告から、検証できる記録に移る
受注予測
いまの管理では：担当者の見込みと予定受注日で、今月の数字を積み上げる
設計すると：予算の時期と承認の段階をもとに見込みを数え、外れたら原因を分ける
営業活動の改善
いまの管理では：長引いた商談に、活動量の目標や上司の同行で対応する
設計すると：どの段階で止まりやすいかを見る。たとえば部長の承認の後で止まる案件が多ければ、決裁者に届く材料が足りないのかもしれない、と打ち手を絞る
リソース配分
いまの管理では：商談が長いのは営業の手が足りないからだと考え、増員を検討する
設計すると：長引いている時間のうち、顧客の稟議や予算待ちがどれだけかを見る。顧客側の待ちが大半なら、増員より、予算編成の前に届ける提案や、承認者向けの材料に投資する
これで予測が当たるようになる、とまでは言えません。予算の時期や承認の段階をもとにした見込みが本当に当たりやすいのかは、予測と実績を何度か突き合わせて、初めて分かります。
変わるのは、外れたときに、どこを直せばいいかが分かるようになることです。
担当者を問う前に、根拠を問う
冒頭の問いに戻ります。予測が外れる原因が、担当者の見立てにあることもあります。
けれど、それを検証できる仕組みがないままなら、担当者を責めても、次の予測は良くなりません。
冒頭の案件も、担当者が予算待ちを伝えた最初の会議で、来期の見込みに移せていたはずです。
予測した時点の判断材料を残し、会議で使い、外れたら結果と並べて直す。その循環を、顧客の予算と承認の進み方に合わせて設計する。
レベニューアーキテクチャは元々アメリカ発祥ですが、これが私の考える日本版のレベニューアーキテクチャです。
次の営業会議の前に、3件だけ開いてみる
では、短いワークショップです。直近の「商談中」の案件を3件開き、それぞれについて、次の2つを書けるか試してみてください。
1. いまボールを持っているのは、自社か、顧客の担当者か、顧客の承認者か
2. 今月の見込みに数えている理由は何か。それは、いつの時点の情報か
記録から分からないものは「不明」としましょう。不明が多ければ、項目が足りないのか、入力が続いていないのか、会議で使われていないのかを見てみてください。
3件を開いてみて「不明」が多かった方へ：
私たちConsilegyでは、レベニューアーキテクチャに基づいて、何を記録し、どう予測に反映し、どの会議で判断し、どう検証するかまでを、一緒に設計しています。
SalesforceやHubSpotなど、今お使いのCRMをそのまま活かした再設計が可能です。
これからCRMを選ぶ会社には、この設計を記録の面から支える選択肢の一つとして、自社で開発したRevenue CRMもご用意しています。
次回は、導入後の話になります。CRMを導入することと、成果につなげること。その間にある課題を考えてみます。お楽しみに！