営業・CSの顧客要望を開発へ渡す方法｜受付フォームと記入例
目次
営業・CSから開発へ「CSVがほしい」「SSOがないと失注する」と渡しても、何を解決する話か分からないままでは判断が止まります。顧客の言葉と困り事を分けて記録し、確認する人と、判断結果を顧客に返す人を受付時に決めます。
- 受付フォームで原文、業務の目的、困り事、期限をそろえる
- 事実・担当者の解釈・未確認事項を分けて、開発へ渡す
- PMと開発が確認し、営業・CSが判断理由と次の回答日を返す
コピーして使える受付フォーム
受付フォームをダウンロード（テキスト・登録不要）次の欄を社内フォームや商談メモにコピーできます。記入時に分からない欄は「未確認」と書き、受付後に確認担当を割り当てます。顧客にすべてを入力してもらうフォームではなく、話を聞いた営業・CSが社内へ渡すための記録です。
顧客の原文：
顧客・発言者（部署・役職）：
受付日・受付経路・元の記録への参照：
何をしようとしていたか：
いま困っていること・回避策・頻度：
希望期限と理由：
商談段階・導入条件／既存顧客の利用状況：
確認済みの事実：
担当者の解釈・未確認事項：
顧客への回答担当・次の回答日：受付後にはPM・開発が「要望ID・関連要望ID、確認担当、判断・理由・代替案、再検討する条件」を追記します。顧客へ連絡したら営業・CSが「回答日・回答内容」を記録する分担です。
必須にするのは、まず原文、顧客・受付元、困り事、回答担当と次の回答日です。商談金額や期限がまだ分からなくても、空欄のまま黙って止める必要はありません。「未確認」の担当と確認日を決めて、追加の聞き取りを進めます。顧客情報を含む記録は、社内で閲覧権限を設定した場所に置いてください。
誰が確認し、誰が結果を返すか
以下は小規模チームで始める分担案です。兼任しても構いませんが、要望ごとに担当名を記入します。
| 工程 | 担当 | 完了時に残す内容 |
|---|---|---|
| 受付 | 顧客と話した営業・CS | 原文、困り事、元の記録への参照、回答担当 |
| 背景確認 | PM。顧客への追加質問は営業・CSが担当 | 事実と未確認事項、関連要望ID |
| 実現性確認 | 開発 | 実現方法、工数、依存関係、既存機能での代替案 |
| 判断 | あらかじめ決めた意思決定者。例としてPM | 採用・保留・見送り、理由、再検討条件 |
| 顧客への回答 | 受付した営業・CS | 回答日と送った内容、次の回答日 |
判断の権限が経営にある場合は、PMがその人へ確認を持ち込みます。開発担当へ直接投げた結果、実装が決まったことにしないでください。回答日までに結論が出なければ、回答担当が確認状況を返します。次の回答日は連絡の予定であり、実装期限ではありません。
悪い記録を、判断できる記録へ直す
ここからの2例は、月次集計と承認を扱うBtoB SaaSの架空例です。顧客名、発言、作業時間、日付は説明用で、Akoreの実績ではありません。優先順位の記入済み評価表では、同じFR-001とFR-002を他の3件と比較します。
CSの「CSVがほしい」を業務の目的まで書く
悪い例は「A社からCSV出力の要望。便利そうなので優先度高」です。担当者の評価だけが増え、顧客が何をするために必要なのかが抜けています。
| 受付欄 | 改善例 FR-001 |
|---|---|
| 原文 | 月次集計をCSVで出したい |
| 顧客・受付元 | 架空A社・経理担当／10/1のCS定例、架空定例メモA |
| 目的・困り事 | 経営会議資料へ毎月2時間かけて転記している |
| 利用状況・回避策 | 月次集計を利用中。画面から手作業で転記 |
| 希望期限 | 次の経営会議まで。日付と必要列は未確認 |
| 事実・解釈 | 転記時間は顧客の申告。CSVで解決できるかは未確認 |
| 回答担当・次の回答日 | CS担当A・10/9 |
PMは出力する列と対象期間を確認し、開発は現状の権限を保ったまま出力できるかを検討します。新機能を作る前に既存の出力機能で足りるかも確かめます。受付フォームの段階で「CSVを実装する」と約束する必要はありません。
営業の「SSOがないと失注する」を確かめられる形にする
悪い例は「B社は大口なのでSSO最優先。ないと失注」です。顧客の導入条件と営業担当者の予測が混ざっています。
| 受付欄 | 改善例 FR-002 |
|---|---|
| 原文 | SSOがないと導入できない |
| 顧客・受付元 | 架空B社・情報システム担当／10/2の営業商談、架空商談メモB |
| 目的・困り事 | 社内の認証審査を通せないという申告 |
| 商談段階 | 比較検討中。契約確度と審査の必須条件は未確認 |
| 希望期限 | 次の審査まで。審査日は未確認 |
| 事実・解釈 | 情シス担当の発言は確認済み。失注見込みは営業の解釈 |
| 回答担当・次の回答日 | 営業担当B・10/12 |
営業担当Bは、審査の条件、例外運用の可否、他の導入条件を顧客へ確認します。PMと開発は対象となる認証方式と工数を検討する役割です。「機能を作れば必ず契約になる」までは、この記録から判断できません。
営業とCSで不足しやすい情報を確かめる
営業経由では、導入前の希望が含まれるため、実際の業務と利用者を確かめます。CS経由では利用中の困り事を聞けますが、同じ課題が他の顧客にもあるかは別途確認が必要です。どちらも、部署名だけで重要度を決めることはできません。
「失注する」という話なら、何社のどの商談で出たのか、顧客の必須条件か、他に回避策があるか、金額と確度が分かるかを確認します。契約金額だけで判断を終えると、1社専用の開発になり、他の顧客が使えないこともあります。強い要望を全体のなかで扱う方法は声の大きい顧客の要望を優先すると失敗する理由で扱っています。
私たちは受託でBtoB SaaSの開発を担当することがあり、そこでは要望が顧客企業の営業・CSを経由して届きます。ほぼ同じ「個別カスタマイズに近い要求」を受けながら、結果が正反対になった2件を紹介します。
1件目は、大手企業からの引き合いでした。基本的な使い方は既存機能で足りていたのですが、不足している機能を指摘され、「それがないと使えない」という話が上がりました。ただしその機能は、プロダクトが向かっている方向とはずれた、その1社のための実装に近いものでした。対応すべきかどうか検討はしたものの、顧客側のCS・営業から強く求められ、結局は要望の形のまま作りました。結果は失注です。受注できなかったため、その機能を使う顧客はひとりも現れませんでした。
2件目は、ある施設からの引き合いです。こちらも新機能のカスタマイズ要求で、そのまま実装すれば個別対応になる内容でした。ここでは開発側から、要求をひとつ抽象度の高い機能として作り直す案を出しました。個別の事情は、その機能と運用の組み合わせで営業・CS側がカバーする形にしたのです。結果として目の前の要望に応えながら、その機能はプロダクトの標準機能の一部として残り、ほかの顧客にも使われるようになりました。
1件目で飛ばしていたのは、回避策の確認である「本当にその機能でなければ解決しないか」です。ここを通していれば、1社のための実装ではなく共通機能として設計し直す道が見えたはずでした。あわせて「何社から出ているか」と「金額と確度」も外しています。大手という金額の魅力に対して、要望は1社からしか出ておらず、しかもプロダクトの方向とずれている。この組み合わせは、仮に受注できていたとしても資産にならない形でした。
要望を課題に変換する作業は、断るための手続きだと受け取られがちです。2件目が示しているのはその逆で、1社向けの実装を、全社向けの資産に変えるための手続きでもあります。
実装しないときも判断理由を返す
PMが「今期は見送る」と決めたら、回答担当へ理由と代替案、再検討する条件を渡します。「優先度が低い」だけでは、営業・CSが顧客へ説明できません。
架空例FR-002の社内返答は、「認証審査の必須条件と契約確度を確認してから再評価します。営業担当Bが10/12に確認状況を返します。実装時期は未定です」と書けます。追加確認と見送りは状態を分けてください。確認していない要望を、実装しないと決まったように伝えることは避けます。
FR-001のような着手候補にも、決まった範囲と未定の範囲を返します。対象列の確認中なら、日付を約束できない理由と次の連絡予定を伝える形です。顧客向けの文面は機能要望への返信文例で確認できます。
フォームを台帳と判断の場へつなぐ
受付フォームは1件の背景を開発に渡す入口です。複数の要望と回答予定を追う台帳には、顧客要望の管理表テンプレートを使えます。複数の要望を同じ課題で比較するときは、原文を保持したまま関連要望IDをつなぎます。重複統合の手順も参照してください。
定期的な確認では、営業・CS・PM・開発が未確認事項と判断待ちの要望を見直します。議論が割れたときの決定者を先に決めておき、確認が終わった要望から記入済みの評価表のように比較します。判断後は台帳を更新し、受付した営業・CSが回答を引き取ります。
収集から判断までの全体像は機能要望管理の基本、受付経路の整理は要望の収集を一本化する方法にあります。
よくある質問
入力項目が分からない要望は受け付けないほうがよいですか？
分かる欄だけで受け付け、未確認の欄には確認担当と確認日を付けます。発言を聞いた営業・CSが元の記録を残していれば、あとで背景を確かめられます。
開発へ渡す前に実装期限を決める必要はありますか？
実装期限は実現性や優先順位を確認してから決めます。受付時には顧客への次の回答日を決め、結論が出ていなければ確認状況を返してください。
まとめ
営業・CSの要望を開発へ渡すときは、原文と困り事、事実と未確認事項を分けて記録します。受付フォームをコピーしたら、確認担当と回答担当も決めてください。判断の理由が顧客へ返るところまでが、要望を受け付ける工程です。
