%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
マーケ営業連携SLAは、リードを営業へ渡す条件と、受け取った後の対応を両部門で決める合意です。引き渡しの定義・期限・記録・改善を一つの運用にすることが核心です。
マーケ営業連携SLAは、リードを営業へ渡す条件と、受け取った後の対応を両部門で決める合意です。引き渡しの定義・期限・記録・改善を一つの運用にすることが核心です。
「マーケが獲得したリードを営業がフォローしない」「営業から見るとマーケのリードは質が低い」「フォロー結果がマーケに戻らない」——こうした声が並ぶときは、どの工程で判断が止まっているかを確かめる必要があります。
マーケ営業連携SLAでは、MQLとSQLの定義、リードの引き渡し条件、営業の対応ルール、結果の記録方法、共通KPIを合意します。誰が、どの情報を見て、次に何を決め、その結果をどこへ残すかを明確にすれば、滞留した工程から見直せます。
例えば、営業が「情報不足」と判断した場合でも、対象企業か分からないのか、相談内容が分からないのかで補完する情報は異なります。SLAには受け入れの基準だけでなく、判断できないときに何を補い、誰が再判定するかまで記載します。
本記事は「BtoBマーケティングのKPI設計ガイド｜フェーズ別の具体例と管理テンプレート」シリーズの一部です。
この記事でわかること
マーケティング・営業・CRMの取り組みを検討されている方に、現在の引き渡しを点検し、両部門の合意を日々の判断と記録へ移す手順を解説します。読み終えたら、自社のリードを使って受け入れ・返却の判断を照合し、SLA文書とCRMに反映する項目を整理してください。
- マーケ営業連携が崩れる原因 — KPI、定義、データ、フィードバックのどこで判断が途切れているかを確認します。
- SLAに盛り込む項目 — 引き渡す情報、営業の受け入れと対応、結果返却について、担当と完了条件を決めます。対応期限の起点と終了条件も整理します。
- MQLとSQLを合意する手順 — 属性、行動、対象外条件を分け、営業の受け入れ理由と返却理由から基準を調整します。情報不足と不適格を区別する判断例も示します。
- リードを商談と再育成へつなぐ流れ — 引き渡し後の結果に応じて、商談管理、情報の補完、再育成へ進む条件を整理します。
- HubSpotで連携を支える方法 — 合意済みの判断を項目、通知、タスク、ダッシュボードへ反映する順序と、試行時に確認する分岐を示します。
マーケ営業連携が崩れる原因を構造で捉える
連携の問題を調べるときは、担当者の対応だけで結論を出さず、リードが発生してから結果が返るまでをたどります。
各工程で次の点を確認すると、定義、受け渡し、対応のどこを直すべきか分かります。
- 「判断に必要な情報があるか」
- 「次の担当が決まっているか」
- 「結果が記録されるか」
部門ごとのKPIが別方向を向いている
マーケティングがリード数、営業が受注だけを見ていると、引き渡し後の状況を両部門で検討しにくくなります。
まず同じ対象期間のリードを起点に、MQL、営業の受け入れ、商談、受注・失注までをつなげて確認します。
| 分断された見方 | 連携した見方 |
|---|---|
| マーケティングは獲得数だけを見る | MQLから商談までの移行と理由を見る |
| 営業は受注案件だけを見る | マーケティング起点の案件経路を見る |
| 未対応を担当者の責任にする | 通知、担当割り当て、期限、記録欄を設計する |
| 失注を営業内で閉じる | 失注理由をマーケティング施策へ戻す |
MQLは増えているのに受け入れが進まないなら、最初に「返却された」のか「まだ判断されていない」のかを分けます。
- 返却が増えている場合 ── 判定条件と引き渡す情報を確認します
- 未判断が残る場合 ── 担当割り当てと受け入れ判断の期限を確認します
受け入れ後の状況は、次のように確認します。
- 受け入れ後に対応が止まる場合 ── 担当者が抱える未対応と新たな引き渡し量を照らし合わせます
- 商談後に失注が偏る場合 ── 案件の失注理由を確かめ、集客時の期待と営業で確認した課題にずれがないかを見ます
止まった工程を特定してから、その工程の条件や担当体制を変えることが基本です。
MQLやSQLが共通言語になっていない
同じMQLという言葉でも、マーケティングは「関心を示したリード」、営業は「接触すべきリード」と捉えている場合があります。名称だけをそろえても、営業が受け取った後の判断は一致しません。
- MQL ── どの属性と行動を根拠に渡すか、どの条件なら渡さないかを定めます
- SQL ── 営業が何を確認できれば商談として進めるかを定めます
例えば「検討時期を確認済み」という条件でも、具体的な時期が判明している必要があるのか、時期が未定である理由と次の確認機会が分かればよいのかを区別します。
判断が割れたリードは、両部門が同じ情報を見ていたかを先に確認します。
- 見ている情報が違う ── 表示や引き渡し項目を直します
- 同じ情報でも結論が違う ── 定義を直します
この切り分けをせずにスコアや入力項目を増やしても、判断のずれは残ります。
スプレッドシートと個別連絡に情報が分散している
リード一覧、引き渡し連絡、営業結果が別々の場所にあると、最新の状態を確認するたびに突き合わせが必要です。
まず実際のリードについて、判定根拠、引き渡し日時、営業担当、対応結果、次の行動がどこに残っているかをたどります。
- 情報が見つからない場合 ── 入力責任と記録場所を決めます
- 情報はあるのに判断が進まない場合 ── 次の担当者に必要な内容が表示されているかを確認します
- 同じ会社の別担当者から問い合わせが来た場合 ── 進行中の商談と関係するかを確認してから担当を決めます
コンタクト、会社、取引をCRM上で関連付ける際も、この判断の流れに沿って項目を配置します。
個人単位のリード数と会社単位の案件数を混同しないよう、引き渡しの管理単位と商談の管理単位を分けておきます。
SLAで合意する範囲と役割を明確にする
SLAは、マーケティングと営業が互いに求めるサービス水準を文書化した合意です。マーケティングが渡す条件と情報、営業が受け取った後の判断と対応、結果を返す方法を対にして決めます。
SLAに含める基本項目
SLAには、リード品質、引き渡し条件、営業対応、結果記録、共通KPIを含めます。次の表を埋める際は、各項目について「誰が記録し、何がそろえば完了か」まで確認します。
| 項目 | マーケティング側の合意 | 営業側の合意 |
|---|---|---|
| 対象 | MQLの定義と対象外条件を満たすリードを渡す | 受け入れ可否を定義された選択肢で返す |
| 情報 | 判定根拠となる属性と行動を記録する | 初回対応とヒアリング結果を記録する |
| 速度 | 条件到達時に担当者へ引き渡す | 合意した期限内に次の行動を決める |
| 品質 | 不適格理由を基に判定条件を見直す | 不適格、保留、商談化の理由を残す |
| 成果 | パイプラインへの貢献を追う | 商談と受注の結果を起点情報へつなぐ |
対象の合意では、MQLの条件に合致し、対象外条件には該当しないことを確認します。情報が空欄であることと、対象外であることは分けて扱います。
対応期限は、時間の長さを決める前に、何を終える期限なのかを決めます。
- 別に記載する ── 営業が受け入れ可否を返す期限と、顧客へ初回接触する期限は別に記載してください
- 受け入れの記録 ── 受け入れを記録しただけで初回対応も完了した扱いにはしません
期限の設計は、次の順で進めます。
- 起点と終了を定義する。 引き渡し日時、受け入れ判断日時、初回接触日時を分けます。受領を起点にする場合も、引き渡しから受領までの待ち時間を残します。
- 時間の数え方を決める。 営業時間外の引き渡し、休業日、担当者不在をどう扱うかを文書化します。不在時の代替担当も決めます。
- 対応の種類を分ける。 相談希望が明示されたリードと、情報収集の行動を基に渡すリードでは、顧客が求める次の行動を確かめて優先度を決めます。
- 実績と対応可能な量を比較する。 期限内に対応できた案件だけでなく、未対応も含めて確認します。割り当てに時間がかかっているなら、期限の変更より先に割り当て方法を直します。
- 試行する期限と見直し条件を合意する。 顧客との約束に間に合わない、特定の担当へ滞留が集中するなど、見直す条件を添えます。
情報不足で処理を止める場合は、不足項目、補完する担当、再確認の予定を残します。期限を止める運用を採用するなら、停止理由と再開条件も合意し、停止中の案件を集計から見えなくしないことが必要です。
SLAは評価表ではなく業務の接続仕様にする
SLAでは、入力がそろえば誰が受け取り、どの状態になれば次工程へ進むかを明確にします。
例えば、営業がMQLを返却する場合は「返却」とだけ記録せず、対象外、情報不足、時期が合わないなどの理由と、その後の担当を決めます。
- 文書 ── 判断に使う定義、責任者、例外時の戻し先を置きます
- CRMの入力欄 ── その判断を残す選択肢を置きます
- 通知文 ── 受け手が確認すべき情報を示します
返却の扱いは、例えば次のように分けます。
- 「対象業種だが相談内容が不明」というリード ── 対象外にはせず、相談内容を補完する担当へ戻します
- 「対象業種で相談内容も明確だが、営業担当が不在」 ── リードの品質を理由に返却せず、代替担当への割り当てとして扱います
品質の問題と担当体制の問題を分けることで、返却理由から修正箇所を選べます。
運用中に口頭の補足が必要になったら、判断条件が文書にないのか、記録された情報が画面で見えないのかを切り分けて直します。
共通KPIをパイプライン全体へつなげる
共通KPIを見る前に、各指標の対象、起点、集計単位をそろえます。本記事では、MQLとなったリードの集団を起点に、その後の受け入れと商談化を追う方法を用います。計算は次のように定義できます。
- 営業受け入れ率： 対象MQLのうち営業が受け入れた件数 ÷ 対象MQL件数。返却、保留、未判断の内訳も併記します。
- MQLからの商談化率： 対象MQLのうち商談化したリード件数 ÷ 対象MQL件数。取引件数を分子に使う指標とは分けます。
- 対応期限の遵守率： 集計時点までに期限が到来した対象のうち、期限内に所定の対応を完了した件数 ÷ 集計時点までに期限が到来した対象件数。期限を過ぎた未対応も分母に含めます。
分母がない場合は比率を算出せず、対象なしと表示します。受け入れを判断済みのリードだけで比率を見る場合は、その指標名に判断済みであることを明示し、未判断件数も隣に置きます。
比較時には、MQLになってからの経過時間もそろえます。
- 新しく発生したリードと、営業対応が進んだリードを同じ条件で比較する場合 ── 前者の商談化率が低い理由を判別できません
- 観察期間 ── 自社の営業過程を踏まえて決め、期間がまだ満了していない対象は途中経過として扱います
また、同じリードの再引き渡しは、リードの重複を除いた件数と引き渡し回数を分けて記録します。取引金額を確認する際は、同じ取引に関連するコンタクトが複数いても、同じ金額を重複して足さない集計にします。
目標値は、この定義で自社の実績を確認した後に設定します。
- 未判断が多い段階 ── 商談化率の目標を上げる前に受け入れ判断の運用を整えます
- 判断結果がそろったら ── 流入経路や対象企業の違いを分け、どの工程を変えるかを決めてから目標を置きます
マーケティング起点案件の受注率を、共通KPIとして営業の受け入れから受注まで追跡し、パイプライン貢献金額とあわせて報告します。
MQLとSQLの定義を両部門で合意する
MQLとSQLの定義は、過去の受注・失注と現場の判断を照らし合わせて作ります。
最初に名称を決め切るのではなく、実際のリードについて「営業へ渡すか」「何を確認できれば次へ進めるか」を両部門で判断し、意見が分かれた理由を定義へ反映します。
ライフサイクルステージを整理する
各ステージには入口条件、管理責任、出口条件を置きます。次の表はSLAを設計するための業務上の整理例です。
表の名称をそのままシステムに追加する前に、受け入れ判断と商談化判断を別々に管理する必要があるかを確認します。
| ステージ（主な管理責任） | 定義 | 次へ進む条件 |
|---|---|---|
| Raw Lead（マーケティング） | 情報を取得した未分類のリード | 判定に必要な情報がそろう |
| MQL（マーケティング） | マーケティングが合意基準を満たすと判断したリード | 営業が受け入れ可否を判断する |
| SAL（営業） | 営業がフォロー対象として受け入れたリード | 初回確認の結果を記録する |
| SQL（営業） | 営業が商談化の見込みがあると判断したリード | 具体的な案件として管理する |
| Opportunity（営業） | 取引として進行している案件 | 受注または失注を記録する |
営業による判定が終わったことと、次のステージへ進めることは区別します。
- MQLを受け入れた場合 ── SALへ進めます
- 返却した場合 ── 理由を記録して補完や再育成へ回します
- 初回確認が終わっても商談化の根拠が足りない場合 ── SQLへ進めず次の確認事項を残します
HubSpotのライフサイクルステージをSLAに対応付ける際は、営業の受け入れと商談化を既存のステージで区別できるか確認してください。
同じステージに次の担当や行動が異なる状態が含まれる場合は、次のどちらかを検討します。
- 段階を分ける必要があるか
- 対応結果を別の項目で記録するか
（出典：Create and customize lifecycle stages）
MQLは属性・行動・対象外条件で決める
属性は自社の営業対象に合うか、行動は何に関心を示したかを判断する材料です。行動があっても対象外条件に該当する場合、営業には渡しません。
情報が足りない場合は、適合とも不適合とも決めず、何を補えば再判定できるかを残します。
| 判定軸 | 確認する内容 | 判定後の扱い |
|---|---|---|
| 属性 | 対象業種、企業規模、役職など | 適合度として記録する |
| 行動 | 閲覧、資料取得、イベント参加など | 関心度として記録する |
| 対象外 | 競合、営業対象外、別目的の問い合わせなど | 営業へ渡さず理由を記録する |
| 情報不足 | 判定に必要な項目が欠けている | 補完または再育成へ回す |
判定は、次の順に進めます。
- 対象外条件の確認
- 必須情報の有無
- 属性の適合
- 行動の意味
各段階で「非該当」と「不明」を分けて記録すると、情報不足を対象外として処理することを避けられます。
例えば、対象企業の担当者が資料を取得した場合、資料取得だけで営業へ渡すのか、相談意向など別の根拠を必要とするのかを先に合意します。
- 相談希望があっても企業情報が不足している場合 ── その情報を誰が確認するかを決めます
- 行動の強さだけで対象条件を飛ばさない ── 設計にします
スコアを使う場合は、引き渡しの境目にあるリードを両部門で確認します。
- 受け入れたリードと返却したリード ── どの属性や行動が違ったかを比べてください
- 点数を上げても同じ返却理由が残る場合 ── 点数の境目ではなく対象外条件や行動の解釈を直します
試行では、営業へ渡さなかったリードも確認します。後から具体的な相談につながったリードが、どの条件で止まっていたかを調べるためです。
返却を減らすことだけを目的に基準を厳しくせず、営業へ渡すべきリードを止めていないかも見ます。
SQLは営業が確認できる情報で定義する
SQLでは、課題、検討時期、意思決定への関与、次の行動について、何が確認できれば商談として進めるかを決めます。
すべての項目が同じ程度に詳しく分かることを求めるのではなく、案件として管理する根拠と、次の接触で補う情報を分けます。
例えば「課題は具体的で、関係者との次回確認も合意できたが、予算は未確定」という場合に進めるかどうかは、自社の商談化条件に従います。
- 予算の確定を入口条件とする場合 ── 保留します
- 案件を進めながら確認する設計の場合 ── 未確定の理由と確認する担当を残して進めます
一方、「興味がありそう」という営業担当の印象だけでは、次の担当者が同じ判断を再現できません。
- 記録すること ── 顧客が話した課題、確認できた検討状況、合意した次の行動を記録します
- 接触できなかった場合 ── 課題がないとは判断せず、未確認として次の接触方針を決めます
ステージ移行時の入力項目は、次の担当者が判断するために必要なものから選びます。その情報が商談化、次の接触、レポートのどれに使われるかを説明できたら、入力する場面と担当を決めます。
SLAを策定して運用へ落とす手順
現状把握、共通目標、定義、文書化、試行の順に進めます。各段階で決めたことを、次の担当者がレコードを見て実行できる状態にするのが完了条件です。
以下では、それぞれの段階で残す情報と、次へ進める条件を整理します。
現状の流れとデータを棚卸しする
リードが発生してから営業へ渡り、商談になるまでの経路を書き出します。スプレッドシート、メール、チャット、CRMに情報が重複している場合は、どこを正として更新するかを確認します。
受注した案件だけでなく、返却されたリード、保留中のリード、未対応のリードもたどります。各工程について、次を説明できれば棚卸しは完了です。
- 入力元
- 担当者
- 完了状態
- 次の受け手
説明できない工程があれば、期限を設定する前に責任と記録場所を決めます。
- 結果が残っていない場合 ── 記憶で分類を埋めず「結果未記録」として扱います
- 新たな引き渡し ── 記録をそろえ、過去分は確認できた範囲と未確認を分けます
これにより、記録方法の変更による差と、業務の変化による差を混同せずに比較できます。
共通目標とパイプラインの設計をそろえる
売上目標とリード目標をつなぐには、SQL以降をどの取引ステージで管理するかもそろえる必要があります。
StartLinkでは、ステージ、角度、ステージ定義、必須入力プロパティの観点で整理することをおすすめします。
| 設計要素 | 決めること | SLAとの関係 |
|---|---|---|
| 取引ステージ | 案件の進行を区切る地点 | SQL後の受け皿を明確にする |
| 角度 | 各ステージの見込みの扱い | パイプライン評価の前提をそろえる |
| ステージ定義 | 何が起きたら移行するか | 部門間の言葉のずれを減らす |
| 必須入力プロパティ | 移行時に残す情報 | 次工程が判断できるデータをそろえる |
SQLから取引へ進める条件が曖昧なら、営業が何を確認した時点で案件として管理するかを決めます。次の点も整理します。
- すでに同じ相談を扱う取引がある場合 ── の関連付け
- 別の相談として取引を作る場合 ── の条件
目標を逆算する際は、受注から商談、商談からMQLへと必要な量を考えます。
- 自社の移行実績がそろっていない段階で任意の比率を置く場合 ── 引き渡し量と営業の対応可能な量が合うか判断できません
- まず ── 定義をそろえた実績を確認し、必要なMQLを受け取れる担当体制と併せて目標を合意します
引き渡しと結果返却のルールを文書化する
SLA文書には、MQLの入口条件、営業の受け入れ方法、対応期限、結果の選択肢、再育成の条件を記載します。次の判断表を使い、状態が変わるたびに担当と完了状態が明らかになるかを確認します。
| 状態（担当） | 行動 | 完了状態 |
|---|---|---|
| MQL到達（マーケティング） | 判定根拠をそろえて営業へ渡す | 担当者と引き渡し日時が記録されている |
| 営業受領（営業） | 優先度と次の行動を判断する | 受け入れまたは返却が選択されている |
| 初回対応（営業） | 合意した方法で接触する | 対応結果と次回行動が記録されている |
| 不適格・保留（営業とマーケティング） | 理由に応じて再育成へ戻す | 理由と再判定条件が記録されている |
受け入れも返却もできない情報不足のリードは、必要な情報、補完する担当、再確認する条件を残します。保留を選択できる場合も、その選択だけで受け入れ判断を完了した扱いにはせず、保留を解除する条件を付けます。
文書化の確認には、担当者以外がレコードとSLA文書を見て、次の行動を説明できるかを使います。
- 「担当者に聞かないと分からない」箇所がある場合 ── 判断条件か記録内容を補います
- 判断が割れる場合の責任者まで決まった場合 ── 試行へ進みます
小さな範囲で試し、定義を調整する
対象施策や担当チームを絞り、実際のリードが引き渡しから結果返却まで進むかを確認します。通知が届いたかだけで終えず、営業が判定根拠を見られるか、受け入れ・返却を選べるか、対応結果が戻るかを順に見ます。
通常の受け入れに加え、情報不足、対象外、担当者不在、再引き渡しの場面も確認します。問題が起きたら、次のように修正先を分けます。
- 文書どおりに判断できない場合は、入口条件や例外条件を直します。
- 判断はできるが結果を残せない場合は、入力欄や入力する場面を直します。
- 記録はあるが次の担当へ届かない場合は、通知先や割り当てを直します。
- 対応可能な量を超える場合は、優先順位と担当体制を責任者が調整します。
変更前後を比較できるよう、次を残します。
- 変更日
- 変更理由
- 適用する対象
- 定義の版
過去のリードを新しい定義で再判定した結果は、当時の運用実績と分けて扱います。
通常時と例外時の行き先が追え、未記録の理由と対応担当が明らかになったら、対象を広げる判断へ進みます。
リード引き渡しと再育成を一つの流れにする
引き渡しは通知で完了しません。営業が受け入れ可否を判断し、接触結果を残し、商談へ進めるか再育成へ戻すかが決まった時点で、マーケティングも結果を確認できます。
引き渡し後に止まった場合の扱いも、同じ流れに含めます。
引き渡しフローに完了条件を置く
各工程で必要な記録がそろっていなければ、その工程を完了した扱いにせず不足情報を補います。「連絡した」「確認中」といった自由記述だけに頼らず、状態と理由を選択し、個別事情を補足欄に残します。
| 順序 | 工程 | 完了条件 |
|---|---|---|
| 1 | MQL判定 | 判定根拠と対象外条件が確認されている |
| 2 | 担当割り当て | 営業担当者と対応期限が設定されている |
| 3 | 営業確認 | 受け入れ、返却、保留のいずれかが記録されている |
| 4 | 初回対応 | 接触結果と次の行動が記録されている |
| 5 | SQL判定 | 商談化または再育成の理由が選択されている |
| 6 | 取引管理 | 取引ステージと必要項目が更新されている |
この順序は、すべてのリードを取引管理まで進める意味ではありません。営業確認で返却・保留となった場合は、その理由に応じた補完や再育成へ分岐します。SQL判定で商談化と判断した場合に、取引管理へ進みます。
初回対応では、「接触を試みた」と「顧客と会話できた」を分けます。
- 返信がない場合 ── それだけで不適格にはせず、合意した接触方針に従って次の行動を残します
- タスクを完了した場合 ── それだけで、商談化の判断まで済んだ扱いにしないことも必要です
滞留を見つけたら、その工程の完了条件を確認します。担当者が未設定なら割り当てを、担当者はいるが判断できないなら判定根拠を、対応済みで結果が見えないなら記録方法を直します。
リサイクル理由ごとに次の施策を変える
営業が今は商談へ進めないと判断したリードには、理由と再判定のきっかけを残します。同じリードを再び渡すのは、あらかじめ決めた条件に変化があったと確認できたときです。
| リサイクル理由 | 次の対応 | 再判定のきっかけ |
|---|---|---|
| タイミングが合わない | 関連情報の提供を継続する | 検討時期や行動の変化 |
| 予算が合わない | 投資判断に必要な情報を案内する | 予算条件の変化 |
| 決裁者ではない | 社内共有しやすい情報を提供する | 関係者の追加や紹介 |
| 情報収集段階 | 課題理解を助ける情報を提供する | 比較や相談につながる行動 |
| 対象外 | 配信や営業対象から除外する | 対象条件そのものの変更 |
- 検討時期が合わない場合 ── 顧客と確認した時期や検討状況の変化を再判定の根拠にします。以前と同じ資料を閲覧しただけで、時期の問題が解消したとは判断しません
- 決裁者ではない場合 ── 役職だけで戻すのではなく、社内検討を進める役割や関係者への接点を確認します
再引き渡し時には、前回の返却理由、今回変わった条件、確認した情報、次に営業が確認することをまとめます。営業が前回と同じ理由で返却したなら、変化の判定条件が適切だったかを見直します。
再育成への移行と、ライフサイクルステージを前の段階へ戻す操作は分けて設計します。
- 再育成の状態と返却理由を追うだけの場合 ── ステージとは別の項目で管理する設計を検討します
- ステージを戻す場合 ── 過去の到達段階と今回の再育成を区別して集計できるかを判断の目安にし、適用前に更新方法と履歴の残り方を確認します
（出典：Use contact and company lifecycle stages）
失注理由をマーケティングへ戻す
失注理由は分類と補足を組み合わせて記録します。
- 分類 ── 傾向を見ます
- 個別の補足 ── 何が起きたかを確認できるようにします。「予算が合わない」なら、予算自体が確保されていないのか、提案内容に対する投資判断が進まなかったのかを補足します
以下の画面は、失注理由の構成を案件単位で確認するレポートです。分類の偏りが見えたら、該当する案件へ戻って理由の内容を確かめます。
同じ分類が目立つ場合も、直ちにMQL基準を変えるとは限りません。
- 集客時に伝えた内容と実際の課題がずれていれば ── 資料を見直します
- 営業が必要な条件を確認できていなければ ── ヒアリング項目を見直します
- 営業対象の条件から外れた案件が渡っていたなら ── MQLの対象条件へ戻ります
失注理由の構成だけでなく、流入経路、商談化した時点の条件、営業が確認した内容を併せて比較します。変更する箇所を決めたら、同じ分類と対象で次の結果を確認し、理由が未記録の案件も別に残します。
HubSpotで連携基盤を構築する
HubSpotで連携を設計する際は、コンタクト、会社、取引を使って、個人の情報、企業の情報、商談の進行を整理します。
次の機能には、合意済みの業務ルールから必要な役割を割り当てます。
- ライフサイクルステージ
- リードスコアリング
- ワークフロー
- タスク
- ダッシュボード
設定の順序は、記録する項目、担当者が判断する画面、通知とタスク、共通レポートです。先に通知だけを作らず、通知を受けた人が何を見て何を記録するかから決めます。
一元管理で判断の前提をそろえる
情報は、次のように持たせる設計を検討します。
- コンタクト ── 個人の属性と行動
- 会社 ── 組織情報
- 取引 ── 商談の進行と金額
情報を配置する前に、営業がMQLを受け入れる場面と、マーケティングが結果を確認する場面をそれぞれたどり、必要な情報に到達できるか確かめます。
各プロパティについて、入力する人、使う判断、更新する場面を決めます。例えば引き渡しに関する項目は、次のように役割を分けます。
- マーケティングは、MQLと判断した根拠、判定日時、引き渡し先を残します。
- 営業は、受け入れ結果、その理由、初回対応の結果、次の行動を残します。
- 再育成へ戻す場合は、再判定条件と、その変化を確認する担当を残します。
会社情報と個人の情報が食い違う場合に、どちらを根拠として判断したかも追えるようにします。値が空欄なら保留するのか、別の情報で判断できるのかを決めておけば、入力漏れと定義の問題を分けて扱えます。
自動化で引き渡し漏れを減らす
MQL条件を満たしたら担当者を割り当て、通知し、対応タスクを作成する流れをワークフローへ落とします。
HubSpotでワークフローからタスクを自動作成する機能は、ProfessionalまたはEnterpriseの契約が必要です。（出典：Create tasks）
設定前に、次の点を確認します。
- 対象となる条件
- 対象外条件
- 通知先
- 担当者がいない場合の扱い
すでに営業が対応中のリードや、進行中の商談に関係するリードは、既存担当へつなぐか、新規の引き渡しとして扱うかを先に決めます。
再引き渡しと試行の確認
再引き渡しについても、単にMQL条件を満たしているだけでなく、返却理由を解消する変化が確認できたことを条件にします。
試行では、次が想定した行き先へ進むかを確認してください。
- 通常の引き渡し
- 対象外
- 情報不足
- 担当者不在
- 再引き渡し
滞留通知の条件は、合意した対応期限を過ぎても必要な対応の完了記録がない状態を目安にし、通知を受けた担当者が対応状況と次の行動を確認する運用にします。
自社では、次のどちらを検知したいのかを決め、それに対応する日時と状態を使います。
- 受け入れ判断待ち
- SQL移行後のフォロー漏れ
（出典：Use contact and company lifecycle stages）
未着手のタスクが残った場合は、次を確認します。
- 対象レコードとの対応
- 担当割り当て
- 判断材料
- 通知の重複
完了したタスクについても、受け入れ結果や次の行動が記録されているかを確認して、自動化の試行を終えます。
ライフサイクルステージが変更された際に関係者へ自動通知する設定も、引き渡しの運用に組み込みます。
ダッシュボードで共通KPIを見る
共通ダッシュボードには、次を並べます。
- リード獲得
- MQL
- 営業受け入れ
- 商談
- 受注
- 失注
比較する前に、各レポートの対象期間、集計対象、ステージの定義をそろえます。
次のレポートは分けます。
- その期間に発生した業務量を見るレポート ── 担当体制や滞留の確認に使います
- その期間にMQLとなったリードの後続結果を見るレポート ── MQL条件や施策の評価に使います
以下の画面は、リード獲得数を目標と実績で月次比較するレポートです。この差を見た後は、対象となるリードが営業受け入れや商談へ進んだかを確認します。
会議では、件数の差、未判断・返却・保留の内訳、該当レコードの理由の順に確認します。集客経路の構成が変わっている場合は、全体の比率だけで良し悪しを判断せず、同じ経路や対象条件で比較します。
- 理由が記録されていなければ ── 入力方法を見直します
- 理由が特定の条件に偏っていれば ── 定義や対応手順を見直します
差の説明と変更する箇所が対応していることを、レポートから次の行動へ進む条件にします。
ツールで解決できない範囲を残す
MQLの基準、例外案件の扱い、優先する市場、商談化の判断は、両部門で合意してからシステムへ反映します。まず同じリードをマーケティングと営業がそれぞれ判定し、結論と根拠を照合します。
判断が割れた場合は、原因に応じて次の処理を変えます。
- 必要な情報がない： 補完する項目と担当を決め、情報がそろうまで自動判定を保留します。
- 同じ情報の解釈が違う： 該当する例と該当しない例を文書に加え、両部門で再判定します。
- 対象市場や優先順位の方針が違う： 責任者が対象範囲を決め、適用条件を文書に残します。
- 顧客との個別事情がある： 例外を判断する責任者へ戻し、通常ルールとの違いを記録します。
同じ情報なら同じ結論になる範囲を自動化し、情報不足や例外は担当者へ戻す設計にします。試行後も例外が意図した担当者へ届き、その判断結果が記録されるかまで確認します。
SLAを形骸化させない運用をつくる
SLAは、記録された結果を使って調整する運用ルールです。日々の滞留への対応と、定義そのものの見直しは分けて進めます。
会議では、同じダッシュボードから課題を見つけ、該当レコードの理由まで確認し、変更後に何を比べるかを決めます。
会議ごとの役割を分ける
現場では次の行動を決め、責任者は繰り返し起きる問題から定義や期限を見直します。目標の変更は、パイプラインや受注・失注の傾向を踏まえて検討します。
| 会議（主な参加者） | 確認すること | 決めること |
|---|---|---|
| ファネルレビュー（マーケティング担当と営業担当） | 新規MQL、未対応、返却、商談化 | 次の行動と担当者 |
| SLAレビュー（両部門の責任者） | 受け入れ状況、対応状況、理由の偏り | 定義、期限、入力項目の修正 |
| 戦略すり合わせ（経営、マーケティング、営業） | パイプライン、受注、失注の傾向 | 目標と優先施策の見直し |
- 個別の未対応 ── 次の担当と行動を決めて進めます
- 同じ理由の返却が続く場合 ── 個別処理に加え、SLAの定義や引き渡し情報を見直します
- 現場で判断できる条件が文書にない場合 ── 責任者が条件を確定するまでの暫定的な相談先を置きます
会議の記録には、確認したレコード、変更する条件、担当者、適用開始、次回の比較方法を残します。「改善する」「営業へ共有する」だけで終えず、どの状態になれば対応完了かを記載します。
未達を原因と次の行動まで分解する
未達が見つかったら、対象の定義、通知、割り当て、入力項目、対応可能な量を順に確認します。例えば受け入れ率が下がった場合は、返却が増えたのか、未判断が増えたのかを切り分けます。
- 返却理由が対象属性に偏るなら ── MQL条件を見直します
- 返却理由が情報不足に偏るなら ── 引き渡し項目を見直します
- 未判断が特定の担当へ集中しているなら ── 割り当てと対応量を確認します
- 全体で未判断が増えた場合 ── 通知や共通の運用変更も調べます
変更の評価では、狙った指標に加えて、その先の工程も確認します。
- 受け入れ率が上がっても商談化につながらなければ ── 受け入れの条件を緩めただけの可能性があります
- 期限内の対応が増えても結果未記録が残るなら ── 初回対応の完了条件を点検します
比較対象と観察期間をそろえられない場合は、改善したと断定せず、途中経過として扱います。
変更後も同じ問題が残ったら、定義の変更を重ねる前に、想定した原因が該当レコードに当てはまっていたかを再確認します。
入力項目を最小限に保つ
項目を必須にする前に、その値が次工程の判断、レポート、顧客対応のどこで使われるかを確認します。
- 使い道があるのに入力されない場合 ── 入力する場面や選択肢が分かりにくくないかを調べます
- 使い道を説明できなければ ── 必須にする必要があるか見直します
選択肢で分類しきれない例外は、補足欄に理由を残します。
- 同じ補足が繰り返されるなら ── 新しい選択肢を追加するか、既存の定義を変えるかを検討します
- 「その他」が多い場合 ── その理由だけで選択肢を増やさず、その分類によって次の行動が変わるかを判断基準にします
ステージ移行時の必須項目は、次の担当者が確認すべき事項も示します。経験に頼っていた確認内容を項目としてそろえた後も、例外時に誰へ相談するかを併せて決めておきます。
定義と自動化を段階的に広げる
最初の範囲で引き渡しと結果返却が回ったら、対象施策や担当チームを広げます。追加前には、既存ルールとの重複、例外時の戻し先、担当者に表示される判断材料を確認します。
異なる施策へ広げるときの確認
対象企業や問い合わせの目的が異なる施策では、同じMQL条件を適用できるかを実際のリードで確認します。
条件を共通化できる部分と、個別の判断が必要な部分を分け、担当者が口頭の補足なしで処理できたら対象を広げます。
追加した対象を分けて確認する
新たな対象で返却理由や未対応が増えた場合は、追加した対象を分けて確認します。
- 既存範囲でも問題が起きているなら ── 共通ルールを見直します
- 追加範囲だけなら ── 対象条件や担当体制を見直します
引き渡し量を増やす前に、受け入れから結果返却まで追える状態を整えます。
よくある質問
SLAの項目や運用を決める際に迷いやすい点を、確認する情報、判断の分かれ目、次の行動の順に整理します。企業様によって最適な形は異なります。自社の商談プロセスと担当体制に照らして採用する項目を選び、実際のリードで判断が一致するかを確認してください。
SLAには何を盛り込めばよいですか？
MQLの入口条件と対象外条件、引き渡す情報、営業の対応期限、受け入れ可否、結果の記録方法、再育成の条件、共通KPIを盛り込みます。各項目について担当者と完了状態を決めます。
対応期限は、受け入れ判断と初回接触を分け、起点、終了条件、営業時間外の扱いを明記します。担当者不在や情報不足の場合の行き先も決め、通常時と例外時の処理をレコードで追えるようになったら試行します。
MQLの定義はどう合意すればよいですか？
過去の受注・失注に加え、返却、保留、未対応のリードを確認し、属性、行動、対象外条件を分けて基準を作ります。同じリードを両部門で判定し、結論と根拠を照合してください。
情報不足で判断できない場合は補完する項目を決め、同じ情報でも結論が違う場合は定義に具体例を加えます。試行後は、営業が返却したリードと、営業へ渡さずに後から相談へ進んだリードを確認し、引き渡しすぎと見落としの両方から条件を調整します。
営業が今すぐ対応しないリードはどう扱いますか？
まず、顧客側の検討条件が整っていないのか、営業側の担当体制で対応が止まっているのかを分けます。担当者不在や対応量が原因なら割り当てを見直し、リードの品質を理由に再育成へ戻さないようにします。
再育成する場合は、検討時期、予算条件、関係者、行動など、何が変われば再判定するかを残します。再引き渡しでは、前回の返却理由と今回確認できた変化を営業へ伝えます。対象外の場合は、対象条件そのものが変わったかを確認してから再判定します。
HubSpotを導入すれば部門連携は改善しますか？
HubSpotの項目、通知、タスク、レポートは、合意したSLAの運用に使えます。まずMQLとSQLの定義、入力責任、例外時の判断を両部門で決めます。次に、実際のリードで引き渡しと結果返却を確認し、繰り返し同じ判断ができる部分から機能へ反映します。
試行では通知の到達だけでなく、営業が判断材料を参照できるか、受け入れ・返却を記録できるか、情報不足や担当者不在が所定の行き先へ戻るかを確認します。判断が割れる部分は、条件を合意してから自動化します。
SLAの見直しは何を基準に行いますか？
営業の受け入れ状況、未対応の滞留、商談化、失注理由、記録漏れを、対象と定義、経過時間をそろえて確認します。未判断を除外せず、返却や保留と分けて見ることが必要です。
偏りがあれば該当レコードを見て、MQL条件、通知、担当割り当て、入力項目のどこに原因があるかを決めます。変更内容と適用開始を残し、その後も同じ方法で比較します。受け入れ率などの指標だけでなく、後続の商談化や記録状況も確認して、変更を続けるか見直すかを判断します。
まとめ
マーケ営業連携SLAは、リードの判定、引き渡し、営業の対応、結果返却を一つの運用につなぐ合意です。設計と見直しでは、次の順序を押さえてください。
- MQLとSQLは、入口条件、判断する担当、次の行動で定義します。情報不足と対象外を分けて扱います。
- 引き渡す情報と営業が返す結果を対にし、受け入れ判断と初回対応それぞれの期限、例外時の戻し先を決めます。
- 共通KPIは対象、集計単位、経過時間をそろえて比較し、未判断や期限を過ぎた未対応も確認します。
- 保留や失注の理由に応じて、再育成、資料、ヒアリング、判定条件のどこを変えるか決めます。
- 合意した判断を通常時と例外時で試し、結果返却まで追える範囲から項目と自動化を広げます。
まずは、現在のリード引き渡しを一枚の表にしてください。
- MQLの入口条件と対象外条件を書き出し、判断に必要な情報が不足する場合の担当を決めます。
- 営業が返す結果、理由、再判定の条件を決め、対応期限の起点と完了状態を明記します。
- CRM上の担当者、期限、入力欄、共通レポートへ反映し、引き渡しから結果返却まで確認します。
その表だけでは次の行動が決まらないリードが見つかったら、不足情報か判断条件のどちらを補うべきかを両部門で確認してください。判断と記録がそろった後に、期限や目標の妥当性を検討します。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
