はじめに
営業ファネルやマーケティングファネルは、多くの企業で「現場の管理ツール」として扱われています。
マーケティング部門が管理し、営業部門が数字を更新し、COOがその結果をレビューするプロセスは一見すると合理的に見えますが、この運用には大きな落とし穴があります。
それは、ファネル設計そのものが現場任せになっていることです。
ファネルは単なる進捗管理の枠組みではありません。
本来は、売上がどの構造で生まれ、どこで詰まり、どこで失われるのかを定義する経営設計です。
本記事では、なぜCOOがファネル設計を現場に委ねてはいけないのか、そしてCOOがどのレイヤーまで関与すべきかを整理します。
ファネルは「管理表」ではなく「売上構造の設計図」
多くの企業で使われているファネルは、次のような扱いになっています。
- ステータスを並べた管理表
- 案件進捗を報告するためのフォーマット
- KPIを置くための箱
しかしCOOの視点では、
ファネルは売上構造そのものを表す設計図です。
- 売上が生まれるまでに、顧客はどんな状態変化を経るのか
- どの段階で失注が発生しやすいのか
- どこに手を入れると、全体に最も効くのか
これらを可視化するのがファネルの役割です。
ファネルを現場任せにすると起きる3つの問題
ファネル設計を現場に委ねると、次のような問題が必ず起きます。
ファネルの粒度が担当者依存になる
営業ごと、マーケ担当ごとに「どこからが次のステージか」の認識がズレます。
結果として、数字はあるのに、同じファネルを見ているはずの人同士で話が噛み合わない状態になります。
ステージが過度に増殖する
現場の改善要望を反映するうちに、
- フェーズA-1
- フェーズA-2
- フェーズA-2-仮
といったステージが増え、誰のためのファネルか分からなくなります。
売上構造ではなく進捗管理になる
本来見るべきは「どこで売上が生まれなくなっているか」ですが、実態は「誰の案件が遅れているか」の管理になります。
これは、ファネルが経営の道具ではなく現場管理の道具に落ちた状態です。
COOがファネル設計で担うべき役割
COOがファネル設計で担うべき役割は明確です。
ファネルを売上構造として定義することです。
COOが決めるべきなのは、
- ステージ数の上限
- 各ステージの意味
- 次に進める条件
現場が決めるのは、その条件をどう満たすかという運用部分です。
この線引きができていないと、ファネルは必ず現場都合に最適化されます。
COO視点での「良いファネル」の条件
COOが設計すべきファネルにはいくつかの条件があります。
売上に直結する状態変化だけで構成されている
ステージは、「顧客の状態が変わったかどうか」で区切られている必要があります。
社内都合の作業進捗はファネルに含めるべきではありません。
説明できる数に抑えられている
ステージ数が多いファネルは一見管理しやすそうに見えますが、説明判断がしにくくなります。
COOが説明できないファネルは設計として失敗です。
改善ポイントが見える
各ステージの遷移率を見ることで、「どこに手を入れるべきか」が一目で分かる構造が理想です。
ファネル設計とMQL・SQLの関係
ファネル設計とMQL・SQLは、必ずセットで考える必要があります。
- MQLはどのステージに位置づくのか
- SQLに進む条件は何か
- 失注した場合、どこに戻すのか
これらが曖昧なままでは、ファネルは単なる箱の並びになります。
COOは、ファネルと責任境界を同時に設計する立場です。
ファネルをCOOが握ると何が変わるか
ファネル設計をCOOが担うと、組織の景色は大きく変わります。
- 会議で議論すべき論点が減る
- 改善施策の優先順位が明確になる
- 数字が判断材料として機能する
これは、売上が構造として管理されている状態です。
COOがやってはいけない関与の仕方
誤解されがちですが、COOがファネルを握ることと細かく口出しすることは別です。
- 各案件の進捗を追いすぎる
- ステージ移動を逐一承認する
- 現場のやり方を細かく指示する
これらはすべて設計ではなく運用への過干渉です。
COOはファネルの「形」と「意味」を決め、あとは運用を任せるべきです。
まとめ
ファネルは、営業やマーケの管理ツールではありません。
売上構造を定義するための経営装置です。
COOがやるべきことは、
- ファネルを構造として設計する
- ステージの意味と条件を定義する
- 改善判断に使える形に保つ
これを現場任せにした瞬間ファネルは経営から切り離され誰も見ない枠組みになり下がってしまいます。
コメント