MQL/SQL合意テンプレート：マーケティングと営業の間のコピー＆ペーストできる契約書

VP of Salesはリードが十分に条件を満たしていないと言います。CMOは営業がフォローアップをしていないと言います。両者はどちらも正しく、どちらも間違っています。そして「条件を満たしている」とは何を意味するのか、「フォローアップ」とは何を要求されるのかを定義した文書がないため、どちらも自分の主張を証明できません。

これはほとんどの収益組織で起きていることです。アライメントとは、会議の記憶として存在します。通常はQ1のキックオフで両チームがスライドデッキに頷き、その後それぞれ独自の定義で業務を続けていきます。

口頭での合意は、最初の目標未達で崩れてしまいます。商談が失注し、誰かが責任を追及しなければならない瞬間、7か月前に会議室で交わされた会話は何の価値もありません。必要なのは、MQLとは何か、SQLとは何か、そしてハンドオフの境界でそれぞれのチームが何を果たすべきかを定義した、両者が署名した文書です。

この記事では、そのためのテンプレートをすぐにコピーできる形で提供します。

重要データ：定義の不一致によるコスト

• マーケティングと営業のプロセスを正式に連携させた企業は、連携していない組織と比べて3年間で24%速い収益成長を実現しています（Aberdeen Group）。
• 同じ企業でも、マーケティングと営業チームがリードを表現するために使う用語の**87%**が両部門間で異なっています（SiriusDecisions）。
• 連携したチームは顧客維持率が36%高く、Win Rateが38%高くなります（MarketingProfs）。
• リード定義の合意文書を持つ組織は、MQLの異議を55%速く解決し、2四半期以内に却下されるMQLを20%減少させています（Demand Gen Report）。
• 書面によるMQL/SQL合意を持つ収益チームは、口頭の規範に頼るチームと比べて、スコアリングモデルを2.4倍高い頻度でキャリブレーションしています（Forresterのアライメント調査）。

MQL/SQL合意とは何か（そして何でないか）

MQL/SQL合意とは、マーケティングと営業の間で共有される語彙、基準、そしてリードハンドオフの境界における説明責任を定義した相互のコミットメントです。四半期ごとにレビューされ、両リーダーが署名します。

これは規律を強制する文書ではありません。マーケティングが低いAcceptance Rateを理由に営業を批判するためのものでもなく、営業がリードに着手する前にマーケティングに完璧さを要求するためのものでもありません。これは参照文書です。両チームが意見の相違がある場合にこれを参照し、状況が変わったときに更新します。

また、静的なポリシーでもありません。MQL/SQL合意はバージョン番号とレビューのケイデンスを持つ生きた文書であるべきです。共有ICPフレームワークは変わります。共同リードスコアリングモデルも変わります。チームも成長します。合意は昨年のキックオフ時点の世界ではなく、現在の現実を反映すべきです。

署名済みの合意を持つチームが持たないチームを上回る理由

調査は一貫しています：書面によるアライメントの成果物は測定可能な収益上の成果をもたらします。Wikipediaのサービスレベルアグリーメントの定義も同じ原則を強調しています。効果的なSLAは、当事者が定期的に会合し、説明責任のメカニズムを適用し、定期的な改定の余地を残すことを要求します。これはまさに、よく設計されたMQL/SQL合意が行うことです。しかし、そのメカニズムは魔法ではありません。それは「具体性」です。

両チームが65という最低スコア閾値（「だいたい高め」ではなく）、4営業時間という受け入れ時間（「合理的に速く」ではなく）、6項目の却下理由コードのリスト（「なぜかを教えてください」ではなく）に合意した場合、特定のリードに関するあらゆる会話が基準との比較になります。個々のリードについての議論は、基準が明確なため速やかに解決します。基準自体に関する議論は生産的です。それは責任転嫁ではなく、キャリブレーションを生み出します。

合意はまた、それを取り巻くツールとプロセスの基盤を作ります：ハンドオフ文書チェックリスト、リードルーティングルール、却下の分類体系、フィードバックループはすべて、基本的な定義が共有され、文書化されている場合に、より機能します。

Reworkの分析： 書面によるMQL/SQL合意を持つチームは、口頭の規範に頼るチームと比べて、リードの異議を55%速く解決しています（Demand Gen Reportの調査）。そのメカニズムは具体性です：両チームが65というスコア閾値（「だいたい高め」ではなく）と4営業時間という受け入れ時間（「合理的に速く」ではなく）に合意している場合、却下されたリードに関するあらゆる会話が、記憶についての議論ではなく、書面の基準との比較になります。合意はまた、他のあらゆるアライメントツール——ハンドオフ文書、ルーティングルール、却下コード、週次リード品質コール——を運用上一貫したものにする定義の基盤を作ります。これなしでは、それぞれのツールが異なる暗黙の前提の上に構築されます。Reworkの収益チーム構成の独自分析では、書面によるMQL/SQL合意の有無が、チームのリード品質レビューがスコアリングモデルの改善を生み出すか、責任転嫁のサイクルを生み出すかの最も強い予測因子です。

---

テンプレート — MQL/SQL合意

以下のセクションをコピーし、ブラケット内に組織の値を記入し、両リーダーに署名してもらいます。このテンプレートは、定義されたICPとCRMベースのリードワークフローを持つSMBおよびミッドマーケットのB2B SaaSチーム向けに設計されています。

---

MQL/SQL合意

組織： [会社名] 発効日： [日付] バージョン： 1.0 レビューケイデンス： 四半期ごと（次回レビュー：[日付＋90日]） 文書オーナー： [RevOpsリード または VP Revenue]

---

セクションA — 当事者と目的

本合意は以下の当事者によって締結されます：

• マーケティングチーム、[CMO / VP Marketing名]を代表として
• 営業チーム、[CRO / VP Sales名]を代表として
• Revenue Operations、証人およびプロセスオーナーとして、[RevOpsリード名]を代表として

目的： Marketing Qualified Lead（MQL）およびSales Qualified Lead（SQL）の共有定義を確立し、ハンドオフ境界における両チームの義務を定め、フィードバックとキャリブレーションのための体系的なプロセスを作成します。

本合意は、リード資格基準に関するそれ以前の口頭または非公式の合意をすべて置き換えます。

---

セクションB — MQLの定義と基準

リードは以下のすべての条件が満たされた場合にMQLステータスを達成します：

B.1 — 最低ICP適合基準（すべて必須）

B.2 — 最低スコア閾値

リードスコアは、フィット＋行動スコアの合計で**[例：65]**以上に達している必要があります。

フィットサブスコアの重み：[例：40%] 行動サブスコアの重み：[例：60%]

B.3 — 必須の行動トリガー

直近[例：30]日以内に、以下の行動シグナルの少なくとも1つが存在している必要があります：

• デモまたは無料トライアルをリクエストした
• 価格ページを[例：2回以上]訪問した
• 統合ページまたは技術ドキュメントページを閲覧した
• ライブWebinarまたは製品イベントに参加した
• 14日間のウィンドウ内でマーケティングメールを[例：3通以上]開封してクリックした
• 具体的な質問やユースケースを含むお問い合わせフォームを送信した

B.4 — MQLからの除外対象

以下のリードはスコアに関わらずMQLとして資格がありません：

• 既存顧客（CSMにルーティング）
• 進行中の商談がある連絡先（担当AEにルーティング）
• 競合他社（競合インテリジェンスキューにルーティング）
• 求職者、学生、または学術機関
• 個人メールドメイン（gmail.com、yahoo.comなど）、ただし会社名と電話番号が確認されている場合を除く
• 配信停止または連絡禁止としてフラグが立てられた連絡先

---

セクションC — SQLの定義と受け入れ基準

リードは営業担当者が以下のすべてを確認した場合にSQLステータスを達成します：

C.1 — 受け入れ基準

C.2 — 受け入れ時間

営業はハンドオフ通知から**[例：4]営業時間**以内に各MQLを受け入れまたは却下する必要があります。

Tier 1 MQL（デモリクエスト、価格ページ訪問）：[例：1]営業時間以内に受け入れまたは却下。

C.3 — 受け入れのログ記録方法

受け入れは、[CRM名]でリードステータスを「MQL — 保留中」から「SQL — 受け入れ済み」に変更することで記録されます。

担当者がセクションE.2の連絡持続性要件を使用して[例：3]営業日以内に連絡先に到達できない場合、リードステータスは「SQL — 無応答」に変更され、マーケティングに判断のために戻されます。

---

セクションD — ハンドオフ義務：マーケティング

マーケティングはすべてのMQLハンドオフで以下を提供することを約束します：

D.1 — データの完全性

D.2 — ハンドオフのタイミング

MQLトリガーからCRMへのハンドオフ：自動ルートの場合、[例：15]分以内。 営業時間内のルーティング：即時。 時間外のルーティング：翌営業日の[例：午前8時現地時間]まで。

D.3 — ルーティングトリガー

セクションBのMQL基準を満たすリードは、[ルーティングルール文書リンク]に記載されたルーティングルールに基づいて自動的にルーティングされます。

マーケティングは、1日に50件以上のMQLを生成することが予想されるキャンペーンについて、担当者のキャパシティ計画ができるよう、1営業日以内にRevOpsに通知します。

---

セクションE — ハンドオフ義務：営業

営業は受け取った各MQLに対して以下を約束します：

E.1 — ティア別の応答SLA

営業時間の定義：[例：リードのローカルタイムゾーンで月〜金の午前8時〜午後6時]。

E.2 — 連絡持続性要件

リードを「無応答」としてマークする前に、営業は最低限以下を実施する必要があります：

• [例：10]営業日にわたって[例：6]回の連絡試行
• 少なくとも[例：2]回の電話試行
• 少なくとも[例：3]回のメール試行
• 少なくとも[例：1]回のLinkedInメッセージまたはInMail（ミッドマーケットおよびエンタープライズリード向け）
• 試行は[例：3日以上]の異なる日に行う必要があります——1日に集中してはなりません

E.3 — 却下の要件

リードが却下された場合：

• 担当者は却下が処理される前に[CRM名]で理由コードを選択する必要があります
• 有効な理由コード：ICP不適合 | 予算シグナルなし | 連絡先不適切 | タイミング不適切 | データ品質の問題 | 既存顧客 / 進行中の商談
• コンテキストのためのオプションのフリーテキストメモを利用可能
• サイレント却下なし——処分なしでリードを放棄することはできません

E.4 — マーケティングへのフィードバック

• 週次リード品質コールに出席する（[会議リンクまたはカレンダー招待]）
• [Win/Lossフォームまたはslackチャンネル]を使用して1か月に[例：2]件のWin/Lossノートを提出する
• スコアの異常（高スコアだが一貫して資格審査に失敗するリード）を[例：3]営業日以内にRevOpsにフラグを立てる

---

セクションF — リサイクルルール

F.1 — 理由コード別の却下処分

F.2 — 再エントリ要件

リサイクルされたリードは以下の場合のみMQLとして再資格を得られます：

1. クーリング期間が過ぎている（最低[例：30]日；「ICP不適合」の場合は[例：90]日）
2. 新しい行動トリガーが発生した（却下前のアクティビティの継続ではない）
3. 2回以上リサイクルされたリードは、MQLキューに再エントリする前にマーケティングOpsによる人的レビューが必要

F.3 — ナーチャー再割り当てのタイムライン

マーケティングは、却下から[例：5]営業日以内にリサイクルされたリードを適切なナーチャートラックに入れることを約束します。

---

セクションG — レビューと修正

G.1 — 四半期レビュー

本合意は四半期ごとにレビューされます。レビュー会議のオーナー：[RevOpsリード]。 参加者：CMO/VP Marketing ＋ CRO/VP Sales ＋ RevOps。 アジェンダ：却下率の傾向、リサイクルコンバージョンデータ、スコアキャリブレーションの提案、定義の修正。

G.2 — 修正プロセス

いずれの当事者も、裏付けデータを添えてRevOpsオーナーに書面でのリクエストを提出することで修正を提案できます。修正は以下の両署名者が書面で承認した場合（メールでの確認も可）に批准されます。

変更はシステム更新を可能にするため、批准から[例：30]日後に発効します。

G.3 — バージョン管理

すべてのバージョンは[共有ドライブまたはwikiリンク]にアーカイブされます。現在のバージョンは常に[リンク]でアクセス可能です。

---

署名

---

テンプレートのカスタマイズ方法

上記のテンプレートは、3〜15名の担当者、定義されたICP、CRMとMAPスタックを持つ典型的なSMBまたはミッドマーケットのB2B SaaSチーム向けに書かれています。以下のように状況に合わせて調整してください：

単一製品・高速度チーム（50名以下）の場合： セクションBとCを簡略化します。サブスコアや「デモリクエスト」以外の行動トリガーは必要ないかもしれません。受け入れ時間をタイトに保ちます：すべてについて2時間以内。

マルチプロダクトチームの場合： セクションB.1に製品ラインフィールドを追加し、セクションD.3にルーティングメモを追加します。製品Aを専門とする担当者は、デフォルトで製品Bのリードを受け取るべきではありません。

長いサイクルのエンタープライズモーションを運営している場合： セクションC.2の受け入れ時間を緩めます（エンタープライズには4〜8時間で問題ありません）。セクションE.2の連絡持続性を強化します（15〜20日間で8〜12回の試行）。セクションFに「予算サイクル」のタイミング却下のためのナーチャー再エントリトリガーを追加します。

パートナーまたはチャネルチームがある場合： 別のルーティングと受け入れルールを持つパートナーソースのリードのためのセクションHを追加します。パートナーリードには標準ルールでカバーされない共同販売の義務が伴うことが多いです。

両チームに署名してもらう方法

ファシリテーションのアプローチは、文書と同じくらい重要です。2つのオプションがあります：

共同ワークショップ（初回合意に推奨）： 両リーダーとRevOpsによる2時間のセッション。各セクションを一緒に検討します。意見が合わない箇所（通常はスコア閾値、受け入れ時間、または却下コードの粒度）では、データを基に作業します。直近90日間のMQLと却下データを引き出し、数字が交渉の指針となるようにします。

非同期レッドライン（既存合意の更新に適切）： ドラフトを回覧し、各チームが自分のセクションをレッドラインし、対立する条件を30分の決定コールに持ち込みます。関係がすでに確立されている場合の四半期修正に有効です。

よくある交渉の争点

スコア閾値の争い。 マーケティングは60を希望します。営業は80を希望します。正直なところ、どちらの当事者も正解を知りません。データが必要です。直近90日間のMQLを引き出し、5ポイント単位でスコアバンドごとのコンバージョン率を計算します。コンバージョン率が意味のある変化を示す点で閾値は自然と落ち着きます。MQLスコア閾値の分析がこの交渉のための参考ベンチマークを提供します。

受け入れ時間の議論。 営業は1日中デモをしているため2時間以内に応答できないと言います。解決策はティア制です：Tier 1（デモリクエスト）は15分以内、Tier 2は2時間、Tier 3は1日。高インテントのリードに対する応答速度を犠牲にすることなく、低インテントのリードには現実的な時間を与えます。

却下理由の粒度。 営業は「悪いリード」という1つのフィールドを望みます。マーケティングは20のコードを望みます。実行可能な却下（タイミング、連絡先不適切）と実行不可能なもの（ICP不適合）を意味のある形で分離する5〜7のコードに落ち着かせます。7コードを超えると遵守率が下がります。リストが長いと担当者は慎重に選択しなくなります。

署名後：合意を実際に機能させる

署名済みの合意を、共有Wiki、CRMのナレッジベース、またはチームドライブ——両チームがオンボーディング文書からリンクする場所——に保管します。週次リード品質コールのアジェンダで参照します。

異議が生じた場合は、議論がエスカレートする前に文書を開いて関連セクションを見つけます。ほとんどの異議はテキストで解決します。誰かが頭の中で別バージョンの合意に基づいて行動しているだけです。

合意が陳腐化しているサインへの警戒

• 特定の理由コードの却下率が2か月連続で30%を超えてスパイクしている
• スコア閾値が一貫して目標を超えるか下回るMQL量を生み出している
• 担当者が定期的にMQLを受け入れてから連絡を試みることなく即座に「無応答」としてマークしている（受け入れ時間が実際のキャパシティに対して窮屈すぎるサイン）
• マーケティングがRevOpsに通知せずにキャンペーンやスコアリングモデルを変更している；MQL量を15%以上変化させるスコアリング変更は緊急レビューをトリガーすべきです

よくある質問

MQL/SQL合意を政治的な争いにせずに展開するにはどうすればよいですか？

コンプライアンス文書ではなく、キャリブレーションツールとして提示します。最も効果的な展開アプローチは、両リーダーとRevOpsによる2時間の共同ワークショップで、直近90日間のMQLと却下データを使用しながら各セクションを検討することです。チームが意見の相違を示す箇所——通常はスコア閾値と受け入れ時間——では、役職ではなくデータによって決定します。意見ではなくデータから交渉するチームは3〜4倍速く合意に達し、両者が同じ数字を見たため、より長く機能する合意を生み出します。

営業がMQL/SQL合意に署名しない場合はどうすればよいですか？

営業の抵抗は通常2つのことのいずれかを示します：スコア閾値が低すぎると感じている（営業がリードを信頼していない）、または受け入れ時間が現在の担当者キャパシティに対して非現実的に感じている。どちらもデータで解決できます。スコア閾値への抵抗には、5ポイント単位のスコアバンドごとのコンバージョン率を引き出します——閾値の議論が実証的になります。受け入れ時間への抵抗には、要件をティア制にします：デモリクエストは15分以内、それ以外はすべて4時間以内。ティア制SLAに署名する方が、包括的なSLAに署名するより簡単です。抵抗が続く場合は、営業に自分たちの閾値を裏付けデータとともに提案するよう求めます。根拠を構築するという行為が、対立から共同オーナーシップへとダイナミクスを変えることが多いです。

MQL/SQL合意はどのくらいの頻度で見直すべきですか？

四半期レビューが最低限です。ただし、3つのイベントが即座のサイクル外レビューをトリガーすべきです：MQL量を15%以上変化させるキャンペーンまたはスコアリングモデルの変更、2か月連続で特定の理由コードの却下率が30%を超えるスパイク、および重大なICP変更（新しいセグメントの追加、既存セグメントの優先度下げ）。四半期レビューは調整のためのものです。トリガーされるレビューは、ドリフトが1つのクォーターを逃す前に捕捉するためのものです。

MQL/SQL合意文書は誰が所有しますか？

RevOpsが文書、バージョン管理、レビューカレンダーを所有します。マーケティングと営業はそれぞれのセクションを所有します。RevOpsリードは、四半期レビューを運営し、修正リクエストを管理し、両者を合意されたケイデンスに従わせるプロセスオーナーです。中立的なオーナーがいなければ、合意はより多くのプレッシャー下にある側が一方的に更新します——これは共有参照としての目的を損ないます。

スコア閾値は実際にどこに設定すべきですか？

普遍的な閾値はありません。直近90日間のクローズドウォン案件を引き出し、それぞれをMQLハンドオフ時の元のリードスコアまでさかのぼります。コンバージョン率が全体平均を意味のある形で上回るスコアバンドを見つけます——その変曲点が経験的な閾値のアンカーです。90日未満のデータしかないチームは60から始め、最初の1か月後の却下率フィードバックに基づいて調整すべきです。却下率が35%を超える場合は閾値が低すぎることを示します。却下率が10%を下回る場合は閾値が緩すぎる可能性があります（条件を満たしていないリードが多く資格を得ています）。

さらに詳しく

• MQL to SQLハンドオフプロセス
• MQL定義フレームワーク
• SQLの定義と受け入れ
• ハンドオフ文書チェックリスト
• マーケティング・セールスSLAテンプレート
• マーケティング・セールスアライメント用語集