商談化率が低い原因とは？MQLからSQLを経て初回面談までの7つの詰まり

リードは獲得できているのに商談化率が低いとき、「問い合わせの質が低い」「営業の対応が遅い」など、どちらか一方に原因を求めがちです。

しかし、リードが生まれてから初回面談へ進むまでには、顧客としての適合度と観測された意向シグナルを判定する軸に加え、営業へ渡す条件、初回連絡、追客という運用工程があります。

判定軸と運用工程が部門ごとに違えば、マーケティングは良いリードを渡したつもりでも、営業は対応対象ではないと判断します。

反対に、営業が対応したいリードが、マーケティング側の点数では優先外になることもあります。

商談化率が低い原因を探すには、リード数ではなく、マーケティングの判定から営業の判定、初回面談までの引き渡しを確認します。

商談化率を判定軸と運用工程に分ける

商談化率は、リードの質だけでは決まりません。

営業対応の優先度を上げるときは、次の四つを確認します。

1. 自社が支援できる相手である
2. 相手が解決したい課題を持っている
3. 今、担当者と話す理由がある
4. 営業がその文脈を理解して連絡できる

このうち、一つ目は顧客としての適合度です。

二つ目と三つ目は、課題の具体性と観測された意向シグナルです。

四つ目は、マーケティングと営業の接続です。

「リードの質」という一言でまとめると、どこを改善すべきか分かりません。

適合度、意向シグナル、接続を分けて確認します。

商談化率は段階ごとに分母を決める

「商談化率」という一つの数字だけでは、どの移行で止まっているか分かりません。

この記事では、次の三つを分けて確認します。

どの段階を社内で「商談」と呼ぶかによって、商談化率の分母と分子は変わります。

改善前後を比べるときは、段階名だけでなく、分母、分子、判定条件を記録します。

MQLとSQLを自社の言葉で定義する

マーケティングが営業対応に進めると判断したリードをMQL、案件化の可能性があると営業が判断したリードをSQLと呼ぶことがあります。

名称そのものより、どの条件で次の段階へ移すかを部門間でそろえることが必要です。

HubSpotのライフサイクルステージに関する公式説明では、マーケティングが営業対応の準備ができたと判断する段階と、営業が見込み顧客として認める段階を分けています。

この記事では、具体的な案件として管理する段階であるOpportunityを「案件化」と表記します。

しかし、同じ名称を導入しただけでは判断はそろいません。

たとえば、自社で資料ダウンロードをMQLの条件にする場合と、対象業種、役職、相談テーマまで確認してからMQLとする場合では、同じ名称でも対象が変わります。

自社では、次の問いに答えられる状態を作ります。

• どの顧客条件なら営業が対応できるか
• どの行動や相談内容を、意向シグナルとして観測するか
• 情報が不足しているリードを誰が確認するか
• 営業が対応しない場合、どの理由を記録するか
• 今は商談にならないリードを、どの条件で追客へ戻すか

定義は、マーケティングが一方的に決めるものでも、営業が受け取りを断るために使うものでもありません。

両部門が同じ案件候補を見つけるための約束です。

商談化率を下げる7つの原因

1. 適合度と意向シグナルを分けていない

対象業種で資料を読んだ人と、対象外の業種から具体的な相談をした人は、どちらも一つの点数では判断しにくいリードです。

前者は顧客としての適合度が高くても、今すぐ話す理由を確認できていないかもしれません。

後者は強い意向シグナルがあっても、自社の提供範囲に合わない可能性があります。

適合度と意向シグナルを別の軸で持つと、営業へ渡すリード、育成するリード、条件を確認するリードを分けられます。

HubSpotのリードスコアに関する公式説明も、属性による適合度と、閲覧やCTAクリックなどの行動によるエンゲージメントを分ける考え方を示しています。

閲覧やCTAクリックはエンゲージメントを示しますが、それだけで本人の購買意向が確定するわけではありません。

点数を作る場合も、合計点だけを見ず、何によって点数が付いたかと、本人に確認できた情報を分けます。

2. MQLとSQLの定義が部門で一致していない

マーケティングがフォーム送信をMQLと呼び、営業が予算と導入時期を確認できたリードだけをSQL候補と考えているなら、引き渡しの間に大きな差があります。

この差を「営業が追わない」「マーケティングの質が低い」と評価しても、定義は変わりません。

問い合わせ時点で分かること、初回連絡で聞くこと、商談として扱う条件を一枚の表にします。

定義を変えたときは、過去の商談化率と単純比較せず、判定条件が変わったことを記録します。

3. CTAの約束と初回連絡の内容が違う

「原因を確認する」というCTAから相談した人へ、すぐに商品説明や見積もりの話を始めると、期待と会話がずれる可能性があります。

「具体的な支援内容を相談する」というCTAなら、課題の確認だけで終わると、次の判断材料が不足する可能性があります。

CTAで約束した内容を、フォーム項目、通知、初回連絡の冒頭まで引き継ぎます。

問い合わせ者が何を期待して連絡したかが分かれば、営業は会話の出発点を合わせられます。

4. 流入ページと相談文が営業へ渡っていない

営業が会社名、氏名、メールアドレスだけを受け取っても、なぜ問い合わせたかは分かりません。

閲覧した記事やLP、押したCTA、相談文を一緒に渡します。

流入ページは、単なる参照元ではありません。

「問い合わせが増えない」「広告の効果が出ない」「商談にならない」など、相手が自分で選んだ課題の手掛かりです。

営業は、その課題が現在も続いているかを確認してから、必要な質問へ進めます。

5. 初回対応の担当と期限が決まっていない

営業へ通知が届いても、誰が最初に確認するかが決まっていなければ、対応は担当者の予定に左右されます。

すべてのリードへ同じ速さで連絡する必要はありません。

営業対応へ進める条件、情報不足を確認する条件、育成へ戻す条件ごとに、担当と対応期限を決めます。

期限は一般的な正解を借りるのではなく、自社の営業体制と、CTAで伝えた連絡方法に合わせます。

Harvard Business Reviewに掲載されたオンラインリード対応の調査は、初動までの時間と接触可能性の関係を調べています。

ただし、2011年の米国調査であり、特定の対応時間を現在の全企業に当てはめる根拠にはしません。

自動返信には、受付完了だけでなく、次に誰がどの方法で連絡するかを書きます。

6. 商談にならないリードを追客から外している

今すぐ話す理由がないリードを、失注と同じ扱いにすると、検討が進んだときの接点を失いやすくなります。

営業が対応しない理由を、対象外、時期未定、情報収集、担当者不在、課題不一致などに分けます。

対象には合うが時期が早いリードなら、課題に合う記事、チェックリスト、レポート例を届けます。

ただし、一律のメールを送り続けることが育成ではありません。

相手が次に判断するための情報と、再度営業へ渡す条件を決めます。

Salesforceの営業とマーケティングの連携ガイドでも、共通の段階定義と、営業準備が整っていないリードを育成へ戻す流れが示されています。

7. 非商談理由を施策へ戻していない

ここでは、Makemaniで施策と営業接続を確認するときの診断仮説を示します。

マーケティングが商談数だけを受け取り、商談にならなかった理由を受け取らなければ、次の施策でも同じ条件のリードを集め続ける可能性があります。

非商談理由は営業の評価ではなく、広告、記事、LP、CTA、フォームを直す材料です。

対象外が多いなら、ターゲットと除外条件を見直します。

情報収集が多いなら、商談CTAへ誘導する前に比較材料や診断項目を置きます。

相談内容が曖昧なら、記事内で原因の選択肢を示し、フォームに引き継ぎます。

問い合わせ後の全体像は、問い合わせが売上につながらない7つの理由でも確認できます。

この記事では、その中でもリードから商談へ移る判定に範囲を絞っています。

適合度と観測された意向シグナルを二軸で判定する

リードスコアを一つの合計点だけで運用すると、「対象企業だが情報収集中」と「対象外だが相談意向は強い」を同じように扱うことがあります。

二軸に分けると、次の対応を決めやすくなります。

適合度には、業種、企業規模、地域、提供範囲、想定する利用場面などを使います。

意向シグナルには、相談内容の具体性、閲覧した情報、比較行動、希望する次の対応などを使います。

閲覧や比較行動は観測材料であり、現在の購買意向そのものではありません。

本人の希望を確認できていない状態は、低意向と決め付けず「不明」として扱います。

どの条件を使うかは、実際に商談となったリードと、対応できなかったリードの記録から決めます。

業界一般の点数をそのまま当てはめても、自社の提供条件と一致するとは限りません。

自社の判定項目を整理したい場合は、商談化率が低い原因を確認するで、集客から営業接続までを一つの導線として確認できます。

営業へ渡す情報を一つの型にする

リードの引き渡しでは、情報量を増やすだけでなく、営業が最初の会話に使える順番で渡します。

最低限、次の項目をそろえます。

• どの記事、広告、LPから来たか
• どのCTAを選んだか
• 相談文に書かれた課題は何か
• 顧客としての適合条件に何が当てはまるか
• 観測された意向シグナルと、本人に確認できた希望は何か
• まだ分からない条件は何か
• 次の対応を誰がいつまでに行うか

営業担当者は、この情報を読んで相談内容を確認し、現在の状況、困っている理由、社内での検討状況を聞きます。

定型文を送る場合も、相手が選んだ課題を一文目へ反映します。

問い合わせが十分に増えていない段階では、問い合わせが増えない原因を先に確認してください。

問い合わせ前と問い合わせ後では、直す場所が異なります。

商談化率を改善する順番

商談化率を上げるために、営業研修やリード数の追加から始めても、判定と接続の問題が残ることがあります。

Makemaniでは、次の順序を診断仮説の出発点として確認します。

1. MQLとSQLの条件を、マーケティングと営業で書き出す
2. 適合度と観測された意向シグナルを別の項目として持つ
3. CTAごとに、問い合わせ後の会話を決める
4. 流入ページ、相談文、判定理由を営業へ渡す
5. 初回対応の担当と期限を決める
6. 非商談理由を選択できる形で記録する
7. 育成へ戻す条件と、再び営業へ渡す条件を決める

先に定義をそろえるのは、改善前後で同じ商談を数えるためです。

判定条件が曖昧なまま商談化率だけを目標にすると、対応しやすいリードだけを商談として数えるなど、数字の意味が変わることがあります。

定義、引き渡し、初回対応を直してから、CTAや集客対象を調整します。

商談数だけでなく段階ごとの動きを見る

結果としての商談数に加え、次の段階を確認します。

下の順序は一例であり、SQL判定、初回面談、案件化の順序は自社の営業プロセスに合わせて定義します。

段階ごとの記録があれば、「リードの質が悪い」という感想を、対象条件、意向シグナル、引き渡し、初回面談のどこに問題があるかへ分解できます。

診断後にどのような整理を行うか確認したい場合は、Standard診断のレポート内容も参考になります。

参考資料

• HubSpotのライフサイクルステージ
• HubSpotのリードスコア
• Salesforceの営業とマーケティングの連携ガイド
• Harvard Business Reviewのオンラインリード対応調査

リードと商談に関するよくある質問

MQLは点数だけで決めてもよいですか

点数は優先順位をそろえる補助として使えます。

ただし、合計点だけでは、適合度と観測された意向シグナルのどちらで高くなったか分かりません。

営業へ渡す前に、点数の内訳、相談内容、対象外条件を確認します。

資料請求リードへ営業から連絡してもよいですか

資料請求時に伝えた内容と、本人が選んだ連絡方法に沿って対応します。

資料を受け取る行動だけで、個別相談を希望しているとは限りません。

相談意向が分からない場合は、資料の利用目的や追加情報の希望を確認し、商談を前提にしない連絡から始めます。

商談にならない理由は誰が記録しますか

実際に連絡した担当者が、選択肢と短い補足を記録できる形にします。

マーケティングはその理由を定期的に集計し、ターゲット、記事、LP、CTA、フォームへ戻します。

Salesforceの営業とマーケティングの連携ガイドも、Lead、MQL、SQL、Opportunityなど、同ガイドで用いる段階の共通定義を作ることを出発点としています。

部門間の判定差を次の改善へ戻す

商談化率を改善するには、マーケティングと営業が同じ段階名を使うだけでなく、判定理由を互いに確認できる状態を作ります。

適合度と意向シグナルの混同、MQLとSQLの定義差、CTAと初回連絡の不一致、流入文脈の欠落、対応期限の未設定、追客の不在、非商談理由の未回収は、商談化を止める要因になり得ます。

マーケティングが集めたリードを営業へ渡すだけでは、接続は完成しません。

営業が受け取った情報を会話に使い、商談にならなかった理由をマーケティングへ戻して、次の集客と育成を直すところまでを一つの流れにします。

マーケティング診断でMQLから初回面談までの導線を確認すると、部門間の判定差と、次に直すべき接続点を整理できます。

担当者と確認内容を整理したい場合は、調査について相談するへ進んでください。