はじめに

本稿は、アメリカのBtoBマーケティング分野のリサーチ＆アドバイザリーファームである「シリウスディシジョンズ(SiriusDecisions)」によって提唱された「デマンドウォーターフォール(Demand Waterfall)モデル」を解説する連載企画の後編です。 

今回も前編同様、マーケットワン インターナショナル(MarketOne International)で執筆された「The SiriusDecisions Demand Waterfall explained: Part II」を日本語に翻訳しています。 

2002年に発表され、2012年に改定されたシリウスディシジョンズ デマンドウォーターフォールモデルはデマンドジェネレーションの仕組みを最適化するための「デファクトスタンダード」となった 

全2回に渡り「デマンドウォーターフォールがどのように機能するか」「なぜ使い勝手がよいモデルと言われるか」について解説する連載企画。前回は、デマンドウォーターフォールを理解するための最初のポイントとして、テレマーケティングの主要な機能を「マーケティングクオリフィケーション(絞り込み)」に組み込む方法を紹介しました。 

今回は、残りの二つのポイントを解説していきます。

• MGL / TGL / SGL：ファネル内のリード生成ステージの3分割 
• SGL：営業の特徴から生まれるSGL精度のバラつき–  「プッシュ」「サンドバガー」「ベストケースシンドローム」

デマンドウォーターフォールのポイント1の詳細は、前回記事をご参照ください。 

デマンドウォーターフォールのポイント2 – ファネル内のリード生成ステージの3分割

シリウスディシジョンズは、2012年版のデマンドウォーターフォールでコンバージョンの分析をするために、3つの異なるステージ概念「MGL(Marketing Generated Leads)」「TGL(Teleprospecting Generated Leads)」「SGL(Sales Generated Leads)」を設けることで、チャネルごとの効果測定を可能にしました。
 (訳者注：
MGL – AQL/TQLに対してマーケティングで絞り込みをしたリード
TGL – テレプロスペクティングでのアウトバウンド活動で創出したリード 
SGL – 営業活動内の引き合いで生まれたリード)

この3つのステージ概念の必要性を説明していく上で、筆者がデマンドジェネレーションに従事した際のユースケースを用いるのがわかりやすいと思いますので、参考にしていきたいと思います。

筆者が当時、コンバージョンの計測を行なったデマンドジェネレーションのチャネルは４つでした。

1. まずは、ウェブリードの「お問い合わせ」用のフォームで、当時はサイトに一つだけ設置されていました（訳者注：Inquiryのインバウンド）。
2. 次に計測を行ったのが、キャンペーンに反応したリードでメルマガに反応したリード(AQL)です。
3. ここにさらに、ISR(インサイドセールス)がターゲットアカウントへのコールドコールで生み出したリード（TGL）が加わります。これら計3つが当時、私のミッションだったパイプライン生成内で生み出されたリードです。
4. さらに、営業部門のSGLが加わることで計4つのリード生成のチャネルがありました。

ただし、SGL部分に関しては当時の私の管轄ではありませんでした。それに加えて、受注までの商談管理やリードの管理といったセールスアドミンのタスクも、営業部門内で行われていて、我々の役割範囲外でしたので補足しておきます。
（訳者注：これらのリードに対して営業がフォローし、案件化に向けて営業が対応する対象がデマンドウォーターフォールにおけるSQL=Sales Qualified Leadsになる) 

我々マーケティングチームは北米・中南米地域において、3つのチャネルから全体の30%をSQLとしてパイプライン創出をしていましたので、SGLは残りの70%になります。
（訳者注：営業自らが作っているのでSGL=SQLとなります） 

30%のSQLの内訳は、60%がお問い合わせから生まれたリード(Inquiry)、5%がメルマガ等のキャンペーンからのリード(AQL)、35%がインサイドセールスのコールドコール(TGL)です。

試しにこの数値をデマンドウォーターフォールに当てはめて、ベンチマークとなる数字を計算してみましょう。「MGL = Inquiry + AQL」として、「全体の30%のリード創出 x (Inquiry: 60% + AQL: 5%)」となり、全体のSQLにおける19.5%がMGLと言えます。TGLも同様に「全体の30%のリード創出 x 35%のコールドコールの割合」となるため、SQLのうち10.5%がTGLです。残りの70%はSGL(=SQL)となります。 

デマンドウォーターフォールにおけるコンバージョンレートは、チャネルごとで大きく変動します。例えば、ウェブフォームの問い合わせにおいては、MQLからSQLにかけてのコンバージョン率は85％でした。ただし、この時はMQLとSQLの間に位置するSALに関しては計測していなかったので補足しておきます。
（訳者注：SAL=マーケティング部門から引き渡し、案件化に向けたフォロー対象のリード） 

私達マーケティングチームはリード創出もしくは絞り込みといった、パイプラインの初期段階のステージに関する責任を背負っていました。いわゆるMQLにあたるものです。受け取ったリードに関しては、クローザーである営業がSQLとして商談にコンバートする(訳者注：SFAでリードを処理して次のステージに進めること)、却下する、失注処理をするなどの、営業活動上の対応をしていました。 

さて、メルマガなどのキャンペーンに反応したリード（AQL）に話を戻すと、SQLへのコンバージョン率は15%でした。同様にインサイドセールスのコールドコール（TGL）は50%です。

しかし、我々は次の工程に当たるSQLからウォーターフォールでのWon/Biz(受注/失注)にいたるまでの正確なデータを持っていませんでした。というのも、営業の商談サイクルが9-12か月くらいであるのに対して、商談を開始して3か月程度たった段階で受注できないことがわかると、マーケチームが創出したSQLを「”将来的”に見込みのあるリード」としてステータスを戻していたためです。その商談が再びホットになり、受注に向けて動き出すと、新たに重複した商談を新規に立て、マーケ由来のSQLを却下することで、営業由来(SGL)のSQLだけ残すというからくりです。
こういったものが以下で解説するサンドバガーの典型例です。
（訳者注：SGLの割合が全体の70%と解説が最初にありましたが、このような状況では実情よりかなり多くなってしまうという、数字上のトリックが出ていると言えるでしょう） 

デマンドウォーターフォールのポイント3 – 営業の特徴から生まれるSGL精度のバラつき 

シリウスディシジョンズが、SGLをデマンドウォーターフォールの一部に組み込んだことは必然と言えるでしょう。しかし私見を述べるなら、おそらくSGLが数値の妥当性を検証することが最も難しいステージといえます。筆者自身、10億ドルを動かすソフトウェアプロバイダーとしての営業経験がありますので、営業の特徴に関して説明していきたいと思います。 

プッシュ

3つポイントがありますが、1つ目が「プッシュ」です。

売上見込みを立てている商談に対して、営業担当がパイプラインの初期の段階でアクティブにしたまま放置をしていても、それをとがめない管理職は想定以上に多い印象です。しかし、実情の案件ステージは変わらないので、システム上で次の期に、次の期にと成約予定時期を「プッシュ」しながら、ずらしていくのです。見込み金額を置く際、営業担当は自身のアクティブなSQL数値のターゲットを満たしながらも、目に留まるほどの大きな数字ではなく、なおかつ重要顧客(キーアカウント)には紐づけないといった巧妙な細工をします。このような「アート」ともいえるパイプラインの操作が常態化すると、実情がどんどん見えなくなってしまいます。 

サンドバガー

2つ目が「サンドバガー(Sandbagger)」です。

前述の重複した商談の例の通り「手柄を横取りする人」と言え、もしかすると皆さんも身に覚えがあるかもしれません。サンドバガーに対応するためには、販売サイクルの長いBtoBビジネス(特にソリューション提案)において、販売サイクルが30〜60日未満などの短期間の商談であった場合、営業責任者が案件を個別に承認するプロセスが必要です。承認されない案件は「そのデータは正しくない」と判断されるため、商談作成日を自動的に上書きするロジックを用意しなければならないケースもあります。例えば、最後の発注日から次回の商談日を自動で計算するなどです。 

ベストケースシンドローム

3つ目は「ベストケースシンドローム」です。

このタイプのSQLはベストケースを想定して組み立てられてしまうため、「希望的観測のパイプライン」とも言えるでしょう。マーケティングチームは、デマンドウォーターフォールモデルを展開する上で、ベストシンドロームタイプのSGLには特に注意を払わないといけません。 

このタイプでは、営業部が四半期ごとにアグレッシブなパイプライン創出目標をたて始め、マーケティング部門にも協力を求めてくるでしょう。私の前職で営業部がこのタイプに陥ってしまった際には、架空の案件を翌四半期に登録し、「案件が発生して、すでにプリセールスチームと要件定義の会議を進めている。大規模案件になる可能性はあるが、伝えるには時期尚早なので改めてアップデートする」という”おとぎ話”を語りました。
（この手の話をするときは、「まだ時期尚早」と伝えることが重要です。これにより次の期が来たらその次の期に”プッシュ”できます）

以上のことから、SGLを活用していく上では規律が重要であるとご理解いただけたでしょう。このテーマはシリウスディシジョンズのサミットやイベント、マーケターやシリウスのアナリストによるプレゼンテーションにおいて、長年に渡って力説されてきた内容です。SGLを、MGLとTGLとならびベンチマーク指標として活用する上では、このようなバラつきをなくすことが不可欠なのです。