この記事でわかること
- 「リードの質が悪い」で止まる会社に共通する3つの欠落
- MQL／SQLの定義を、自社の条件に落とし込む手順
- 初回接触時間・打ち切り基準など対応ルール（SLA）の決め方
- 却下理由を6分類で戻すフィードバックループの作り方
- 月1回の定例で見るべき数字とチェックリスト
「リードの質が悪い」で止まる会話
問い合わせは増えているのに受注が増えない。この状態の会社で、社内の会話はたいてい次のようになります。
マーケ側：「今月は問い合わせが40件。目標は達成しました」
営業側：「でも、まともに話せたのは数件です。質が悪い」
マーケ側：「では、どういうリードなら良いのか教えてください」
営業側：「……買う気のある人、ですかね」
この会話が繰り返される会社には、共通して3つの「決まっていないもの」があります。逆に言えば、この3つを決めるだけで議論は前に進みます。
| 決まっていないもの | 起きること | 決めると変わること |
|---|---|---|
| リードの定義 | 「質が良い／悪い」が主観の応酬になる | 何を渡すかの基準が共有され、施策の方向が定まる |
| 対応のルール | 渡したリードが放置され、機会損失が見えない | いつまでに誰が何をするかが決まり、対応漏れが可視化される |
| 返す仕組み | 営業側の判断がマーケ側に届かず、改善が起きない | 却下理由が蓄積し、次の施策の材料になる |
「質」を持ち出す前に確認したいこと
リードの質を問題にする前に、次の3点を確認してください。ここが崩れていると、定義を作っても機能しません。
- 問い合わせから初回接触までに何時間かかっているか——数日空いていれば、質の問題ではなく速度の問題です
- そもそも全件に接触できているか——「対応した件数」ではなく「渡した件数のうち何件に触ったか」で見ます
- 何をもって「商談」と呼んでいるか——人によって定義が違えば、商談化率は比較できません
リード定義（MQL／SQL）を先に合意する
MQLはマーケティング側が「営業に渡してよい」と判断したリード、SQLは営業側が「商談として進められる」と認めたリードを指します。用語自体は一般的なものですが、重要なのは英語の定義ではなく、自社の基準を具体的な条件として書き出すことです。
ステップ1：受注した顧客の共通点を洗い出す
直近1年で受注した顧客のリストを見て、業種・規模・役職・課題・きっかけとなった行動を並べます。感覚ではなく実データから始めるのが原則です。件数が少なければ、失注した案件も含めて比較すると輪郭が出ます。
ステップ2：条件を「属性」と「行動」に分けて書く
| 種類 | 条件の例 | 確認方法 |
|---|---|---|
| 属性条件 | 対象業種に該当する／従業員規模が一定以上／商圏内にある／決裁に関われる役職 | フォームの入力項目、企業情報の確認 |
| 行動条件 | 料金ページを閲覧している／資料をダウンロードした／再訪している／問い合わせ本文に具体的な課題が書かれている | GA4・MAツール・フォームの自由記述欄 |
| 除外条件 | 営業目的の問い合わせ／採用に関する連絡／対応エリア外／個人利用 | フォームの選択肢と本文 |
ステップ3：営業と一緒に、過去のリードで試す
作った基準を、過去3か月分の問い合わせに当てはめて分類してみます。ここで営業側の実感とズレるなら、基準のほうを直します。この作業を一緒にやることに意味があり、机上で作った定義を後から渡しても運用されません。
最初から精密にしないことがコツです。条件を10個並べた定義は、現場で判定できません。属性2つ・行動1つ程度から始め、3か月ごとに見直すほうが定着します。判定に迷う時間が長い定義は、それだけで失敗しています。
ステップ4：「まだ渡さない」リードの置き場を作る
定義を決めると、必ず「条件を満たさないリード」が出ます。これを捨てるのではなく、資料送付やメール配信の対象として残しておく置き場が必要です。ここがないと、営業側が渡されたくないリードをマーケ側が抱え込めず、結局すべて流すことになります。
対応ルール（SLA）を数字で決める
SLAは、部門間で交わす「これだけはやる」という約束です。形式的な合意書ではなく、数字と期限の入った短いルールにします。
初回接触までの時間を決める
「問い合わせから◯時間以内に一次連絡を入れる」という約束です。営業時間の考慮、担当が不在のときの代替、複数回の架電ルールまで含めて決めます。時間を決めずに「なるべく早く」で運用している限り、対応漏れは必ず出ます。
まず現状の平均時間を測ってから、実行可能なラインを設定する接触の回数と打ち切りを決める
1回架電して不在なら終わり、という運用は機会損失そのものです。「何回・どの手段で・何日かけて接触し、その後どう扱うか」まで決めます。打ち切ったリードをナーチャリングに戻す先も、同時に決めておきます。
打ち切り基準がないと、担当者ごとに扱いがバラバラになるマーケ側が約束する数と質
SLAは営業側だけの約束ではありません。マーケ側も「月に何件のMQLを、どの条件を満たした状態で渡すか」を約束します。件数だけを約束すると条件の緩いリードが増えるため、必ず条件とセットにします。
件数と条件を同時に約束することで、数合わせを防ぐ記録の入力ルール
接触日時・結果・却下理由をどこに、いつまでに、どの粒度で入れるか。ここが決まっていないと、後述するフィードバックが成立しません。入力項目は選択式を中心にし、自由記述は最小限にするのが定着のコツです。
項目が多いほど入力されなくなり、データは使えなくなるSLAは「守れているか」を測って初めて意味を持ちます。達成率を毎月見る場所を決めてください。守れていない場合、原因は担当者の怠慢ではなく、件数に対して人員が足りない・通知が届いていない・そもそも時間設定が非現実的、のいずれかであることがほとんどです。ルールを厳しくするのではなく、守れる設計に直すのが正解です。
却下理由を戻す、フィードバックループ
連携の仕組みで最も効くのに、最も抜けやすいのがここです。営業が「商談にならなかった」と判断した理由を、選択式でマーケ側に戻す。これだけで、次に打つ手が具体的になります。
却下理由の分類例
| 却下理由 | 多いときに疑うこと | 打ち手の方向 |
|---|---|---|
| 検討時期が先 | 集客が悪いのではなく、渡すタイミングが早い | ナーチャリング（メール・資料）を挟み、時期が来てから渡す |
| 予算が合わない | 訴求か流入キーワードのターゲットがずれている | 広告のターゲティング見直し、LPでの価格帯の示し方を調整 |
| 対象外（エリア・業種・規模） | フォームで弾けていない、除外設定が緩い | フォーム項目の追加、広告の地域・除外設定の見直し |
| 連絡がつかない | 質ではなく、対応速度か連絡手段の問題 | SLAの初回接触時間を短縮、連絡希望時間帯をフォームで取得 |
| 期待していた内容と違った | LPや広告の表現が実際のサービスとずれている | 訴求の修正、提供範囲を明示、料金の考え方をLPに追記 |
| 他社に決めた | 競合との比較で負けている | 比較検討コンテンツ、実績・事例の拡充、初回提案の内容を見直す |
「リードの質が悪い」という一言を、この6分類に置き換えるだけで会話が変わります。「検討時期が先」が多いのと「対象外」が多いのとでは、打つ手はまったく違います。前者は集客を絞る必要がなく、後者は絞る必要がある。分類がないまま「質を上げてほしい」と言われると、マーケ側は件数を減らす方向にしか動けません。
戻し方の設計
- 選択式にする——自由記述だけにすると集計できず、入力もされません
- 入力のタイミングを決める——「商談化しないと判断した時点で必ず選ぶ」など、業務の流れに組み込みます
- 月次で分布を見る——件数ではなく比率の変化を追い、施策の前後で動いたかを確認します
- 受注した案件の経路も戻す——却下理由だけでなく、受注に至ったリードがどこから来たかを共有します
定例の設計と、そこで見る数字
仕組みを作っても、見る場がなければ運用されません。月1回、営業とマーケが同じ数字を前に話す場を設けます。長い会議は不要で、30分あれば足ります。
定例で見る数字
- 問い合わせ件数 → MQL件数 → 接触件数 → 商談件数 → 受注件数の推移（各段階の通過率も併記）
- SLAの達成率（初回接触の時間、接触率）
- 却下理由の分布（前月比で増えた理由は何か）
- 受注した案件の流入経路と、初回接触までの日数
定例が「実績報告会」になると機能しません。見るべきは達成／未達ではなく、どの段階の通過率が落ちたか、そして次の1か月で何を変えるかです。数字を出す側と使う側が分かれていると報告会になりやすいので、通過率が落ちた段階について両部門から仮説を出す進め方にしてください。
チェックリスト
営業・マーケ連携チェックリスト
【定義】
- 営業に渡す基準（MQL）が、属性・行動の条件として書き出されている
- 「商談」の定義が両部門で同じである
- 基準を満たさないリードの置き場が決まっている
- 定義を過去のリードで検証し、営業の実感と突き合わせた
【対応ルール】
- 初回接触までの時間が数字で決まっている
- 接触の回数・手段・打ち切り基準が決まっている
- マーケ側が渡す件数と条件を約束している
- SLAの達成率を毎月確認する場所がある
【フィードバック】
- 却下理由が選択式で記録されている
- 却下理由の分布を月次で確認している
- 受注案件の流入経路が共有されている
- 月1回、両部門が同じ数字を見る場がある
LnXの見解
「リードの質が悪い」という言葉は、ほとんどの場合「基準を決めていない」という意味です。私たちが入るときにまずやるのは、新しい施策の提案ではなく、直近の問い合わせを営業の方と一緒に1件ずつ分類する作業です。地味ですが、ここで「これは渡してほしい」「これは要らない」が具体例で共有されると、それまで平行線だった議論が一気に進みます。
もうひとつ現場でよく見るのが、対応速度の問題が質の問題にすり替わっているケースです。問い合わせから連絡までに2日空いていれば、どんなに条件の良いリードでも商談にはなりません。集客を変える前に、渡したあとの動きを測る。これだけで受注が動くことは珍しくありませんし、費用もかかりません。
この領域は、施策の実行より部門をまたいだ基準づくりと合意形成が中心になります。社内の人だけで進めると、どうしても「どちらが悪いか」の話になりやすい。だからこそ、外部の立場で数字を並べ、決めるべきことを決めていく役回りが機能します。LnXのマーケティング顧問制度では、代表が直接入り、定義とルールの設計、定例での数字の見方、そこから逆算した施策の優先順位づけまでを継続してご一緒します。集客の打ち手を増やす前に、いま獲れているものを取りこぼしていないかを見る。順番としては、こちらが先です。
よくある質問
Q MQLやSQLといった用語を使わないと始められませんか？
必要ありません。大事なのは用語ではなく、「営業に渡す基準」と「商談として扱う基準」が両部門で一致していることです。社内では「渡してよい問い合わせ」「商談」といった言葉のままで構いません。用語を先に導入すると、定義の議論ではなくツールや呼び方の議論になりがちです。
Q 営業が2〜3人の小さな会社でも、SLAのようなルールは必要ですか？
むしろ小規模なほど効果が出やすい部分です。人数が少ないと担当者が営業もマーケも兼ねることが多く、その分「後で対応しよう」が積み上がります。初回接触までの時間と、接触の回数・打ち切り基準を決めておくだけでも、取りこぼしは目に見えて減ります。書面である必要はなく、共有ドキュメント1枚で十分です。
Q 却下理由の入力を営業が嫌がります。どうすればよいですか？
入力項目が多すぎるか、入力した結果が何にも反映されていないかのどちらかであることがほとんどです。選択肢は6つ程度に絞り、自由記述は任意にしてください。そのうえで、集計した分布を定例で見せ、「この理由が多かったのでLPの表現を変えました」と結果を返すことです。自分の入力が施策に反映されると分かれば、入力は続きます。
Q リードの定義を厳しくすると、件数が減って目標に届かなくなりませんか？
マーケ側の目標を「問い合わせ件数」に置いたままだと、その懸念は当たります。定義を導入するタイミングで、マーケ側の評価指標も商談数や受注への寄与に寄せるのが本来の形です。同時に、基準を満たさなかったリードを捨てるのではなく、時期が来たら渡せるよう残しておく仕組みを用意してください。
Q ツール（MA・CRM）を入れないと、この仕組みは回りませんか？
最初は不要です。月間の問い合わせが数十件までなら、スプレッドシート1枚で十分に運用できます。むしろツールを先に入れると、定義が決まっていないまま項目だけが増え、入力されずに終わることが多いです。運用が回り、手作業が明らかに追いつかなくなった段階で検討するのが順番として無理がありません。