デマンドウォーターフォールとは？基本と実践例を解説
デマンドウォーターフォールは、BtoBマーケティングにおいてマーケティング部門と営業部門が協力して案件を創出していく一連のプロセスを構造化したフレームワークです。
アメリカのシリウスディシジョン社で2006年に発表され、その後2度のアップデートを経て今日まで使われている非常に強力なフレームワークです。「案件創出業務」において、これを知っているのと知らないのでは大違い。今回は、その詳細と実践例を紹介します。
デマンドウォーターフォールの基本構造
原始的なデマンドウォーターフォールは５つのステップに分かれています。
1.「Inquiries」 ：連絡先を取得できた見込み客
2.「Marketing Qualified Leads」：営業に引き渡せる有望なリード
3.「Sales Accepted Leads」 ：営業が受け取って対応するリード
4.「Sales Qualified Leads」 ：有望な注力商談
5.「Closed/Won Business」 ：受注商談
獲得した連絡先情報からMQL→SAL→SQLとステップを経てリードの数が絞られていきます。だんだんと数が絞られていくためファネル構造になります。上から下へ。滝のように水が流れる様を模して「デマンド（需要・見込み客）のウォーターフォール（滝）」と名付けられました。
この構造で業務を捉えることで、必要な受注件数に対してどのくらいの商談が必要か？有効リードが必要か？名刺獲得が必要か？の数量が算出されます。それぞれの部門が、繋がった業務プロセスの中でどこに位置づけられているのかがわかり、それぞれがどれだけの成果を出せば全社目標を達成できるのかが可視化できます。
そしてシリウスディシジョン社のレポートによると、組織によって各ステップの遷移率には大きく差がでます。通常のBtoBマーケティング組織では獲得した見込み客はほとんど絞り込みもナーチャリングもされずに営業に引き渡されるとあり、営業による初期対応ののち、注力する商談は実にその3%。営業リソースの無駄遣いです。一方で、BtoBマーケティングが高いレベルで機能している組織では、営業に引き渡される前にマーケとインサイド部門で十分に絞り込んでいます。「全てを営業任せにせず分業する」のがデマンドウォーターフォールの基本思想です。
デマンドウォーターフォールの進化
このフレームワークは、生みの親のシリウスディシジョン社自身によって2012年と2017年に2度のアップデートが行われています。
※図表引用：ノヤン先生のマーケティング講座 ファネルの物語【前編】
2012年のアップデートでは、マーケティング部門と営業部門の間にプロセスが増えました。遠隔で顧客とやりとりをして有望度を見極めていく「Teleprospecting（遠隔調査）」のプロセスです。インサイドセールス部門の普及に伴うものですね。加えて、現実の営業活動では、全ての案件がマーケティング部門から引き渡されるものではなく、営業部門が直接生成する案件もあります。これもファネルに加わりました。「Sales Generated Leads（SGLs）」です。これらにより、セールス＆マーケティングの全貌をより正確に描写しうる構造に変わりました。
そして2017年のアップデートでは、大きくファネル構造が様変わりしました。一番上に「Target Demand（顧客候補）」を置いて、その候補とのつながりをどんどんと深めていき、商談化・受注を目指すというモデルになりました。いわゆるABMの考え方を取り入れた形ですね。
それまでの考え方は、リードを大量に集めて、ふるいにかけて残ったリードを商談対象にしていくモデル。いわば投網漁のような考え方から、きちんとターゲットを見定め、その顧客候補との接点を取り続けていくような一本釣りの考え方に変わりました。特にエンタープライズ営業の分野においてマッチするモデルです。
これらの変遷を、概念として学ぶ事は意義があります。ただどちらもデマンドセンターの業務プロセスや組織連携が確立できていないチームが使うには教科書的で複雑です。実際の実務で使い始めるには、まず2006年の源流から始めるのが現実的なように思っています。
デマンドウォーターフォールが組織にもたらすもの
このフレームワークを活用する利点は2つあります。
1つ目は、組織の個別最適を予防することができます。例えばダメな例で、会社によってはマーケティングやインサイドセールス、営業部門がそれぞれの部門で目標を定めたりします。「うちの部門は、前年比xx%増のリード獲得を目指します」「うちは、一人あたりの業務量を考えて月間xx件のアポイント創出をします」のように。
ただ、このような考え方は部門ごとの個別最適になりがちです。ともすると組織間の分断や、いがみあいを生みかねません。（「うちの会社は営業とマーケ部門の仲が悪くて、、」なんて話をよく聞きます）
デマンドウォーターフォールのモデルを使って、必要な受注数から逆算してそれぞれの部門に求められるプロセス目標を設定する。そうすると、組織として連結された一連のプロセスを担っているという意識が生まれます。個別最適を予防して組織の一体感が高まります。
2つ目は、目標達成におけるボトルネックが特定しやすくなります。受注目標を作り、そのために必要なSQL→SAL→MQLと逆算した定量的な計画がありますから、期間が終わった後に実績と突き合わせられます。
予実の差分を元に定量的に振り返りを行うことで、そもそもリードの数が足りなかったのか、リードの質が悪かった（≒SALへの転換率が低い）のか、またはSALを受注につなげる受注率が低かったのか、はたまた計画がそもそも無理のあるものだったのかが数値で算出できます。組織のボトルネックがどこにあるのかがより正確にわかるようになります。
実際のところBtoBマーケティングにおいて、営業やインサイドセールス、マーケティング部門はそれぞれスキルセットも違えば、焦点を当てる時間軸も異なります。いわば異なる人種です。異なる者同士が協力的に連携するには、このような定量的で構造化された1つのフレームワークの中で一緒に考えていくことが、効果的な処方箋になると思っています。
日本におけるデマンドウォーターフォールの実態
私自身、BtoBマーケティングをテーマにいろいろなセミナーで登壇する中で、多くのBtoBマーケターの方と情報交換してきました。そして、事例発表で呼ばれるような成果を残しているマーケターの多くは、このデマンドウォーターフォールの考え方を取り入れた業務プロセスを構築しています。
とはいえ実際のところ、このモデルを正確に適用していると言うよりは、その中核にあるエッセンスをそれぞれが解釈して実践しているのが実態です。
例えば、SQLとSALを区別せずに考えたり、インサイドセールスが獲得したアポ＝SQLとしたり、マーケ部門が獲得したリード＝MQLのように。MQLやSQLなどデマンドウォーターフォールの用語は使っているものの、解釈はわりとおおざっぱに実務適応している方が多いようです。特にアポ＝SQLで捉える方は非常に多く、その解釈が正しいのか・・？と錯覚するほどに多数派です（笑）
もちろん私達は学者ではないですので、むやみに正確な解釈にこだわるよりも、使いやすいところから取り入れるのが実務家として正しい姿だなと感じます。ですので、誰かの事例発表等でMQLやSQLの用語が出てきても、それが必ずしも原典と同義ではないという前提で聞くと、誤解が少ないと思います。
デマンドウォーターフォールの実践例
ここまでは一般的な基礎知識の話。ここからは具体的な実例の紹介をします。私のチームでは2017年からこのデマンドウォーターフォールの考え方で案件創出業務に取り組んでいます。当初は以下のようなフレームワークで構造化しました。
プロセス指標を5つのステップに分けました。プロセス間の遷移率は、過去データがあるものはそれを元に。正確なデータがない箇所は営業部長の肌感覚を受けて仮置きして作りました。当時から今に至るまで、獲得リードのうち有効リードはだいたい40%。そこから営業に引き渡すアポイントの率はだいたい17%前後というのはそんなに変わっていないです。
この構想をモニタリングするために使ったシステムはSalesforceです。具体的には商談オブジェクトとキャンペーンメンバーを使って必要な情報を入れるように設計しました。（※1）
定量計画とシステム開発、ここまでくれば道具はバッチリです。とはいえ、道具があってもこれを活用する業務プロセスを作り上げないと絵に描いた餅です。現実論では、それぞれの部門がこれに沿ってデータを入れてもらうよう巻き込まないといけません。この「プロセス定着化」の段階でつまづいて企画倒れになっているケースもよく見受けられます。
デマンドウォーターフォールを定着させる工夫
私のチームにおいては、幸いなことに比較的スムーズにこのプロセスを定着させることができました。効果のあった工夫を3つ紹介します。
インサイドによるリードフォロー状況をSalesforceに入れてもらうために
マーケ部門が取ってきたリードをインサイドがどれだけフォローしてくれているか状況がわからないと言う話を、他社からよく聞いていました。使い慣れたエクセルなどにデータを落として業務をしているのでしょうね。なのでそうならないように仕組みをつくりました。
インサイドセールスが望んでいたものは、リードの熱が冷めないうちに早く引き渡してもらうこと、自分が対応すべきリードを一覧で見れること、コールメモ入力事務の効率化、この3つです。そこで、キャンペーンメンバー画面に直接フォロー状況を書き込めるようにSalesforceを改造しました。「わざわざエクセルに落とすより使いやすい・入力が早い」という状況を作り、インサイドでのリード精査状況（Inquiries→MQL）や、フォロー状況（MQL→アポ）がモレなくデータ反映されるようになりました。
営業のアポイントフォロー状況をSalesforceに入れてもらうために
インサイドのアポを営業が、、、という話もよく聞いていました。特に、商談が本格化するまで商談レコードを登録してくれない、というのがあるあるです。なのでここにも仕組みを。
インサイドがアポを取ったときに、自動的に商談レコードを作成するように改造しました。更に、インサイドから渡された商談は、初回面談後に営業としてフォローするかしないかの2択を入力してもらうように項目を作りました。ダッシュボードも作り、営業会議のアジェンダの１つに入れ、白黒つけていないまま保留になる商談がないように会議に同席して一緒に確認しました。これによって、アポが営業に受け取ってもらったかどうか（アポ→SAL）がモレなくデータ反映されるようになりました。（※2）
別部門の業務だからこそ、できていない量でなくできた量に焦点を当てる
インサイドも営業も、マーケとは別部門です。異なる人種です。そのうえで「◯◯を入力してください」とか「◯◯さんは、◯◯件が未入力ですよ」というコミュニケーションを続けたら、摩擦が起きることが確実です。
データが入力された完成形を基準で見てしまうと、未入力という状態が目につきます。この視点を反転させます。そもそもSalesforceのレコードは全て未入力な状態なのですから。白紙の状態を基準にします。
例えば前述の「営業が受け取るかどうかの商談項目」であれば、未入力状態が基準ですから、営業にかける言葉は「◯◯さん、先週は◯◯件入力いただきありがとうございます！」となります。ダッシュボードのラベルも「未入力な案件一覧」ではなく、「受け取り判断を入力して欲しい案件一覧」とします。何件か未入力があってもわざわざ触れません。来週にもこのダッシュボードに名前と共に表示され続けるのですから。
「◯◯さん、全件対応いただきありがとうございます！」と、適切に対応した方にポジティブな感謝の言葉を投げかけることで、段々とその行動が浸透していきます。結局は同じ依頼なのですが、ポジティブに伝えると捉えられ方が全然違います。
新しい行動様式の定着化は、業務プロセス設計力、システム開発力、コミュニケーション能力の総合戦です。企画部門の腕の見せ所だと思います。
まとめ
BtoBマーケティングの案件創出活動において、デマンドウォーターフォールは非常に有効なフレームワークです。これに基づいて事業計画をし、これを実現するようにシステムを構築し、これを可視化して部門横断で見ていくことで、異なる人種の部門が、同じ目線で連携することができます。
会社は「顧客に価値を提供するもの」という原点に立ち戻ったとき、マーケ部門、インサイド、営業、カスタマーサクセスのいずれも単体では顧客に価値を提供することができません。正しいフレームワークとファクトデータは異なる部門同士を効果的につなぎます。
第4次産業革命の時代。「Data is New Oil」と言われてます。データは石油に変わる新しい資源でもありますし、組織の潤滑油にもなります。
デマンドウォーターフォールを用いたデータ活用が広がることで、多くの組織で、異なる人種の部門同士が仲良く連携できるといいなと思っています。
※1 キャンペーンメンバーを使ったデータの持たせ方の詳細はこちら
※2 インサイド用の自動で商談を作ってくれる画面作りの詳細はこちら