BtoBマーケのKPIを「お問い合わせ数」だけで見るのをやめた話
「今月もお問い合わせ、増えてます。先月比プラス20件です」
受託のWebコンサルをしていた頃、クライアントの定例でそう報告するのが、私の"良い仕事"でした。営業さんには喜ばれます。商談の種が増える話ですから。
でも、同席している経営者の反応は、いつも薄い。あるとき、はっきり言われました。
「で、受注にはどれくらいつながってるの？」
言葉に詰まりました。報告していたのは、営業メールなどのノイズを除いた"正しい"問い合わせ数です。数字は間違っていない。それなのに、経営には届かない。
先に結論を言います。私はこのあと、「問い合わせ数を報告する」こと自体をやめました。代わりに、受注から逆算して"どこからが営業の仕事か"を、経営と握りにいくようにした。そうしたら、ようやく数字が"次の一手"につながり始めました。
なぜそこに行き着いたのか。少し恥ずかしい失敗談と、その裏にあった構造、そして公開されている理論を突き合わせながら、明日からできる最小の一歩まで書きます。
先に結論：「問い合わせ数の報告」をやめて、"どこからが営業の仕事か"を握ることにした
問い合わせ数は、ファネルの"入口の一指標"でしかありません。
追うべきは、受注（ゴール）から逆算した各段階の数字。そして何より、「ここまでがマーケの仕事、ここからが営業の仕事」という線引きを、誰と、どう握るかです。
この線引きさえ握れてしまえば、マーケの報告は「問い合わせが増えました」から「営業に渡せる質のリードを◯件作りました。線の先はお願いします」に変わります。経営との会話が、まるで変わります。
きれいにまとめましたが、ここに至るまでが長かった。順に話します。
「お問い合わせ、増えてます」と報告していた頃
受託のWebコンサルとして、私は毎月、クライアントに問い合わせ数の増加を報告していました。
現場サイド、特に営業さんには本当に喜ばれます。商談の種が増える話なので、当然です。「今月も反響いいですね」なんて言われると、報告している自分も、正直、仕事をした気になっていました。
でも不思議なことに、この声は経営サイドには驚くほど届かない。定例で経営者が同席すると、空気が変わる。うなずきはするけれど、身を乗り出してはこない。あの温度差の正体が、当時の私にはわかっていませんでした。
ノイズは除いていた。それでも経営には響かなかった
誤解のないように言うと、雑な数字を報告していたわけではありません。営業メールやスパムのような明らかなノイズは除外した、"きれいな"コンバージョン数を出していました。数字は正しかったんです。
それでも、経営の反応は変わらない。
理由はシンプルでした。経営が見たいのは商談の数ではなく、受注だからです。商談がいかに獲得できたかは、経営にとっては（言い方は悪いですが）割とどうでもいい。どれぐらい受注できたかがすべて。だから報告のたびに、必ずこう返ってくる。
「その問い合わせの"質"はどうなの？」
そして、もっと厄介な副作用がありました。営業側が「この問い合わせ、見込みないな」と気づき始めるんです。数だけ増えて質が伴わないリードを渡され続けると、問い合わせを処理するモチベーションが静かに、確実に下がっていく。
数字は増えているのに、現場は疲れていく。数字は正しいのに、機能しない。
これが「単一指標の罠」の正体だと、いまなら言えます。冷やかしが混ざるとか、そういう話ではない。問い合わせ数という一つの数字だけでは、誰も意思決定できないという、構造の問題でした。
理論でも同じことが言われている——デマンドウォーターフォール
見方を変えるヒントは、実は昔から公開されていました。
BtoBマーケの世界には、デマンドウォーターフォールという有名なフレームワークがあります。米SiriusDecisions社（現在はForrester傘下）が提唱したもので、リードが受注に至るまでを段階で定義するモデルです。
段階はこうです。
Inquiry（問い合わせ）→ MQL（マーケが有望と判断）→ SAL（営業が受け入れ） → SQL（営業が有望と判断）→ Close（受注）
私がこのモデルで一番好きなのは、SAL（Sales Accepted Lead）という段階がわざわざ存在することです。
「営業がそのリードを受け入れたかどうか」を、独立した関門として明示する。しかも、受け入れを拒否するなら理由を残させる。つまりこのモデルは、マーケから営業への受け渡し点があいまいになること、そして営業が黙ってリードを選り好みすることを、"構造で"防いでいるんです。
もうひとつ、マーケと営業の間で「ここまでマーケが頑張る、ここからは営業が頑張る」を口約束ではなく文書で合意するSLAという考え方も広く知られています。MQLの定義は「フィット（相手がターゲットに合っているか）」と「エンゲージメント（買う気配があるか）」の両方で決めるのが原則で、片方だけでは不十分。そして、マーケがMQLと呼んでも営業が動かないなら、その定義のほうが間違っている——とまで言われます。
私が現場で悶えていた問題は、理論の側では、とっくに整理されていたわけです。
参考：SiriusDecisions Demand Waterfall（Forrester公式ブログ・英語）
「誰が」線を引くのか——私が実際にやったこと
ここからが、この記事でいちばん書きたかったことです。
MQLやSQLの線引きが大事。ここまでは理論の通り。では、その線は誰が引くのか。
最初、私は営業側に基準を聞きに行きました。そして学びました。営業に聞くと、自分たちが商談しやすいリードしか持ってこない。悪気はないんです。ただ、自分の成果に直結する基準を自分で決めていいなら、誰だってそうする。
だから私の結論はこうです。線引きのジャッジは、営業単独に委ねてはいけない。経営者か、事業全体を統括している人が行うべき。「ここまでは営業頑張れ、ここまではマーケ頑張れ」と、事業全体を見ている人が線を引く。受注から逆算したときに、これが一番大事な"営み"だと思っています。
ただし、経営がジャッジするには判断材料が要ります。私はそれを、受注の"実態"に自分で潜り込んで取りに行きました。
まず「受注履歴を見せてください」とお願いする。……基本、出てきません。これはもう、あるあるだと思ってください。逆に言うと、受注履歴がすぐ出てくる会社は、それだけで結構できている会社です。
出てこないなら、現場に行くしかない。私はクライアントの営業さんが実際に商談している場に、同席させてもらいました。
もちろん、都合の悪い情報を見せないパターンもあります。なので鵜呑みにはせず、疑いは持ちながら。それでも、商談の場には一次情報しかありません。どんなデータが出て、どんな会話になったか。そこから「お客さんには、こういうニーズとこういう前提があったはずです」と読み解く。
そのうえで、経営・事業統括にこう提案しました。
「商談を見た結果、実態はこうでした。だから、こういう座組にしませんか。ここまでをマーケが持ちます。ここから先は営業にお願いしたい」
一次情報を根拠にすると、この提案は通ります。そして一度線が引ければ、マーケのKPIは「問い合わせ数」ではなく「線のこちら側で、質の合ったリードを何件作れたか」に変わる。デマンドウォーターフォールのSALやSLAが"上位の合意"を前提にしているのは、そういうことだったのかと、あとから腑に落ちました。
明日からできる、最小の一歩
「わかったけど、いきなりKPIツリーだのスコアリングだの作れないよ」と思った方へ。作らなくていいです。最小の一歩は3つだけです。
STEP1：まず「3つの数字」を横に並べる。 入口（問い合わせ数）・中間（商談化数）・成果（受注数）。この3つを1枚に並べるだけ。それだけで「どこが詰まってるんだっけ？」という会話が始まります。単一指標では、この会話が永遠に始まりません。
STEP2：営業と一緒に、直近の問い合わせを仕分けする。 「これは追うべき」「これは追わなくていい」を一件ずつ。この仕分けの中に、あなたの会社のMQLの"たたき"が眠っています。
STEP3：その基準を、経営・事業責任者に持って行って握る。 できれば商談の場も覗かせてもらう。一次情報を添えて、「この線でいきませんか」と提案する。握れた瞬間から、数字の意味が変わります。
まとめ：数字は"報告"のためではなく、"次の一手"と"合意"のために見る
問い合わせ数の報告で満足していた頃の私は、数字を「報告するもの」だと思っていました。
いまは違います。数字は、次の一手を決めるためのものであり、マーケと営業と経営が同じ景色を見るための合意のツールです。問い合わせ数はその入口の一つでしかなくて、単体では誰の意思決定も動かせない。
もしいま、毎月「問い合わせ、増えてます」と報告して、どこか手応えのなさを感じているなら。まずは3つの数字を横に並べるところから、始めてみてください。
（次回は、この記事で触れたMQL/SQLの「決め方」を、もう一段実務に踏み込んで書く予定です）
