資料請求や診断登録は増えたのに、営業担当が「誰へ連絡すればよいか」を決められない。反対に、関心を確かめないまま連絡して、相手に売り込みと受け取られてしまう。
この混乱は、集客と営業の境目を人の感覚だけで決めている時に起こります。
本記事ではMQL・SQLの一般的な意味と、講座・スクールを提供するひとり社長や中小企業で相談へ引き継ぐ条件の作り方を解説します。
本シリーズでいう「ひとり社長や中小企業」は、運営する事業者の規模を示す呼称です。BtoBとBtoCは購入者の目的で分かれ、個人事業主が事業改善のために購入する講座や支援はBtoBとして扱います。
MQL・SQLとは、成約確度を言い当てる言葉ではない
MQLはMarketing Qualified Lead、SQLはSales Qualified Leadの略です。一般には、MQLをマーケティングが営業対応を検討できると認めた見込み客、SQLを営業が潜在顧客として対応を進めると認めた見込み客として使います。HubSpotのライフサイクルステージの説明も、この役割分担で整理しています。
ただし、これは業界を横断して固定された成約予測のラベルではありません。SQLだから契約が近い、MQLだから価値が低い、という意味にすると、担当者は数字を守るために判断を遅らせます。
本記事の設計例では、MQL・SQLを、マーケティングから営業へ「次の対話を始める条件」を渡す共通言語として扱います。どちらの担当者も同じ記録を見て、今は情報提供を続けるか、個別に状況を聴くかを決められる状態が目的です。
ひとり社長や中小企業でMQLとSQLを分ける意味
講座やスクールでは、資料請求した全員がすぐ個別相談を望むわけではありません。発信の悩みを整理したい人、受講条件を比較したい人、すでに相談の予定を考えている人が、同じ登録者一覧に入ります。
ここで登録直後に全員へ電話をすると、集客の成果を営業の圧力に変えてしまいます。一方で、相談したい意思がある人を配信だけに置くと、検討の熱が冷めることもあります。
MQLとSQLを分けると、入口の反応を否定せずに、必要な情報と対応の順番を分けられます。ひとり社長や中小企業では部署を分ける必要はありません。1人が集客と相談を兼任していても、工程と判断条件を分ければ引き継ぎ漏れを防げます。
本記事が提案するMQLの引き継ぎ基準
一般定義とは別に、本記事の設計例では、次の4点が確認できた状態をMQL候補として扱います。
- 連絡許諾がある：案内したメールや連絡方法を受け取る意思が記録されている
- 関心文脈がある：記事、診断、説明会など、何を解決したくて来たかが分かる
- 商品対象と適合する可能性がある：提供対象、課題の種類、支援範囲が大きく外れていない
- 営業対応を検討する根拠がある：具体的な質問、比較検討の意向、相談希望などが確認できる
例えば「発信しているのに相談につながらない」という診断を受け、講座の対象条件に合い、説明会と個別相談の違いを具体的に質問した人はMQL候補です。資料請求と関連メールの希望だけなら、まだ教育対象であり、自動的にMQLへ昇格させません。
登録経路と連絡許諾を先に残す考え方は、リード獲得でリスト・見込み客・問い合わせを分ける方法で解説しています。記録がない連絡先を、反応があったという理由だけでMQLにしないことが大切です。
SQLへ渡す条件は、相談の意思と論点をそろえること
本記事の設計例では、SQLは「営業がMQLの根拠を確認し、個別対応を受け入れる」と判断できる状態です。判断には、MQLの情報に加えて、相談したい論点と、相手が期待する連絡方法・時期を確認します。
確認項目は多くありません。誰が意思決定するか、何に困っているか、いつ頃までに整理したいか、相談で何を持ち帰りたいかが分かれば、初回の対話を設計できます。予算や契約時期が未確定でも、相談の意思と論点があるならSQLとして扱える場合があります。面談日時の確定はSQLの一例であって、必要条件ではありません。
想定例として、講師として活動する個人が「発信は続けているが、自分の講座の相談申込が増えない」と具体的に質問した場合を考えます。営業は資料をもう一度送るのではなく、集客、説明会、相談のどこを見たいかを聴く準備をします。SQLは成約確実の印ではなく、営業が対話の準備を受け入れた印です。
相談で状況を聴き、提案を急がずに課題を整理する流れは、個別相談の成約率を上げる5つのステップも参考になります。
引き継ぎシートは4項目から始める
CRMやMAの製品を先に選ぶ必要はありません。表計算でも、MQLとSQLの判定理由を同じ場所に残せれば運用できます。
| 項目 | MQLで残すこと | SQLで追加すること |
|---|---|---|
| 流入と許諾 | 記事・資料・登録時の連絡希望 | 希望する連絡方法の再確認 |
| 関心文脈 | 読んだテーマ、選んだ診断、対象との適合 | 個別に整理したい論点 |
| 行動 | 具体質問、比較意向、相談希望 | 営業の受入判断、日時選択は必要に応じて |
| 次の担当 | 営業への引き継ぎ確認担当と不足情報 | 相談担当と準備内容 |
判定日は必ず残します。「SQL」とだけ書いても、いつ、何を根拠に変えたかが分からなければ、対応の遅れを改善できません。MQLからSQLに進まないことも失敗ではありません。必要な情報がまだ足りないなら、教育工程へ戻す判断ができます。
MQL・SQLで起きやすい3つの誤解
1つ目は、資料請求だけでSQLにすることです。資料を受け取る目的が比較や自己診断なら、まず役立つ情報を渡す方が自然です。
2つ目は、スコアだけで判定することです。メールを開いた回数は関心の手がかりですが、相手の課題や連絡の期待を代替しません。開封やクリックを、電話してよい根拠に読み替えないようにします。
3つ目は、営業が引き継ぎを受け取った後に最初から聞き直すことです。相手がすでに選んだ資料や困りごとを確認し、足りない点だけを尋ねれば、相談は「売る場」ではなく診断の場になります。
よくある質問
Q1. MQLとSQLは小さな会社でも必要ですか
必要なのは用語ではなく、渡す条件です。集客と相談を同じ人が担う会社でも、「情報提供を続ける段階」と「個別に話を聴く段階」を分ければ、対応の優先順位を説明できます。
Q2. SQLになったらすぐ電話すべきですか
いいえ。登録時または相談時に確認した連絡方法を優先します。メールで相談日時を選んだ人にはメールで準備を案内するなど、相手が期待した方法と目的を守ります。
Q3. MQLからSQLへ進まない人は除外しますか
除外を急ぐ必要はありません。連絡許諾と関心文脈があるなら、判断に役立つ情報を届ける対象です。停止希望や目的との不一致が確認できた時は、記録に基づいて配信対象を見直します。
まとめ
MQL・SQLは、マーケティングと営業が同じ人を違う基準で扱わないための言葉です。本記事の設計例では、MQLを連絡許諾・関心文脈・対象適合・営業対応の根拠がそろった状態、SQLを営業がその根拠を確認し個別対応を受け入れた状態として分けます。
自社の引き継ぎ条件を見直したい場合は、記事右側のLM01「ビジネス構造診断チェックリスト」で、集客・教育・相談のどこに判定の空白があるかを整理してください。