SLA設計と運用｜戦略設計から実装までの具体的なステップ

マーケティングが渡したリードをセールスが追わない。四半期末に「質が低いリードだった」「そもそも対応が遅かった」とどちらの責任かで議論になる。こうした摩擦の多くは、両部門の期待値が言語化されていないことから生まれます。SLA（サービスレベル合意）は、互いに何をどれだけ提供し合うかを数値と期限で文書化することで、この構造的な摩擦を解消する仕組みです。本記事では、SLAの設計から運用・見直しまでの具体的な手順を整理します。マーケティングとセールスの連携の全体像については、マーケティングとセールスの連携の全体像をあわせてご参照ください。

マーケ・セールス間のSLAとは何か

SLAはもともとIT・受託サービスの文脈で使われてきた概念ですが、BtoBのマーケ・セールス間に適用すると「互いに何をどれだけ提供し合うかを数値と期限で合意した文書」になります。抽象的な連携宣言との最大の違いは、測定できる・達成/未達が判断できるという点にあります。本セクションでは定義の確認と、IT文脈のSLAとの使い分けを整理します。

IT領域のSLAとの違い

IT・受託文脈のSLAは、システムの稼働率や問い合わせへの応答速度など、サービス提供側が守るべき基準を一方向で定めます。マーケ・セールス間のSLAはこれとは異なり、リードの「量・質・対応速度」を双方向で合意するものです。

重要なのは、マーケからセールスへの一方向の義務で終わらないことです。「マーケは月○件のMQLを渡す」という約束だけでなく、セールス側の対応義務（初回コンタクトまでの時間・活動記録のフィードバック・返却リードの理由記録など）も含めて合意することで、初めて機能する仕組みになります。

SLAが解決する具体的な問題

SLAがないまま連携を試みると、次のような問題が繰り返し発生します。

• リードの量と質に対する期待値のずれ（マーケは「十分渡している」、セールスは「使えるリードが来ない」）
• ハンドオフのタイミングのあいまいさ（どの状態のリードを渡すのかが明文化されていない）
• 月次レビューで責任の所在が不明確なまま議論が終わる

これらの構造的な原因については、マーケティングとセールスの連携の全体像で詳しく扱っています。本記事ではSLAを使ってこれらを解消する設計と運用の手順に絞って進めます。

SLAの構成要素

SLAを「なんとなく合意した文書」で終わらせないためには、6つの構成要素をすべて揃える必要があります。要素が欠けると「測定できない」「責任の所在が取れない」という状態になり、形骸化の入口になります。以下で各要素の意味と、実務で迷いやすいポイントを整理します。

双方の定量目標

マーケとセールスそれぞれが達成すべき数値目標を明記します。

• マーケ側：月間MQL数・MQLの商談化率の目標値・リード単価の上限目安
• セールス側：MQL受け取り後の初回コンタクトまでの時間（例：営業日2日以内）・商談化後の活動記録の提出タイミング

目標値は現状の実績数値を起点に設定することが基本です。根拠のない理想値では合意が取りにくく、設定できたとしても達成見込みのない数値になります。まず直近3〜6か月のデータを確認し、そこから現実的な改善幅を積み上げる順序が実務に合っています。

リードの定義と引き渡し条件

MQL（マーケティング適格リード）とSQL（セールス適格リード）の定義を、SLAの中で明文化します。引き渡し条件は「スコア○点以上かつ特定ページを閲覧済み」のように客観的な条件で書き、担当者の主観による判断を排除することが重要です。定義が属人化すると、担当者が変わるたびに基準がぶれます。

MQL・SQLの定義と引き渡し基準の詳細については、MQL/SQLの定義と引き渡し基準をご参照ください。

ハンドオフルールの設定

「誰が」「何をもって」「どのチャネルで」引き渡すかを手順として明文化します。ハンドオフを受けたセールスが「引き取れない理由」（例：予算なし・時期未定・担当部門が違う）を返却できるルートも設けることが重要です。返却されたリードについて、マーケ側がどの条件を満たしたら再ナーチャリングを終了して再度ハンドオフするかも合わせて決めておきます。このルートがないと、質の低いリードが繰り返しセールスに届き続ける状態になります。

対応タイムラインと期限

セールスがMQLに対して初回コンタクトを取るまでの時間を定めます。初回対応の速さと商談化率の関係は多くの調査で指摘されていますが、自社の商材・商習慣・リードの温度感によって現実的な期限は異なります。業界の統計をそのまま転用せず、自社の過去データ（初回コンタクト時間と商談化率の相関）を確認したうえで設定することを推奨します。

期限を超過した場合のエスカレーション先（マネージャーへの自動通知など）も明記しておくと、ルールが形骸化しにくくなります。

目標未達時の対応フロー

どちらかの数値が目標を下回った場合に何をするかを事前に決めます。具体的には、振り返りMTGの召集条件・原因分析のフォーマット・目標値を一時修正する権限者などです。「未達の責任を問う」ではなく「未達の原因を構造的に解析する」という設計思想を両部門で共有することが、SLAを懲罰的な文書にしないために重要です。

合意の更新・失効条件

SLAの有効期間と見直しのトリガーを明記します。見直しトリガーの例としては、四半期ごとの定期見直し・組織変更・新商材の追加・マーケ施策の大幅な方向転換などがあります。更新の手続きを決めておかないと、実態と乖離したSLAがそのまま残り続け、誰も参照しない文書になります。

SLAを設計する5つのステップ

SLAの設計で多くの組織がつまずくのは、完璧なSLAを一度に作ろうとする点にあります。現状データが揃っていない段階で理想値を決めようとすると、どの数値が適切かの議論が収束せず、合意形成が止まります。最初は「暫定版」として小さく合意し、データを蓄積しながら精度を上げていく進め方が、現実的かつ継続しやすい順序です。

ステップ1：現状の数値を棚卸しする

直近3〜6か月のリード数・MQL数・商談化率・受注率を、マーケとセールスが共通の定義で確認します。このステップで重要なのは「数値を揃えること」ではなく、「同じ定義で数値を見ているかどうかを確認すること」です。

実務では、マーケが「MQL」と呼んでいるリードの基準と、セールスが「対応したリード」として記録しているものの基準が一致していないケースが頻繁に発生します。この段階で定義のずれが発覚した場合、定義を合わせることがステップ1の実質的なゴールになります。数値の確認より定義の統一を優先してください。

ステップ2：目標値の合意（暫定値でよい）

現状数値から「改善後に目指すライン」を、両部門のマネージャーが合意します。初回は現状比10〜20%改善程度の現実的な暫定目標で十分です。

目標値に説得力を持たせるには、事業目標（四半期の受注目標・必要な商談数・必要なパイプライン金額）から逆算して必要なMQL数を算出する方法が有効です。「マーケが○件渡せばセールスが○件商談化し、受注目標が達成できる」という因果関係を数字で示せると、両部門が共通の文脈で目標値を議論できます。

ステップ3：MQL/SQLの定義をすり合わせる

セールスに「これまで受け取ったリードで対応しやすかったもの・しにくかったものの特徴」を整理してもらい、MQL/SQLの定義と引き渡し基準をボトムアップで構築します。「対応しにくいリード」の共通点（業種・企業規模・役職・閲覧コンテンツのパターンなど）を言語化することで、マーケ側がスコアリングや配信セグメントを修正する具体的な手がかりになります。

マーケ側は「セールスが出してくれた基準を現在の施策で実現できるか」を確認します。実現困難な基準がある場合は、施策の修正・スコアの見直し・ターゲティングの変更のいずれで対応するかを議論します。ここで無理な基準をそのまま採用すると、達成できないMQL定義になります。

ステップ4：ハンドオフと対応タイムラインを文書化する

手順を1枚のフローで可視化します。「MQLが発生→MAツールがセールスに通知→セールスが営業日○日以内に初回コンタクト→CRMに活動記録→SQL判定→商談化またはマーケへ返却」の流れを、担当部門と使用ツールを明記した形で整理します。

ツール間の連携（MAからSFA/CRMへのデータ移送のタイミング・セールスへの通知方法）も含めて明記します。「連携のつもりが手動で転記していた」という状態が発覚するのはこのステップが多く、SLAの設計と並行してツール連携の状態を確認することが重要です。

ステップ5：振り返りサイクルを先に決める

SLAを作った後の「いつ・誰が・何を確認するか」を、文書化の段階で一緒に決めます。振り返りの仕組みを後回しにすると、SLAは作成した時点で役割を終えた文書になります。

月次の連携定例を先にカレンダー登録し、SLAの数値確認をアジェンダの固定項目にすることで、運用が継続しやすくなります。定例を「SLA確認の場」として位置づけることが、形骸化を防ぐうえで最も確実な手段の一つです。連携定例会議の設計については、連携定例会議の設計で詳しく扱っています。

SLAの運用と見直しサイクル

SLAは作った時点ではなく、運用の中で「使われ続ける」状態になったときに機能します。多くの組織でSLAが形骸化する理由は、数値のモニタリング方法と振り返りの手順が決まっていないことにあります。設計段階と同等の重要性を持つのが、この運用フェーズです。

モニタリングすべき指標と確認頻度

SLAの運用では、マーケとセールスがそれぞれの指標を定期的に確認し、月次の連携定例で持ち寄ることが基本になります。

マーケ側がモニタリングすべき指標は次のとおりです。

• 月間MQL数（目標値との比較）
• MQLの商談化率の推移
• リード単価の推移

セールス側がモニタリングすべき指標は次のとおりです。

• 初回コンタクトまでの平均時間（SLAで定めた期限との比較）
• MQL返却率とその理由の分類（返却理由のパターンを把握する）
• 商談化後の受注率

両部門が共通で確認すべき指標は次のとおりです。

• パイプライン金額に占めるマーケ起点の比率
• ターゲットセグメント別の商談化率

週次でダッシュボードを確認し、月次の連携定例で両部門が数値を持ち寄る運用が基本サイクルになります。「確認している」と「議論できている」は異なるため、月次定例では数値の変化の原因まで議論できる場として設計することが重要です。

形骸化を防ぐチェックポイント

SLAの形骸化には、早期に発見できるサインがあります。以下の3つのサインが現れた場合の対処を事前に決めておくことで、崩壊を防ぎやすくなります。

サイン①：セールスがMQL返却率を記録しなくなる

返却の記録がなくなると、マーケ側はリードの質について改善のフィードバックを受けられなくなります。対処として、返却理由の入力をCRM上で商談登録の前提条件として設定し、未入力では次のステップに進めない設計にします。ルールではなく、ツールの構造で担保することが継続のコツです。

サイン②：月次定例でSLAの数値確認が口頭報告だけになる

「先月のMQL数は○件でした」と口頭で報告するだけでは、数値の変化の原因を共同で分析する場になりません。対処として、ダッシュボードのURLを定例のアジェンダに固定リンクとして記載し、画面共有しながら確認する運用に変えます。参照先が明確になると、議論の密度が変わります。

サイン③：目標値が四半期を超えても更新されていない

事業環境・組織・施策の変化とともにSLAの目標値もずれていきますが、更新の機会がないまま放置されると、誰も達成できない数値か逆に簡単すぎる数値が残ります。対処として、四半期末に「SLA更新MTG」を30分設定し、次四半期の暫定値を決めることをカレンダーに先に登録します。

SLAの定期見直しと改訂の判断基準

四半期ごとの定期見直しを標準サイクルとします。見直しの場では、達成・未達の事実確認だけでなく、「現在の目標値が事業目標と整合しているか」を確認することが本来の目的です。

定期サイクルを待たず臨時で改訂すべきタイミングとしては、次のような事象があります。

• 新商材の追加またはターゲットセグメントの変更
• 組織改編（担当者の変更・チーム構成の変更）
• マーケ施策の大幅な方向転換（チャネル変更・コンテンツ戦略の転換など）

改訂の際は、前回のSLAとの変更差分と変更の理由を記録します。この記録が蓄積されると、次回の見直し時に「どの変更が効果的だったか」を判断する材料になります。

SLA設計でよくある失敗と回避策

SLAを設計した組織の多くが同じポイントでつまずきます。失敗パターンを先に把握しておくことで、設計段階での手戻りと運用後の形骸化を防ぎやすくなります。SLAの理想的な姿を説明するにとどまらず、「なぜ崩れるか」の構造を以下で整理します。

マーケ側だけが義務を負う片方向SLAになる

「マーケは月○件のMQLをセールスに渡す」だけを定め、セールス側の対応義務を書かないケースが最も多い失敗パターンです。この状態では、セールスが「質が低い」とリードの受け取りを事実上拒否しても、マーケ側には反論の根拠がありません。

片方向SLAは合意書ではなく、マーケへの要求書になります。回避策として、セールス側の初回コンタクト期限・返却時の理由記録・活動フィードバックの提供を必ずSLAの構成要素として盛り込みます。双方向の義務を明文化することが、SLAを機能させる前提条件です。

根拠のない理想値を合意してしまう

現状データを確認せず、経営目標から逆算した「あるべき商談化率」をそのままSLAの目標値にするケースがあります。現状の商談化率が15%の組織が、目標から逆算して30%を初回SLAに設定しても、両部門とも達成の見込みのない目標になります。

回避策として、初回SLAは現状の実績数値を起点とした暫定値にし、3か月のデータ蓄積後に改訂することを文書に明記します。「暫定値＋改訂の約束」を最初から組み込むことで、過度な理想論を避けながら合意形成を進められます。

ツール連携が整っていないまま運用を始める

SLAで合意した数値をモニタリングするには、MAとSFA/CRMのデータが共通の基盤で参照できる状態が前提になります。データが別々のシステムに分散している場合、SLAの数値を確認するたびに手作業での突き合わせが発生し、振り返りの準備コストで定例が形骸化します。

回避策として、SLAの設計と並行して「モニタリングに必要な指標がどのシステムから取れるか・自動で取れるか・手動作業が残るか」を確認し、連携の優先順位を決めます。SFA/CRMとMAが連携していれば、商談化率やリードのステータス変化を自動で追えるため、振り返りの準備コストを大幅に下げられます。例えばMazrica SalesのようなSFA/CRMでは、マーケ起点の案件とセールスの活動状況を一つの画面で確認できるため、SLAのモニタリング体制を整えるうえでの手段の一例になります。

マーケとセールスが参照すべき共通指標の設計については、マーケ・セールスの共通KPI設計で詳しく扱っています。

まとめ：SLAを「生きたドキュメント」にするために

SLAは作ることが目的ではありません。数値が目標を下回ったときや、組織や施策が変わったときに、マーケとセールスの両部門が同じ文書を参照して議論できる状態を維持することが本来の目的です。

完璧なSLAを最初から作る必要はありません。最初の一歩として現実的なのは、「直近3か月のMQL数と商談化率を、マーケとセールスが同じ定義で確認する」という作業です。この小さな確認から、定義のずれ・期待値のずれ・データの所在が明らかになり、SLAの設計に必要な素材が揃い始めます。

マーケティングとセールスの連携を体系的に整理したい場合は、マーケティングとセールスの連携の全体像をご参照ください。

よくある質問

Q SLAとKPIは何が違いますか？

A

KPIは各部門が目指す指標そのものです。SLAは「その指標を達成するために互いに何をするか」を双方向で定めた合意書です。KPIが目標値であるのに対して、SLAはその達成のための相互の責任と手順を定めた取り決めです。KPIだけでは「マーケが目標を達成してもセールスが追わない」という状態が起きますが、SLAはその責任の境界を明文化することで解消します。

Q SLAは何人くらいの組織から必要ですか？

A

規模よりも役割分担の発生が目安になります。マーケティングとセールスが別の担当者または別のチームに分かれた時点で、暫定版を作っておくことを推奨します。1〜2人が兼任している体制では不要ですが、役割分担が発生した段階で「渡す側と受け取る側」の期待値のずれが生まれ始めるため、早期に文書化しておくことが後の摩擦を防ぐうえで有効です。

Q SLAを作ったが誰も守らない。どうすればよいですか？

A

守られない原因は主に3つに分類できます。①数値を確認する場所がない（ダッシュボードが整備されていない）、②定期的に確認する場がない（連携定例が設定されていない）、③目標値が現状と乖離している（暫定値への修正が必要）。まずどれが原因かを特定し、一つずつ対処します。最も着手しやすいのは②で、月次定例のカレンダー登録とアジェンダへのSLA確認の追加は即日できます。

Q MQLの定義がまだ決まっていないがSLAは作れますか？

A

作れます。まず「セールスが対応したいリードの条件」を言語化することから始め、その暫定的な定義をSLAに入れておく方法を推奨します。「MQLの定義が決まってからSLAを作る」と待ち続けると、どちらも進まない状態になりがちです。定義の詳細化はSLAの運用と並行して進める前提で、最初は粗くても明文化することが重要です。

Q SLAはどのくらいの頻度で見直すべきですか？

A

標準は四半期ごとです。組織変更・新商材の追加・ターゲットセグメントの変更・マーケ施策の大幅な転換のタイミングでは、定期サイクルを待たず臨時で改訂します。改訂の際は変更差分と変更理由を記録しておくと、次回の見直し時の判断材料になります。「見直す」というよりも「データが更新されたら数値を調整する」という感覚で運用すると、形骸化しにくくなります。