商談化率を上げる方法｜マーケと営業のSLA設計

商談化率とは、獲得したリードのうち実際に商談へ進んだ割合を示す指標であり、リード獲得KPIの先にある成果を可視化するものです。
リード数が足りているのに案件化しない現場では、原因は営業やマーケティングの力量差ではなく、両部門が持つ「良いリード」の定義のズレにあります。
展示会で集めたリードの約80%が一度もフォローされず放置される実態も、その断絶をよく表しています。
だからこそ、MQLとSQLの合意を土台にSLAで引き渡し条件を言語化し、責任の押し付け合いを止めることが先になります。

リードは獲れているのに案件化しない理由

商談化率は、獲得したリードのうち商談（案件）に進んだ割合を示す指標です。
リード獲得数だけを追っていると見えない「その先」の変換効率を可視化でき、ここが低いままでは、いくら母数を増やしても売上にはつながりません。
要するに、マーケ投資がファネルの途中で目減りしている状態です。

現場では、毎月のリード数レポートがきれいに伸びているのに、営業会議では「マーケのリードは温度が低い」という不満が定例化していることがあります。
数字だけを見ると前進しているのに、案件化の実感が伴わない。
ここで起きているのは量の問題ではなく、定義の問題です。
まずこの前提をそろえない限り、改善策はいつまでも噛み合いません。

商談化率とは何を測る指標か

商談化率は、リード獲得KPIの先にある成果を測る指標です。
インバウンド起点では20〜30%、アウトバウンド起点では数%が目安になり、インサイドセールス全体では15%以上、SDRで10〜20%、BDRで3〜10%が目標水準とされます。
MQLからSQLへの転換率も20〜30%が標準で、改善はまず自社の数値を源泉別・体制別に分解し、どこで落ちているかを見極めるところから始まります。

ここで押さえるべきは、商談化率が低いからといって、すぐにリード母数を増やす発想に飛びつかないことです。
流入源や役割が違えば基準も変わるため、同じ「商談化率が低い」という現象でも、ボトルネックはまったく別にあります。
インバウンドで落ちているのか、SDRの初動で失っているのか、MQLの定義が広すぎるのか。
切り分けて初めて、打ち手が見えてきます。

「リード不足」ではなく「定義のズレ」が真因

リードは十分に獲れているのに案件化しない最大の原因は、量不足ではなく、マーケが「渡す価値がある」と考える基準と、営業が「今すぐ会いたい」と考える基準のズレにあります。
同じ「良いリード」という言葉を使っていても、両部門が見ている条件はほとんど重なっていないことが多いです。
だからこそ、数字が増えても会議は静かになりません。

このズレは、現場でかなり露骨に表れます。
リード数のレポートは順調なのに、営業側では「温度が低い」「今は追えない」という反応が続く。
実際に両部門を同じ会議室に集めて「良いリードとは何か」を書き出してもらうと、マーケは属性や行動を重視し、営業は導入時期や課題の明確さを重視している、というように回答がほぼ噛み合いません。
その場で初めて、問題はリードの質そのものではなく、定義の不在だったと気づくわけです。

責任の押し付け合いを終わらせるSLAという発想

この断絶が放置されると、マーケは「せっかく渡したのに営業が動かない」、営業は「使えないリードばかり渡してくる」と互いを非難し合うようになります。
展示会で獲得したリードの約80%が一度もフォローされず放置されるのは、その分断が行動にまで落ちた典型です。
原因を人のやる気に求めるより、先に部門間の接続条件を整えるべきです。

そこで共通言語になるのがSLAです。
どんな状態のリードを、いつ、どんな情報を添えて渡すのか。
営業はいつまでにどう反応するのか。
双方が文書で約束すれば、責任の押し付け合いは構造的に減らせます。
MQLとSQLの間にSALを挟み、過去6ヶ月の受注・失注リードを両部門で振り返って定義を詰めると、ようやく「何を渡せば商談になるか」が同じ言葉で話せるようになります。
SLAは、そのための土台です。

商談化率の計算式と業界別ベンチマーク

商談化率は、商談数を対象リード数で割って100を掛ければ求められます。
式そのものは単純ですが、分母をリード総数に置くのか、MQLに絞るのかで数字の意味はまったく変わるため、社内で定義をそろえないとベンチマークと比較しても判断を誤ります。
現場で改善議論が噛み合わない会社の多くは、同じ「商談化率」という言葉を別の母集団で使っているだけです。
まずは数値の見え方ではなく、比較の前提を固定しましょう。

正しい計算式と分母の選び方

商談化率の基本式は『商談数 ÷ 対象リード数 × 100』です。
ここでつまずきやすいのが分母で、リード総数を置けば全体の歩留まりが見えますが、MQLを置けばマーケティングが選別した後の精度が見えます。
両者は同じ数字ではありません。
たとえば、営業会議では「商談化率が低い」と言いながら、片方は全リード、もう片方はMQLだけを見ていることがあり、これでは施策の是非を論じても結論がずれます。
実務では、どの母集団を対象にした数値かを指標名に含めるくらいの運用がちょうどよいでしょう。

分母を統一する意味は、単に集計の都合をそろえることではありません。
受注に近いリードだけを母集団にすれば数字は上がりやすく、接点を持った全件を母集団にすれば厳しめに出ます。
だからこそ、社内の報告値が「良いのか悪いのか」を判断する前に、その数字が何を表すのかを確認する必要があります。
改善の打ち手も変わります。
MQL基準で低いなら選別精度の問題、全リード基準で低いならリード投入後の運用や初回接触の問題が疑われます。
数式より先に、比較軸を定義することが先決です。

インバウンドとアウトバウンドで桁が違う

商談化率は、リード源によって平均が桁違いになります。
問い合わせや資料ダウンロードのようなインバウンド起点は20〜30%が一般的な目安ですが、テレアポや展示会名刺などのアウトバウンド起点は数%にとどまるのが普通です。
この差は、最初から温度感が違うからです。
インバウンドは自社に関心を持って流入してきた層であり、アウトバウンドはまだ課題認識が浅い層をこちらから開拓する形になります。
両者を混ぜた平均値だけを見て「平均並みだから問題ない」と判断すると、実態を見誤ります。

実際、全体の商談化率だけを見て安心していた企業で、源泉別に分けた瞬間にインバウンドは優秀なのにアウトバウンドが足を引っ張っていると判明したことがあります。
そこで初めて、打ち手が明確になりました。
受け皿そのものは機能しているのに、別の入口で失速しているなら、必要なのは同じ施策の強化ではなく、源泉ごとの設計変更です。
こうした切り分けは、ファネルのどこが壊れているかを見つける近道になります。
ベンチマークも、インバウンドとアウトバウンドを分けて並べてこそ意味があります。

SDR/BDR別の目標水準を分けて設定する

インサイドセールスの商談化率は、体制ごとに目標水準を分けて考えるべきです。
顕在層に対応するSDRは10〜20%、潜在層を開拓するBDRは3〜10%が目安で、全体としては15%以上を一つの目標水準に置くと運用しやすくなります。
ここを一括りにすると、難易度の違う役割を同じ物差しで測ることになり、現場評価が不公平になります。
SDRは取りこぼしを減らす役割、BDRはまだ熱量の低い層を掘り起こす役割です。
目標は同じである必要はありません。

この切り分けが効くのは、改善の焦点がはっきりするからです。
SDRで低いなら、レスポンスの速さ、引き渡し条件、初回対応の質が見直し対象になります。
BDRで低いなら、リスト精度、訴求設計、接触回数の設計が論点です。
商談化率は単なる結果指標ではなく、リード獲得の先で何が起きているかを映す診断値です。
源泉別・体制別に分解してベンチマークと並べれば、どの工程で落ちているかが見えます。
改善はその診断から始めるのが、いちばんおすすめです。

MQL・SQLの定義を両部門で合意する

MQLとSQLの定義が曖昧なままだと、SLAを結んでも運用はすぐ崩れます。
まず両部門で「どの条件を満たしたら次の段階へ進めるのか」を揃え、受け渡しのたびに判断基準がぶれない状態を作る必要があります。
特にMQLは属性条件と行動条件を掛け合わせ、SQLはニーズの顕在化と導入時期の見極めで定義するのが軸になります。

MQLは属性条件と行動条件の掛け算で定義する

MQLは、マーケが営業に渡す価値があると判断したリードですが、ここで大切なのは「見込みがありそう」という感覚では切らないことです。
業種・企業規模・役職といった属性条件に加え、資料ダウンロードや複数回訪問といった行動条件を両方満たしたものだけをMQLにすると、営業が追うべき対象が明確になります。
受注に至ったリードの行動ログを遡って並べると、特定の導入事例ページを2回以上閲覧しているという共通項が浮かび、それを行動スコアの中心条件に据えたことでMQL精度が上がった、という場面は珍しくありません。
現場ではこうした具体的な閲覧履歴が、抽象的な関心度よりもずっと再現性の高い判断材料になります。

SQLとSAL（営業が受領を承認したリード）の違い

SQLは、営業が確度が高いと認めたリードであり、ニーズが顕在化し導入時期が見えている状態を指します。
MQLからSQLへの転換率は20〜30%が業界標準の目安で、ここが極端に低ければMQLの基準が甘い、高すぎれば厳しすぎる可能性を示すバロメーターになります。
さらにMQLとSQLの間にSAL（営業が受領を承認したリード）を挟むと、引き渡しの受け取り確認が可視化され、放置を防げます。
誰が、何を基準に、どの段階へ昇格させるのかを一つずつ言語化しておくほど、後段のSLAは実務に耐える形になります。

過去の受注/失注から逆算する合同ワークショップ

定義は会議室の議論だけで決めるより、データから逆算したほうがぶれません。
過去6ヶ月の受注案件と失注案件を両部門で振り返り、商談化したリードに共通する属性・行動を抽出して定義へ落とし込むと、営業が『欲しい』と言うリード像と、実際に受注したリード像の食い違いも見えてきます。
感覚で握っていた基準をデータで置き直す作業は地味ですが、納得感が違います。
合同ワークショップでは、どの条件が本当に再現性を持つのかを確認しながら、MQL、SAL、SQLの境界を両部門で同じ言葉にしていきましょう。

SLAに盛り込む5つの合意項目

SLAは、リードを「誰が、いつ、どの状態で、どこまで責任を持って渡すか」を決めるルールブックです。
引き渡し基準、付帯情報、初回対応期限、フィードバックの内容と期限、双方の数値目標がそろって初めて、マーケと営業の間でリードが滞留しにくくなります。
現場ではここが曖昧だと、優先順位の解釈が部門ごとにずれ、せっかく取れたリードが商談機会に変わりません。

いつ・どんな状態のリードを・どんな情報を添えて渡すか

まず決めるべきは、MQL/SQLの閾値です。
スコア何点以上で渡すのか、どの行動を取ったらSQLとみなすのかを先に固定しておくと、営業は「なぜこのリードが今渡されたのか」を迷わず理解できます。
さらに、どの資料を見たか、問い合わせ内容、想定ニーズまで付帯情報として添えると、最初の会話が相手に寄りやすくなります。
営業の初回接触で「このリードは話が早い」という反応が出やすくなるのは、単に情報量が増えるからではなく、会話の起点がそろうからです。

付帯情報をSLAに加える前は、条件を満たしたはずのリードでも、営業が一から関係構築をやり直す場面が目立ちました。
誰が何に反応したのかが見えないまま渡されると、初回接触での仮説が立てにくく、結果として提案の精度も下がります。
ここで押さえるべきは、リードを「渡す」こと自体ではなく、次の打ち手を組み立てられる状態で渡すことです。
SLAは量ではなく再現性を担保する仕組みだと考えると、定義の厳密さがなぜ必要かが見えてきます。

営業の初回対応期限を数値で約束する

営業側のSLAには、『渡されたSQLは○時間以内に初回接触する』という期限を必ず数値で入れます。
ここを曖昧にすると、優先度の低いリードが暗黙のうちに後回しにされ、気づけば1週間放置されていた、という事態が起きやすくなります。
現場ではこうなりがちですが、時間基準がない運用は、忙しさの波に引きずられるだけです。
速度を約束させることで、マーケが基準を守って渡す責任と、営業が速く動く責任がつながります。

この期限設定で見落とされやすいのは、速さが単独のKPIではない点です。
初回接触までの時間が短くても、引き渡し基準や付帯情報が弱ければ商談化率は伸びません。
だからこそ、営業の数値目標だけを切り出すのではなく、マーケ側のMQL/SQLの閾値とセットで管理する必要があります。
要するに、渡す側と受け取る側の両方に数値目標を置いて、同じルールの上で動かすことが重要なのです。

マーケへ返すフィードバックの内容と期限を決める

見落とされがちなのが、営業からマーケへの逆方向の約束です。
『受け取ったリードの評価（有効/無効と理由）を○日以内に返す』と定義しておくと、マーケはどの条件が効いているのかを学習できます。
評価の中身も、有効・無効だけで終わらせず、失注につながる論点やニーズのズレまで含めておくと、次の判定精度が上がります。
フィードバックは単なる報告ではなく、次回の引き渡し基準を更新するための材料です。

数値目標も、ここで片側だけに寄せてはいけません。
営業は初回接触の速度、マーケは適切な基準での引き渡し件数と質、双方は評価の返却率や期限遵守率を持つことで、SLAが運用として回り始めます。
SLAの本質は、部門ごとの善意ではなく、守るべき数字を相互に約束することにあります。
これが整うと、リードは単なる名簿ではなく、改善が回る資産になるでしょう。

リード対応速度を5分以内にする仕組み

リード対応速度は、SLAの中でも最初に見直すべきレバーです。
初回対応までの業界平均は約47時間と長く、その間に検討熱は冷めてしまいます。
逆に、5分以内に返せば商談化率は約9倍まで跳ね上がるため、獲得数を追う前に取りこぼしを止めるほうが先です。

なぜ平均47時間が5分で9倍に変わるのか

47時間という遅さの問題は、単に待ち時間が長いことではありません。
問い合わせを送った瞬間が最も関心の高いタイミングであり、ここを逃すと比較検討の温度は一気に下がります。
だからこそ、5分以内の対応は単なる“速さ”ではなく、獲得した関心を商談に変えるための最重要条件になります。
推奨水準が3分以内とされるのも、初動の差がそのまま成果差になるからです。

実際、問い合わせフォームの送信をトリガーにインサイドセールスへ即時通知する設定を入れた途端、翌営業日対応だったリードが当日中に商談化し始めたことがあります。
ここで効いたのは、丁寧な追客トークではなく、熱量が残っているうちに接触できたことでした。
スピードは才能ではなく設計で決まります。

即時通知と自動アサインで属人化をなくす

対応速度を仕組み化する要点は、MAからの即時通知、担当者の自動アサイン、対応SLAの可視化の3点です。
誰が見るか、誰が動くか、どれだけ止まっているかを曖昧にすると、現場はすぐに「確認してから返す」運用へ戻ります。
つまり遅さの正体は、個人の怠慢ではなく、判断が毎回発生する構造にあります。

展示会で集めた数百枚の名刺を会期後にまとめて入力していた運用を、その場でリード化し、翌朝には担当アサインまで終わる流れに変えたときも同じでした。
入力と配分が自動化されると、担当者は「見つける」作業から解放され、「返す」ことだけに集中できます。
おすすめです。
営業組織では、この分業ができるだけで初動のばらつきが小さくなるでしょう。

「あとで対応」を物理的に発生させない運用

展示会で獲得したリードの約80%が放置される最大の理由は、「あとでまとめて対応しよう」という運用そのものにあります。
あとでやる前提の仕組みは、必ず積み残しを生みます。
だから運用を変えるなら、気合いではなく、発生した瞬間に担当が決まり通知が飛ぶ流れへ切り替えるべきです。

具体的には、リード発生時点で担当を自動確定し、未対応リードと経過時間をダッシュボードで全員に見せる状態を作ります。
こうすると、放置は意思ではなく構造として起こりにくくなります。
現場で「あとで」が出る余地を消すのがコツです。
営業現場では、見えない遅延ほど後から大きな機会損失になるものです。
おすすめです。
仕組みで止めれば、商談化の入口は安定していきます。

スコアリングとナーチャリングで渡す前を整える

スコアリングとナーチャリングは、渡す前のリードを整えてMQLの精度を上げるための仕組みです。
速度を上げても中身の薄いリードをそのまま営業へ流せば、商談化率にはすぐ上限が来ます。
だからこそ、全体の約16%しかいないホットリードを見極め、残り約84%を育成対象として設計する発想が必要になります。

ホットリードは全体の16%という前提で設計する

今すぐ商談に進むホットリードは、リード全体の約16%に過ぎません。
この数字を前提に置くと、営業へ渡す件数を増やすことだけでは成果が伸びない理由が見えてきます。
残り約84%を「質が悪い」と切り捨てると、まだ温度が上がりきっていないだけの見込み客まで失うことになるためです。

現場では、すべてのリードを一律に営業へ回していた時期よりも、スコア閾値で自動抽出する運用に切り替えた後のほうが、営業の対応工数が減り、渡した後の商談化率も上がりました。
ここで効いているのは、数を追う発想から、受注に近い順へ整える発想への転換です。
営業が追うべき相手を絞るほど、初回接触の質も提案の深さも揃いやすくなります。

属性×行動のスコアリングでMQLを自動判定する

スコアリングは、属性スコアと行動スコアを加点し、一定の閾値を超えたリードをMQLとして自動抽出する仕組みです。
属性スコアは業種・規模・役職など、自社のターゲットにどれだけ近いかを見ます。
行動スコアは資料DL、価格ページ閲覧、セミナー参加など、検討の進み具合を測るために使います。

この2軸を分ける理由は明快です。
属性が合っていても、まだ情報収集の初期段階なら商談化は先になりますし、逆に行動量が多くても自社のターゲット外なら失注しやすいからです。
両方が揃った瞬間にMQLとして拾うことで、営業は「今、話す理由がある相手」だけに集中できます。
多くの企業でスコア設計がうまくいくかどうかは、この軸を混ぜずに運用できるかで決まります。

ナーチャリングで残り84%を引き上げる

ナーチャリングは、閾値に届かないリードを眠らせないための継続接触です。
メールや事例コンテンツで関心を保ちながら、行動スコアが上がった瞬間をMAで検知し、営業へ即時共有します。
渡すタイミングを逃さないことが、育成を商談化に直結させるいちばんの鍵でしょう。

半年間スコアが上がらずに眠っていたリードが、事例メールへの反応をきっかけに再浮上し、そのまま商談化した場面がありました。
こうした動きは珍しくありません。
反応が止まって見える相手でも、情報の出し方が変われば急に温度が上がることがあるためです。
だからこそ、ナーチャリングは「いつか買うかもしれない層」を放置しないための保険ではなく、商談の発生源を増やすための実装だと捉えましょう。

フィードバックループで商談化率を伸ばし続ける

SLAは作って終わりではなく、回し続けて初めて効きます。
営業が持つ失注理由や商談化したリードの傾向をマーケへ戻し、MQL定義やコンテンツ施策に反映していく双方向のフィードバックループがあって、はじめて商談化率は底上げされるのです。
現場で起きがちなのは、営業とマーケが別々の正しさを持ったまま、SLAだけが紙の上に残る状態でしょう。

失注理由を施策改善に還流する双方向ループ

営業の失注理由は、単なる敗因の記録ではありません。
どの業種で決裁が長引くのか、どの訴求が初回接触では刺さっても商談化前に離脱するのかを示す、最前線の観測データです。
毎月この情報をマーケへ戻す運用を組むと、MQL定義を見直すべき領域と、ナーチャリングで補うべき領域が切り分けやすくなります。
実際に失注理由の共有を毎月続けたところ、特定業種では決裁プロセスが長いと分かり、その業種向けにナーチャリング期間を延ばす設計へ変えたことで商談化率が改善しました。
ここで効いているのは、営業の感覚をマーケ施策に翻訳する工程です。

この還流が弱い組織では、失注理由が「営業の都合」として扱われやすく、施策修正につながりません。
逆に、商談化したリードの傾向まで含めて共有されると、どの属性を厚く育てるべきか、どの情報を先に渡すべきかが見えてきます。
SLAは、その判断を繰り返し更新するための約束事になります。

共通ダッシュボードと定例会で温度差を消す

共通ダッシュボードは、リード数・MQL数・SQL数・商談化率・受注を一気通貫で同じ画面に並べる仕組みです。
これがないまま会議をすると、マーケは流入量を見て話し、営業は商談化率だけを見て話し、議論が責任論に寄りやすくなります。
かつて別々のレポートを見ていた頃は、会議のたびに「どちらが悪いか」に話が寄っていました。
共通ダッシュボードに統一した途端、会話は「どこを直すか」に変わり、改善点が具体化したのです。

ただし、画面をそろえるだけでは足りません。
月次の定例会で数字の解釈と次の打ち手を合意する場を持ち、商談化率の変動を源泉別・施策別に分解して見ていく必要があります。
市場や商材が変われば「良いリード」の条件も変わるため、MQLの定義、SLAの閾値、対応期限は生きた文書として定期的に見直しましょう。
ここで止めず、会議で決めた変更を翌月の運用へ落とし込んでみてください。

10%から25%へ、改善は積み上げで効く

定義合意、SLA、対応速度、スコアリング、フィードバックループを積み上げて運用すると、商談化率は10%前後から25%程度まで引き上げられます。
魔法の施策が一つあるわけではなく、判定基準をそろえ、初動を速め、失注理由を戻し、必要に応じて閾値を変えるという小さな改善を重ねることが成果を作ります。
おすすめは、まずダッシュボードをそろえ、次に失注理由の回収頻度を決める進め方です。

この積み上げが効く理由は明快です。
リードの質だけを変えても、対応速度が遅ければ商談化前に熱が冷めますし、逆に営業の速度だけを上げても、そもそも定義がずれていれば歩留まりは上がりません。
両者をつなぐ運用が回り始めると、改善は局所最適ではなく全体最適に変わります。
継続して整えていけば、商談化率の伸びは再現しやすくなるでしょう。
やってみてください。