RFPへの回答プレゼンでは、評価者が一つの要件から回答、根拠、実施の約束までたどれるようにします。発注側の要件IDを残し、「対応」「一部対応」「未対応」を区別してください。例外は、評価者が自分で見つける前に説明します。幅広い機能を並べるより、比較しやすい資料のほうが説得力を持ちます。

ここでは、小売業者がサポート業務用プラットフォームを求めていると想定します。要件の抜粋と提供側の回答は、方法を説明するために作った架空の例です。Presentiや他の製品の機能を示すものではありません。

回答チームで内容に合意したら、Presentiで営業提案の内容を編集可能なプレゼンに整理できます。入力には要件IDと根拠資料の参照番号を残し、発注側の評価手順に沿った資料にします。

要件カードと根拠資料のフォルダーをつなげて提案をまとめる図
各要件には、緑のチェックだけでなく、発注側が根拠まで確認できる回答が必要です。

自社の機能名ではなく、発注側の言葉から始める

要件IDと原文を作業用の対応表に転記します。「監査イベントをCSVで出力する」を「高度な分析」に言い換えたり、関係のないレポート機能とまとめたりしないでください。回答形式、評価基準、デモの指示、締め切りも対応表と一緒に管理します。これらは参考情報ではなく、資料作成の条件です。評価する側の視点は、サプライヤー評価のプレゼンで確認できます。購入側が評価基準、裏付け資料、未解決の差異を比較する方法を扱っています。

例に使う小売業者の要件は、次の四つです。

IDRFPの抜粋スライド作成前に確認すること
REQ-0140人の担当者が共有キューで作業できること。どのワークスペースと権限設定をデモで示すか。
REQ-02管理者が監査イベントをCSVで出力できること。どのイベントと項目が含まれるか。
REQ-0324時間365日の電話サポートを提供すること。提案する契約で提供できるか。
REQ-04顧客のサンプルデータを使い、6週間の試験導入を完了すること。「完了」とは何を意味し、誰が必要な情報を用意するか。

実際の提案に合った対応状況を書く

架空の提供側には共有キューがあり、一部の監査イベントを出力できます。電話サポートは営業時間内です。小売業者がサンプルデータと評価担当者を用意すれば、試験導入を提案できます。そのため、回答は次のようになります。

ID対応状況回答根拠または次の行動
REQ-01対応提案する利用者と役割で共有キューを利用可能E-01：日付付きの担当者・監督者のアクセス確認デモ
REQ-02一部対応ログインとレコード変更はCSV出力に含むが、設定変更は含まないE-02：出力例と項目一覧。未対応のイベントが必須か確認する
REQ-03未対応提案には営業時間内の電話サポートが含まれ、24時間365日の対応ではない不足を明示し、受け入れ可能な代替案を協議する
REQ-04提案顧客データと評価担当者の確保を前提とする6週間の試験導入計画E-03：開始条件と受入手順を含む計画

監査機能があるという理由だけで、REQ-02を「対応」に変えてはいけません。REQ-03にカスタマーサクセスの窓口を示し、求められたサポート時間を満たすように見せることも避けます。必須要件が未対応なら、対応表だけでなく概要スライドにも示してください。

重要な回答ごとに、根拠を示す場面を一つ用意する

REQ-01では、担当者が問い合わせを見つけ、監督者が権限のあるキューを確認する様子を示します。REQ-02では、出力ファイルの列見出しと、架空のデータを使った一行を見せます。再び営業説明を聞かなくても、見る人が要件と根拠を結び付けられることが重要です。

根拠資料の参照番号は、この例のE-01、E-02、E-03のように固定します。文書の版またはデモの日付、責任者、関係する条件も付けてください。スライドには「E-02、出力例、項目1–8」と書き、ファイル全体は提案書一式に含められます。顧客のロゴや利用者の推薦コメントは、特定要件への対応を示す根拠の代わりにはなりません。

架空のREQ-02への一部対応としてログイン・レコード変更を含め設定変更を含めないことを示す図とPresenti公式ツールバーの抜粋
架空のRFP回答で、対応するイベントと未対応の設定変更を分けた例です。ツールバーはPresentiの公式画面からの抜粋です。

試験導入の条件を具体的に示す

工程表に6週間の帯を引くだけでは、実施を止める可能性のある作業が見えません。この架空の試験導入を、準備、ユースケースのテスト、受け入れに分けます。準備にはサンプルデータ、利用者の役割、指名された顧客側の評価担当者が必要です。テストでは合意した担当者の操作手順と出力内容を確認します。受け入れ時には、どの基準を満たし、満たさず、再テストが必要かを記録します。

たとえば、「サンプルデータ、テストアカウント、評価担当者の参加日程がそろった時点から試験導入期間を数える」という開始条件を示します。実際のRFPや契約には別の規定があるかもしれません。この条件を一方的に追加せず、提案する条件として回答に記載し、発注側に可否を判断してもらいます。

例外を隠さないスライドの順序

  1. 回答の概要：発注側の目的、提案の方針、未対応の必須要件。
  2. 要件対応表：ID、対応状況、各回答の参照先。
  3. 共有キューの根拠：REQ-01とE-01。
  4. 監査出力の範囲：REQ-02、E-02、未対応のイベント。
  5. サポートの例外：REQ-03と協議する代替案。
  6. 試験導入：REQ-04、責任分担、開始条件、受け入れ。
  7. 発注側への確認：一部対応とサポートの代替案を受け入れられるか、誰が確認するか。

プレゼンと提出する提案書では、回答、範囲、取引条件を一致させます。スライドで説明を簡略化するときは、詳しい回答への参照を残してください。親しみやすい口頭説明で、提出文書にない条件を約束してはいけません。

完成した対応表から、Presentiで回答プレゼンを作ってみてください。例外も説明に残します。削除すれば資料は短くなりますが、発注側は判断しにくくなります。