Sales Accepted率をマーケKPIに置く理由と測り方
MQLは出ているのに商談にならない。その断絶を可視化するのがSales Accepted率です。定義の揃え方、却下理由の分類、ダッシュボードの作り方と運用手順を、明日から使える基準として整理します。
公開 2026年10月3日
結論：MQL数ではなくSales Accepted率を見る
マーケティングのKPIにSales Accepted率（SAL率）を加えると、リード品質の議論が感情論から数字の議論に変わります。MQL数だけを追うと、営業が受け取らなかったリードが見えないまま積み上がります。Sales Accepted率は「営業が受領して着手したか」を測る指標で、マーケと営業の接合部そのものを可視化します。
重要なのは、率そのものの高低よりも、却下された理由の分布です。理由が分類されて初めて、ターゲティング・コンテンツ・引き継ぎ情報のどれを直すべきかが判断できます。
※本記事は2026年10月時点の情報をもとに作成しています。
Sales Accepted率とは
Sales Accepted率とは、マーケティングが営業へ引き渡したMQLのうち、営業が受領を承諾し、フォロー対象として着手したものの割合です。分母はMQL（引き渡し件数）、分子はSAL（Sales Accepted Lead）になります。
関連する用語との関係を整理します。
- MQL：マーケティング側の基準を満たしたリード
- SAL：営業が受領を承諾し、着手したリード
- SQL：営業が接触し、案件要件（課題・予算・時期など）を確認したリード
- 商談（Opportunity）：パイプラインに計上された案件
MQL→SQLの間に挟まるSALを明示的に測る点が特徴です。MQLとSQLだけを見ていると、「営業が触っていないから進まない」のか「営業が触ったが要件に合わなかった」のかが区別できません。Sales Accepted率はこの2つを切り分けます。
なお、受領の定義は組織ごとに決めて構いません。ただし「営業が主観で良し悪しを判断する」のではなく、行動（初回アクションを実施した）で定義するほうが運用は安定します。
受領と却下の判定基準を先に決める
Sales Accepted率を測る前に、受領・却下の判定基準を文章で固定します。基準が曖昧なまま計測すると、率は営業の気分を反映するだけの数字になります。
判定基準は次の3要素で定義します。
| 要素 | 決めること | 悪い例 |
|---|---|---|
| 受領の条件 | 何をしたら受領とみなすか（例：初回アプローチを実施し記録を残す） | 「営業が良いと思ったら」 |
| 判定の期限 | 引き渡しから何営業日以内に受領/却下を返すか | 期限なし |
| 却下の必須入力 | 却下理由コードと自由記述を必須にするか | 理由なしで差し戻し可 |
期限を設けない運用では、リードが放置されたまま「未判定」に滞留します。未判定は却下として扱うか、別区分として明示するかを先に決めます。この取り決めは引き渡し全体のルールと一体で運用すべきもので、詳細はMQLの引き継ぎSLA設計で扱っています。
却下理由を分類する
Sales Accepted率の価値は、却下理由の分類にあります。理由コードは多すぎると入力されず、少なすぎると打ち手に結びつきません。5〜7種類を目安に設計します。
| 却下理由コード | 内容 | 主な改善主体 |
|---|---|---|
| ターゲット外 | 企業規模・業種・国が対象外 | マーケ（配信・フォーム設計） |
| 役割不一致 | 購買や検討に関与しない立場 | マーケ（獲得チャネル） |
| 既存・重複 | 既存顧客や既存商談と重複 | 両者（名寄せ・ルール） |
| 情報不足 | 連絡先や文脈が足りず接触不能 | マーケ（引き渡し情報） |
| 時期尚早 | 検討時期が先 | 両者（ナーチャリングへ戻す） |
| 競合・不適合 | 製品要件が合わない | マーケ（訴求内容） |
「時期尚早」はマーケへ差し戻す前提の区分にします。差し戻し先が決まっていないと、営業は却下をためらい、結果として受領したまま放置されます。
理由別の件数推移を月次で見ると、どの打ち手が効いたかが追えます。ターゲット外が多いならチャネル構成、情報不足が多いなら引き渡しフォーマットの問題です。
測り方とダッシュボードの作り方
計測は、引き渡し日を基準にしたコホートで行います。月内に発生したSALを月内のMQLで割ると、判定のタイムラグで数字が歪みます。
運用手順は次の通りです。
- MQLに「引き渡し日時」を記録する
- 営業側で「受領日時」「却下日時」「却下理由コード」を記録する
- 引き渡し月のコホートごとに、受領・却下・未判定の件数を集計する
- チャネル別・キャンペーン別・セグメント別に分解する
- 却下理由の構成比を並べて推移を見る
分解の軸は、施策の意思決定単位に合わせます。チャネル単位で予算を動かすならチャネル別、コンテンツ単位で改善するならオファー別です。
合わせて見る指標も決めます。
| 指標 | 見る目的 |
|---|---|
| 受領までの所要時間 | 引き渡し後の滞留を検知する |
| 未判定率 | ルールが運用されているかを確認する |
| 却下理由の構成比 | 改善対象の切り分け |
| SAL以降の進捗率 | 受領基準が緩すぎないかの検証 |
受領基準が緩いと、Sales Accepted率は上がる一方で後工程が詰まります。SAL以降の進捗を必ず併置して、片方だけを最適化しない設計にします。
よくある失敗のパターン
率だけを目標値にする。数字を上げること自体が目的化すると、営業は却下を避け、マーケは確度の高いリードだけを引き渡します。母数が縮小し、パイプラインの入口が細くなります。率と件数を必ずセットで見ます。
却下理由がフリーテキストのみ。集計できず、改善の議論に使えません。コード化したうえで補足を自由記述にします。
判定期限がない。未判定が積み上がり、どの時点の数字かが分からなくなります。期限超過は自動で区分を変える運用にします。
定義の見直しをしない。製品やターゲットが変われば、MQL定義もSAL定義も陳腐化します。四半期ごとに両チームで再確認します。
引き渡し情報が薄い。フォーム入力値だけでは、営業は文脈を掴めません。却下理由「情報不足」が多い場合は、獲得時点のヒアリング設計を見直します。LPでの情報取得の考え方はBtoB LPのCVR停滞で整理しています。
向いていないケース
Sales Accepted率をKPIに据えるのが適さない状況もあります。
- 引き渡しの運用自体が存在しない：MQLを営業へ渡すプロセスが未整備なら、まず引き渡しルールの設計が先です
- 営業組織が小規模で、全リードに接触している：却下という概念が実質的に発生せず、指標として機能しません
- PLG中心で、セルフサーブが主導線：営業接触を前提としないため、プロダクト内の利用状況を見るほうが整合します
- 月次の引き渡し件数が少ない：母数が小さいと率が大きく振れ、意思決定に使えません。件数と理由の生データを直接見るほうが実務的です
- CRMに受領・却下を記録する運用が定着していない：入力が欠ける前提の数字は、議論の土台になりません
これらの場合は、率の導入を急がず、記録が残る運用の定着を優先します。
よくある質問
Sales Accepted率の目標値はどう決めればよいですか。
他社の水準を参照するより、自社の直近数四半期の実績を基準線にします。そのうえで、却下理由のうち「ターゲット外」「情報不足」など自社で制御できる区分を減らす方向で目標を置きます。率そのものより、理由別の構成変化を目標にするほうが改善に直結します。
営業が却下理由を入力してくれません。
入力項目を減らし、必須をコード選択だけにします。自由記述は任意にします。あわせて、却下したリードがどう扱われるか（ナーチャリングへ戻る、再引き渡しの条件）を明示すると、入力の動機が生まれます。
MQLの定義を厳しくすれば率は上がりますか。
上がりますが、母数が減ります。率と件数、さらにSAL以降の進捗を同時に見て判断します。定義変更の際は、変更前後でコホートを分けて比較します。
展示会やウェビナー経由のリードも同じ基準で測りますか。
基準は共通にしつつ、チャネル別に分解して見ます。イベント系は判定期限の設計が特に重要です。時間経過の扱いは[ウェビナー後72時間のフォロー設計](/knowledge/webinar-lead-72-hours)で整理しています。
まとめ
Sales Accepted率は、マーケティングと営業の接合部を数字にする指標です。
導入の順序は、①受領・却下の定義を文章で固定、②却下理由のコード設計、③引き渡し日基準のコホート集計、④チャネル別・理由別の分解、の4段です。率だけを追わず、件数・未判定率・SAL以降の進捗を併置します。
四半期ごとに定義を見直し、ターゲットや製品の変化に合わせて更新します。関連する考え方はナレッジ記事一覧にまとめています。
UniAgentは、Webサイト上で登録資料を根拠に説明とヒアリングを行い、その文脈を担当者へ引き継ぐAIです。