RFP回答向けAI——自社の回答ライブラリから下書きを作る

AIによるRFP対応. AIによるRFP対応とは、既存の回答ライブラリから入札書の最初のバージョンを組み立てる、下書き・レビュー型のパイプラインだ。発注元の質問票を読み取り、各設問を過去のベストな回答と照合し、今回の案件に合わせて調整したうえで、自社のトーンで書かれた完全な下書きを入札責任者に渡す。人がそれを編集し、署名する。発注元へ自動送信されることはない。

入札リードは金曜日に、セキュリティとサービスに関する180問のRFPを受け取り、期限は水曜日だ。回答の大半はすでに存在する。前四半期に勝った提案書、SOC 2のPDF、CRMの3件の案件に散らばっている。それらを探し直し、貼り付け、この買い手向けにトーンを直す作業が、持っていなかったはずの日数を食いつぶす。

#下書き・レビュー型のRFPパイプラインは、実際に何をするのか

組み立てを担うのであって、承認を担うのではない。RFPが届くと、パイプラインはすべての設問を解析し、回答ライブラリから最も近い回答を引き出し、今回の発注元の業種と案件規模に合わせて書き直し、回答書を最初から最後まで埋める。入札責任者が開くのは、180の空欄が並んだ白紙のテンプレートではなく、完成した下書きだ。間違っている2つの回答を修正し、エグゼクティブサマリーを磨き、自分の名前で送る。

この役割分担こそが設計のすべてだ。認証について誇張した回答や、間違ったSLAを引用した回答は、発注元の調達チームに見抜かれ、案件を失う原因になる。だからパイプラインは下書きをし、人が判断する。レビューという工程は、我慢して受け入れる余計な手間ではない。間違った数字を署名済みの入札書に載せないための仕組みだ。

#長いRFPでは、時間はどこに消えるのか？

説明のために、顧客ではなく、仮定のB2Bサービス企業を考える。200問のRFPに、2人で3営業日かかっているとする。過去に勝った提案書、セキュリティ文書、1枚ものの製品資料から下書きを作るパイプラインは、その下書き作業の大半をレビューの工程に移す。効果が出るのは短い案件ではなく、長い技術系の入札だ。

短いRFPが問題になることはまずない。20問の導入アンケートは、もともと1時間で済む。ボトルネックは、200行のセキュリティと導入の入札で、2024年の提案書にある回答を、医療系の買い手向けにトーンを直さなければならない場面だ。その最初の下書きを作れば、チームはどの入札を見送るかを選ぶのをやめ、同じ人数でより多くに回答できる。

自分のチームで探したいパターンはこれだ。大きな質問票は、担当を割り当てられないという理由で見送られる。完成した下書きがあれば、その判断が変わる。

#これはloopioやresponsiveがすでにやっていることではないのか

Loopioと、旧rfpioのresponsiveは、検索可能な回答ライブラリを保持しており、それ自体は確かな価値の蓄積だ。しかしそれでも、各回答を組み立て、発注元向けに調整し、設問ごとにトーンを合わせるのは人の仕事のままだ。下書きにかかる時間はチームに残り続ける。私たちが構築するパイプラインは、その組み立て工程を取り除く。署名する人間を取り除くわけではない。

#構築後、RFPパイプラインは誰のものになるのか

• コードはあなたのものになる。AI導入の仕事では、永遠に借り続けるツールではなく、パイプラインとリポジトリそのものを引き渡す。
• エンゲージメント内でのトレーニングにより、提案チームは私たちを呼び戻さなくても、自分たちでパイプラインを運用し、トーンを調整し、受注のたびに新しい回答を追加できるようになる。
• パイプラインは入札責任者の背後に位置づけられているので、認証やSLAが変わったときは、人が元となる回答を更新すれば、以降のすべての下書きにそれが反映される。

引き渡しが重要なのは、回答ライブラリが生きたものだからだ。受注するたびに、より良い回答が加わり、パイプラインはチームが実際に送ったバージョンから学ぶ。これは、モデルが担当者のトーンで下書きし、人が量に流されず正直さを保つ、私たちの営業・サポート構築の裏にあるのと同じ、下書き・レビューの形だ。読まれずに発注元へ送られるものはない。

質問票に人手が足りず入札を断っていて、提案書ライターをもうひとり雇うことしか手が残っていないなら、その求人を出す前に一度整理してみるべきだ。30分のディスカバリー通話を予約してほしい。回答ライブラリと直近3件のRFPを見て、下書き・レビュー型のパイプラインが正しい解決策かどうかを、一行もコードを書く前に確認する。