はじめに
MQLやSQLという言葉は、多くの企業で使われています。
しかし実際には、その定義が組織内で曖昧なまま運用されているケースがほとんどです。
- マーケティングは「十分に温度感のあるリードだ」と言う
- 営業は「全然売れる状態ではない」と言う
- COOは数字を見ているが、どこでズレているのか分からない
この状態は、現場の努力不足ではありません。
MQL・SQLを定義すべき立場の人が、定義していないことが原因です。
本記事では、営業・マーケティングを管掌するCOOとして、
MQL・SQLをどう定義し、売上創出プロセス全体をどう設計すべきかを構造的に整理します。
MQL・SQLは「マーケティング用語」ではない
MQL（Marketing Qualified Lead）やSQL（Sales Qualified Lead）は、マーケティングや営業の専門用語だと誤解されがちです。
しかしCOOの視点では、MQL・SQLは売上創出プロセスにおける「責任の切り替え点」です。
- どこまでをマーケの責任とするのか
- どの状態から営業が責任を持つのか
- 受注に至らなかった場合、どこに戻すのか
これらを曖昧にしたままでは売上プロセスは構造として成立しません。
なぜMQL・SQLが曖昧な会社は必ず揉めるのか
MQL・SQLが曖昧な組織では、次のような現象が起きます。
- マーケは「数は出している」と主張する
- 営業は「質が悪い」と不満を持つ
- 失注理由が誰の責任か分からない
これは人間関係の問題ではなく責任境界が定義されていない構造の問題です。
COOがMQL・SQLを定義しない限りこの対立は形を変えて繰り返されます。
COOが考えるべきMQLの定義
COO視点でのMQLは、「マーケ施策として成功したリード」ではありません。
営業プロセスに引き渡してもよいと判断できる状態がMQLです。
COOがMQLを定義する際に考えるべき観点は以下です。
- 顧客属性はターゲットに合致しているか
- 課題やニーズが顕在化しているか
- 営業が次のアクションを取れる情報が揃っているか
重要なのはMQLを「数」で定義しないことです。
COOは売上構造上の意味で定義する必要があります。
COOが考えるべきSQLの定義
SQLは、単に「営業が対応したリード」ではありません。
営業が受注に向けて時間を投下すべきと判断した状態です。
COOがSQLを定義する際には、
- 決裁権者との接点があるか
- 予算・時期・検討度合いが一定水準にあるか
- 営業工数をかける合理性があるか
といった観点を営業個人の感覚ではなく構造として整理します。
MQL・SQLは売上創出プロセスの一部でしかない
重要なのは、MQL・SQLを単独で定義しても意味がないという点です。
COOが設計すべきなのは、リード獲得から受注、失注、再アプローチまでを含めた売上創出プロセス全体です。
- MQLにならなかったリードはどう扱うのか
- SQLから外れた案件はどこに戻すのか
- 再度マーケに戻す条件は何か
この循環を設計しない限り、MQL・SQLは単なるラベルになります。
COOが主導すべき売上創出プロセス設計
COOは、売上創出プロセスを部署別ではなく一本の線として設計する必要があります。
- 顧客の状態がどう変化するか
- その変化に対して誰が責任を持つか
- 次の工程に進める条件は何か
この設計ができて初めて、営業とマーケは「連携」ではなく「分業」になります。
MQL・SQLを定義するとCOOの仕事はどう変わるか
MQL・SQLが構造として定義されるとCOOの仕事は大きく変わります。
- 数字のズレを感覚ではなく構造で説明できる
- 部門間の対立に巻き込まれなくなる
- 改善すべき工程が明確になる
これは売上がプロセスとして管理されている目指すべき状態です。
まとめ
MQL・SQLは、マーケや営業のための用語ではありません。
COOが売上創出プロセスを設計するための判断装置です。
COOがやるべきことは、
- MQL・SQLを責任境界として定義する
- 売上創出プロセス全体を設計する
- その構造が拡大に耐えるかを判断する
この役割を放棄すると売上は出ていても組織は必ず歪みます。
コメント