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

KPI（Key Performance Indicator）＝目標達成度を測るための重要指標。と、SLA（Service Level Agreement）＝部門間で引き渡し基準と対応期限を合意する取り決め。を揃える目的は、会議を増やすことではなく、意思決定の材料を同じ前提にそろえることです。特にリニューアルや制作ベンダー変更の局面は、フォーム・計測・運用ルールを再設計できるため、連携を整えるタイミングとして相性が良いです。

営業とマーケが噛み合わないと何が起きるか（経営インパクトの整理）

分断が続くと、経営上のダメージは主に「機会損失」と「隠れコスト」に分かれます。リード＝将来顧客になり得る見込み客情報。が増えても、営業が追えない（追わない）状態なら、広告費や制作費は売上に結び付きにくくなります。

機会損失として表れるもの

取りこぼし：初回対応が遅れ、比較検討の土俵に乗れない
失注理由が残らず、改善の仮説が積み上がらない
受注までの道筋が見えず、チャネル投資の配分が感覚に寄る

隠れコストとして表れるもの

会議で数字の出どころを確認する時間が増える
「量」か「質」かの対立で、施策の優先順位が決まらない
ツール追加や運用ルールの後付けが続き、TCO（Total Cost of Ownership）＝導入後の運用費も含めた総コスト。が膨らむ

さらに見落とされがちなのが、サイト改修と連携改善を別物として扱うリスクです。フォームの仕様変更や計測の漏れが起きると、施策の良し悪し以前に「数字が信用されない」状態になり、改善が止まります。ベンダー乗り換え時は、移行期間に問い合わせ導線が不安定になりやすいため、経営としては売上機会の毀損を避ける観点で優先順位を付ける必要があります。

連携の土台づくり：目的・用語・データの「共通言語」を揃える

連携は精神論では続きません。目的と定義を先に決め、次に運用へ落とす順番が現実的です。KGI（Key Goal Indicator）＝最終目標の達成度を示す指標。を最初に置き、「どの事業で、どの売り方を伸ばすか」を明確にします。ここが曖昧だと、マーケは反応数、営業は受注数だけを見て会話が噛み合わなくなります。

合意すべき共通言語（最小セット）

目的：対象事業、重点商材、想定単価、狙う業種や規模
用語：有効問い合わせ、商談、失注理由、対応完了の定義
データ：どのシステムを正とし、必須入力を何にするか
会議体：誰が指標を更新し、どこで改善判断をするか

情報システム責任者の観点では「後から連携できるデータ設計」になっているかが重要です。例えば、会社名の表記ゆれ、部署名、役職、メールドメインの扱いがバラバラだと、集計や重複排除に手間がかかります。逆に、入力項目を増やしすぎると現場が埋めなくなり、データが空欄だらけになります。ここは、営業・マーケ・情シスで「最低限、ここだけは揃える」を合意し、運用負荷と分析精度のバランスを取ります。

加えて、意思決定の責任者を決めないと、定義は徐々に崩れます。部門横断の指標は、誰が最終判断するか（事業責任者など）を明確にし、変更するときは「いつから」「何が変わるか」を残します。これだけで、数字の解釈違いによる摩擦が減ります。

KPI設計の手順：最終成果から逆算して指標を絞る

KPIは増やすほど管理が難しくなります。ファネル＝認知から受注までの段階を漏斗状に整理した考え方。で分解し、各段階で「次に進んだか」を測れる指標に絞るのが実務に向きます。ポイントは、マーケの指標だけでなく、営業側の行動指標（初回対応、商談設定、失注理由の記録）も同じボードに載せることです。責任の切れ目が見えると、改善が前に進みます。

KPIを決める3ステップ

最終成果から逆算：KGIに直結する要因を洗い出す
定義を文章にする：誰が見ても同じ判定になる条件を決める
見る頻度を決める：週次で動かす指標と、月次で見る指標を分ける

ここで意識したいのは「入口の数値だけで勝った気にならない」ことです。閲覧数や問い合わせ件数が増えても、初回対応や商談化で落ちていれば、経営インパクトは小さくなります。だからこそ、営業側のKPIも同じ粒度で並べます。

ファネル段階	指標	定義（計測条件）	主担当
流入	重点ページ閲覧数	主要導線ページの閲覧回数	マーケ
反応	問い合わせ件数	フォーム送信完了数	マーケ
反応	有効問い合わせ率	対象外を除いた問い合わせ割合	マーケ
初動	初回対応時間	受信から初回連絡までの時間	営業
商談	商談化率	商談数 ÷ 有効問い合わせ数	営業
受注	受注率	受注数 ÷ 商談数	営業

この表を起点に、次の2点を詰めます。

有効問い合わせの判定基準：対象業種、規模、用途、導入時期などを文章で定義する
初回対応の扱い：連絡手段（電話、メールなど）と、到達の定義を揃える

定義が揃ったら、次はSLAで「どの状態になったら営業へ渡すか」「どれくらいの時間で対応するか」を合意し、運用を安定させます。ここが決まると、サイト改善や施策の優先順位も、経営目線で説明しやすくなります。

SLAの作り方：引き渡し基準と対応期限で摩擦を減らす

SLAを置く狙いは「良い見込み客かどうか」の議論を減らし、次のアクションを迷わず決められる状態をつくることです。ポイントは、品質（どんな状態なら渡すか）と速度（どれくらいで対応するか）を、同じ紙に並べて合意することにあります。

まず決めるのは「段階」の言葉と判定条件

MQL（Marketing Qualified Lead）＝マーケが有望と判定した見込み客。
SQL（Sales Qualified Lead）＝営業が追う価値があると判定した見込み客。

MQLとSQLの境界が曖昧だと、マーケは「渡した」、営業は「追えない」で止まります。ここでは、理想論より運用できる線引きを優先します。たとえば「対象外の明確化（業種・規模・用途）」と「温度感の判定（導入時期・予算の有無）」を最小セットとして文章化し、例外を減らします。

SLAは「入力を増やす」のではなく「戻し先」を作る

SLAは、渡した後のルールも含めて意味があります。営業が追えない場合に、どの条件でマーケへ戻すか（育成に回すか）を決めておくと、対立が減り、学習が進みます。育成（ナーチャリング）＝見込み客の検討度を高めるために情報提供を継続する運用。の戻し先があるだけで、営業は安心して優先順位を付けられます。

SLA合意シート（たたき台）

下の表は、部門間で責任の境目を見える化するためのテンプレートです。自社の実態に合わせて項目を削るほうが運用に乗りやすくなります。

項目	マーケ責任	営業責任	合意基準（期限・品質）
有効問い合わせの定義	対象外条件を明文化し判定する	定義に不足があれば理由を返す	定義は文書化し月次で見直し
引き渡し条件（MQL）	条件を満たすものだけ渡す	受領可否をステータスで返す	受領判定は1営業日以内
初回対応	連絡先不備のチェック	初回連絡と結果の記録	初回連絡は当日〜翌営業日
戻し（育成へ）	育成シナリオと配信設計	戻し理由をコードで記録	戻し理由は選択式で統一
失注理由	分類を整備し分析する	失注理由を記録する	記録率と分類精度を月次確認

SLAで揉めやすいのは「期限が守れない」「理由が残らない」の2点です。期限は理想値ではなく、現場が回る前提（担当人数、受電体制、繁忙期）で設定します。理由は自由記述にすると集計できないため、選択式のコードに寄せ、必要なら補足欄で運用します。

体制設計：役割分担・会議体・運用ルールを決め切る

KPIとSLAは、作って終わりではなく、更新し続けて初めて資産になります。そこで必要なのが、運用を担う体制設計です。おすすめは、役割を「意思決定」「運用」「分析」に分けて責任を固定することです。

役割分担はRACIで決める

RACI＝業務ごとに責任の種類（実行・説明・相談・報告）を整理する枠組み。を使うと、部門横断でも曖昧さが減ります。最低限、次の席を用意します。

事業責任者：KGIと投資配分の最終判断
営業責任者：対応品質と商談プロセスの改善
マーケ責任者：流入〜有効問い合わせの改善と運用
情報システム責任者：システム連携と権限、データ保全
Web担当：サイト改修の優先順位と実装管理
PM（Project Manager）＝関係者のタスクと期限を管理し、意思決定を前に進める役割。：要件定義から運用定着までの推進

会議体は「週次で動かす」「月次で判断する」に分ける

週次は、SLAの遵守（初回対応、受領判定、戻し理由）と、ボトルネックの特定に絞ります。月次は、商談化率や受注率を見ながら、施策とサイト改修の優先順位を見直します。ここで大切なのは、各指標のオーナーが「次に何をするか」を決めて持ち帰る形にすることです。議論が抽象化する場合は、指標の定義とデータの出どころへ戻ると収束しやすくなります。

Webと営業データをつなぐ要件：フォーム・計測・データ連携の設計ポイント

連携の実装は、サイトの入口（フォーム）から始まります。コンバージョン＝サイト上で成果とみなす行動（問い合わせ、資料請求など）。を正しく計測し、営業側の結果（商談・受注）につなげるために、要件を3層で整理します。

1 フォーム要件：入力項目は「識別」「判定」「連絡」の3種類に絞る

識別：会社名、メール、電話など重複を判定できる情報
判定：業種、規模、検討状況など有効判定に必要な情報
連絡：担当者名、希望連絡手段など一次対応に必要な情報

入力項目を増やすと質は上がりますが、送信率が下がることがあります。そこで、最初は最小セットに絞り、追加情報は後工程（自動返信や初回ヒアリング）で回収する設計が現実的です。

2 計測要件：流入経路と行動を「同じID」で追えるようにする

UTMパラメータ＝流入元などをURLに付与して計測するための識別子。を運用ルール化すると、広告・メール・SNSなどの比較がしやすくなります。さらに、フォーム送信の前後で「どのページを見て、どんな導線で到達したか」が分かると、サイト改善の打ち手が具体化します。

3 連携要件：営業側の結果を戻せる設計にする

MA（Marketing Automation）＝見込み客への施策を自動化・可視化する仕組み。や、CRM（Customer Relationship Management）＝顧客情報と接点履歴を一元管理する仕組み。にデータを送るだけでは、学習が進みません。商談化・失注理由などの結果が戻ってくる設計にして、KPIの因果を確認できる状態を目指します。加えて、個人情報を扱うため、権限設計と保管期間、取り扱い手順を文書で揃えます。

費用と投資判断：初期と運用の総コスト、優先順位、段階導入

投資判断では、制作費だけでなく運用まで含めた総コストを分解し、どこに手当てすると効果が出やすいかを見ます。よくある費用の塊は、(1)要件定義と設計、(2)サイト改修と計測実装、(3)連携やレポートの仕組み、(4)運用改善の人件費です。最初から全部を高い精度で揃えるより、売上機会に直結する箇所（フォーム、初回対応、商談化の可視化）から段階的に整えるほうが失敗しにくくなります。

段階導入の考え方：いきなり全部を整えない

経営として意思決定しやすいのは、段階ごとに「達成条件」を置く方法です。たとえば、最初の段階はSLAで初動の取りこぼしを減らし、次にKPIで商談化までの改善を回し、最後にデータ連携を深くして投資配分を最適化します。

段階1（止血）：フォーム送信の計測、初回対応時間、受領判定（営業が追う／戻す）までを安定させる
段階2（改善）：有効問い合わせ率、商談化率、失注理由の記録率を運用に乗せ、サイト改修の優先順位を付ける
段階3（最適化）：施策別の商談・受注まで追い、チャネル別の投資判断に使える状態へ近づける

この順番にすると、費用対効果の説明が「次の段階へ進める根拠」になり、関係者の合意形成がしやすくなります。

リスクと失敗パターン：形骸化・データ不整合・現場負荷・乗り換え事故

連携の取り組みは、設計より運用で崩れます。代表的な失敗パターンと、先回りの対策を整理します。

失敗パターン1：定義が曖昧で、現場が判断できない

「有効」の判定が人により変わると、数字が信用されなくなります。対策は、定義を文章化し、例外を減らすことです。加えて、定義の変更は「いつから適用か」を残し、過去データと混ぜない運用にします。

失敗パターン2：入力負荷が高く、更新されない

入力項目やステータスが多いほど、運用は止まりやすくなります。対策は、SLAで必要な項目だけを必須にし、分析用の項目は段階的に増やすことです。情シス側は、権限と必須項目の設計を早めに固めると再設計が減ります。

失敗パターン3：データがつながらず、施策評価が分断する

フォーム、計測、営業側の結果が別々に管理されると、「何が効いたか」が見えません。対策は、誰がどのデータを正とするかを決め、レポートの出どころを固定することです。ダッシュボード＝複数の指標を一画面に集約して可視化する画面。は、見る人と判断内容を決めてから作ります。

失敗パターン4：ベンダー乗り換えで問い合わせ導線が壊れる

移行時の事故は、売上機会の毀損につながります。対策は、UAT（User Acceptance Test）＝利用者目線で要件どおりに動くか確認する受け入れテスト。を計画に組み込み、フォーム送信から通知、登録、計測までを「通し」で確認することです。加えて、公開直後は監視項目（送信数、エラー、通知遅延）を決め、早期に異常検知できる体制を置きます。

ベンダー選定のチェックポイント：要件定義支援・PM支援・運用設計で見る

ベンダー選定で起きやすい落とし穴は、「見た目が整っている」提案が評価され、運用や連携の設計が後回しになることです。意思決定者の観点では、成果（売上・問い合わせ）につながる問題解決になっているかを基準に置くのが安全です。みやあじよでは、デザインを「問題解決」と捉え、目的に対して最善の手段を選ぶ考え方を制作の前提にしています。

提案依頼前に押さえる成果物

RFP（Request for Proposal）＝ベンダーに提案を依頼するための文書。を出す前に、最低限そろえたい成果物は次の3つです。

目的と優先順位：KGIと、まず整える範囲（段階1〜3）
KPIとSLAのたたき台：定義、期限、戻し先まで含む
運用設計：会議体、更新責任、レポートの見方

この3点があると、提案が比較可能になり、見積もりの前提もそろいます。逆にここが無いと、各社が別の前提で提案し、安い／高いの議論になりがちです。

ベンダー選定チェックリスト

評価観点	確認ポイント	求める成果物	注意点
要件定義支援	部門横断の定義・運用を文書化できるか	要件定義書、SLA案、KPI案	制作物だけの要件に偏らない
PM支援	会議設計と意思決定の前進ができるか	計画書、課題管理、合意ログ	担当者依存の体制はリスク
計測・連携設計	フォーム〜営業結果までの追跡を設計できるか	計測仕様、イベント定義、連携仕様	ツール導入が目的化しない
運用設計	運用負荷と分析精度の落とし所があるか	会議体、レポート雛形、運用ルール	入力項目の増やしすぎに注意

「言語化」と「ストーリー」ができるかで差が出る

運用に乗る設計は、関係者が腹落ちする言葉で説明できる状態から始まります。みやあじよが大切にしているのは、依頼側が整理しきれていない魅力や課題を「言語化」し、ページ全体のストーリーとして初見で伝わる構成へ落とし込むことです。
見積もり金額だけでなく、このプロセス（合意形成の支援）が提案に含まれているかは、長期運用の失敗確率を下げる観点で確認したいポイントです。

まとめ

営業とマーケの連携を整える要点は、KPIとSLAを「数字」ではなく「運用ルール」として設計し、段階導入で定着させることです。

最終成果から逆算してKPIを絞り、定義を文章にする
SLAで引き渡し基準と対応期限、戻し先を合意する
フォーム・計測・データ連携は、運用負荷とのバランスで設計する
ベンダー選定は、要件定義・PM・運用設計まで含めて比較する

リニューアルや制作ベンダー変更を検討している段階は、要件定義と運用設計を同時に整えやすい局面です。要件定義支援、Web制作・リニューアル、PM支援、運用設計まで一気通貫で整理したい場合は、関係者の合意形成から伴走する形で検討を進めると、投資判断と現場運用のズレが減ります。