SDR／BDRとは？SaaSで成果を出す組織設計

MQLが急増してきた／アウトバウンドを強化したい——そんなタイミングで「SDRとBDR、どう分けるべきか」「評価設計はどうするのか」という組織設計の壁にぶつかるSaaS企業は少なくありません。

本記事では、SaaSに適切化したSDR／BDRの役割定義・チーム設計・KPI設計・ワークフロー構築のベストプラクティスを整理。急成長フェーズの営業責任者が、明日から組織をアップデートできるような実務的内容にフォーカスします。

SDRとBDRの
役割とミッションの違い

SDR（Sales Development Representative）とBDR（Business Development Representative）は、ともに「商談の起点をつくる」役割を担いますが、対応チャネル・リードの起点・ミッションの定義が異なります。

項目	SDR	BDR
起点	インバウンド（問い合わせ、ホワイトペーパーDL等）	アウトバウンド（リスト起票、ABM施策等）
主な業務	MQL対応、初回接触、ヒアリング、SQL化	リードリサーチ、初期アプローチ、アポ獲得
KPI例	MQL→SQL率、商談設定数	架電数、アポ獲得数、アポ率
主な対象	比較検討中／関心層	未認知層／ターゲット企業群

SaaSモデルにおいては、SDRが「反応のあったリードを確度高く商談につなげる役割」、BDRが「戦略的に新規ターゲットへアプローチする役割」と捉えるのが基本です。

境界の曖昧化と
ミッション基準での再定義

近年、SDRとBDRの役割分担は従来より柔軟になりつつあります。たとえば、SDRがハウスリストに対してアウトバウンドアプローチをかけるケースや、BDRが反応のあったリードに対してフォロー対応を行うといった、境界が曖昧になってきています

このような背景から、SDR／BDRの区分はプロセスよりもミッションベースで定義すべきという考え方が広がっています。どちらが対応するかは「誰に、何を目的に接触するのか」を軸に判断することが、運用の実態とズレない設計につながります。

成果を上げるチーム編成方法

SDR／BDR組織を立ち上げる際に重要なのは、人数配置とスキル要件、評価設計をセットで考えることです。特にSaaSでは、1人あたりの商談創出能力を基準にヘッドカウントを設計する必要があります。

人数設計の一例

• 想定SQL数：月30件
• 1人あたりのSQL処理上限：月15件 → 2名配置が必要

求められるスキル要件

• SDR：インバウンド対応力、傾聴・要件整理、CRM入力の正確性
• BDR：リスト構築力、仮説思考、商談創出の粘り強さ

スキルマトリクスと評価設計

評価の属人化を防ぎ、明確な成長基準を組織全体に示すためには、スキルマトリクスや評価グリッドの整備が有効です。たとえば「リサーチ力」「ヒアリング力」「課題仮説力」「CRM運用力」などの評価軸に対して、各レベルで期待される行動例を定義すると、個人のスキルギャップと育成方針が明確になります。

組織フェーズ別の構成例

また、組織規模の拡大に伴って、構成の見直しが必要になります。「0→3人」「3→5人」「5→10人」といったステージごとに、必要なマネージャー配置やプレイング比率、リーダー1人あたりのマネジメント対象人数（スパンオブコントロール）を整理した設計パターンがあると、拡張時の失敗を未然に防ぐことができます。

マネジメントラインは、チーム規模が3〜5名を超えたあたりからPod型（SDR複数人＋1名のリーダー or AE）に移行する企業が多く見られます。人数と成果指標をセットにした組織設計テンプレートを持っておくことが、スケール時の失敗を防ぎます。

リードジェネレーションから
商談化までのフロー

SaaSにおけるSDR／BDRは、単なる“アポ取り”ではなく、営業ファネルの入り口を「整える・磨く・つなぐ」ことに責任を持ちます。

SDR（インバウンドプロセス）

1. MQL（ホワイトペーパーDL・セミナー参加）
2. 初回対応：2営業日以内に架電／メール
3. ヒアリング：課題、導入時期、検討体制など
4. スコアリング：SQL判定
5. AEへの引き継ぎ（Slack通知＋CRM内メモ）

引き継ぎ精度を高める
SLA設計と項目定義

インサイドセールス体制が軌道に乗るためには、SDR→AE間の「引き継ぎ基準」が曖昧でないことが重要です。たとえば、初回ヒアリングでBANT項目のうち最低2項目が明確になっている場合にSQL判定を出す、など、明文化されたSLA（サービスレベルアグリーメント）を定めると判断が標準化されます。

また、HubSpotやSalesforceなどのCRMを活用している場合、「ステータス変更のトリガー」や「通知ルール」をどのタイミングでどう設定しているかが成果に直結します。たとえば「リード→コンタクト→SQL」への移行時に、スコアとステージが自動で更新されるようオブジェクト連携を設計しておくことで、運用の属人性を削減できます。

BDR（アウトバウンドプロセス）

1. ターゲット企業リスト化（業界／従業員数／技術スタック）
2. 初期アプローチ（電話／メール／SNS）
3. 反応のあった企業にテンプレではなくカスタムスクリプトで対応
4. アポ設定後、AEまたはFSへ連携

特に引き継ぎ工程では、“熱いリードを渡す”だけでなく、AE側の期待値と整合した情報粒度での報告が必要です。ヒアリング項目テンプレート、CRM内コメントフォーマットなどを標準化することで、パイプライン全体の歩留まりが安定します。

KPI設定と評価指標
（MQL→SQL率など）

SDR／BDR組織のパフォーマンス可視化には、ファネルの分解と先行指標・成果指標の両方の設計が欠かせません。

代表的なKPI指標

フェーズ	KPI例
SDR	・MQL→初回接触率 ・接触→ヒアリング実施率 ・SQL化率（商談可と判断されたリード） ・商談化数（AE連携完了件数）
BDR	・架電数／通電率／アポ率 ・アポからのSQL化率 ・1人あたりのアポ創出数

KPIは週次・月次単位で可視化し、早期にリード品質やスクリプトの改善余地を発見する設計が望ましいです。また、インセンティブと連動させる場合は、「量×質」の両軸で設計するのが一般的です（例：商談化数と接触率に対する報酬係数の掛け合わせ）。

KPIダッシュボードの
可視化と管理例

KPI設計は運用で回ることが前提です。Google SheetsやLooker Studioなどを活用し、週次で確認できるKPIダッシュボードを構築しておくことで、リードの質やコンバージョンの傾向を早期に検知し、アクションに移すことが可能になります。

さらに、報酬制度とKPIを連動させることで、個人の行動に再現性が生まれやすくなります。たとえば「アポ数×商談化率」に応じた2軸評価や、「接触率90%以上で加点」「SQL未達成で一定比率減額」などの具体モデルがあると、目標と行動の整合性が高まります。チーム全体へのインセンティブ設計を併用することで、成果を“分業の総和”として捉える文化づくりにも寄与します。