営業とマーケ連携をKPIとSLAで設計する

営業とマーケティングの連携は、共通KPIを最終成果から逆算して絞り、有効問い合わせとMQL・SQLを同じ言葉で定義した後、SLAで引き渡し条件・初回対応期限・戻し条件を決める順番で設計します。問い合わせ数や商談数が見えていても、部門ごとに判定基準が違えば、改善すべき場所は特定できません。30日間で現状確認、共通定義の合意、SLAの試行、計測確認まで進め、週次では初動、月次では商談化までを見直す流れです。

この記事では、営業とマーケの数字が噛み合わず、どこから直すべきか決められない経営者、事業責任者、営業・マーケ責任者、Web担当者に向けて、合意の順番と記録項目を整理します。読後は、問い合わせから受注までの最初の詰まりを選び、定義・期限・担当・記録方法を決められます。

制作前に確認する要点は次のとおりです。

• 共通KPIは最終成果から逆算して絞る
• 有効問い合わせとMQL・SQLを同じ言葉で定義する
• SLAには引き渡し条件、期限、戻し条件を含める
• 30日で現状確認、合意、試行、計測確認まで進める

最初に結論：KPIを絞ってからSLAで引き渡しを決める

KPIは目標達成の途中経過を測る指標、SLAは部門間で引き渡し条件や対応水準を合意する運用ルールです。営業とマーケの連携では、先にKPIで「どの段階を共通して見るか」を決め、その後にSLAで「誰が、どの条件で、いつまでに動くか」を固定します。

順番を逆にすると、期限を決めても営業へ渡す対象が揃いません。KPIだけを増やしても、受領、初回対応、戻し理由が記録されなければ、数字を見て終わるだけです。

最初に合意する範囲は、次の4点で足ります。

1. 受注や粗利など、自社が最終成果とする指標
2. 有効問い合わせ、MQL、SQL、商談、受注の定義
3. 営業への引き渡し条件、受領期限、初回対応期限、戻し条件
4. 週次と月次で確認する数字、更新担当、意思決定者

ツールや会議は、この4点を運用する手段です。定義と責任の境目を決める前に増やすと、同じ不一致が新しい画面でも繰り返されます。

連携不全を数字と運用のどちらで見分けるか

最初の作業は、問い合わせから受注までの各段階を、同じ期間・同じ対象で一列に並べることです。件数が落ちている場所だけでなく、記録が欠けている場所も確認します。記録がない段階では、成果が悪いのか、運用されていないのかを分けて判断できません。

5分で確認するチェックリスト

• 問い合わせ総数と、有効・対象外・重複・迷惑送信の内訳が一致しているか
• 有効問い合わせ、MQL、営業受領、SQL、商談、受注を同じ対象期間で追えるか
• 受信時刻、引き渡し時刻、営業受領時刻、初回対応時刻が同じ案件に紐づいているか
• 営業が受け取らなかった案件やマーケへ戻した案件に、選択式の理由が残っているか
• フォーム送信、通知、顧客管理への登録、アクセス解析の件数に説明できない差がないか

この確認で見つかる詰まりは、大きく4種類です。フォーム送信後の通知漏れや登録漏れは「計測・連携の不良」、部門ごとに有効判定が違う状態は「定義の不一致」です。受領後の未対応や期限超過は、機会損失を生み得る「初動の遅れ」に当たります。初動が守られていても商談へ進まないなら、「対象条件や営業プロセスの見直し」が候補です。

数字の落ち込みより前に未記録の段階がある場合は、施策の良し悪しを評価する前に記録を直します。すべて記録できている場合は、段階間の率が最初に悪化している場所を改善対象にします。この切り分けにより、「問い合わせを増やすべきか」「営業対応を変えるべきか」を同じ会議で混同せずに済みます。

共通KPIを最終成果から逆算する

共通KPIは、マーケの活動量から積み上げるのではなく、最終成果から逆向きに選びます。受注を最終成果とするなら、受注の直前に商談、その前にSQL、営業受領、MQL、有効問い合わせ、問い合わせという流れです。自社の販売工程に存在しない段階を無理に増やす必要はありません。

設計は次の順で進めます。

1. 最終成果を決める 受注件数、売上、粗利など、経営判断に使う成果を一つ選び、対象事業と集計期間を固定します。
2. 成果までの段階を並べる 問い合わせ、有効問い合わせ、MQL、営業受領、SQL、商談、受注のうち、残すのは自社で実際に判定できる段階だけです。
3. 段階ごとの件数と移行率を決める 有効問い合わせ率は「有効問い合わせ数÷問い合わせ総数」、営業受領率は「営業受領数÷MQL数」のように、分母と分子を文章で残します。商談化率の分母を営業受領とするのかSQLとするのかも統一します。
4. 担当とデータの出どころを固定する マーケが更新する数字、営業が更新する数字、システムから自動取得する数字を分け、最終的にどの画面や台帳を正とするか決めます。

見る候補は、有効問い合わせ数・率、MQL数、営業受領率、初回対応期限内率、商談化率、受注率です。改善対象と、その前後を判断できる範囲に絞るのが要点です。

定義を変更するときは、変更日と旧定義を残します。途中で「有効問い合わせ」の条件を変えた場合、変更前後を同じ基準の推移として扱うと、改善したように見えても判定基準が変わっただけということが起こります。

SLAで引き渡し条件・期限・戻し先を決める

ここでいうSLAは、顧客向けのサービス保証ではなく、マーケから営業へ案件を渡す際の部門間合意です。対象となる案件、受領判断の期限、初回対応の完了条件、追わない場合の戻し先までを一つの運用として定めます。

MQLはMarketing Qualified Leadの略で、マーケが共通条件を満たすと判定した見込み客です。SQLはSales Qualified Leadの略で、営業が情報を確認し、具体的に追う対象と判定した見込み客を指します。MQLを営業へ渡した時点で自動的にSQLとせず、営業受領とSQL判定を分けると、どこで止まったかが見えます。

期限は「いつから、何をしたら完了か」まで書く

「早めに連絡する」では、担当者ごとの判断になります。受信時刻を起点とするのか、営業が受領した時刻を起点とするのかを決め、電話発信、メール送信、顧客との接続のどれを初回対応完了とするかも揃えます。営業時間外や休業日に受信した案件の扱いも、SLAの合意事項です。

営業が追わない案件は、未対応のまま終わらせません。対象外、重複、連絡先不備、時期未定、条件不一致など、自社で分析に使う戻し理由を選択式にし、育成対象・終了・再確認のいずれへ進めるかを記録します。

この表で表現が揃っていない行や、期限・記録欄が空いている行が、最初の合意候補です。すべてを一度に精緻化せず、最初の詰まりに関係する行から運用を始めます。

30日で試す営業・マーケ連携の設計手順

30日で完成形を作るのではなく、合意した定義が案件で機能するかを確かめます。対象事業や問い合わせ種別を一つに絞れば、現在のツールでも試行できます。

進行順は次の4段階です。

1. 現状確認：問い合わせから受注までの件数、定義、画面、担当を並べ、最初の未記録または急減箇所を選ぶ
2. 共通定義：有効問い合わせ、MQL、営業受領、SQL、商談の判定文と分母・分子を決める
3. SLA合意：引き渡し条件、受領期限、初回対応期限、戻し理由、例外時の責任者を決める
4. 試行と計測確認：実案件とテスト送信で運用し、記録漏れ、通知漏れ、判断のばらつきを確認する

30日目には、「同じ案件を同じ定義で判定できたか」「期限を守れなかった理由が残ったか」を確認します。迷いが多かった項目だけを修正し、問題なく運用できた項目は増やしません。

フォーム・計測・営業データをつなぐ要件

連携設計をWebサイトへ反映するときは、フォーム単体ではなく、入力、識別、計測、権限、営業結果の返却までを一つの要件にします。見た目や必須項目だけを決めても、営業側で同じ案件を特定できなければ、商談や受注とのつながりを検証できません。

フォームは判定に使う最小項目へ絞る

入力項目は、連絡に使う情報、重複を見分ける情報、MQL判定に使う情報の3分類です。各項目について、必須・任意、選択肢、入力形式、営業画面での保存先を決めます。送信率への影響が読めない項目は、フォームで必須にせず、初回対応で回収する方法も比較します。

フォーム種別、送信ページ、受信時刻、案件IDは、利用者が入力しなくても記録できる設計にします。自動返信、社内通知、顧客管理への登録のいずれかが失敗したときに、誰がどの画面で気づけるかも受け入れ確認の対象です。

流入情報と案件を結び付ける

Google Analyticsの公式資料では、URLにUTMパラメータを付け、流入をもたらしたキャンペーンを識別する方法が案内されています。広告、メール、SNSなどで命名規則を揃え、フォーム側には流入元・メディア・キャンペーン、送信ページ、フォーム種別を引き継ぐ要件を置きます。

ただし、アクセス解析上の数値と営業案件を無条件に同一人物として結び付けるのではなく、自社の利用目的、同意や告知、使用するツールの仕様の確認が必要です。フォームで取得した個人情報は、利用目的、保存先、閲覧権限、保管期間、削除方法、委託先の取り扱いまで運用として決めます。個人情報保護委員会の通則編は、利用目的の特定・通知または公表、データの正確性、安全管理措置、従業者・委託先の監督を個人情報取扱事業者の義務として整理しています。

営業結果をマーケへ返す

営業画面には、受領可否、SQL判定、初回対応日、商談化、失注理由、受注結果を保存します。マーケ側へ戻す際は個人情報を広く共有するのではなく、改善判断に必要なステータス、日付、理由コードを返します。これにより、流入数だけでなく、どの施策が有効問い合わせや商談へ進んだかを確認可能です。

権限は「閲覧できる人」「編集できる人」「出力できる人」「設定を変更できる人」に分け、退職・異動・委託終了時の変更手順も決めます。IPAの「中小企業の情報セキュリティ対策ガイドライン」第4.0版は、経営者が認識すべき指針と社内で対策を実践する手順を、中小企業や小規模事業者向けにまとめています。Webサイトを安全に運用する観点も含まれるため、改修要件と運用体制を切り離さず確認する資料として使えます。

流入、再訪、フォーム、ツール活用を含めて入口から見直す場合は、ウェブサイトのリード獲得戦略で押さえるべきポイントも参考資料です。この記事のKPI・SLA設計と合わせると、集客施策から営業結果までのどこをWebサイトの要件に含めるか整理しやすくなります。

週次と月次で見る数字を分ける

週次会議と月次会議で同じ一覧を眺めると、初動の修正と投資判断が混ざります。週次は、いま発生している取りこぼしを止める場。月次は、一定期間の結果から、定義、施策、営業プロセス、予算配分を変えるか決める場です。

週次で確認するのは、新規の有効問い合わせ数、引き渡し未完了件数、営業受領期限内率、初回対応期限内率、戻し理由の未記録、フォームや通知のエラーです。期限超過があれば、担当者を責めるのではなく、担当割り当て、営業時間、通知方法、案件集中など、守れなかった条件を記録します。会議の終わりには、修正する項目、担当、期限を一つずつ残します。

月次では、MQLから営業受領、SQL、商談、受注までの移行率を見ます。チャネル別の商談・受注結果、失注理由の偏り、定義変更の影響を確認したうえで、フォーム項目、コンテンツ、広告、営業ヒアリングのどこへ手を入れるかが判断対象です。

定義そのものを変える場合は、週次の個別案件判断だけで決めず、月次で責任者が承認します。変更日、変更理由、影響する指標を残しておけば、過去との比較ができなくなる事故を避けられます。

まとめ：最初の詰まりを1つ選んで合意を始める

営業とマーケの連携を変える起点は、KPIの数やツールの多さではありません。問い合わせから受注までを一列に並べ、最初に記録が欠ける場所、または段階間の移行が止まる場所を一つ選ぶことです。

選んだ箇所について、判定文、担当、期限、記録項目を関係者で確認してください。有効問い合わせの定義が違うなら定義から、営業受領後の放置があるなら初回対応期限から、フォームと営業データがつながらないなら案件IDと結果返却から始めます。30日間の試行で判断のばらつきと記録漏れを確認し、週次で初動、月次で商談化と投資判断を更新すれば、改善会議を具体的な意思決定へ変えられます。

社内で担う範囲と外部へ依頼する範囲を検討する際は、集客支援やアクセス解析を含むマーケティング支援の内容も判断材料です。フォーム改修だけで足りるのか、計測、定義、SLA、改善運用まで要件化するのかを切り分ける材料になります。

参考資料一覧

• URL 生成ツール: カスタム URL でキャンペーン データを収集する（Google Analytics ヘルプ。UTMパラメータによるキャンペーン識別の説明）
• 個人情報の保護に関する法律についてのガイドライン（通則編）（個人情報保護委員会、平成28年11月、令和8年6月一部改正）
• 中小企業の情報セキュリティ対策ガイドライン（IPA、第4.0版は2026年3月27日公開、ページ最終更新2026年7月3日。個人事業主・小規模事業者を含む中小企業向け）