問い合わせフォーム営業代行とは｜業務範囲 6 工程と支援範囲別 3 分類で選ぶ

「問い合わせフォーム営業代行」で検索し、12 選・14 選・15 選と並ぶ比較記事を数本読み進めても、「結局、代行に何をどこまで任せられるのか」という肝心な疑問が残ったままではないでしょうか。個社紹介と料金相場の並列で構成された記事の多くは、発注者が最初に必要としている「業務範囲の分解」と「自社の要件に合う支援範囲の見極め方」までは踏み込んでいません。

新規リード獲得手段として問い合わせフォーム営業を検討する場面では、上長から「代行と自社 SaaS の両方を比較して報告してほしい」と指示されることが多いはずです。しかし比較記事だけを読み続けても、「なぜ代行なのか／なぜ SaaS なのか」を上長に説明できる判断軸は手に入りません。加えて、過去に別チャネルの外注で送信結果が見えなくなった経験がある方ほど、「任せた後に文面・送信先が見えなくなる状態」をどう回避するかは切実な論点になります。

本記事では、この 3 つの疑問に順序立てて答えます。まず問い合わせフォーム営業代行の業務範囲を 6 工程で分解し、「どの工程を外注するか」を発注前に決められる型を提示します。次に、代行会社の 3 分類・料金体系・透明性を担保する 5 確認項目を整理し、代行と自社 SaaS 運用のどちらを選ぶかの判断フローに接続します。最後に、発注後の運用ガバナンスまで含めて「任せる／持つ」の設計を完成させる流れです。

読み終えたときには、発注要件書の骨格を自力で作成でき、候補社を 3 社程度に絞り、上長への説明材料が揃った状態を目指します。

問い合わせフォーム営業代行とは｜「代行」の定義と一般的な誤解を最初に整理する

比較記事を読み進める前に、まず言葉の定義を揃えます。ここが曖昧なまま個社紹介を見比べても、「なぜこの会社とあの会社を並べているのか」の判断軸が持てないためです。

問い合わせフォーム営業代行の定義

問い合わせフォーム営業代行とは、企業の問い合わせフォーム（コーポレートサイトの「お問い合わせ」ページ）を通じて自社サービスの提案文を送信する営業活動を、代行会社に業務工程として委託するサービスを指します。ポイントは「一連の作業を丸ごと外注する」というよりも、後述する 6 工程のうち「どの工程を外部に任せ、どの工程を自社で持つか」を選べる業務委託である点です。

この認識は、実務上とても重要です。上長から「代行に任せておけばいい」と指示された場合でも、実際には送信文面の最終責任・送信先リストの管理責任・配信停止依頼の受け皿など、発注者側に残る責任が必ずあります。この責任範囲を最初に区切らないまま契約すると、後述する「送信結果が見えなくなる」問題に直結します。

フォーム営業ツール（SaaS）・フォーム DM ツール・アウトバウンド営業支援ツールとの違い

比較検討の初期段階でつまずきやすいのが、代行サービスと SaaS 型ツールの違いです。市場には次の 4 つのカテゴリが混在しています。

• フォーム営業代行: 営業代行会社が業務工程を人手（または半自動）で受託
• フォーム営業ツール（自動送信型 SaaS）: 自動入力・自動送信を SaaS として提供
• フォーム DM ツール（一括配信型）: 問い合わせフォームを一斉配信チャネルとして扱う DM 送信基盤
• アウトバウンド営業支援ツール: フォーム送信を一機能として含む、SFA / CRM 連携型のプラットフォーム

「代行 = 人がやる／SaaS = 機械がやる」という粗い理解は誤ってはいませんが、判断の粒度としては不十分です。より正確な理解は、「代行は業務工程を外部に委託する契約／SaaS は業務工程を社内で運用するための道具」という区分です。

「代行 vs SaaS」を粒度を上げて考えるための前提

この定義の置き換えが効いてくるのは、上長への説明段階です。「代行と SaaS のどちらが安いか」だけを比較すると、社内のインサイドセールス人員の有無・見える化要件・継続運用予定期間などの要素が抜け落ちます。工程を委託するか、道具を運用するかは「作業の担い手が誰か」だけでなく、「意思決定と責任を誰が持つか」の設計問題です。

この視点を持ったうえで、次章の 6 工程分解に進むと、「どこまで任せられるか」の輪郭が具体的に見えてきます。

問い合わせフォーム営業代行の業務範囲｜6 工程で分解して「どこまで任せるか」を決める

ここが本記事の中核です。代行会社が担う業務は、次の 6 工程に分解できます。各工程について「代行会社が主に担う内容」と「発注者が持つべき責任」を整理し、最後に工程マトリクスの作り方を提示します。

【工程1】ターゲット企業選定（業種・所在地・従業員規模の絞り込み条件）

送信先とする企業群を、業種・所在地・従業員規模・売上規模などで絞り込む工程です。代行会社に任せる場合は、業種分類コード（日本標準産業分類の中分類・小分類レベルで指定できるか）、地域指定の粒度（都道府県・市区町村）、企業規模の下限・上限の指定可否を確認します。

発注者側に残るのは、「どのペルソナに刺さる提案なのか」の定義責任です。ターゲット選定条件は代行会社が絞り込みますが、その条件が自社サービスの受注可能性の高い企業群と一致するかは発注者にしか判断できません。ここを丸投げすると、条件は満たすがサービス提供が難しい企業に大量送信してしまうリスクが残ります。

【工程2】送信リスト作成（企業マスタの出所・重複除去・接触履歴照合）

工程 1 で定めた条件に沿って、実際の送信対象企業リストを作成する工程です。企業マスタの出所（自社データベースかスクレイピングか業界誌ベースか）、重複除去の方針、既に接触している企業（過去に商談履歴がある／別チャネルで接触済み）の除外可否を確認します。

過去に接触した企業への重複送信は、単に無駄なだけでなく信頼を毀損します。発注者側では、自社の CRM / SFA に登録された既接触企業リストを代行会社に共有できる仕組みを、契約前に設計しておく必要があります。

【工程3】送信文面作成・A/B 設計（テンプレートの版管理・法令チェック）

問い合わせフォームに投稿するメッセージ本文を作成する工程です。代行会社が文面作成まで担う「一気通貫型」もあれば、発注者が文面を用意し代行会社が添削のみを行うパターン、発注者の完全指定文面をそのまま送るパターンもあります。

法令面では、特定電子メール法の適用範囲は原則としてメール送信ですが、フォーム経由の営業行為であっても受信企業が「営業を受けたくない」と示している場合の配慮は必要です。文面テンプレートに複数バージョンを用意して A/B テストを行う場合、どのバージョンをいつ・どのセグメントに送ったかの版管理が代行会社と発注者の双方で追える状態が望ましいと考えられます。

【工程4】フォーム送信の実行（送信方式・CAPTCHA の扱い・エラー時の再送方針）

作成したリストと文面を使って、実際にフォームへ送信する工程です。ここで確認すべき論点が最も多く、後述する透明性 5 確認項目の中心にもなります。

• 送信方式: 完全自動（人手を介さない）／セミオート（入力自動化・送信は人）／完全人手のいずれか
• CAPTCHA の扱い: CAPTCHA が設置されたフォームで送信を試みるか、送信をスキップするか、突破ツールを使うか
• エラー時の再送方針: フォーム構造の変更・タイムアウト・入力項目のバリデーションエラーが発生した場合の対応

CAPTCHA は受信側が「機械的な送信を受け付けたくない」と示す意思表示の一種です。突破ツールを使う運用は、受信企業の意思表示を機械的に迂回する行為となり、発注者名義で送信される以上、信頼失墜リスクを発注者側が直接引き受ける構造になります。代行会社の CAPTCHA ポリシー（突破する／スキップする／手作業に切り替える）は、契約前に明示的に確認したい論点です。

【工程5】送信結果レポート（総送信件数だけか、ドメイン単位・時間帯単位・失敗理由単位で開示されるか）

送信結果を可視化する工程です。ここでレポート粒度が「総送信件数と成功率」だけの代行会社と、「ドメイン単位・時間帯単位・失敗理由単位」まで開示する代行会社の差が顕著に出ます。粒度が粗いほど、後で「実際にどの企業に送ったのか」を検証できなくなります。

発注者側では、CSV ダウンロードが可能か、ダウンロードに追加費用がかかるか、ダウンロード対象データに送信先ドメインが含まれるかを最初に確認しましょう。

【工程6】反応検知・フォローアップ（開封／クリック計測・メール返信検知・電話フォローの設計）

送信後の反応を追う工程です。開封・クリック計測（短縮 URL 経由）、返信メールの検知、電話フォローの実行までを代行に含めるかは分岐します。フォローアップまで一気通貫で任せると運用は楽ですが、返信内容が代行会社側で完結してしまい、発注者の営業担当が反応内容を直接見られない構造になりがちです。

反応検知はできるだけ発注者側で見える仕組みにし、フォローアップ実行のみを委託する切り分け方も選択肢になります。

工程マトリクスの作り方

6 工程が整理できたら、次のような表を作り、各工程を「必ず外注」「任意で外注」「自社で持つ」の 3 レイヤーで埋めていきます。これが発注要件書の骨格になります。

このマトリクスを埋めることで、代行会社に対する RFP（提案依頼書）の質問項目が自動的に定まります。次章の「支援範囲別 3 分類」は、このマトリクスの結果に応じて候補社を絞り込むための道具です。

支援範囲別の 3 分類｜「一気通貫型／送信＋文面添削型／送信専業型」で候補社を絞る

6 工程のうちどこまでを代行会社が担うかで、市場のサービスは大きく 3 分類に整理できます。前章の工程マトリクスと照らし合わせながら、自社の要件に合う分類を選びます。

一気通貫型（全 6 工程を代行）の適用シーンと注意点

工程 1〜6 のすべてを代行会社が担う形態です。ターゲット選定から反応検知・フォローアップまでを丸ごと委託できるため、社内にインサイドセールス人員が不在・立ち上げ期のフェーズで採用されやすい分類です。

一方、丸投げに近い委託形態のため、送信文面・送信先・反応内容が発注者側から見えなくなるブラックボックス化のリスクは最も高い分類でもあります。契約前に、後述する透明性 5 確認項目を全て満たすかを確認しておく必要があります。料金は最も高くなる傾向があり、月額固定型が中心です。

送信＋文面添削型（工程 3〜6 を代行）の適用シーンと注意点

ターゲット選定と送信リスト作成は発注者が持ち、文面作成の添削と送信以降を代行会社が担う分類です。自社のターゲットペルソナが明確で、既に企業リストの母集団を持っているが、送信作業を社内で行うリソースがない場合に適合します。

この分類の強みは、ターゲット選定の意思決定を発注者が握り続けられる点です。既接触企業への重複送信も、リストを発注者が握っているため事故が起きにくい構造になります。

送信専業型（工程 4 のみを代行）の適用シーンと注意点

工程 4「フォーム送信の実行」のみを代行し、その他の工程は発注者が持つ分類です。文面作成能力とリスト作成能力を社内に持つ組織が、「送信作業だけを外部の物量に切り出したい」場合に選ばれます。

料金は最も低くなる傾向があり、従量課金型（送信 1 件あたり単価）が中心です。ただし、送信のみを担う関係上、送信文面の法令チェックや反応検知の設計は完全に発注者側の責任になります。

3 分類の使い分けと「向いていない発注シーン」

3 分類のどれを選ぶかは、工程マトリクスで「自社で持つ」と判定した工程の数に対応します。「自社で持つ」が 0 個なら一気通貫型、2 個（ターゲット選定・リスト作成）なら送信＋文面添削型、5 個（送信以外全部）なら送信専業型、という対応関係です。

一方で、次のようなシーンは代行そのものが向かない可能性が高い場面です。

• 送信予定件数が月 100 件未満で、代行会社の最低契約単位に届かない
• 送信文面が高度な専門知識を要し、代行会社の文面添削では対応困難
• 社内のガバナンス上、送信履歴が代行会社のシステム内にのみ存在することが許容されない

上記に該当する場合は、次章以降で扱う代行会社選定のポイントに進む前に、自社 SaaS 運用や内製化の選択肢を検討するほうが妥当な場合があります。

代行会社選定のポイント｜料金体系と発注前チェックの最低限

支援範囲別 3 分類で候補が絞れたら、次は料金体系ごとの落とし穴と発注前チェックを押さえます。透明性関連の項目は次章の独立章に譲り、ここでは料金と契約条件のみに絞ります。

料金体系の 3 タイプ（月額固定・従量課金・成果報酬）とそれぞれの落とし穴

料金体系は大きく 3 タイプです。それぞれ「安く見えるが後で追加費用が膨らむパターン」を把握しておくと、稟議書に耐える比較ができます。

• 月額固定型: 月あたりの送信件数の上限が定められている。上限を超えた分は追加課金される契約が多いため、契約前に月次の想定送信件数を試算しておく必要があります
• 従量課金型: 送信 1 件あたりの単価が明示される。単価が安く見えても、リスト作成費用・レポート追加費用が別立てになっているケースがあります
• 成果報酬型: アポ取得 1 件あたり・返信 1 件あたりで課金される。成果の定義が発注者と代行会社でズレていると、想定より請求が膨らむ場合があります

「送信件数」の定義を発注前に揃える（送信済み／受信確認済み／到達済みの区別）

「送信件数」という言葉の定義は、代行会社によって異なります。代表的な区別は次のとおりです。

• 送信済み: フォームの送信ボタンを押した回数（送信が失敗した場合も含む定義がある）
• 受信確認済み: 送信後、代行会社側で受信完了ページの表示・エラーなし応答を確認した件数
• 到達済み: 上記に加え、返信メール等で受信企業側の到達を確認できた件数

契約書の「送信件数」がどの定義かによって、実質的な単価が数倍変わることがあります。RFP の段階で必ず定義を確認しましょう。

「成果」の定義を発注前に揃える（アポ／返信／リード獲得のいずれか）

成果報酬型を選ぶ場合、「成果 1 件」の定義を発注前に代行会社と揃えます。よくある定義は次のとおりです。

• アポ: 商談日時が確定した件数（キャンセル分の扱いも合意しておく）
• 返信: 受信企業から何らかのメール返信が届いた件数（自動返信・断り返信を含めるかを明示）
• リード獲得: 名刺情報・キーマン情報が取得できた件数

「返信」を成果とする定義は、断り返信も件数に含まれる可能性があるため、発注者側にとって望ましくない結果になりがちです。

最低契約期間・追加費用・解約条件の落とし穴

料金以外で見落としやすいのが、契約条件面です。

• 最低契約期間: 3 か月・6 か月・12 か月の最低契約期間が設定されている契約が多く、途中解約は違約金が発生する場合があります
• 追加費用: レポート追加発行・CSV ダウンロード・文面追加テンプレート作成が別料金の契約があります
• 解約条件: 解約希望月の前月末までに書面通知が必要など、解約タイミングに制約がある契約があります

発注前チェックリスト（料金関連 5 項目）

料金関連は、次の 5 項目を最低限確認しておくと稟議書に耐えます。

1. 月次の想定送信件数と料金体系の整合性（月額固定の上限に収まるか）
2. 「送信件数」の定義（送信済み／受信確認済み／到達済み）
3. 「成果」の定義（成果報酬型を選ぶ場合）
4. 最低契約期間と違約金の有無
5. レポート追加・CSV ダウンロード等の追加費用の有無

透明性確保の重要性｜「見える化」を担保するための最低限の 5 確認項目

ここが、過去に別チャネルの外注で送信結果が見えなくなった経験を持つ方にとって最重要の章です。代行に丸投げした結果としてブラックボックス化する典型パターンを 5 つに分解し、各項目について「なぜ問題か」「どう問うか」「危険な回答例」を示します。発注要件書と契約書に反映すべき条項として提示します。

【確認1】送信文面のコピー保管と版管理

なぜ問題か: 発注者ブランド（自社の会社名・サービス名）で送られた文面が、代行会社の内部システムだけに存在すると、後日「あの企業に何を送ったのか」を発注者側で検証できなくなります。受信企業から問い合わせやクレームが入った際に、送信内容を確認できないと対応が後手に回ります。

どう問うか: 「送信文面の全バージョンを、発注者側にも版管理された形（PDF またはドキュメントリンク）で共有いただけますか」「文面変更のたびに、変更履歴を発注者に通知いただけますか」と問います。

危険な回答例: 「送信文面は当社内で管理しており、共有はサンプルのみ」という回答は、後の検証が困難になる兆候です。

【確認2】送信先ドメインリストの共有可否

なぜ問題か: 誰に送ったのかが発注者側で把握できないと、既に自社と取引のある企業への重複送信・営業禁止指定企業への誤送信を検知できません。

どう問うか: 「送信を実行した企業のドメインリスト（または企業名リスト）を、送信の翌営業日までに共有いただけますか」「事前に送信除外リストを共有した場合、除外処理が実行された旨を証跡として確認できますか」と問います。

危険な回答例: 「送信先の詳細は当社の営業ノウハウのため、集計値のみ開示」という回答は、除外指示の実行を検証できない構造を意味します。

【確認3】配信停止依頼のフロー

なぜ問題か: 受信企業から「配信を停止してほしい」との連絡が来た場合、その依頼が代行会社側で完結してしまうと、発注者側では「どの企業から停止依頼が来たか」の履歴が残りません。同じ企業に別チャネルから連絡してしまう二次被害の原因になります。

どう問うか: 「配信停止依頼を受けた場合、代行会社の内部処理に加え、発注者にもドメイン単位で通知いただけますか」「配信停止対象企業のマスタは、発注者・代行会社の両側で参照可能ですか」と問います。

危険な回答例: 「配信停止対応は当社内で処理し、必要時に月次レポートで集計値のみ報告」という回答は、個別ドメインの追跡ができない構造を意味します。

【確認4】CAPTCHA の扱い

なぜ問題か: CAPTCHA は受信企業が「機械的な送信を受けたくない」と示す意思表示の一種です。代行会社が CAPTCHA を突破する運用を採用している場合、その送信は受信企業の意思に反する行為として、発注者名義で行われることになります。

どう問うか: 「CAPTCHA が設置されたフォームに対する対応方針は何ですか」「突破ツールを使用しますか、送信をスキップしますか、それとも手作業で送信しますか」と問います。

危険な回答例: 「CAPTCHA は自動突破ツールで対応しており、送信率は 95% 以上を維持」という回答は、受信側の意思表示を機械的に迂回する運用を意味します。

【確認5】送信結果レポートの粒度

なぜ問題か: 送信結果レポートが「総送信件数と成功率」だけの粒度だと、「どの時間帯にどのドメインに送ったか」「どの失敗理由がどれくらい発生したか」を追えません。改善のためのフィードバックループが機能しなくなります。

どう問うか: 「レポートには次の粒度を含みますか。(1) ドメイン単位、(2) 送信時間帯単位、(3) 失敗理由単位」「レポートは CSV でダウンロード可能ですか」と問います。

危険な回答例: 「レポートは月次で PDF 提供のみ、CSV は追加費用」という回答は、社内でのデータ活用と検証を困難にします。

以上 5 項目を発注要件書と契約書に条項として盛り込むことで、「任せた後に見えなくなる」構造を発注時点で回避できます。契約書のドラフトを代行会社が用意する場合でも、この 5 項目に関する条項の追加を発注者側から求めることは十分合理的な要求です。

自社運用ツール（SaaS）との比較｜「代行 vs 自社 SaaS 運用」の判断フロー

代行会社の分類・料金体系・透明性を押さえたら、次は「そもそも代行が最適か、自社で SaaS を運用したほうが良いのか」の判断フローに接続します。ここで扱う 5 つの判断軸は、上長への説明材料としてもそのまま使えます。

判断軸1: 送信量の月次規模（数百件／数千件／数万件で分岐）

月次の想定送信件数によって、選択肢の妥当性は大きく変わります。

• 数百件/月: 代行会社の最低契約単位に届かないケースがあり、自社 SaaS 運用または内製が現実的です
• 数千件/月: 代行と自社 SaaS 運用のどちらも成立する規模です。他の判断軸との組み合わせで決めます
• 数万件/月: 代行の物量メリットが効きやすい規模ですが、レポート粒度と透明性の担保はより厳密に確認する必要があります

判断軸2: 社内のインサイドセールス人員の有無と学習コスト

社内に SaaS を運用できる人員がいるかを見極めます。自社 SaaS 運用は、送信リスト作成・文面設計・レポート分析を担う担当者が必要です。専任 1 名を確保できない場合、SaaS を導入しても稼働しない可能性が高くなります。

一方、担当者を確保できる場合は、自社 SaaS 運用のほうが「見える化」と「ノウハウの社内蓄積」の面で優位性があります。

判断軸3: 見える化要件の重要度（社内ガバナンス・法務要求の厳しさ）

送信履歴・送信文面・送信先ドメインが発注者側の管理下に置かれることを、社内ガバナンス上どの程度求められるかを整理します。上場企業の子会社・金融業・医療業など、コンプライアンス要件が厳しい業界では、送信履歴が外部の代行会社のシステム内にのみ存在することが許容されないケースがあります。

見える化要件の厳しさが高い場合、自社 SaaS 運用のほうが要件を満たしやすい傾向があります。

判断軸4: 送信ガバナンス要件（送信除外・CAPTCHA 方針・組織単位データ分離の自社ポリシー）

自社として、次のようなポリシーを持つかを確認します。

• 送信除外: 取引先・別チャネルで既に接触した企業への送信を、機械的に除外できる仕組みが必要か
• CAPTCHA 方針: CAPTCHA が設置されたフォームへの送信を、突破せずスキップする運用を採用したいか
• 組織単位データ分離: 事業部単位・子会社単位で送信先リスト・送信履歴を分離管理したいか

これらのポリシーを明文化して持つ組織では、代行会社に運用を委ねると自社ポリシーの遵守を検証しにくくなります。自社 SaaS 運用であれば、こうしたガバナンス要件を自社の運用ルールとして直接コントロールできる利点があります。

弊社（秋霜堂株式会社）が提供する Form Pilot は、送信除外 API 連携を fail-closed を基本とする設計にし、CAPTCHA の突破は行わず、マルチテナントで組織単位のデータ分離を提供する SaaS です。「発注者側で送信ガバナンスを自分でコントロールしたい」というポリシーを持つ組織にとって、代行の代替案として検討する選択肢の 1 つになります（詳細は本記事末尾の CTA を参照）。

判断軸5: 継続運用予定期間（試験導入か長期運用か）

3〜6 か月の試験導入か、1 年以上の長期運用かで、選択肢の妥当性は変わります。試験導入なら代行の月額固定型のほうが立ち上げコストを抑えられます。長期運用なら自社 SaaS 運用のほうが、運用ノウハウが社内に蓄積される分、中長期的な費用対効果は良くなる傾向があります。

代行が向くケース／自社 SaaS 運用が向くケース／併用が向くケース

5 つの判断軸を整理すると、次のように大別できます。

• 代行が向くケース: 社内にインサイドセールス人員なし・見える化要件は中程度・試験導入・月次数千件規模
• 自社 SaaS 運用が向くケース: 担当者を確保できる・見える化要件が高い・送信ガバナンス要件が明確・長期運用前提
• 併用が向くケース: 一気通貫型代行で立ち上げ、運用が回り始めた段階で自社 SaaS 運用に段階的に切り替え

代行と自社 SaaS 運用を「敵対する選択肢」と見なす必要はありません。導入初期は代行、成熟後は自社 SaaS 運用という段階移行も現実的な設計です。

発注後の運用で「見える化」を保つ 3 つの運用ルール

発注時点で良い代行会社を選定できても、運用開始後に「見える化」が形骸化してしまうケースは少なくありません。発注後に発注者側で守るべき運用ルール 3 つを、稟議書の運用条項として盛り込むことを推奨します。

【運用1】週次で送信先ドメインリストと送信文面の版履歴を共有してもらう

透明性 5 確認項目のうち【確認1】【確認2】に対応する運用ルールです。「共有します」という契約条項があっても、実運用で共有されなければ意味がありません。週次の定例レビューで、送信先ドメインリスト（当該週に送信した企業のドメイン一覧）と送信文面の版履歴（当該週に使用した文面のバージョン）を必ず共有してもらう運用にします。

共有形式は、代行会社側の管理画面へのアクセス権付与・CSV でのメール送付・共有ドライブへのアップロードなどが考えられます。発注者側で長期保管できる形式を優先します。

【運用2】送信履歴を CSV でダウンロードできる形にし社内で保管する

透明性 5 確認項目のうち【確認5】に対応する運用ルールです。代行会社の管理画面で閲覧できるだけでは、代行会社との契約が終了した後に履歴が参照できなくなります。契約期間中に、送信履歴を月次で CSV ダウンロードし、社内の共有ドライブ（アクセス権を管理された場所）に保管する運用を組み込みます。

契約終了時の履歴引き渡し条項も、契約書に含めておくことを推奨します。

【運用3】配信停止依頼のログを月次でレビューし KPI 再定義に反映する

透明性 5 確認項目のうち【確認3】に対応する運用ルールです。配信停止依頼が特定業界・特定規模の企業に集中している場合、ターゲット選定条件そのものを見直す必要があります。月次レビューで、配信停止依頼が発生した企業のドメイン・業界・規模を集計し、送信対象ターゲットの絞り込み条件に反映する運用ループを回します。

このループを回さないと、「送信量は増えたが受注貢献しない」状態が続き、KPI 上の成果が上がらない典型的な失敗パターンに陥ります。

まとめ｜業務範囲を分解 → 支援範囲別 3 分類 → 透明性 5 確認項目で「任せる／持つ」を設計する

問い合わせフォーム営業代行の検討は、個社比較の前に「業務範囲の分解」と「支援範囲の設計」から始めるのが本記事の主張です。改めて、本記事で提示した骨格を要約します。

• 業務範囲を 6 工程で分解: ターゲット選定・リスト作成・文面作成・送信実行・レポート・フォローアップの 6 工程で「必ず外注／任意で外注／自社で持つ」を決める
• 支援範囲別 3 分類で候補社を絞る: 一気通貫型／送信＋文面添削型／送信専業型のいずれかで市場を絞り込む
• 料金体系の 3 タイプで落とし穴を回避: 月額固定・従量課金・成果報酬それぞれの「送信件数の定義」「成果の定義」「最低契約期間」を発注前に揃える
• 透明性 5 確認項目を RFP の質問項目にする: 送信文面の版管理・送信先ドメインの共有・配信停止依頼のフロー・CAPTCHA の扱い・レポートの粒度を条項として盛り込む
• 代行 vs 自社 SaaS 運用は 5 軸で判断: 送信量・人員・見える化要件・送信ガバナンス要件・継続運用予定期間で判断フローを組む
• 発注後の運用ルール 3 つで見える化を維持: 週次共有・CSV 保管・月次配信停止レビューを稟議書の運用条項として明文化する

次のアクションとしては、次の 4 つが自然な流れになります。

1. 6 工程マトリクスを埋めて、発注要件書の骨格を作る
2. 支援範囲別 3 分類のうちどれに合うかを判定し、候補社を 3 社程度に絞る
3. 透明性 5 確認項目を RFP の質問項目に転記する
4. 代行と自社 SaaS 運用を同じ物差しで判断フローに載せ、上長への提案書を作成する

代行と自社 SaaS 運用のどちらを選ぶかの検討は、「送信ガバナンスを誰がコントロールするか」の設計問題でもあります。「発注者側で送信除外・CAPTCHA 方針・組織単位データ分離を自分でコントロールしたい」というポリシーを持つ組織向けの選択肢として、弊社の SaaS も次のセクションでご紹介します。

関連情報｜Form Pilot（AI フォーム営業自動化 SaaS）

代行以外の選択肢として、送信ガバナンスを発注者側で直接コントロールしたい場合は、弊社が提供する SaaS「Form Pilot」もご検討ください。送信除外 API 連携を fail-closed を基本とする設計にし、CAPTCHA の突破は行わず、マルチテナントで組織単位のデータ分離を提供しています。サービス概要は Form Pilot サービスページ をご覧ください。

発注要件書の骨格作成・透明性を担保する契約条項の設計について、社内での検討を進めるうえでご相談されたい場合は、お問い合わせフォーム からご連絡ください。要件の整理段階からご相談いただけます。