MQLとSQLとは?違いと引き渡しの基準
この記事の結論
- MQLはマーケティング側、SQLは営業側が認めた段階を指します。
- 基準は受注顧客の属性と行動の種類から組み立てると、ぶれにくくなります。
- 営業が月に対応できる件数から逆算すると、基準の厳しさが決まります。
展示会やフォームで集めたリードを前に、営業へ渡すかどうかで迷うことがあります。この記事を読むと、リードを渡す側と受け取る側で、どの段階を何と呼ぶかを揃えられるようになります。あわせて、引き渡しの線をどこに引くか、運用でつまずいたときにどう立て直すかも扱います。
MQLとSQLとは何か
違いは、誰が見込み度を認めたかにあります。マーケティング側が認めた段階と、営業側が受け入れた段階に分かれます。
MQL(マーケティング活動で見込み度が上がったリード)の定義
MQL(Marketing Qualified Lead)とは、マーケティング側が営業に渡してよいと判断したリードです。
この段階を設ける目的は、集まった接点の中から、営業が時間を使う相手を絞ることです。
判断の材料は、資料請求や問い合わせといった行動と、業種や従業員規模などの属性です。例えば、月に集まった200件のうち、資料請求と見積依頼が60件あったとします。この60件をMQLとして扱う、という決め方をします。
SQL(営業が商談対象と認めたリード)の定義
SQL(Sales Qualified Lead)とは、営業が内容を確認し、商談を進める対象として受け入れたリードです。
目的は、渡されたリードを営業の目で確かめ、追いかける順番を決めることです。
マーケティング側が渡しただけでは、まだSQLではありません。営業が受け入れて初めてSQLになります。受け入れなかったリードは、マーケティング側へ戻して育成を続けます。
なぜ2つに分けるのか(分業と追跡のため)
理由は、責任の持ち場を分けることと、どこで数が減っているかを追えるようにすることです。
マーケティングはMQLの数と質に、営業はSQLから先の商談と受注に責任を持ちます。境目を決めておくと、話し合いの焦点が人ではなく基準に向きます。
数も追いやすくなります。例えば、ある月のMQLが60件で、営業が受け入れたSQLが24件なら、受け入れ率は40%です。翌月に30%へ下がれば、基準か集め方を見直す合図になります。
リードの流れの中でMQL・SQLがどこに位置するか
2つは、接点から受注までの間にある関門です。順番に並べると次のようになります。
- 名前と連絡先が分かり、リードになります。
- 行動や属性の条件を満たし、MQLになります。
- 営業が受け入れて、SQLになります。
- 提案や見積もりの話が始まり、商談になります。
この並びを社内で共有しておくと、週の初めの数字の確認が短く済みます。どの関門で止まっているかを、同じ言葉で話せるためです。
リード・MQL・SQL・商談は何が違うのか
4つの段階は、判断する人と判断する時点で見分けられます。似た言葉ですが、区切りははっきりしています。
リード(単なる接点)とMQLの違い
リードとは、連絡先が分かっていて、自社と何らかの接点ができた相手です。
名刺交換、資料請求、セミナーの申し込みなど、入り口は問いません。そこに見込み度の判断が加わると、MQLになります。
例えば、展示会で100枚の名刺をいただいたとします。この100件はすべてリードです。そのうち、後日に価格のページを見た相手だけをMQLとする、という区切り方ができます。
MQLとSQLの違いは誰が判断するか
一番の違いは、判断する人です。MQLはマーケティング側が、SQLは営業側が決めます。
見ている材料も違います。マーケティング側は、行動の履歴と登録された属性を見ます。営業側は、会話で確かめた検討状況や社内の優先順位を加えて判断します。
SQLと商談・案件の違い
商談とは、提案や見積もりなど、取引の中身について話し合いが始まった状態です。
SQLは営業が受け入れた段階で、まだ商談には進んでいません。連絡がつかないまま終わることもあります。SQLと商談の件数を分けて数えると、営業の接触がうまくいっているかが見えてきます。
見込み度のスコアと営業の受け入れ判断の違い
スコアリングとは、リードの行動や属性に点数を付け、見込み度を数値で表す方法です。
多くのリードに優先順位を付けるために利用します。スコアは機械的な目安で、受け入れは人の判断です。両方を揃えると、基準が安定します。
例えば、資料のダウンロードに3点、価格ページの閲覧に5点、問い合わせに20点を割り当てます。合計20点以上をMQLにする、といった設計です。ただし点数が高くても、予算や時期が合わなければ営業は受け入れません。スコアは入口の目安として扱うと、運用が落ち着きます。
引き渡しの基準をどう決めるか
基準は、属性・行動・会話で確かめる条件・対応できる件数の4つを組み合わせて決めます。順に埋めていくと、現実的な線が引けます。
自社の受注顧客に共通する属性から決める
出発点は、すでに受注しているお客様の共通点です。これが一番ぶれにくい材料になります。
直近1年の受注企業を並べ、業種・従業員規模・地域・担当部署を書き出します。例えば受注30社のうち22社が、従業員50〜300人の製造業だったとします。この条件に当てはまるリードを優先して渡す、という基準が作れます。
当てはまらない相手を切り捨てるわけではありません。優先の順番を決める材料として扱うと、営業との会話が進みます。
問い合わせ・資料請求など行動の種類から決める
行動の種類によって、見込み度の重みは変わります。問い合わせと資料請求を分けて扱うほうが、基準は実態に近づきます。
価格や見積もりの問い合わせは、検討が進んでいる合図です。入門的な資料のダウンロードは、情報収集の段階にとどまることもあります。導入事例や料金のページを続けて見ている動きは、その間として扱えます。
自社のフォームや資料を一覧にして、「すぐ渡す」「少し育ててから渡す」に仕分けておくと、迷いが減ります。
検討時期や予算の有無など会話で確かめる条件から決める
行動だけでは見えない部分は、会話で埋めます。中心になるのは、検討時期、予算の有無、困っていること、決め方の4点です。
購入を検討してもらえる段階かどうかは、行動の履歴だけでは見極めが難しいところです。ここが曖昧なままだと、リストの数字の読み方がぶれやすくなります。電話やオンライン面談で確かめた内容は、同じ項目名で記録しておきましょう。
例えば「3か月以内に導入を検討している」と確認できた相手だけをSQLにする、といった線引きができます。
営業が1か月に対応できる件数から逆算して決める
最後に、営業が対応できる件数で調整します。上限を超えて渡すと、基準の良し悪しとは別の理由で取りこぼしが起きます。
例えば営業が3名で、1人が月に新規20件まで対応できるとします。受け入れられるのは月60件です。MQLが月150件集まるなら、属性と行動の条件を足して60件前後に絞ります。
反対に、MQLが月20件しかなければ基準を緩めます。件数の逆算は、基準の厳しさを決めるつまみとして利用できます。
MQL・SQLの運用でつまずきやすい点
つまずきの多くは、基準の言葉が足りないところから始まります。起きやすい4つの場面と、それぞれの対処を見ていきます。
基準が曖昧でマーケと営業が言い争いになる
「質が低い」「追いきれていない」というすれ違いは、基準が文章になっていないときに起きます。
条件を文章にして、両者が読める場所に置いておくと安心です。あわせて、営業が受け入れなかった理由を選択肢で記録できるようにしておきます。理由がたまると、基準のどこを直せばよいかが見えてきます。
月の締めに短い時間でも、受け入れ率と差し戻しの理由を一緒に見る場を作ることをおすすめします。
MQLの数だけを追って質が落ちる
MQLの件数を目標にすると、条件を緩める力が働きます。件数と一緒に、受け入れ率と受注率を並べて見ておきましょう。
例えば、MQLが100件でSQLが50件なら、受け入れ率は50%です。翌月にMQLが200件へ増えてもSQLが60件なら、受け入れ率は30%に下がります。件数は倍でも、営業の手応えは薄くなります。
マーケティング側の目標を、MQLではなくSQLの件数に置く方法もあります。
営業が受け取らなかったリードが放置される
受け入れられなかったリードの行き先を決めておくと、取りこぼしが減ります。多くは、まだ時期が来ていないだけです。
差し戻されたリードは、育成の対象に戻します。再検討の時期が分かっていれば、その日付を記録します。時期が来たらもう一度営業へ渡す流れを作っておくと、あとが楽になります。
以前に見送った相手が、改めて問い合わせてくることもあります。記録が残っていれば、前回の話を踏まえて会話を始められます。
一度決めた基準を見直さないまま運用し続ける
基準は、商品や市場が変われば合わなくなります。見直す時期をあらかじめ決めておくと、そのままになるのを防げます。
四半期に一度、受注した顧客の属性と失注の理由を確認します。受け入れ率が大きく動いた月があれば、その月の変化もあわせて見ます。見直した内容は日付とともに残し、いつ何を変えたかを追えるようにしておきましょう。
まとめ
MQLはマーケティング側が渡してよいと判断した段階、SQLは営業が受け入れた段階です。違いは判断する人と時点にあり、ここを揃えるだけで社内の会話がかみ合います。基準は、受注顧客の属性、行動の種類、会話で確かめる条件、営業が対応できる件数の4つで組み立てます。まずは直近1年の受注顧客を一覧にして、業種と従業員規模の共通点を洗い出すところから始めてください。
Amoでできること
基準が決まったら、次はその条件に合うリードを手元に集める段階です。Amo の Leads では、手持ちのリストの取り込みから、条件に合う相手の絞り込みまでを行えます。
名刺リストや既存の顧客リストは、CSV(Comma-Separated Values/カンマ区切り形式)のファイルや表計算ソフトの表のまま取り込めます。事前の整形は不要で、列の対応は確認画面で修正できます。取り込むときにリスト名を入れると、そのリードをまとめた固定リストが作られます。例えば「9月展示会」と名前を付けておくと、あとで配信の宛先に利用できます。
取り込みの際は、その連絡先をどこでいただいたかを選びます。フォームからの問い合わせ、名刺交換・お取引、展示会・イベントなどから選ぶ形です。入手元が分かっていると、行動の種類で基準を作るときの材料になります。
1人ずつの追加も行えます。電話で聞いた相手や名刺1枚のときは、Leads 一覧の「リードを追加」から登録します。同じメールアドレスの方がすでにいる場合はその方の画面が開くため、二重の登録を避けられます。
商談や電話の内容は、活動タイムラインに記録できます。検討時期や予算を確かめた会話も、ここに残せます。記録に次回アクション日を入れると、「今日フォローすべき」でその日を迎えたリードだけに絞り込めます。差し戻したリードへの再アプローチにも役立ちます。
やってはいけないこと
- MQLとSQLの基準を、口頭の合意だけで運用するのは避けましょう。
- MQLの件数だけを目標に置くのはおすすめしません。
- 営業が受け入れなかったリードを、行き先を決めずに置いたままにするのは避けましょう。
- スコアの点数だけでSQLを決めるのは避けましょう。
- 一度決めた基準を、見直す時期を決めないまま使い続けるのは避けましょう。
よくある質問
Q. MQLとSQLの基準は、最初から細かく決めた方がよいですか?
A. 最初は属性と行動の2つで十分です。例えば「従業員50人以上の製造業」かつ「見積もりの問い合わせがあった」の2条件から始め、営業が受け入れなかった理由を記録していきます。例えば3か月ほど運用すると、足りない条件や厳しすぎる条件が見えてきます。細かく作り込むのは、その後で問題ありません。
Q. スコアリングの仕組みがなくてもMQLは運用できますか?
A. 運用できます。フォームや資料の種類ごとに「すぐ渡す」「少し育ててから渡す」を決めておくだけでも、引き渡しの線は引けます。点数の仕組みは、リードが増えて手作業の仕分けが追いつかなくなってから検討しても間に合います。
Q. MQLからSQLへの受け入れ率は、どのくらいを目安にすればよいですか?
A. 自社の推移を基準にする方法をおすすめします。例えば3か月分の受け入れ率を出し、その平均を基準にします。そこから大きく下がった月は、集め方か基準のどちらかを確認する合図として扱うと判断しやすくなります。