フォーム営業ツールのRFPテンプレート｜要件18項目と書き方

フォーム営業ツールのデモを3社受けたのに、比較表が作れない。A社は「1時間あたりの送信件数」を、B社は「リストの網羅性」を、C社は「月額の安さ」を前面に出してきて、そもそも同じ項目が並んでいない。この状態で「どれが一番いいのか」を上司に聞かれても、答えられるのは「印象」だけです。

こうなる理由は単純で、比較の土俵を自分たちで作っていないからです。ベンダーは自社が勝てる指標で語るのが当たり前ですから、こちらが同じ質問状を出さない限り、回答は永遠に噛み合いません。その質問状にあたるのが RFP（提案依頼書）です。

ところが、Web で配布されている汎用の RFP テンプレートをダウンロードしても、手は止まります。章立てや書式は書いてあるのに、肝心の「機能要件」欄は空白のまま渡されるからです。フォーム営業ツールという特定カテゴリで、何を聞けば各社の差が浮かび上がるのか。そこを埋めてくれる資料が見つかりません。一方でツール比較記事は「おすすめ○選」でツールを並べるだけで、自社がベンダーに投げる質問の設計には踏み込みません。

その空白を埋めるのが本記事の目的です。フォーム営業ツールの RFP に載せるべき要件を、機能要件9項目・ガバナンス要件6項目・費用契約要件3項目の計18項目に整理し、それぞれについて「ベンダーにそのまま投げられる質問文」と「回答のどこを見れば差が出るか」を対にして提示します。

あわせて、7章構成の RFP テンプレート全体像、回答を点数化する評価シートの作り方、RFP 送付から社内決裁までの進め方まで通しで解説します。読み終える頃には、当日中にドラフトを書き上げて同一フォーマットで各社に送付できる状態を目指します。

フォーム営業ツールのRFP（提案依頼書）が必要になる場面

RFP（Request for Proposal／提案依頼書）とは、発注側が自社の課題・要件・前提条件を文書にまとめ、複数のベンダーへ同じ内容で提示して提案を求める文書です。目的は「良い提案をもらうこと」だけではありません。全社に同一の問いを投げることで、回答を横並びに置ける状態を作ることが本質的な役割です。

営業ツールの領域で rfp（提案依頼書）を営業ツールの選定に用いる場面は、おおむね次の3つに集約されます。

1. 購買規程で複数社からの提案書取得が義務づけられている場合。一定額以上の SaaS 契約には相見積もりや提案書の保管が必要と定める企業は多く、提案依頼の起点として RFP が求められます。
2. 情シス・法務の審査が入る場合。データの保管場所、権限管理、ログの保持期間といった項目は、口頭のデモでは記録が残りません。書面で回答させて初めて審査の対象になります。
3. デモだけでは実態が見えない場合。フォーム営業ツールは「送信できる」ところまでは各社同じように見えて、送れなかったときの挙動や、送ってはいけない相手をどう弾くかに製品差が出ます。この差はデモの成功シナリオでは表面化しません。

RFP・RFI・要件定義書・稟議書の違い

選定の過程で登場する文書は名前が似ていて混同しやすいため、「誰に向けた文書か」「何を確定させる文書か」で整理しておきます。

本記事が扱うのは2行目の RFP、つまり社外へ出す質問状です。選定結果を社内で通すための文書は別物なので、フォーム営業ツール導入の稟議書テンプレートを参照してください。RFP の回答と評価シートは、そのまま稟議書の「選定理由」欄の根拠になります。

なお、候補がまだ十数社ある段階でいきなり RFP を投げると、回答の作成負荷が高すぎて辞退が増えます。候補の広い把握は RFI や公開情報の調査で済ませ、3〜5社に絞ってから RFP に進むのが現実的です。

RFPを出さずにデモだけで決めたときに起きること

RFP を省略してデモと見積書だけで決めた場合、次の2つが典型的に起きます。

ひとつは、訴求軸の不一致がそのまま残ることです。各社は自社の強い指標だけを提示するため、比較表を作ろうとすると空欄だらけになります。空欄を埋めるために追加ヒアリングを繰り返すことになり、結局 RFP を作るより時間がかかります。

もうひとつは、導入後に前提のズレが判明することです。たとえば「自動でフォーム送信できます」という説明を受けて契約したあとに、CAPTCHA が設置されたフォームでは自動送信が止まる仕様だと分かる。あるいは、接触済みの企業を送信対象から外す機能は「リストを手動でアップロードする運用」だと後から知る。いずれもデモの成功シナリオでは触れられない部分です。

この2つ目が、選定担当者にとっては重い問題になります。導入を推したのは自分であり、運用開始後に想定と違うと分かったときに説明を求められるのも自分だからです。書面で回答をもらっておけば、少なくとも「何をどう確認したうえで選んだか」を示せます。RFP は良い製品を引き当てるための道具である以上に、判断の過程を残すための道具でもあります。

汎用RFPテンプレートがフォーム営業ツールで機能しない理由

汎用の RFP テンプレートが役に立たないわけではありません。章立て（依頼概要／現状と課題／要求要件／選定プロセス）や、提案書式の指定、スケジュールの書き方といった枠組みは、そのまま流用できます。行き詰まるのは決まって「機能要件」の欄です。

機能要件の欄が埋まらないのは、業務要件から落とせない項目があるため

汎用テンプレートの多くは「業務要件から機能要件へ落とし込む」という手順を示します。自社の業務フローを書き出し、そこで必要になる機能を列挙する、という考え方です。この手順は基幹システムのように、業務が先にあって道具が後から来る領域ではうまく機能します。

しかしフォーム営業ツールでは、この手順だけでは埋まらない項目が残ります。理由は、製品差が出る部分の多くが「うまくいかなかったときの挙動」に宿っているからです。自社の業務フローを書き出しても、「フォームが見つからなかったとき」「送信先が接触済みかどうか判定できなかったとき」「送信が失敗したとき」に何が起きてほしいかは、その製品の設計を知らないと要件として言語化できません。

つまりフォーム営業ツール 選定 基準を業務側から演繹するには限界があり、カテゴリ固有の論点リストを外から持ち込む必要があります。比較軸そのものの考え方を整理したい場合は営業ツール選定の比較軸が参考になります。本記事はそこから一歩進めて、比較軸を「ベンダーに投げる質問文」に変換する工程を扱います。

もうひとつ押さえておきたいのが、SaaS 選定特有の前提です。SaaS は標準機能に業務を合わせる前提で作られているため、「現行の運用をそのまま再現できるか」を要件に並べると、どのベンダーもカスタマイズ見積を出してきて比較が成立しなくなります。要件は「何を実現したいか」の水準で書き、実現手段はベンダーの提案に委ねる書き方にしてください。

製品差が最も大きい3軸

フォーム営業ツールで各社の設計思想がもっとも分かれるのは、次の3軸です。RFP で聞かないまま契約すると、後から前提のズレとして表面化しやすい部分でもあります。

1. 送信の実行方式

完全自動送信、セミオート（入力までを自動化し送信は人が行う）、手作業補助、人手による代行といった方式があり、同じ「フォーム営業ツール」という名前でも中身が異なります。方式が違えば、1日に処理できる量も、運用に必要な人員も、社内の承認プロセスも変わります。

2. CAPTCHA の扱い

CAPTCHA（「私はロボットではありません」の認証）が設置されたフォームをどう扱うかは、製品の設計思想が最も端的に現れる部分です。突破を試みる製品もあれば、突破せず人の操作に切り替える製品もあります。どちらの設計かによって、送信可能なフォームの範囲も、受信企業との関係で自社が負うリスクも変わります。

3. 送信除外の運用

すでに他社が接触している企業や、送ってはいけない相手をどう除外するかです。除外リストを自社で用意して手動アップロードする方式、外部のデータと突合する方式、除外機能自体を持たない製品と幅があります。ここが弱いと、接触済みの企業に重ねて送ってしまい、信頼を損なう事故につながります。

この3軸は、カタログのスペック表には載りません。だからこそ RFP の質問項目として明示的に書く価値があります。

フォーム営業ツールのRFPテンプレート｜7章構成と18項目の全体像

ここからが本記事の中核です。フォーム営業ツール rfp 項目を、7章構成の RFP テンプレートに配置した全体像を示します。まず俯瞰してから、章ごとの書き方に進みます。

7章構成の全体マップ

18項目を3章に振り分けているのは、社内の審査担当者が分かれるためです。機能要件は営業部門、ガバナンス要件は情シスと法務、費用契約要件は購買と経理が主に見ます。章を分けておくと、回答が返ってきた後にそのまま各部門へ回覧できます。

冒頭2章（依頼概要・現状と課題）の書き方と記入例

1章と2章には要件項目を割り当てていませんが、ここの記述が薄いと3章以降の回答の質が落ちます。ベンダーは自社の状況を知らないため、前提が書かれていなければ最大公約数の提案しか返せないからです。

1章（依頼概要）の記入例

当社は BtoB 向けの〇〇（商材カテゴリ）を提供しており、従業員数は約〇〇名です。本提案依頼書は、当社のアウトバウンド営業における問い合わせフォーム経由のアプローチを仕組み化することを目的に、フォーム営業ツールの導入提案を依頼するものです。提案の範囲は、ツールの機能・運用体制・費用・導入支援を含みます。本書および提案書に記載された内容は、双方の秘密情報として取り扱います。

2章（現状と課題）の記入例

現在、インサイドセールス担当〇名が、企業リストをスプレッドシートで管理し、各社の問い合わせフォームに手作業で入力・送信しています。課題は次の3点です。（1）送信作業に工数が集中し、他の営業活動に時間を割けない。（2）送信先リストが担当者ごとに分かれて管理されており、接触済みかどうかの確認が属人化している。（3）送信後の反応を追う仕組みがなく、フォローアップの判断が担当者の記憶に依存している。想定する利用規模は、月間の送信対象〇〇社、利用アカウント〇名です。

利用規模（想定送信数・アカウント数）を書いておくと、5章の費用回答で各社が同一条件の試算を出しやすくなります。ここを空欄にすると、各社が異なる前提で見積もるため、後から条件を揃え直す手間が発生します。

Must / Want / Future の3分類で要件に優先度を付ける

18項目すべてを「必須」として出すと、どれか1つでも満たせないベンダーは辞退するか、無理な回答を書いてきます。どちらも比較の妨げになるため、要件には優先度を付けます。

実務上の目安として、Must は18項目のうち5〜7項目程度に絞ると比較が機能しやすくなります。Must が多すぎると候補が残らず、少なすぎると足切りが働きません。

重要なのは、この分類を RFP を送付する前に確定させておくことです。提案書を受け取ってから優先度を決めると、特定ベンダーの提案内容に引きずられて評価の公平性が損なわれます（RFPの評価基準とは？失敗しないベンダー選定を実現する作り方と評価項目）。分類表は RFP 本体に記載して各社に開示しても構いませんし、社内資料として持っておくだけでも構いません。開示すると、ベンダーは Must 部分を厚く書いてくるため、回答の焦点が絞られます。

機能要件で聞くべき9項目｜送信方式とCAPTCHA対応

ここからが、汎用テンプレートでは空白のまま渡される部分です。フォーム営業ツール 機能要件として押さえるべき9項目を、質問文例と「回答に差が出るポイント」の対で示します。質問文はそのまま RFP に貼り付けて使える形で書いています。

送信の実行方式とCAPTCHA対応（項目1〜2）

項目1｜送信の実行方式

• 質問文例: 「貴社ツールにおけるフォーム送信の実行方式をご教示ください。完全自動送信・入力自動化と人による送信の組み合わせ・その他のいずれに該当するか、また方式が対象フォームによって切り替わる場合はその条件をご記載ください。」
• 回答に差が出るポイント: 「自動送信できます」だけの回答は情報量がゼロです。どの条件下で自動が成立し、どの条件で人の操作が必要になるかまで書かれているかを見ます。方式が切り替わる条件を明示している回答は、運用設計を具体的に詰められます。

項目2｜CAPTCHA への対応方針

• 質問文例: 「CAPTCHA 等の自動送信防止機構が設置されたフォームに対する貴社ツールの対応方針をご教示ください。突破を行うか否か、行わない場合の代替手段、および CAPTCHA 設置フォームが送信対象全体に占める割合の想定をご記載ください。」
• 回答に差が出るポイント: フォーム営業 captcha の扱いは、製品の設計思想が最も分かれる論点です。突破する設計なのか、突破せず人の操作に切り替える設計なのかで、送信できるフォームの範囲も、自社が受信企業に対して負うリスクも変わります。回答が曖昧な場合は、契約前に必ず書面で確認しておくべき項目です。

この項目について、Form Pilot の設計を例として補足します。Form Pilot は CAPTCHA の突破を行いません。CAPTCHA 等で完全な自動送信ができないフォームでは、Chrome 拡張機能が入力までを自動化し、送信ボタンは人が押すセミオート方式に切り替わります。CAPTCHA は受信側が「機械的な送信を受けたくない」と示す意思表示であり、それを迂回する行為は送信元である利用企業の名前で行われることになる、という判断に基づく設計です。他社ツールの方針はそれぞれの公式情報でご確認ください。

フォーム発見・入力・リスト作成（項目3〜5）

項目3｜問い合わせフォームの自動発見の対象範囲

• 質問文例: 「企業の Web サイトから問い合わせフォームを自動で発見する機能の有無と、その対象範囲をご教示ください。発見できなかった場合の挙動（スキップ・手動登録の案内・エラー通知等）についても併せてご記載ください。」
• 回答に差が出るポイント: 発見率そのものより、発見できなかった企業がどう処理されるかに運用負荷の差が出ます。黙ってスキップされる設計だと、送ったつもりで送れていない企業が積み上がります。

項目4｜入力項目マッピングの精度と手動補正

• 質問文例: 「フォームの入力項目（会社名・氏名・メールアドレス・問い合わせ内容等）を自動で判別しマッピングする仕組みをご教示ください。誤ったマッピングが発生した場合の検知方法と、手動での補正手段の有無を併せてご記載ください。」
• 回答に差が出るポイント: マッピング誤りは、相手企業に不自然な内容が届く事故につながります。誤りを事前に検知できるか、送信前にプレビューできるか、という点を見ます。

項目5｜営業リストの作成・取り込み方式

• 質問文例: 「送信対象となる企業リストの作成方式をご教示ください。ツール内蔵の企業データベースから業種・所在地等の条件で絞り込めるか、外部で作成したリストの取り込みが前提か、両方に対応するかをご記載ください。取り込み可能なファイル形式と、1回あたりの上限件数も併せてお願いします。」
• 回答に差が出るポイント: 内蔵データベースを持つ製品は、リスト作成サービスを別途契約しなくて済みます。一方で内蔵データの鮮度・カバー範囲には差があるため、対象業種が自社のターゲットと合うかを確認します。

送信制御・記録・計測・フォローアップ（項目6〜9）

項目6｜送信スケジュールと配信量の制御

• 質問文例: 「送信のスケジュール設定機能について、どのリストに・どの文面を・いつ送るかを事前に登録できるか、また1日あたりの送信量の上限設定が可能かをご教示ください。実行状況を管理画面で確認できるかも併せてご記載ください。」
• 回答に差が出るポイント: 量の上限を制御できるかは、受信企業への配慮と、社内での運用管理の両面で効きます。「一斉に送るしかない」製品は、送信ペースの調整ができません。

項目7｜送信結果の記録と失敗診断

• 質問文例: 「送信の成否がどのように記録されるか、および失敗した場合にその理由を確認できる仕組みの有無をご教示ください。失敗理由の分類（フォーム構造の変更・必須項目の不足・送信拒否等）が提示されるかを併せてご記載ください。」
• 回答に差が出るポイント: 失敗理由が分類されて出る製品は、リストや文面の改善に接続できます。「送信済み／未送信」の2値しか返さない製品は、なぜ届かなかったかを人が調べ直すことになります。

項目8｜開封・クリックの計測

• 質問文例: 「送信した内容に対する開封・クリックの計測機能の有無と、その計測方式（短縮 URL の付与等）をご教示ください。計測結果を管理画面およびエクスポートで確認できるかを併せてご記載ください。」
• 回答に差が出るポイント: 計測の有無は、フォローアップの判断を仕組み化できるかを左右します。計測方式まで書かれていれば、自社の文面設計と整合するかを事前に検討できます。

項目9｜返信検知とフォローアップ分岐

• 質問文例: 「送信先からの返信を検知し、送信履歴と紐づけて確認する機能の有無をご教示ください。また、反応の有無に応じてフォローアップの内容を分岐させるシナリオ設計機能の有無を併せてご記載ください。連携可能なメールサービスがある場合はその範囲もお願いします。」
• 回答に差が出るポイント: 返信が送信履歴と紐づかない製品では、反応があった企業の把握が担当者の受信箱に依存します。連携可能なメールサービスの範囲は、自社の環境と合うかを必ず確認してください。

ガバナンス要件で聞くべき6項目｜送信除外とログ管理

ここから先は、導入後に社内で問題化しやすい「リスク側」の項目です。フォーム営業ツール セキュリティ要件として情シス・法務の審査対象になる部分でもあり、RFP の段階で書面回答を得ておくと、契約直前に審査で止まる事態を防げます。

質問の書き方には一点コツがあります。詰問の形にせず、自社の運用要件として提示することです。「〜は可能ですか」ではなく「当社では〜という運用を想定しています。貴社ツールでの実現方法をご教示ください」という形にすると、ベンダー側も防御的にならず、具体的な回答が返ってきやすくなります。

送信除外と、判定できないときの挙動（項目10〜11）

項目10｜接触済み企業の送信除外運用

• 質問文例: 「当社では、すでに他のチャネルや取引関係で接触のある企業を送信対象から除外する運用を想定しています。貴社ツールにおける除外リストの管理方法、除外データの取得元（自社で用意したリストの取り込みか、外部データとの突合か）、および除外判定が行われるタイミングをご教示ください。」
• 回答に差が出るポイント: 除外機能の有無そのものより、除外データをどこから得るかに差が出ます。自社リストの手動アップロードのみの場合、リストの更新は運用側の作業になります。外部データと突合する仕組みがある場合は、その取得元と更新頻度を確認してください。

項目11｜判定できない場合の挙動

• 質問文例: 「除外判定に必要な情報が取得できなかった場合、または判定処理が正常に完了しなかった場合の挙動をご教示ください。送信を実行する設計か、送信を保留する設計か、設定で切り替え可能かをご記載ください。」
• 回答に差が出るポイント: この質問への回答が、そのベンダーの設計思想を最も正確に映します。判定できないときに送ってしまう設計は、送信数を優先した設計です。保留する設計は、安全側に倒した設計です。どちらが自社の方針に合うかを判断してください。

Form Pilot は、他社（取引先・別チャネル）が接触済みの企業ドメイン一覧を外部 API から取得し、送信リストと突合して該当企業への送信を回避する設計を採っています。判断できない場合には送らない方向に倒すことを基本としています。

文面審査・データ分離・監査ログ（項目12〜14）

項目12｜送信文面の審査・NG表現チェック

• 質問文例: 「送信する文面について、事前の審査・チェック機能の有無をご教示ください。禁止表現や不適切な記載を検知する仕組みがある場合はその方式、承認者による事前承認フローを設定できる場合はその設定範囲をご記載ください。」
• 回答に差が出るポイント: 複数名で運用する場合、文面の品質を人のレビューだけで担保するのは難しくなります。承認フローを組める製品は、担当者が増えても文面の統制を保てます。

項目13｜組織単位のデータ分離と権限管理

• 質問文例: 「当社では部門ごとに送信先リスト・送信履歴を分離して管理する運用を想定しています。組織・部門単位でのデータ分離の可否、およびユーザー権限の設定粒度（閲覧・編集・送信実行・管理設定等）をご教示ください。」
• 回答に差が出るポイント: 権限の粒度が粗い製品では、全員が全データを見られる状態になります。営業代行・BPO のようにクライアントごとの分離が必要な場合は、この項目を Must に置くべきです。

項目14｜操作ログ・監査証跡の保持

• 質問文例: 「誰がいつどの操作を行ったかを記録する操作ログの有無、記録対象となる操作の範囲、保持期間、およびエクスポート可否をご教示ください。」
• 回答に差が出るポイント: 保持期間とエクスポート可否は、情シスの審査で必ず問われます。「ログはあります」だけの回答では審査を通せないため、期間と出力形式まで書かせてください。

データ分離・権限・ログの3点は、フォーム営業ツールに限らず営業ツール全般の審査項目と重なります。情シスに提出する観点を整理する段階であれば、営業ツール導入前のセキュリティチェックリストの項目を RFP の4章に転記するのが効率的です。

Form Pilot はマルチテナント設計を採用しており、企業リスト・送信履歴・文面は組織単位で分離され、他の組織からは参照できません。

法令順守と受信企業からの停止依頼への対応（項目15）

項目15｜法令順守の考え方と停止依頼への対応

• 質問文例: 「貴社ツールを用いた送信活動に関して、遵守が必要と考える法令・ガイドラインについての貴社の見解をご教示ください。また、受信企業から送信停止の申し出があった場合に、当該企業を以後の送信対象から除外するための手順と、ツール上の対応機能の有無を併せてご記載ください。」
• 回答に差が出るポイント: 法令解釈そのものはベンダーの回答をもって確定するものではなく、最終的には自社の法務・顧問弁護士の判断領域です。ここで見るべきは、ベンダーがこの論点を認識し、機能として手当てしているかです。停止依頼を受けた企業を再送信対象から確実に外す手順が用意されているかは、実務上もっとも効く部分です。

関連する法令としては、広告宣伝目的の電子メール送信を規律する特定電子メールの送信の適正化等に関する法律（総務省・消費者庁の共管、消費者庁の解説ページ）や、取得した担当者情報の取り扱いに関わる個人情報の保護に関する法律（個人情報保護委員会）が挙げられます。問い合わせフォームからの送信がこれらの適用対象にどう位置づけられるかは送信の態様によって整理が分かれる論点のため、自社の法務部門に確認したうえで RFP の記載内容を決めてください。RFP の役割は解釈を確定させることではなく、ベンダーの認識と機能面の手当てを文書として残すことにあります。

費用・契約・サポート要件で聞くべき3項目

見積書の総額だけを並べても比較にはなりません。各社が異なる前提で算定しているため、同じ金額でも中身が違うからです。営業ツール 料金体系 比較を成立させるには、算定の単位と条件を RFP 側で指定する必要があります。

料金体系は「算定単位」を揃えて聞く（項目16）

項目16｜料金体系と従量課金の算定単位

• 質問文例: 「料金体系をご教示ください。固定費・従量課金の内訳、従量課金がある場合の算定単位（送信試行件数・送信成功件数・対象企業数・利用アカウント数のいずれか）、および最低利用料金の有無をご記載ください。あわせて、当社の想定規模（月間送信対象〇〇社／利用アカウント〇名）での月額総額を試算いただけますでしょうか。初期費用・オプション費用が発生する場合は内訳を分けてご提示ください。」
• 回答に差が出るポイント: 算定単位の指定が、この質問の要です。「送信試行件数」で課金する製品と「送信成功件数」で課金する製品では、フォーム発見率や送信成功率が低い場合に総額が大きく変わります。また、想定規模での試算を求めることで、各社の見積が同一条件になります。初期費用とオプションを分けさせるのは、後から追加費用が判明する事態を防ぐためです。

費用相場そのものの把握にはフォーム営業ツールの費用相場が参考になります。本記事で扱うのは、相場感ではなく「比較可能な形で見積を集める聞き方」です。

なお Form Pilot の料金は送信数に応じた従量制を予定していますが、詳細は未確定です。

契約条件とサポート体制（項目17〜18）

項目17｜最低利用期間・解約条件・データ返還

• 質問文例: 「契約期間の単位、最低利用期間の有無、解約時の申し出期限、および中途解約時の費用精算の扱いをご教示ください。あわせて、契約終了時に当社が登録した企業リスト・送信履歴・文面等のデータを返還またはエクスポートする手段と、ベンダー側でのデータ削除の取り扱いをご記載ください。」
• 回答に差が出るポイント: 最低利用期間は、月額単価が安く見える製品ほど長く設定されている場合があります。総額で比較するには、最低利用期間を掛けた金額で並べる必要があります。データの返還手段は、将来の乗り換え可能性を確保する意味でも確認しておく項目です。

項目18｜導入支援と運用サポートの範囲・体制

• 質問文例: 「導入時の支援内容（初期設定の代行範囲・トレーニングの有無と回数・リスト作成支援の有無）と、運用開始後のサポート体制（問い合わせ窓口の種別・受付時間・障害時の連絡手段・専任担当の有無）をご教示ください。これらが基本料金に含まれるか、別途費用となるかを併せてご記載ください。」
• 回答に差が出るポイント: 「サポートあります」の一言で終わる回答と、窓口種別・受付時間・費用区分まで書かれた回答では、運用開始後の実態が大きく異なります。基本料金に含まれるかどうかの明示を求めることで、項目16の試算との整合も取れます。

ベンダー回答を横並びで比較する評価シートの作り方

回答が返ってきたら、rfp 評価シートに落として点数化します。ここまで来れば「なぜこのツールを選んだか」を説明できる状態になります。

評価スケールと点数の状態定義

評価スケールは3段階または5段階が実務的です。重要なのは点数の刻み方ではなく、各点数がどういう状態を指すかを事前に定義しておくことです。定義がないと、評価者によって同じ回答に違う点が付き、合議で揉めます。

5段階にする場合は「3」と「2」の間に細分を設けます。18項目すべてに同じスケールを適用し、Want 項目のみ合計します。項目ごとに重み（×2 など）を設定する場合も、重みは RFP 送付前に決めておいてください。

評価者は1名ではなく、機能要件を営業部門、ガバナンス要件を情シス・法務、費用契約要件を購買が担当する形で分担すると、評価の妥当性が上がります。分担する場合も、状態定義の表は全員で共有します。

Must未充足は合計点の前に落とす（二段階判定）

点数化で起きやすい失敗が、合計点の高さで Must 未充足を覆してしまうことです。Want で高得点を取ったベンダーが、Must の除外機能を満たしていないのに合計点で1位になる、というケースです。

これを防ぐため、判定は二段階で行います。

1. 第一段階（足切り）: Must に指定した項目を確認し、1つでも未充足（0点）があれば、合計点に関わらず候補から外す
2. 第二段階（比較）: 第一段階を通過したベンダーのみ、Want 項目の合計点で順位を付ける

この手順を評価シートの先頭に明記しておくと、合議の場で「総合点では A 社が上だが」という議論に流れずに済みます。第一段階で候補が全社落ちた場合は、Must の設定が厳しすぎる可能性があるため、要件側を見直します。

点数を歪める回答パターンと対処

書面回答には、そのまま点数化すると比較を歪めるパターンがいくつかあります。評価前に次の3つを確認してください。

「対応予定」「次期リリースで対応」の回答

現時点で使えない機能を、使える機能と同点で扱ってはいけません。リリース時期が契約書等で確約されていない限り、0点または1点として扱い、備考欄に「〇年〇月対応予定との回答」と記録します。時期が明示されている場合でも、その時期に自社の運用が始まるかを確認してください。

「可能です」だけで根拠が示されない回答

仕組み・条件・制約が書かれていない回答は、満点にしません。2点（条件付き充足）に置き、質問受付期間または提案説明会で追加確認します。追加確認で具体的な回答が得られた場合のみ、加点します。

質問の趣旨をずらした回答

たとえば項目11（判定できない場合の挙動）に対して「除外機能があります」と答える、といったケースです。聞いた内容に答えていない回答は、未回答として扱います。全社に同じ質問を出している以上、1社だけ趣旨をずらした回答を好意的に解釈すると、比較の前提が崩れます。

いずれの場合も、点数だけでなくその点を付けた根拠の一文を評価シートに残してください。後の決裁説明で、点数の妥当性を問われたときに答えられるのは、この一文だけです。

RFP送付から選定・社内決裁までの進め方

文書ができたら、あとは運用です。フォーム営業ツール 導入 進め方として、送付から決裁までの流れを整理します。

送付社数・質問受付・回答期限の設計

送付社数は3〜5社が現実的です。2社では比較として弱く、6社以上になると回答の読み比べと追加確認に時間がかかりすぎます。RFI や公開情報で候補を広く把握したうえで、3〜5社に絞って RFP を出す流れが扱いやすい構成です。

質問受付期間は必ず設けます。RFP を読んだベンダーからは、必ず前提の確認質問が来ます。この質問に個別回答すると、情報提供に差が出て公平性が崩れます。「質問は〇月〇日までにメールで受け付け、回答は全社に一斉共有する」と RFP に明記してください。実務上、この一斉共有の回答集が、自社の要件記述の曖昧さを可視化してくれる副産物にもなります。

回答期限は、RFP 送付から2〜3週間程度を目安にします。1週間では各社が定型資料を送ってくるだけになり、1か月以上は選定全体が長引きます。期限と併せて、提案書のページ数上限（たとえば20ページ以内）と、18項目への回答フォーマット（本記事の項目番号に対応した表形式）を指定しておくと、読み比べの負荷が大きく下がります。

提案説明会と試用で回答の裏を取る

書面回答だけで確定させず、裏を取る機会を設けます。

提案説明会は、全社を同じ時間枠・同じ質問セットで実施します。この場で聞くべきは、書面で「可能です」とだけ書かれた項目と、質問の趣旨をずらした項目です。「項目11について、判定できなかったケースの管理画面上の表示を見せてください」のように、画面を出させる質問にすると実態が分かります。

試用での検証は、可能であれば上位2社に絞って実施します。検証すべきは成功シナリオではなく、失敗時の挙動です。フォームが見つからない企業、CAPTCHA が設置されたフォーム、除外対象に該当する企業を意図的に含めたリストで動かし、それぞれで何が起きるかを記録します。デモでは見えない部分が、ここで初めて表面化します。

試用の結果は、評価シートの該当項目の点数を修正する根拠として使います。書面回答と実際の挙動が異なった場合は、その差分も記録に残してください。

評価シートから社内決裁文書へつなぐ

評価シートが完成したら、社内決裁へ進みます。決裁者が知りたいのは点数の詳細ではなく、次の3点です。

1. どういう基準で候補を絞ったか（Must の設定内容と、足切りで落ちた社）
2. 最終候補のうち、なぜこの1社なのか（Want 項目で差がついた箇所）
3. 選ばなかった選択肢のリスクと、選んだ選択肢の残課題

評価シートはこの3点の根拠資料として添付し、決裁文書本体には要約を書きます。RFP の回答という一次資料が手元にあるため、「担当者の主観で決めた」という指摘には耐えられる構成になります。決裁文書そのものの書き方はフォーム営業ツール導入の稟議書テンプレートで扱っているため、そちらを参照してください。

RFPテンプレートを流用するときの注意点

最後に、本記事のテンプレートをそのまま使う際に気をつけたい点を整理します。

要件過多と画一的な提案を避ける

18項目すべてを Must にすると、回答できるベンダーがいなくなります。辞退が相次げば比較そのものが成立せず、RFP を作った意味がなくなります。Must は5〜7項目に絞り、残りは Want と Future に振り分けてください。

もう一点、機能一覧だけを求めると提案が画一化します。「この機能はありますか」の羅列に対しては、各社とも「あります／ありません」の表を返してくるだけです。2章（現状と課題）で自社の業務実態を具体的に書き、「この課題に対してどう解決するか」を提案してもらう欄を設けると、各社の考え方の違いが見えてきます。機能の有無では差がつかなくても、課題への向き合い方では差がつきます。

また、比較の根拠は公開情報とベンダーの書面回答に限定してください。伝聞や第三者の評判を評価に混ぜると、選定理由の説明が成り立たなくなります。本記事で整理した項目も含め、製品仕様は変更されるため、最終判断は各社の最新の公式情報と書面回答に基づいて行ってください。

送信量ではなく送信先の適切さを要件に入れる

フォーム営業というカテゴリに固有の注意点として、送信量の最大化を目的に据えた要件設計は、受信側との軋轢を生みやすいという点があります。「1時間あたり何件送れるか」を最重要の Must に置いた RFP を出せば、各社は量で応える提案を返してきます。その結果として構築される運用は、送信先の適切さを担保する仕組みを持ちません。

問い合わせフォームは本来、受信企業が商談や問い合わせを受け付けるために設置しているものです。そこに営業目的の送信を行う以上、送ってよい相手かどうかの判断を仕組み側で担保しないと、届いた側の心証を損ない、自社ブランドに跳ね返ります。

そのため RFP では、量に関する要件（項目6の配信量制御）と、送信先の適切さに関する要件（項目10・11の送信除外、項目15の停止依頼対応）を対で置いてください。Must の枠が限られているなら、量よりも除外側を優先して指定することを検討する価値があります。導入後に社内で問題化するのは、たいてい量が足りなかったケースではなく、送るべきでない相手に送ってしまったケースだからです。

RFP は、ベンダーを選ぶための文書であると同時に、自社がどういう営業活動を行う組織なのかを外部に表明する文書でもあります。その観点で要件を読み返してから、送付に進んでください。

Form Pilot は、送信量の最大化ではなく「送ってよい相手にだけ送る」ことを設計の中心に据えた、AI によるフォーム営業自動化サービスです。CAPTCHA の突破は行わず、他社が接触済みの企業を送信対象から除外する仕組みを備えています。本記事の要件項目に沿って比較検討をされている方は、Form Pilot のサービスページをご覧ください。

関連記事

• 営業ツール選定の比較軸 — 比較軸そのものの考え方を整理したい方へ
• 営業ツール導入前のセキュリティチェックリスト — 情シス審査の観点を先に把握したい方へ
• フォーム営業ツール導入の稟議書テンプレート — 選定後の社内決裁文書を準備する方へ