MQL/SQL・PQL概要：リード認定の各段階

Webサイトに訪れた人が、料金ページを2回目に訪れたとき、その人をどう扱えばよいでしょうか。資料や電子書籍をダウンロードしたときは、どうでしょうか。サービスを提供している私は、次にどう行動すればよいでしょうか。何もしなければ、売上に悪影響をもたらしますし、カスタマーエクスペリエンスから見て思わしくない状況になります。

アプローチまでの時間が長すぎると、リードは他を探すでしょう。他の競合に目を向けるでしょう。アプローチが早すぎると、これもまた自社を避けるでしょう。

リードの行動と、リードにアプローチするタイミングを知るには、カスタマーライフサイクルやセールスファネルのどの位置にリードがいるかを見極める必要があります。

リードと見込み客（プロスペクト）

リード（Lead）が見込み客（Prospect）に至る段階を表すのか、見込み客（Prospect）がリード（Lead）の各段階として遷移していくのか、業界や会社やモデルによって扱いが異なります。それに、リードや見込み客の定義が流動的で、確定した定義はないというのが実情です。

ここでは以下のように定義します。

リードとは

MQL（マーケティング適格リード）、SQL（販売適格リード）、及び、適格リードに至る直前の段階を含む人の状態を指します。PQL（製品適格リード）では、PQLがリードです。

見込み客（プロスペクト）とは

SQLを通過した人が見込み客です（ただ、MQL/SQLリードに至る前の段階を見込み客と呼ぶ場合もあります）。PQLでは、例えばSaaSでよくあるサインアップもしくはトライアルに登録した人が見込み客です。

MQL/SQLを含む販売サイクル（顧客獲得プロセス）

MQL/SQLを含む販売サイクルは、リードの生成からリードを顧客（カスタマー）に変換するまでのプロセス（ジャーニー）です。ここではカスタマージャーニーを以下のようにします。

MQL（マーケティング適格リード）とは？

MQL（Marketing Qualified Lead、マーケティング適格リード）とは、基準に応じて特定の行動や複数の行動をとったものの、まだ購入には至っていないリードのことです。彼らは自分が何かしらの問題を抱えていて、それを解決してくれるだろうものとして、製品やブランドに関心を持っています。

適格リードと見なすには、少なくとも以下3つの基準に適合しなければなりません。

必要性（ニーズ）がある

製品で解決できる問題を抱えていること。例えば、提供できる「スキル」もまた製品ですので、グラフィックデザイナーにとって、ポスターを作りたいが作れないという問題を抱えている人は、適格リード候補となります。

予算がある

製品を買うことができること。予算がなければリードに適格とはなりません。

権限がある

意思決定者であること。B2Bの際の決済者であるかどうか、B2Cの場合は成人であるかどうかです。未成年個人はトラブルの元ですので適格リードとしないのが安全です（2022年4月1日からは18歳以上が成人となります）。

リードがMQLになるのは、およそ以下のような場合です。

• ニュースレターや無料クーポンに登録する
• オンラインで製品のデモ動画を見る
• 電子書籍や体験版ソフトなどの無料ソフトをダウンロードする
• 料金ページに何度もアクセスする
• 商品をお気に入りやウィッシュリストに登録する
• ショッピングカートに商品を入れたままにする
• チャットボットと対話する
• 詳細情報を求めて連絡してくる

MQLは、WebサイトやSNSを見ただけで何の反応も示さず、リードジェネレーションファネルにも入らない受動的な訪問者とは異なります。

訪問者がブランドに興味を持ってくれれば、カスタマージャーニーが始まり、マーケティングオートメーションソフトウェアを使っている場合は、連絡先と見なされます。

MQLとするには、上記のように、どのような見込み客の行動が購買意思を示していると考えられるかを特定しなければなりません。この判断材料は、販売者側から見た極めて主観的な基準ですので、見込み客の意図を深く理解できない欠点があります。

MQLとSQLとの違いは？

MQLとSQL（販売適格リード）との違いは、訪問者の購買意欲の違いです。MQLは、製品やサービスに興味・関心を持ってはいますが、ファネル上では検討段階にあり、SQLは、今すぐにでも購入したいという気持ちがあってコンバージョンに向けて動いている状態となります。

例えば、MQLは、「CRM」「マーケティングオートメーション」のようなフレーズでソフトウェアソリューションを検索しています。SQLは、CRMソフトウェアを必要としているのが明らかなので、ブランドをいくつか検索してみたり、製品のデモを依頼しています。

リードマーケティングソフトウェアには、リードスコアリング機能が含まれていることもあります。MQLがスコアリングの閾値に達した場合、それをSQLとして営業チームに渡します。

営業チームが必要十分な数のリードを持っていて、顧客データの詳細なデータベースにアクセスしない場合は、リードスコアリング機能を使わないこともあります。その代わりに、SQLとMQLの定義に基づく特定のアクションによってリードを識別し、優先順位付けを行います。

リードをスコアリングする際に確認すべき情報はおよそ以下になります。

• 個人情報（氏名、メールアドレス、電話番号、役職名など）
• 会社情報（業種、売上高、従業員数など）
• 電子メール、SNS、Webサイトなどの各チャネルにおけるマーケティングへの関与の度合い
• オンラインでの行動や参照元チャネル

MQLを営業に引き渡すタイミングは？

セールスコールやデモの依頼など、リードの一定のアクションによってMQLはSQLに変わりますが、実際の定義やタイミングは、営業チームやマーケティングチームによって異なります。

MQL/SQLを明確に定義することは、スムーズなリードの受け渡しと、優良なリードのパイプラインを充実させるために不可欠となります。

MQL/SQLの定義には、以下のような顧客セグメンテーションの各要素を用いることができます。

人口統計（デモグラフィック）

職種、会社規模、年収、業界、地域など、リードに関する詳細情報です。

企業属性

従業員数、売上高、法的構造やステータス、業績などの企業固有のデータです。

行動分析

エンゲージメント数やタイプなど、コンテンツに対する顧客の行動についての洞察です。

テクノグラフィック

IT系ソフトウェア企業の場合は、テックスタックを評価し、企業ソリューションと統合するシステムを使用しているリードを優先することがあります。

定義付けが終わったら、リードを営業と結びつけるためのアクションをリストアップします。販売サイクルの長い企業では、リードがSQLの要件を満たす前に、関心の高いいくつかの活動を完了する必要があるかもしれません。一方、販売サイクルの短い企業では、営業チームがもっと早い段階で関与することもあります。

MQLの6ステップ

MQLのプロセスでは、リードの育成（リードナーチャリング）によって、SQLへの移行を促します。

1. 認知から訪問者へ

Webサイト、SNS、広告、検索エンジンなどのマーケティングチャネルで、ブランドあるいは製品を知った人（「認知（Awareness）」）がWebサイトへの「訪問者」となります。

2. 訪問者からコンタクトへ

「訪問者」は購買意思があるかもないかも不明です。彼らはファネルの一番上（TOFU）に登場しますが、ブランド、製品、サービスについてまったく知らない場合も多く、自分に解決すべき問題があることにさえ気づいていないかもしれません。

チャネルの情報に引っかかった訪問者は、生活の中で何らかのフリクション（問題、障害）を経験しており、それ故に、無意識的にチャネルから興味を持ったり、フリクションの解決策を探している場合もあります。

ここでの目標は、訪問者を「コンタクト」すなわち「IQL（Information Qualified Lead、情報適格リード）」に変えることです。

訪問者が、以下のような情報を得るためにメールアドレスなどの情報を提供すると、IQLとなります。

• ハウツーガイド、ビデオ、ブログ記事
• チェックリスト
• インフォグラフィック
• 教育用ウェビナー
• 無料テンプレート
• ニュースレター（メルマガ）

3. IQLからMQLへ

コンタクトはまだTOFUの認知段階です。しかし、詳細情報を得るためにメールアドレスを送信するなど、ブランドに関わり始めています。しかし、多くのIQLは情報を得ても行動を起こしません。調べ物をしていたり、学生だったり、競合他社だったり、理想的な顧客像に当てはまらないリードが大部分を占めるからです。

この段階では、評価、検討、関心、欲求の段階とも呼ばれるファネルの中央部分（MOFU）に移動しているかどうか、行動の手がかりを見極めることが重要です。

ターゲットのペルソナに合致し、ブランド認知度が高く、製品に興味を持ってくれたリードは、ある程度の信頼関係が築けているウォームリードとしてMQLに移動させることができます。

4. MQLの育成

MQLは、自分や自社が問題を抱えていることに気づき、それを解決するために、どの程度の費用や時間がかかるかを知りたいと思っています。まだ購入段階ではありませんが、明確な回答を求めています。

リード（IQL）が、「飼い犬をうまく散歩できる方法」を探しているのに対し、MQLは、「飼い犬のしつけサービス」や「ドッグトレーナー」を探しています。

MQLは、購入方法、比較表、よくある質問（FAQ）などをつぶさに見て、Webサイトの滞在時間が長時間に渡るかもしれません。無料サンプルの提供や、製品デモ、顧客の声などのマーケティング活動は、MQLを次のステップSQLに移動させるのに役立ちます。

5. MQLからSQLへ

SQLの定義とスコアリングによって、MQLがSQLに移行するタイミングが決まります。マーケティングオートメーションソフトウェアは、自動的にMQLをSQLに登録します。

SQLを判定する行動は例えば以下のようなものがあります。

• 製品の無料トライアルやソフトウェアのデモに申し込む
• 製品、価格、サービスに関する詳細情報を問い合わせる
• より詳しい情報を得るために連絡するよう要望する
• 製品が現在のテックスタックにどのように適合するかについての詳細情報を要求する

6. SQLから顧客へ

リードがMQLからSQLに変わった後は、営業チームが担当します。SQLは購入を決断する前に、より多くの情報を要求します。折り返し電話や見積もりを要求したり、無料トライアルやデモの期間が終わると、連絡してきたりします。

販売戦略では短時間で対応することが不可欠です。リードが購入の意志を示せば、即座にコンバージョン（購入）するために必要なものを提供しなければなりません。

リード適格のモデル/フレームワーク例

以下のようなモデルがあります。

• BANT ― 予算（Budget）、権限（Authority）、必要性（Need）、タイミング（Time frame）
• ANUM ― 権限（Authority）、必要性（Need）、緊急性（Urgency）、予算（Money）
• FAINT ― 資金（Funds）、権限（Authority）、興味（Interest）、必要性（Need）、タイムライン（Timeline）
• GPCT、GPCTBA/C&I ― 目標（Goals）、計画（Plans）、課題（Challenges）、タイムライン（Timeline）、予算（Budget）、権限（Authority）、悪影響と好影響（Negative Consequences and Positive Implications）
• ChAMP ― 課題（Challenges）、権限（Authority）、予算（Money）、優先順位（Prioritization）

これらのモデルを活用し、リードをスコアリングし、適格か判定します。

MQL/SQLの問題点

様々な調査結果がありますが、訪問者からリードへのコンバージョン率は5～15％程度で、そこから顧客に至るまでのコンバージョン率は1～10％です。

中間をとって、それぞれ7.5％、5％とすると、1,000人の訪問者が75人のリードになり、最終的に3～4人が顧客になる計算です。場合によっては、1,000人の訪問者のうち顧客になるのはゼロということもあり得ます。ということは、75人いるリードの大半を捨てることになり、そこに費やすリードの育成（リードナーチャリング）に多大なコストを支払う羽目になります。

MQL/SQLの問題点は、そのリードが育成するに値するか、すなわち、本当に購買意欲のあるリードなのか、判断基準が主観的で曖昧で、購買意欲との相関を判断しにくいことです。それ故に、マーケティングとセールスとのギャップが生じます。

マーケターは購入意思のない、あるいは購入の準備ができていないリードをセールスに渡し、セールスはリードの質に不満を抱きます。MQLとされたリードは、SQLでさらに適格性を高める作業を行うこととなり、非効率ゆえにコストが嵩みます。

ビジネスに疎いセールス担当がチームにいると、報酬目当てで適格性のないリードに強引な営業を行い、無理やり成約に結びつけようとすることもあります。そうなると、その後のプロダクトチームやカスタマーサクセスチームに多大な負荷がかかり、ビジネスが破綻の危機に陥ります。これはMQL/SQLの問題ではなく営業資質の問題のように見えますが、適格性を判断し切れていないために起こりうる問題です。

販売主導でのビジネスでは、製品とのミスマッチが起こりやすくなります。例えば受託開発などで、プロダクトチーム、この例ではエンジニアチームになりますが、セールスチームが、既存スキルや納期では対応しきれない要件の案件を受注した場合、新規技術習得などのコストがすべてプロダクトチームに降りかかることとなります。

PQLを含む販売サイクル

PQLを含む販売サイクルは、リードの生成からリードを顧客（カスタマー）に変換するまでのプロセス（ジャーニー）です。ここではカスタマージャーニーを以下のようにします。

PQL（製品適格リード）とは？

PQL（Product Qualified Lead、製品適格リード）とは、製品への関心、使用状況、行動データに基づいて適格とした、購入意思を示したリードです。

PQLとして認定できるリードは、製品を使い倒していて、問題を自己解決したいと思っています。ということは、頻繁に質問や問い合せをしてきて、問題を自分で解決するのに消極的な人は、PQLとしては認定できません。

経験的に、こういった顧客をPQLあるいはSQLとして製品を販売したり、アップセルやクロスセルなどをしてしまうと、サポートのコストが掛かりすぎる上に、解約（チャーン）の確率が極めて高くなります。一時はカスタマーサポートの質が問題と考えたこともありましたが、顧客として相応しくない人に製品を売っていたことが原因だったのです。

よくテストで同僚、知人、家族に製品を使ってもらい意見を求めることもあるでしょう。しかし彼らはその製品を買おうとしていませんし、買うつもりもありません。ですので、PQLにおいて、彼らの意見は参考になりません。

多くの人が、AmazonやAppleといった企業のサービスを使ったこともあるでしょう。私はAmazonのヘビーユーザーですが、Amazonから顧客アンケートなどで意見を求められたことが一度もありません。

彼らは顧客の意見を必要としていません。ビジネスを進めていくのに主観的で曖昧な「言葉」は（宣伝面以外）不要なのです。というのも、製品への関心も使用状況も行動履歴も、常に実際の具体的なデータとして収集して分析しており。これを元に製品を改良し続けているからです。

Amazonで製品を物色しているときに、営業担当者に製品の説明を受けたいと思う人はほとんどいないでしょう。購入前に、その製品がどれだけ素晴らしいものかを過剰に宣伝されずとも、自分で探し、自分で判断して買いたいと思っています。

PQLにおいては、製品がどれだけ素晴らしいかを伝える必要はありません。顧客は、製品を使うことで製品の価値を発見します。

実際、Gartner社の調査によると、2025年までにB2Bの80％がデジタルチャネルで購入され、33％の顧客は営業担当者との接触を望まず、これがミレニアル世代になると44％にまで上昇します。また、Aspect社の調査によると、顧客の71％は問題の自己解決を望んでいます。

オンライン会議のMicrosoft Teamsのホームページには、「無料でサインアップ」と「サインイン」のボタンが一番目立つ位置にあります。

そして、自己解決（セルフサポート）のためのリソース、トレーニングが充実しています。

旧来のセールスレターやランディングページに慣れているマーケターは、ファーストビューに「サインアップ」のコンバージョンエリアがあることを、疑問に思っていたかもしれません。

ここまで読めばお分かりのように、顧客は、すぐに製品を試すことを望み、製品に触れる前の長々としたセールスコンテンツを望んでいません。そして、製品提供側は、顧客が製品を使うことで得られる具体的なデータによって、ビジネスを成功に導けるのです。よって、優先すべきは、最終的にコンバージョンさせるための込み入った「仕掛け」ではなく、製品内に導くコンバージョンエリアとなります。

PQLはSaaSのみに適用できるのか

フリーランスにとって、営業以外のフリーランスですが、特に芸術・技術系のフリーランスにとって、営業というのはまったくビジネス文化が離れすぎていて、自分のビジネスに採り入れていくのは、相当な困難が伴います。

ですので、MQL/SQLは取っ付きにくく、企業文化に合いにくいかもしれません。ビジネスを、セールスが強い「販売主導文化」、マーケティングが強い「マーケティング主導文化」、製品開発が強い「製品主導文化」、カスタマーサクセスが強い「顧客主導文化」に分けると、先述のフリーランスは、製品主導文化もしくは顧客主導文化に属するでしょう。

そのため、ビジネスの文化に沿ってPQLを設計していくのが肝心です。理想的な地点は、営業・販売の自動化です。例えばサブスクリプションの形態や、中長期に渡ってサービスを提供しているのであれば、話は早いです。しかし、受託ビジネスであろうとも、工夫次第で実現可能です。製品にそれほど差はないでしょうから、差別化すべきは、顧客にどういう認識をさせ、どういう体験をもたらすか、すなわちカスタマーエクスペリエンスです。