営業代行の送信履歴を可視化する 6 系統｜稟議に耐えるレポート要件と契約 SLA の作り方

営業代行から届く月次 PDF レポートを開いたとき、「送信件数 1,800 件・返信 42 件・アポ 8 件」といった総量数字だけが並んでいて、それ以上の内訳が書かれていない状態に心当たりはないでしょうか。上長から「他社の営業と取引先が混ざっていないか」「配信停止依頼にちゃんと対応しているか」を問われたとき、代行会社の PDF を差し出しても答えにならず、代行会社に問い合わせても「弊社のツールでは詳細ログは出せない」と返ってくる。稟議や監査の場面で説明責任が果たせない、という感覚は、多くの発注担当者が抱えている悩みです。

契約前のヒアリングでは「レポートは月次で出します」と聞いていたはずですが、実際に届く成果物は稟議書・監査対応に耐える粒度ではありませんでした。かといって代行会社を今すぐ乗り換えれば解決するかというと、切り替えのコスト・営業リスト再構築の負担・新しい代行会社が本当に可視化できるかの検証工数まで考えると、判断は簡単ではありません。多くの場合、必要なのは「乗り換え」ではなく「次回契約更新までに、いま契約している代行会社にどこまで開示させるか」を要件定義することです。

そこで本記事では、営業代行の送信履歴を「可視化する」という抽象的な要求を、契約書 SLA と週次運用に落とせる具体項目まで分解します。中心となるのは、可視化項目を 6 系統（対象リスト／送信ログ／失敗診断／返信スレッド／接触済み除外の突合／配信停止対応）に整理し、代行会社のレポート提供パターン 4 類型（総量数字型／リスト単位型／リアルタイム共有型／週次 MTG 型）と突き合わせて「いま何が見えて、何が見えないのか」を可視化するアプローチです。

本記事では、まず月次総量レポートで答えられない構造的な理由を整理し、その上で 6 系統の可視化項目・4 類型のレポート・SLA の書き方・自社側で補う分担設計・「アポ数」以外の KPI・次回契約更新までのロードマップの順に解説します。読み終えた時点で、稟議書・契約書付帯資料に転記できる粒度で「代行会社に開示させるべき項目」と「自社で並行管理する項目」を切り分けられる状態を目指します。

なお、本記事は「営業代行のブラックボックス化対策」という広い論点のうち、送信履歴（誰に・いつ・何を送ったか）という 1 領域に絞った深掘り記事です。契約書全般のチェック項目（データ帰属・秘密保持・解約条件・KPI 定義など）、内製化・切替・ハイブリッド運用の意思決定軸、発注担当が自社側で持つべきダッシュボード全般の設計は、より広い視点で営業代行のブラックボックス化対策｜契約前チェック7項目と運用の可視化で整理しています。ブラックボックス化対策の全体像から把握したい方は先にそちらをご覧いただくと、本記事の位置づけが分かりやすくなります。

営業代行の月次レポートが「上長の質問に答えられない」構造的な理由

多くの発注担当者が抱く「代行会社の月次レポートを読んでも安心できない」という感覚には、構造的な理由があります。ここでは「月次総量レポート」というフォーマットそのものが、どのような情報を欠落させているのかを整理します。この欠落を言語化しておくことが、以降の章で扱う可視化項目の要件定義につながります。

本記事で扱う「営業代行」「送信履歴」「可視化」の定義

本記事では、以下の 3 つの用語を次の意味で使います。

• 営業代行: 発注企業に代わって、営業リストの作成・お問い合わせフォームからの営業送信・返信対応の一部を受託するサービス。本記事では特にフォーム営業（お問い合わせフォームからの営業メッセージ送信）を委託しているケースを想定します。
• 送信履歴: 営業代行が発注企業の名義で行った送信行為の記録全般。単なる件数の集計ではなく、いつ・誰に・どのリストから・どの文面で・どのフォームに・どんな結果で送ったかまでを含みます。
• 可視化: 発注企業側から代行会社の送信履歴を確認できる状態にすること。単に「レポートで見せてもらう」ではなく、稟議・監査・上長への説明という場面で証跡として使えるレベルの粒度と信頼性を持たせることを指します。

以降で扱う「可視化項目」は、代行会社が営業効率のために内部管理する項目ではなく、発注企業が説明責任を果たすために外部から確認できる必要がある項目です。この視点の違いが、代行会社の「弊社レポートで十分」と発注者の「これでは説明できない」というギャップの根本原因になっています。

月次総量レポートで欠落する 3 軸（時間解像度・粒度・突合可能性）

月次総量レポート（送信件数◯件・返信◯件・アポ◯件のような形式）が説明責任を果たせない理由は、以下の 3 軸で情報が欠落しているためです。

• 時間解像度の欠落: 「今月は 1,800 件送信」という月合計は、いつ・どの日に・どの時間帯に送られたかを示しません。特定日に相手先から「取引先なのに営業メッセージを受け取った」と抗議が届いたとき、その日にどのリストから何件送信したかを遡って照合できません。
• 粒度の欠落: 「送信 1,800 件」の裏側で、実際に何社に・どんな業種のリストに・どの文面で送ったかが分かりません。同じ 1,800 件でも、同一業種に均等に送ったのか、特定業種に偏っていたのかで営業戦略上の意味は大きく変わります。監査対応でも「送信対象の選定基準はどのように定めているか」を説明する材料が総量数字にはありません。
• 突合可能性の欠落: 自社が別チャネル（商談中の企業リスト・既存顧客リスト・取引先マスタ）で保有している「送ってはいけない企業」と、代行会社が実際に送った企業リストを突き合わせて確認できません。代行会社が「除外リストは徹底しています」と口頭で説明しても、突合できない以上、事故が起きていないことを事後的に確認する手段がありません。

この 3 軸の欠落は、代行会社のレポートフォーマットを「もう少し詳しくしてほしい」と要望するだけでは埋まりません。時間解像度・粒度・突合可能性のいずれも、代行会社側のツールが最初から出力できるかどうかで決まるためです。要件定義の場面では、この 3 軸のうちどれが特に自社にとって重要かを事前に整理しておく必要があります。

上長・法務・情シスから飛んでくる 5 つの質問

3 軸の欠落を実務レベルで感じるのは、社内の関係部門から質問が飛んできたときです。営業代行を委託している発注担当者に投げかけられる代表的な質問を 5 つに整理します。

1. 「他社の営業と混ざっていないか」（上長・営業部）: 代行会社が複数のクライアントを抱えている場合、他クライアントの営業リストと自社のリストが混ざり、意図しない相手に自社名義で送信していないか、という懸念。
2. 「取引先に送っていないか」（法務・上長）: 既存の取引先・パートナー企業に対して自社名義で新規営業のフォーム送信が届くと、信頼関係を損ないます。既存取引先マスタとの突合が取れているかの懸念。
3. 「配信停止依頼にちゃんと対応しているか」（法務）: 送信先から「今後の営業メッセージは不要」と連絡が来たとき、その企業への以降の送信が本当に止まっているかの確認手段があるか。
4. 「送信文面は現行のブランドガイドラインに沿っているか」（マーケティング・広報）: 代行会社が使っている文面が古いバージョンのままだったり、法務チェックを通していない表現が含まれていないか。
5. 「失敗したフォームで再送はしていないか」（情シス・法務）: 送信エラーが発生したフォームに対して、代行会社側が自動リトライで繰り返し送信していないか。相手側のサーバ負荷や DoS 誤認判定のリスクにつながります。

月次総量レポートは、この 5 つのどれにも直接答えられません。「送信件数」の数字を差し出しても、上記の質問はどれも「その内訳・そのプロセス」を問うものであり、集計後の総量では回答になりません。次章では、この 5 つの質問に答えるために必要な情報を、可視化項目の 6 系統として分解していきます。

可視化すべき送信履歴を 6 系統に分解する

営業代行の送信履歴として発注者側が最低限確認すべき情報を、6 系統に分解します。これは、代行会社に「どこまで開示してほしいか」を要件として突きつけるときの共通言語になります。抽象的な「送信履歴を可視化してほしい」という要望では代行会社側も対応範囲を絞れませんが、6 系統で分解することで契約書 SLA・週次運用ミーティング・自社側の分担運用のいずれにも落とし込めるようになります。

対象リスト（送信対象マスタ）— 誰に送るかを事前に確認するためのデータ

送信履歴の起点は「誰に送るかを決めたリスト」です。事後的な送信ログではなく、送信前に確定していた送信対象マスタを発注者側から確認できることが、事故防止の最初の関門になります。

確認すべき項目は、リスト単位で以下の粒度です。

• リスト名・作成日時・作成担当者（代行会社側の誰が承認したか）
• 送信対象企業数と選定条件（業種・所在地・従業員数・上場区分などの絞り込みロジック）
• 除外条件（既存取引先マスタとの突合・接触済み企業リストとの突合の有無）
• リスト確定日と、そのリストに対する送信スケジュール

対象リストが送信前に発注者側に共有されないと、上長・法務・情シスの質問に対して「事故が起きていないことを事前に確認する仕組み」が存在しない状態になります。多くの代行会社が実施する「事後の総量レポート提出」では、この起点部分が抜けています。

送信ログ（実行結果）— いつ・どのフォームに・何を送ったかの記録

対象リストが確定した後、実際にいつ・どのフォームに・どんな文面で送ったかを 1 送信単位で記録したものが送信ログです。前章で挙げた「時間解像度」の欠落を埋めるための中核データです。

送信ログとして確認したい項目は、以下の 1 行 1 送信の粒度です。

• 送信日時（秒単位が理想。少なくとも分単位）
• 送信先企業名・ドメイン・送信先フォーム URL
• 送信文面のバージョン識別子（テンプレート ID や版数）
• 送信結果ステータス（送信成功／送信失敗／CAPTCHA 遭遇でスキップ／人手による送信）
• 送信担当（自動送信ツール／代行会社の担当者名または担当 ID）

この粒度の送信ログがあれば、「今月◯日にこの企業に送ったかどうか」の照会に即答できます。代行会社のツール上で送信ログが取れていない場合、そもそも代行会社の運用体制自体が発注者からの照会に耐えられない設計であることを示します。

失敗診断（失敗理由の分類）— 送信できなかった件数だけでなく理由の分類が必要

送信ログに「送信失敗」ステータスが含まれるだけでは、可視化として不十分です。失敗の理由を分類し、それぞれの件数と代表的な失敗例を確認できる状態が必要です。

失敗理由の分類項目としては、以下の 5 分類を最低限持つことが望まれます。

• フォーム未発見: 相手企業の Web サイトに問い合わせフォームが見つからなかった（Contact ページはあるが電話のみだった等）
• フォーム項目不整合: 必須項目に想定外の項目があり、代行会社側で回答が用意できなかった
• CAPTCHA 遭遇: reCAPTCHA 等の突破試行が必要になり、代行会社の運用ポリシーで送信を中止した
• 送信後エラー返却: 送信ボタン押下後にサーバエラー・タイムアウトが返却された
• 明示的な受信拒否: フォーム画面に「営業目的での送信禁止」等の明示的な文言があり、送信を中止した

失敗診断の可視化は、単なる運用改善だけでなく、法務・情シスからの質問（特に「失敗したフォームで再送はしていないか」）への回答材料になります。「失敗した企業には自動で 3 回リトライしている」のような運用が代行会社側に存在した場合、それがリスト単位で見えることは重要です。

返信スレッド（Gmail 等の返信検知）— 送信後の反応を送信履歴と紐づけて確認

送信履歴の一部として見落とされがちなのが、送信後の返信スレッドです。フォーム送信後に相手企業から自社の代表メール宛に届く返信が、送信履歴と紐づいて記録されていないと、そのやり取りが可視化されません。

確認したい項目は以下です。

• 返信を受信したメールアドレス（代行会社の返信受け窓口）
• 返信内容の分類（興味あり／後日連絡希望／不在／担当外／配信停止依頼／クレーム）
• 返信内容と元の送信ログとの紐づけ（どの送信に対する返信か）
• 返信への一次対応の記録（代行会社が返信したか／発注者に転送したか）

特に「配信停止依頼」と「クレーム」の返信は、次章で扱う配信停止対応と直接連動します。返信スレッドが可視化されていないと、代行会社が「配信停止依頼をこっそり握り潰していた」ケースを検知できません。

接触済み除外の突合結果 — 自社が保有する接触済み企業リストとの照合ログ

多くの発注企業は、代行会社に委託していない別チャネル（自社インサイドセールス・展示会・別の営業代行）で接触済みの企業リストを保有しています。代行会社側の送信リストと、自社側の接触済み企業リストを突き合わせ、重複していた企業を送信対象から除外できているかの記録が「接触済み除外の突合結果」です。

確認したい項目は以下です。

• 発注者側から代行会社に事前提供した接触済み企業リスト（ドメイン単位）
• 代行会社側の送信リストとの突合実施日時
• 突合の結果、除外対象になった企業数と該当企業のドメイン一覧
• 突合が取れなかった件数（不明ドメイン等）と、その扱い

接触済み除外の運用は、代行会社側だけでは完結しません。発注者側が保有する接触済み企業リストを最新の状態で共有する運用と、代行会社側が突合を実施する運用の両方が必要です。この分担設計は本記事の後半で改めて扱います。接触済み除外リストの棚卸し手順そのものについては、フォーム営業の送信除外リストで扱う 6 カテゴリの整理が参考になります。

配信停止対応の記録 — 停止依頼を受けた企業への以降の送信抑止の証跡

配信停止依頼は、返信スレッドや電話問い合わせで届きます。この依頼を受けた企業に対して、以降の送信が止まっているかを事後的に証明できるのが「配信停止対応の記録」です。

確認したい項目は以下です。

• 配信停止依頼を受けた日時・依頼元企業のドメイン
• 依頼の受信経路（返信メール／電話／フォーム上の記載）
• 代行会社側の送信抑止リストに追加された日時
• 該当企業への以降の送信がゼロであることの証跡（送信ログ上で該当ドメインが以降ゼロ件であること）

配信停止対応は、法務・コンプライアンスの観点で最も重要な項目です。「対応しました」という代行会社の口頭説明ではなく、送信抑止リストと送信ログの突合結果として可視化できることが求められます。

6 系統の比較表（何のデータか／なぜ必要か／代行会社に依頼する項目名／望ましい形式）

ここまでの 6 系統を、代行会社への開示依頼と契約書 SLA に落とし込みやすい形で整理します。

この 6 系統を軸に、次章では現行の代行会社のレポート提供パターンを 4 類型に整理し、どの系統が確認できて・どの系統が欠落しているかを対応表で可視化します。

代行会社のレポート提供パターン 4 類型と、6 系統との対応関係

現行の代行会社が提供するレポートを、粒度と提供方式で 4 類型に整理します。読者は自社の代行会社がどの類型に該当するかを判定し、6 系統のうち欠落している系統を「次回契約更新までに補うべき項目」として認識できるようになります。個別の代行会社の実名比較は行わず、レポート提供パターンの類型化として扱います。

類型 A: 総量数字型（月次 PDF）

月次で 1 通の PDF が届き、「送信件数◯件・返信◯件・アポ◯件」の総量数字が集計されているタイプです。フォーム営業代行の初期契約でもっとも多く見られる提供パターンで、契約前のヒアリングで「レポートは月次で提出します」と言われた場合、多くはこの類型に該当します。

このタイプで確認できるのは、6 系統のうち以下の一部に限られます。

• 送信件数の総量（送信ログの件数だけ・内訳は見えない）
• アポ件数の総量（返信スレッドの結果だけ・分類は見えない）

対象リスト・失敗診断・返信スレッドの内訳・接触済み除外の突合・配信停止対応の証跡は、いずれも確認できません。上長・法務・情シスの 5 つの質問に対しても、直接の回答材料にはなりません。

類型 B: リスト単位型（週次 CSV）

週次で CSV ファイルが届き、送信リスト単位（またはキャンペーン単位）で集計されたレポートが提供されるタイプです。総量数字型より一段粒度が細かく、「今週の A リストからは何件送信・何件返信」といった内訳が確認できます。

このタイプで確認できるのは、以下です。

• 送信ログのリスト単位集計（1 送信単位の粒度はまだ見えない）
• 対象リスト（リスト名・件数程度は見える。選定条件までは提供されないことが多い）
• 失敗診断の一部（失敗件数は見えるが理由分類までは提供されない場合が多い）

返信スレッドの内訳・接触済み除外の突合・配信停止対応の証跡は、この類型でもまだ確認できないケースが多い状態です。

類型 C: リアルタイム共有型（スプレッドシート／専用画面）

Google スプレッドシートや代行会社の専用管理画面へのアクセス権が発注者側に付与され、日次または準リアルタイムで送信ログ・失敗診断・返信スレッドを確認できるタイプです。SaaS 型のツールを内製化している代行会社や、比較的透明性を重視する代行会社で見られます。

このタイプで確認できるのは、以下です。

• 対象リスト（選定条件を含む形で共有されることも多い）
• 送信ログ（1 送信単位の粒度で確認できる）
• 失敗診断（理由分類・失敗ログの原文が確認できる場合が多い）
• 返信スレッド（分類ラベル付きで共有されることも多い）

接触済み除外の突合・配信停止対応の証跡は、代行会社側のツール設計次第で確認できるかどうかが分かれます。契約更新前のヒアリングで、この 2 系統が確認できるかを個別に問い合わせる必要があります。

類型 D: 週次 MTG 型（画面共有＋対話）

週次または隔週で代行会社担当者との定例ミーティングが設定され、画面共有で送信状況・返信内訳を確認しながら、その場で疑問点を質問できるタイプです。ファイル提供型ではなく、対話ベースで可視化が担保されます。

このタイプの特徴は、ファイル形式では出せない情報（判断の背景・グレーな判定の理由・イレギュラーな返信への対応方針）まで確認できることです。ただし、後日「そのとき何を確認したか」を稟議や監査の証跡として残すには、ミーティング議事録・録画・画面共有スクリーンショットを発注者側で保管する運用が別途必要になります。

このタイプで確認できるのは、対話の内容次第で 6 系統のすべてに及ぶ可能性がありますが、証跡としての永続性（後日振り返れるか）は運用ルール次第です。

4 類型 × 6 系統の対応表と、欠落系統の見つけ方

4 類型が 6 系統に対してどこまでカバーできるかを、対応表として整理します。

※ ○=標準で確認可、△=部分的に確認可または設計次第、×=標準では確認不可

自社が契約している代行会社がどの類型に該当するかを判定し、「×」または「△」が付いている系統が、次回契約更新までに補うべき項目です。特に「接触済み除外の突合」「配信停止対応」の 2 系統は、類型 C・D でも代行会社側のツール設計に依存するため、契約更新時の重点確認項目になります。

契約書 SLA と週次運用に落とし込む要件定義テンプレート

前章までで整理した 6 系統・4 類型を踏まえ、次回契約更新時に代行会社に突きつけられる要件定義テンプレートを提示します。ここでは契約書に盛り込むべき項目と、週次運用ミーティングで画面共有してもらう項目に分けて整理します。SLA 記述例は法的助言ではなく、法務確認を前提とした叩き台として掲載します。

なお、本章では送信履歴の可視化に絞った SLA・週次運用項目のみを扱います。契約書全体のチェックリスト（データ帰属・秘密保持契約・解約条件・成果定義など）は本記事の対象範囲外です。契約書全般の再交渉ポイントを整理したい方は、営業代行のブラックボックス化対策｜契約前チェック7項目と運用の可視化の「契約前・契約更新前に押さえるチェック 7 項目」を先に参照してください。本章で扱う SLA 5 項目は、その 7 項目のうち「レポート仕様」に該当する部分を、送信履歴の可視化という切り口でさらに細分化したものと位置づけられます。

契約書 SLA に盛り込む 5 項目（開示項目・開示頻度・アクセス権限・保存期間・違反時対応）

契約書のサービスレベルアグリーメント（SLA）に盛り込むことで、代行会社側に運用義務として位置づけられる項目を 5 つ整理します。

1. 開示項目: 前章の 6 系統のうち、代行会社が発注者に開示する義務を負う項目を明示的に列挙する。「送信ログを開示する」ではなく「送信日時・送信先ドメイン・文面バージョン識別子・送信結果ステータスを 1 送信単位で開示する」まで粒度を確定させる。
2. 開示頻度: 系統ごとに開示頻度を明示する。送信ログは日次または週次、対象リストは送信前（週次で翌週分を事前共有）、配信停止対応の証跡は月次、など。
3. アクセス権限の粒度: 開示物へのアクセス権限を、発注者側の何名まで・どの部門まで許可するかを明示する。営業推進チームだけでなく、法務・情シス・監査担当も参照できる権限設計を SLA レベルで確保する。
4. ログの保存期間: 送信ログ・返信スレッド・配信停止対応の証跡を、代行会社側で最低何ヶ月保存する義務を負うかを明示する。監査・法務対応の観点では、少なくとも 24 ヶ月の保存を確保することが望ましい水準です。
5. 違反時の対応: SLA に定めた開示項目・開示頻度が守られなかった場合の対応（違約金・改善計画の提出義務・契約解除条項）を明示する。

この 5 項目は、代行会社との契約書ドラフトを法務レビューに回す前に、発注部門側で整理しておくべき事項です。

週次運用ミーティングでの画面共有 5 項目

契約書 SLA が中長期の枠組みだとすると、週次運用ミーティングは日常の可視化を担保する場です。代行会社担当者との週次 MTG で画面共有してもらう項目として、以下 5 項目を運用要件に含めます。

1. 今週の対象リストの内訳: 今週送信予定のリスト名・件数・選定条件・除外条件を、送信開始前に画面共有で確認する。
2. 送信ログの日次内訳: 前週の送信ログを日次で集計し、送信件数の推移と例外事象（一時停止・失敗急増）を確認する。
3. 失敗診断の分類: 前週の失敗件数の理由別内訳を表示し、失敗率が高い理由への対応方針を対話する。
4. 返信スレッドの内訳: 前週の返信件数を分類別（興味あり／後日連絡／不在／担当外／配信停止／クレーム）に集計し、配信停止・クレーム分の詳細を必ず確認する。
5. 接触済み除外の突合結果: 前週に発注者側から提供した接触済み企業リストと、代行会社側の送信リストの突合結果を確認する。除外対象になった企業数と、突合が取れなかった件数を報告してもらう。

この 5 項目を毎週の定例 MTG で運用に組み込むと、月次総量レポートを待つことなく、事故の兆候を早期に検知できるようになります。この 5 項目は「送信履歴の可視化に必要なデータ」を毎週確認する運用フォーマットですが、これに加えて「代行会社側の意思決定プロセスを可視化する」観点で良化指標・悪化指標・来週の改善アクションの 3 項目セットを併用したい場合は、営業代行のブラックボックス化対策｜契約前チェック7項目と運用の可視化の「週次レポートで最低限含めるべきプロセス指標と 3 項目セット」で扱っています。データ確認と代行会社の思考プロセス確認は目的が異なるため、両方を組み合わせることで週次 MTG の情報密度が上がります。

SLA 記述例（法務確認前提の叩き台として提示）

契約書に盛り込む SLA の記述例を、叩き台として掲載します。実際の契約書は法務確認を経て確定してください。以下は日本の契約書で用いられる文言に近づけた記述例です。

第◯条（送信履歴の開示）

1. 乙（代行会社）は、甲（発注者）に対し、本業務に基づく送信活動について、以下の情報を開示するものとする。

   • 送信ログ（送信日時、送信先企業ドメイン、送信文面バージョン識別子、送信結果ステータスを含む 1 送信単位のログ）
   • 送信対象リスト（リスト名、選定条件、除外条件、送信対象企業数、リスト確定日時）
   • 失敗診断（送信失敗件数の理由分類別集計）
   • 返信スレッド（受信メールの分類ラベル別集計と、甲が個別内容を確認する場合のアクセス手段）
   • 接触済み除外の突合結果（甲から提供された接触済み企業リストとの突合実施日時、除外対象になった企業数）
   • 配信停止対応の記録（配信停止依頼を受けた企業のドメイン、対応日時、以降の該当ドメインへの送信がゼロであることの証跡）

2. 開示頻度は次のとおりとする。送信ログおよび失敗診断は週次、送信対象リストは送信開始日の 3 営業日前まで、返信スレッドおよび接触済み除外の突合結果は週次、配信停止対応の記録は月次。

3. 乙は、前項各号の情報について、本契約終了後 24 ヶ月間の保存義務を負う。甲は本契約期間中および契約終了後 6 ヶ月間、当該情報の写しの提供を求めることができる。

4. 乙が本条各項に定める開示義務を継続的に履行しない場合、甲は乙に対し、書面により是正を求めることができる。是正要求から 30 日以内に是正が完了しない場合、甲は本契約を解除することができる。

上記はあくまで叩き台であり、実際の SLA 文言は法務部門・顧問弁護士のレビューを経て確定してください。特に違反時対応の条項は、契約金額・違約金の考え方・裁判管轄の設定などと組み合わせて検討する必要があります。

契約更新前に代行会社に確認する 10 の質問リスト

契約更新交渉の前に、現行の代行会社に対して事前ヒアリングで確認しておく質問リストを 10 個整理します。この質問への回答内容によって、SLA としてどこまで盛り込めるか、または自社側で並行管理する必要があるかが決まります。

1. 送信ログは 1 送信単位で出力できますか。出力形式（CSV／API／画面参照）と項目一覧を教えてください。
2. 送信対象リストは送信開始前に、選定条件・除外条件を含めて事前共有できますか。
3. 失敗診断の分類は、貴社のツール上でいくつのカテゴリに分類されていますか。
4. 発注者側から提供した接触済み企業リストと、貴社の送信リストを送信前に突合する運用は可能ですか。突合の実施頻度と、突合結果の共有方法を教えてください。
5. 配信停止依頼を受けた企業のドメインを、貴社の送信抑止リストにどのように登録していますか。登録後、その企業に対する以降の送信ゼロ件を証明する方法はありますか。
6. 送信ログ・返信スレッド・配信停止対応の記録は、貴社側で何ヶ月保存されますか。契約終了後の保存期間も教えてください。
7. 発注者側から複数名（営業推進・法務・情シス）で貴社の管理画面を参照する権限は付与できますか。参照可能な項目に部門別の制限はありますか。
8. 失敗した送信について、貴社側で自動リトライを行う運用はありますか。ある場合、リトライの回数・間隔と、リトライ対象外の判定基準を教えてください。
9. 貴社が複数のクライアントを抱えていることを前提に、当社のリストと他クライアントのリストを分離するデータ設計の説明資料はありますか。
10. 貴社の送信履歴の開示項目・頻度を、契約書の SLA として明文化することは可能ですか。可能な場合、対応可能な範囲と対応が難しい範囲を明示してください。

この 10 個の質問への回答パターンを整理すると、代行会社を「透明性を重視する運用ができる会社」「現状のツールでは対応が難しい会社」に切り分けられます。後者の場合、次章で扱う「自社側で並行管理する分担設計」がより重要になります。

代行会社が対応できない可視化項目を自社側で補う分担設計

6 系統のうち、代行会社側では対応できない項目があった場合の分担設計を整理します。「代行会社を乗り換える」ではなく「代行会社の可視化範囲は現状のまま、自社側で並行管理する項目を持つ」という選択肢を持つことで、次回契約更新までのアクションが現実的な範囲に収まります。

なお、本章で扱う分担設計は「代行会社の送信履歴データを自社側でどのように受け取り、突合するか」という送信履歴の可視化に絞った運用設計です。SFA・CRM の共同利用方式全般（読み取り専用ゲスト発行／エクスポート定型化／API 連携）や、発注担当が自社側で持つべきダッシュボード全般の設計（送信履歴・反応・案件クロージング理由の 3 領域）については、より広い視点で営業代行のブラックボックス化対策｜契約前チェック7項目と運用の可視化の「SFA / CRM 共同利用の 3 方式」および「発注担当が持つべき最小限のダッシュボード設計」で扱っています。本章の分担パターンは、そこで整理された共同利用方式の中で「送信履歴の可視化」に必要なデータをどう扱うかを具体化したものと位置づけられます。

6 系統のうち代行会社側で対応できないことが多い項目

前章の 4 類型 × 6 系統の対応表で明らかになるとおり、以下の 2 系統は代行会社側のツール設計次第で対応できないケースが多い項目です。

• 接触済み除外の突合: 発注者側の接触済み企業リストと代行会社側の送信リストの突合機能を、代行会社のツールが持たないケースが多い。あっても手動のスプレッドシート運用に留まり、リスト更新のタイムラグで漏れが発生することがある。
• 配信停止対応の記録: 配信停止リストの管理はしていても、以降の送信ゼロ件を証跡として出力する機能がツールに実装されていないケースがある。

これらは、契約更新交渉で代行会社側の対応強化を要求してもすぐには実装が難しい項目です。同時に、法務・情シスからの質問への回答責任が最も重い項目でもあります。この 2 系統について、自社側での補完手段を持つ必要があります。

分担パターン A: 送信対象マスタの自社事前整備

自社側で「代行会社に渡してよいリスト」「渡してはいけない企業のドメイン一覧」を事前に整備し、代行会社に渡す段階でクリーンな状態にしておく分担パターンです。代行会社側の突合機能に依存せず、リスト受け渡しの前段で自社が責任を持つ設計になります。

自社側で用意するデータは以下です。

• 既存取引先マスタ（ドメイン一覧・企業名・取引ステータス）
• 別チャネルで接触済みの企業リスト（自社インサイドセールス・展示会・過去の営業代行）
• 商談中・失注・保留中の企業リスト（SFA・CRM から抽出）
• 配信停止依頼を受けた企業のドメイン一覧（過去の代行会社経由分も含む）

これらを統合した「送信除外リスト」を、代行会社への送信対象リスト提供前に自社で突合し、除外済みの状態で渡します。送信除外リストの構築・棚卸し・更新運用の具体的な進め方については、フォーム営業の送信除外リストを参照してください。

このパターンの利点は、代行会社側のツール仕様に依存せずに事故防止の第一線を確保できることです。難点は、自社側で送信除外リストのメンテナンス責任を負う運用工数が発生する点です。

分担パターン B: 自社 SFA・CRM への取り込み

代行会社側から送信ログ・返信スレッドの CSV エクスポート（または API 連携）を受け取り、自社の SFA・CRM に取り込んで自社側で分析・監査する分担パターンです。代行会社側は既存のレポートフォーマットのまま、可視化の主体を自社側に移す設計になります。

自社側で構築する運用は以下です。

• 代行会社から週次 CSV を受領し、SFA の「営業活動」ログとして 1 送信単位で取り込む
• 返信スレッドを SFA の商談レコードに紐づけ、興味あり・配信停止・クレーム分類を SFA 側で管理
• 送信ログと自社の除外リストを SFA 上で突合し、除外漏れがなかったかを事後監査

このパターンの利点は、代行会社側の運用を大きく変更せずに可視化を確保できる点です。難点は、CSV 取り込み・SFA へのマッピング設計・分析ダッシュボードの構築という初期投資が必要な点です。取り込みプロセスを人手で運用する場合、月次で数時間〜十数時間の工数が発生します。

分担パターン C: 自社側の二重チェック用マスタ管理

代行会社側のツールとは別に、自社側で「送信対象マスタ」「送信除外マスタ」「配信停止マスタ」を独立して管理し、代行会社側の運用と並行で二重チェックする分担パターンです。監査・法務対応の観点で最も証跡が確保しやすい設計になります。

このパターンでは、代行会社が使うツールと自社の管理ツールの両方に同じデータが存在するため、以下の運用が必要です。

• 送信除外マスタの更新を代行会社と自社で同期する運用ルール
• 週次で代行会社側の送信ログを取得し、自社の除外マスタに含まれる企業への誤送信がなかったかを突合する監査
• 配信停止依頼を受けた際、代行会社側と自社側の両方の管理台帳に登録する二重登録ルール

このパターンで自社側の管理を担うツールを選ぶ際は、接触済み企業を除外するツールが備えるべき機能を整理しておくと選定判断がスムーズです。代表的な 4 方式（自社履歴照合／業種ルール／外部シグナル連携／配信停止フィードバック）と実装レベルの判断軸については接触済み企業除外営業ツールが参考になります。

このパターンの利点は、代行会社側の運用リスクに対する冗長性を確保できる点です。難点は、二重管理による運用工数の増加と、代行会社側マスタと自社側マスタの同期タイムラグから来る不整合リスクです。

分担設計の意思決定チャート

3 つの分担パターンから自社に適した設計を選ぶための、意思決定の優先順位を整理します。

1. 代行会社側の 6 系統への対応度が高い場合（類型 C・D）: パターン B（自社 SFA・CRM への取り込み）を優先。代行会社側の出力を活かしつつ、可視化の主体を自社側に置く設計が費用対効果に優れます。
2. 代行会社側の対応度が低いが、乗り換えは避けたい場合（類型 A・B）: パターン A（送信対象マスタの自社事前整備）を優先。代行会社の運用変更に依存せず、リスト受け渡し前段の自社責任範囲で可視化の一部を確保できます。
3. 法務・情シスからの監査要求が特に厳しい場合: パターン C（自社側の二重チェック用マスタ管理）を検討。運用工数は大きいものの、代行会社の運用リスクに対する冗長性を最大化できます。

多くの発注企業は、パターン A を最低限のベースラインとして持ちつつ、契約更新後の代行会社の対応度に応じてパターン B・C を追加する段階的な設計を採ることになります。すべてを一度に構築する必要はありません。

送信履歴の可視化を「アポ数」以外の KPI に組み込む

ここまで整理した可視化項目は、監査ログとして「見て終わり」にするのではなく、代行会社との運用改善サイクルに組み込むことで、監査対応と営業成果の両方に寄与するようになります。ここでは、可視化項目を KPI として組み込む方法を扱います。

なお、本章で扱うのは送信履歴の可視化から派生する「送信の質」に絞った KPI 4 指標です。案件クロージング理由（Why not）の分類・失注理由の吸い上げ運用など、送信履歴の可視化から派生しない KPI については本記事の対象範囲外です。案件レベルの失注理由分析（5 件レビュー運用など）や、営業代行 KPI ツリー全体の設計については、営業代行のブラックボックス化対策｜契約前チェック7項目と運用の可視化の「定例レビューで案件クロージング理由を吸い上げる 5 件レビュー運用」で扱っています。

アポ数だけでは代行会社の「送信の質」を評価できない

多くの発注企業が代行会社との月次評価で見ているのは、アポ数（またはアポ率）です。しかしアポ数だけを KPI にすると、「送信の質」を犠牲にしても「送信の量」を増やせばアポ数は増える構造になります。具体的には、以下のような問題を検知できません。

• 除外すべき企業に送ってしまってもアポ数には反映されない（クレームが返ってきた場合のみ検知される）
• 失敗率が高い運用でも、送信数を増やすことでアポ数を保てる
• 配信停止依頼を無視して送り続けてもアポ数は増える方向に働く

アポ数だけの KPI 設計は、代行会社に「量で稼ぐインセンティブ」を与える構造になっており、可視化した情報を活かしきれていません。

追加 KPI 4 指標(純度・品質・返信内訳・遵守率)

可視化した 6 系統の情報を活用し、アポ数に加えて代行会社の「送信の質」を評価する KPI を 4 指標追加します。

1. リスト純度: 送信対象リストのうち、接触済み除外の突合で除外された企業を除いた「実質送信可能企業数」の割合。除外率が高いほどリストの純度が低いことを示し、リスト供給元の見直しにつながります。
2. 送信ログ品質: 送信ログ全体に対する送信失敗率と、失敗理由の分類分布。フォーム未発見・フォーム項目不整合など運用改善で減らせる失敗の比率を継続的に下げる目標にできます。
3. 返信内訳: 返信スレッド全体に対する分類別の比率。特に「配信停止依頼／クレーム」の返信率を継続的にモニタリングし、増加傾向がある場合はリスト選定基準・文面のレビューを行います。
4. 配信停止遵守率: 配信停止依頼を受けた企業への以降の送信がゼロであることを、送信ログとの突合で継続的に確認する指標。100% であることが SLA として求められる項目です。

なお、フォーム営業では原理的にメール配信のような「開封率」は測れませんが、短縮 URL を挟むことでクリック率相当の計測は可能です。開封・クリック計測の技術的な背景と実装方法については、フォーム営業の開封・クリック計測で詳しく扱っています。

週次運用ミーティングでの KPI レビュー項目

上記 4 指標を週次運用ミーティングでレビューする際、アポ数以外のこれらの指標を毎週固定で確認する運用に組み込みます。ミーティングアジェンダは以下の順序で構成することを推奨します。

1. 前週の送信件数・アポ件数（従来の量的 KPI）
2. リスト純度（今週の対象リストの除外率）
3. 送信ログ品質（前週の失敗率と失敗理由分類）
4. 返信内訳(前週の分類別返信比率と、配信停止・クレームの詳細)
5. 配信停止遵守率（前週までの累計遵守率と、違反事例の有無）

このアジェンダで週次レビューを継続すると、代行会社側の運用改善が「送信数を増やす方向」から「送信の質を保つ方向」に自然と誘導されます。KPI の重み付けを発注者側で明示的にコントロールできる状態を作ることが、代行会社との健全な関係構築につながります。

次回契約更新までのロードマップ（30 日 / 60 日 / 90 日）

最後に、本記事で整理した内容を、次回契約更新までの実行ステップとして 30 日 / 60 日 / 90 日のロードマップに落とし込みます。すべてを一度に進める必要はなく、段階的に社内の関係部門を巻き込んでいく設計にしています。

30 日目までのアクション（現状把握）

契約更新までのリードタイムを確保する意味でも、まずは現状把握を先行させます。この段階では代行会社への交渉はまだ行わず、社内での認識整理に集中します。

• 現行の代行会社のレポート提供パターンが、4 類型（A: 総量数字型／B: リスト単位型／C: リアルタイム共有型／D: 週次 MTG 型）のどれに該当するかを判定する
• 6 系統のうち、現在確認できる系統と欠落している系統を対応表として整理する
• 上長・法務・情シスから過去に飛んできた質問を棚卸しし、それらの質問に対して現行レポートで回答できるかを検証する
• 稟議書・監査対応で説明責任を果たすために、6 系統のうちどれが「絶対に必要」か「あれば望ましい」かの優先順位を社内で合意する

この段階の成果物は、「現状把握レポート」として稟議書に添付できる 1〜2 ページの資料です。関係者は営業推進・法務・情シスに限定し、代行会社にはこの段階では働きかけません。

60 日目までのアクション（要件定義・分担決定）

現状把握を踏まえ、代行会社への開示要求項目と、自社側で並行管理する項目を切り分ける段階です。この段階から代行会社担当者への事前ヒアリングを開始します。

• 前章の「契約更新前に代行会社に確認する 10 の質問リスト」を使って、代行会社担当者に事前ヒアリングを実施する
• ヒアリング結果を踏まえ、6 系統のうち代行会社が対応できる項目と、自社側で並行管理する項目を分担決定する
• 自社側の分担部分について、3 つの分担パターン（A: 送信対象マスタの自社事前整備 / B: 自社 SFA・CRM への取り込み / C: 自社側の二重チェック用マスタ管理）から適した設計を選定する
• 契約書 SLA に盛り込む 5 項目（開示項目・開示頻度・アクセス権限・保存期間・違反時対応）の要求水準を、社内の法務・情シスと合意する

この段階の成果物は、「代行会社への要件定義書」と「自社側の分担運用設計書」の 2 種類です。関係者に、経理・調達（契約金額の見直しが発生する場合）を追加します。

90 日目までのアクション（契約更新・SLA 落とし込み）

要件定義と分担設計が固まった状態で、契約更新交渉と SLA の契約書落とし込みを行います。同時に、週次運用ミーティングのフォーマット変更も並行して進めます。

• 代行会社への要件定義書を提示し、契約書 SLA に盛り込む項目のドラフトを法務レビューに回す
• SLA 記述例（本記事で叩き台として掲載した例）を参考に、自社の実情に合わせた文言を確定する
• 週次運用ミーティングのアジェンダを、可視化 5 項目・KPI 4 指標を含む形にアップデートする
• 自社側の分担運用（送信対象マスタの整備／SFA 取り込み／二重チェック）を実装開始する

この段階の成果物は、更新後の契約書・週次運用フォーマット・自社側分担運用の実装計画です。関係者に代行会社担当者・顧問弁護士を追加し、契約発効までのマイルストーンを確定します。

まとめ

本記事では、営業代行の送信履歴を「可視化する」という抽象的な要求を、契約書 SLA と週次運用に落とせる具体項目まで分解しました。中心となる考え方を再掲します。

• 可視化項目は 6 系統に分解する: 対象リスト・送信ログ・失敗診断・返信スレッド・接触済み除外の突合・配信停止対応。この 6 系統が上長・法務・情シスからの 5 つの質問への回答材料になります。
• 代行会社のレポート提供パターンを 4 類型で判定する: 総量数字型・リスト単位型・リアルタイム共有型・週次 MTG 型。自社の代行会社がどの類型に該当するかによって、次回契約更新までに補うべき系統が決まります。
• 契約書 SLA に 5 項目を盛り込む: 開示項目・開示頻度・アクセス権限・保存期間・違反時対応。中長期の枠組みとして代行会社側の運用義務を明文化します。
• 代行会社が対応できない項目は自社側で分担設計する: 送信対象マスタの自社事前整備・自社 SFA/CRM への取り込み・自社側の二重チェック用マスタ管理の 3 パターンから、代行会社の対応度に応じて選択します。
• アポ数以外の KPI 4 指標を追加する: リスト純度・送信ログ品質・返信内訳・配信停止遵守率。可視化した情報を運用改善に活かし、代行会社との健全な関係構築につなげます。

代行会社を「乗り換える」か「そのまま使い続ける」かの二択ではなく、「今の代行会社にどこまで開示させるか」を要件定義するアプローチであれば、次回契約更新のタイミングで実現可能な範囲から段階的に着手できます。まずは 30 日目までの現状把握から始めることをおすすめします。送信履歴の可視化は「営業代行のブラックボックス化対策」という広い論点の中の 1 領域なので、契約書全般のチェックポイント・内製化と切替の意思決定軸・発注担当が持つべきダッシュボード全般の設計についても続けて検討したい方は、営業代行のブラックボックス化対策｜契約前チェック7項目と運用の可視化を続けてご覧ください。

関連情報

送信除外リストの運用・失敗診断の可視化・接触済み企業の自動除外を、代行会社との運用要件だけでなく自社側のツールとして整備することを検討されている方は、Form Pilot のサービスページもあわせてご覧ください。他社が接触済みの企業ドメインを送信リストから自動で除外する設計を軸に、送信履歴・失敗診断・返信スレッドの可視化を発注者側で確保できるサービスです。

関連記事

• 営業代行のブラックボックス化対策｜契約前チェック7項目と運用の可視化 — 送信履歴の可視化を含む「営業代行のブラックボックス化対策」全体像を、契約書チェック 7 項目・運用 3 レイヤー・内製化判断軸まで扱います
• フォーム営業の送信除外リスト — 送信除外リストを 6 カテゴリで棚卸しし、三層更新運用を組み立てる手順を扱います
• 接触済み企業除外営業ツール — 接触済み企業を除外するツール群を 4 方式で分類し、選定判断の軸を整理します
• フォーム営業の開封・クリック計測 — フォーム営業で「開封は原理的に測れない」「クリックは短縮 URL で測れる」の技術背景と KPI 設計を扱います