IT営業の提案書は、顧客が課題と提案内容の関係を理解し、次に進む条件を判断するための資料です。製品の機能紹介が詳しくても、今回の課題に何をどう使い、どこまで対応するのかが見えなければ、具体的な検討を進めにくくなります。
顧客の確認済みの事実、提案する範囲、まだ決めていない条件を分けることから作りましょう。本記事では、IT提案で技術条件を伝えるための構成例を示します。
表紙の次に、今回の判断を短く示す
初回の方向性確認なのか、検証の実施判断なのか、本導入の見積もり検討なのかを明記します。提案書を読んだ人が何に答えればよいかが分かる状態を目指します。
ITソリューション提案の研修案内の例として、HPE教育サービスが公開するコース概要にも、背景や課題、提案範囲、ソリューション、活用場面・期待効果を検討する項目が載っています。以下の構成はその書式の転載ではなく、本記事が技術提案の確認に使うために整理した例です。出典：HPE教育サービス コース概要
| 提案の部分 | 読み手が確認できる内容 |
|---|---|
| 今回の論点 | 何について合意・判断したいのか |
| 現状と目指す状態 | 確認した問題と、解決できたと判断する条件 |
| 提供する範囲 | 対象業務、機能、連携、成果物、対象外 |
| 技術上の条件 | 実現方法、制約、検証が必要な点 |
| 実施条件 | 双方の担当、日程、費用の範囲と前提 |
| 次の進め方 | 未決事項、確認先、回答後に決めること |
順番やページ数は固定しません。予算判断が必要な相手には概要で費用条件も伝えるなど、読み手と検討段階に合わせます。
課題を、機能へ直接飛ばさず整理する
架空の問い合わせ受付業務で「同じ内容を複数システムへ入力している」と聞いたとします。この段階で、すぐに新しいツールの導入を結論にするのではなく、どの情報を、誰が、どのタイミングで入力しているかを整理します。
提案書では、「確認済み：受付後に担当者が別システムへ転記」「未確認：転記件数と例外の割合」「仮説：一部の項目を連携できれば転記を減らせる」のように分けられます。仮説を顧客が認めた事実のように書かないことが重要です。
この整理があれば、提案する連携がどの作業へ影響するかを説明できます。自社の一般的な製品紹介は、今回必要な機能と対応付けて掲載します。
「連携できます」に、範囲と確認条件を付ける
技術条件を営業資料へ落とすときは、専門用語だけで説明を終えず、相手の業務にどう関わるかを示します。たとえば、受付情報の連携について、対象項目、送る頻度、認証、失敗時の扱い、既存側で必要な作業を確認します。
標準機能で対応できる範囲と、設定・追加開発・顧客側の変更が必要な範囲を分けると、費用や日程の前提も示せます。未検証なら「接続方式と対象項目を検証して確定」と書き、確定した対応能力として約束しないでください。
説明用の構成図を使う場合も、実際の接続先と仮置きの部分が分かるようにします。図が整っていることだけで、実現性が確認済みにはなりません。
効果は、計算の前提と未確認分を見せる
「作業時間を削減できる」と示すなら、どの作業を、どの件数に対して、どれだけ変える想定かを説明します。転記時間だけでなく、連携エラーの確認や例外処理が残るかも考えます。
仮に月間件数と一件当たりの時間から試算する場合は、実測した数値と仮定した数値を分け、試算の対象外を明記します。顧客へ未確認の効果を保証する数字として見せないことが大切です。
費用側も初期作業だけなのか、運用・利用料を含むのか、追加対応の条件は何かをそろえます。比較案がある場合は、同じ範囲と期間で比べられるようにします。
提出前に、営業と技術で確認する点を合わせる
営業は顧客の課題・検討段階・判断者との整合を確認し、技術担当は実現方法と制約、確認が必要な条件を確認する、と役割を分けられます。実際の承認者は社内の運用に合わせてください。
最後は、「説明がうまいか」だけでなく、範囲・費用・日程の前提が互いに矛盾していないかを読みます。次の打ち合わせでは、未決事項を誰が確認するかを決めると、提案資料が行動につながります。
このような技術と顧客の橋渡しに関心がある方は、テクノヴァースの採用情報で実際の職種・仕事内容をご確認ください。提案書の構成は、受注を保証する型ではなく、判断に必要な材料を届けるための方法です。