営業・CSからの機能要望をどう扱うか｜受け取り方と返し方
機能要望の多くは、顧客から直接プロダクトチームに届くわけではありません。商談で聞いた話が営業から、問い合わせ対応で出た話がカスタマーサクセス（CS）から、それぞれ社内を経由して届きます。
このとき要望は必ず一度、社内の誰かの解釈を通っていることになります。誰がどんな立場で聞いた話なのかを踏まえずに受け取ると、判断を誤ることがあるでしょう。この記事では、営業・CS経由で届く要望をどう受け取り、どう返すかを整理します。
- 営業要望とCS要望は優劣ではなく、読めない確度の種類が違う。営業は「本当に使うか」、CSは「市場全体を代表しているか」が読めない
- 「この機能がないと失注する」は主張であって事実ではないことを考慮する。何社が・どの段階で・他に手はないのか・金額はいくらかを確かめる
- 誰が・何をしようとして・いまどう困り・いつまでに必要か。この4点を入口のフォームで揃えると、後から背景を聞き直す手間がなくなる
- 実装しない判断ほど、理由とセットで結論を出す。返さないと同じ要望が繰り返し届き、やがて要望自体が上がってこなくなる
営業要望とCS要望の性質の違い
同じ「機能要望」でも、営業要望とCS要望では、背後にある動機と根拠の質が異なります。
| 観点 | 営業からの要望 | CSからの要望 |
|---|---|---|
| 誰の声か | まだ顧客でない見込み客 | すでに使っている既存顧客 |
| 動機 | 受注したい・失注を避けたい | 解約を防ぎたい・活用を進めたい |
| 根拠 | 商談での発言、競合との比較 | 実際の利用体験、問い合わせの蓄積 |
| 時間の圧力 | 商談の締切がある | 案件による（解約予兆なら最も強い） |
| 強み | 支払い意思と紐づく／市場全体の声が届く | 実利用に基づき、課題の実在性が高い |
| 弱み | 導入後に本当に使うかは未検証 | 既存顧客の現在の使い方に偏る |
営業要望は未来の売上、CS要望は既存の売上に紐づくもので、どちらも事業に必要です。優劣ではなく、確からしさの弱点の種類が違うと考えてみるのがおすすめです。
営業要望で読めないのは「本当に使うか」です。見込み客はその製品をまだ使っていないため、契約前に強く求められた機能がリリース後ほとんど使われないことも珍しくありません。ただし購買判断の直前に出る要望は、金銭的なコミットメントと紐づいた発言でもあります。「あったら嬉しい」で出るCS要望より、支払い意思の証拠としてはむしろ強く働きます。
CS要望で読めないのは「市場全体を代表しているか」です。実際に業務で詰まった結果として出てくるぶん課題の実在性は高い一方、いまの使い方に最適化された内容になりやすく、まだ顧客でない層のニーズは構造上ここには届きません。CS要望だけを重く扱うと、プロダクトは既存顧客の現状に引きずられてしまいます。
どちらを重く見るかは、事業フェーズで決めるのが一つの考え方です。獲得を伸ばす局面なら営業要望、解約率の改善が課題ならCS要望が相対的に重くなると考えることができます。
この機能がないと失注する？
営業要望でいちばん判断が難しいのが、この主張になります。
事実なら最優先で対応すべきですが、事実でないまま受け入れれば、1件の商談のために貴重な開発リソースを割くことになります。しかもこの主張は、営業担当者にとって最も強い交渉材料でもあります。悪意なく、無意識に強調されてしまいます。
このときは、次の4つを確認しましょう。
何社から・どのセグメントで出ているか
社数だけでなく、業界やセグメントに偏りがないかも確認してみましょう。1社でも戦略顧客なら市場の先行指標のことがあり、複数社でも同一業界に偏っていれば全体のニーズとは言えません。過去の商談記録を遡って数えられない場合は、そのこと自体が記録の仕組みから整えるべきサインとなります。
商談のどの段階で出た話か
初回ヒアリングで挙がった「あったらいいですね」と、最終検討で出た「これがないと稟議が通らない」はまったく重みが違います。どの段階の発言かを必ず確認します。
本当にその機能でなければ解決しないか
顧客が挙げているのは解決策であって、その背後にある課題そのものではありません。運用や既存機能の組み合わせで代替できないかを検討します。何を聞き取れば課題まで下りられるかは、次の節で扱います。
その商談の金額と確度はどの程度か
開発工数と天秤にかけるための情報です。年間契約額が小さく確度も低い商談のために数人月を投じる判断は成立しにくくなります。例外は、参照顧客としての価値や横展開の見込みが金額を上回るケースです。
これらを確認すること自体が、営業チームに「主張には根拠が要る」という規範を伝えることにもなります。逆に確認せず受け入れ続けると、「失注する」と言えば通るという学習が組織に定着します。
判断のたびに商談を遡って調べるのは現実的ではありません。失注理由を選択式で記録し、「機能不足」を選んだ場合はどの機能かを必須入力にする、といった仕組みをCRM等に用意しておくと、次からは集計するだけで済むので、運用が楽になります。
営業チームの入力負荷が増えてしまいますが、記録した結果が実際にロードマップへ反映される様子を見せることで運用が続きやすくなります。
私たちは受託でBtoB SaaSの開発を担当することがあり、そこでは要望が顧客企業の営業・CSを経由して届きます。ほぼ同じ「個別カスタマイズに近い要求」を受けながら、結果が正反対になった2件を紹介します。
1件目は、大手企業からの引き合いでした。基本的な使い方は既存機能で足りていたのですが、不足している機能を指摘され、「それがないと使えない」という話が上がりました。ただしその機能は、プロダクトが向かっている方向とはずれた、その1社のための実装に近いものでした。対応すべきかどうか検討はしたものの、顧客側のCS・営業から強く求められ、結局は要望の形のまま作りました。結果は失注です。受注できなかったため、その機能を使う顧客はひとりも現れませんでした。
2件目は、ある施設からの引き合いです。こちらも新機能のカスタマイズ要求で、そのまま実装すれば個別対応になる内容でした。ここでは開発側から、要求をひとつ抽象度の高い機能として作り直す案を出しました。個別の事情は、その機能と運用の組み合わせで営業・CS側がカバーする形にしたのです。結果として目の前の要望に応えながら、その機能はプロダクトの標準機能の一部として残り、ほかの顧客にも使われるようになりました。
1件目で飛ばしていたのは、本節の3つめ「本当にその機能でなければ解決しないか」です。ここを通していれば、1社のための実装ではなく共通機能として設計し直す道が見えたはずでした。あわせて「何社から出ているか」と「金額と確度」も外しています。大手という金額の魅力に対して、要望は1社からしか出ておらず、しかもプロダクトの方向とずれている。この組み合わせは、仮に受注できていたとしても資産にならない形でした。
要望を課題に変換する作業は、断るための手続きだと受け取られがちです。2件目が示しているのはその逆で、1社向けの実装を、全社向けの資産に変えるための手続きでもあります。
要望を課題に変換するためには？
営業・CSから要望が届いたとき、そのまま管理台帳に記録していくだけでは「エクスポート機能が欲しい」のような解決策だけが並ぶことになります。これでは優先順位を後からつけることが難しくなります。
登録の時点で、少なくとも次の4点を埋める運用をおすすめします。
誰が言ったか — 会社名、部署、役職。決裁者の発言か現場担当者の発言かで扱いが変わります。
何をしようとしていたか — その人が達成したかった業務上の目的です。「エクスポートしたい」ではなく「月次で経営会議に出す資料を作りたい」まで考察して深堀ります。
いまどう困っているか — 現状の回避策と、そこにかかっている手間です。「毎月2時間かけて手作業でコピーしている」まで聞けると、インパクトの見積もりに利用できます。
いつまでに必要か、その理由は — 期限があるならその背景です。「決算期に間に合わせたい」「競合のトライアルが走っている」など。
この4点をテンプレート化しておくと、変換の手間を入口で片づけられます。ただし必須項目を増やしすぎると入力しにくくなりますので、最初は「何をしようとしていたか」「今どう困っているか」の2点だけを必須にする形もおすすめです。
背景を聞くのはPMの役割だと考え、要望だけ受け取って後からヒアリングし直すというワークフローは難しいことがあります。営業・CSは次の商談や対応に移っており、記憶は薄れていってしまうでしょう。顧客にもう一度聞き直すことになれば、相手の時間も使うことになります。
聞いたその場で書いてもらうのがいちばん精度が高く、全体の工数も小さくなります。その場で書ける長さにテンプレートを保つことが重要です。
実装しない判断
仮に、実装しないと判断したときに、どのようにコミュニケーションを取るのが良いでしょうか？
採用した要望も、リリースしただけでは伝わりません。何がどう変わったのかをリリースノートにして、顧客と営業・CSに知らせる工程が要ります。それでも採用した要望には、リリースノートという伝える場があります。一方見送った要望は、伝える場すらなく、放置すると誰にも伝わりません。
その結果、営業は「あの要望はどうなったのか」を追えないまま、次の商談でまた同じ要望を持ち帰ることになります。CSは顧客に「確認します」と答えたまま返せず、顧客との関係にも影響してしまうでしょう。そして社内には「要望を上げても無駄」という空気が生まれ、要望が上がってこなくなるかもしれません。
これは一見すると平和な状態に見えますが、顧客の声が届かなくなったという意味で最も危険と考える事もできます。
実装を見送りする場合
見送る場合は、次の3つをセットで返すのがおすすめです。
判断 — やらない（今後も対応しない）、今期はやらない（時期の問題）、別の形で解決する（課題は認めるが解法を変える）のいずれか。
理由 — なぜそう判断したか。「優先度が低い」ではなく、「同じ課題を持つ顧客が現時点で1社で、対応には2人月かかるため、今期は他の施策を優先する」のように、根拠を具体的に書く。
代替案 — 現状の機能や運用で近いことができるなら、その方法。何もないなら「現時点では回避策がない」と正直に伝える。
見送りの伝え方ひとつで、営業・CSの納得感は大きく変わります。判断そのものより、判断の根拠が共有されているかどうかが効きます。
根拠が共有されていれば、営業は顧客に対して「今は対応予定がないが、こういう考え方で優先順位をつけている」と説明できます。根拠がなければ「開発に断られました」としか言えません。前者は顧客の信頼を保ちますが、後者は社内の分断を顧客に見せることになります。
部署をまたいで議論する場をつくる
個別の要望を1件ずつ処理していると、全体の傾向が見えません。定期的に集まって、まとめて見る場を用意します。
頻度は流入量によりますが、月1回から始めるのがやりやすいでしょう。なお日々の重複統合は別サイクルで、こちらは溜めすぎると作業自体が重くなるため週次で回すほうが向いています（機能要望の重複統合・粒度そろえの実践Tips）。統合は週次、議論の場は月次、と分けて考えてみてください。
参加するのは営業・CS・プロダクト・開発です。それぞれの立場から「なぜこれが重要か」を持ち寄ります。
やることは、前月に届いた要望をまとめて読み、同じ課題を指すものを統合し、次に着手する範囲を合意する、の3つです。
議論の場は合意形成のためにありますが、全員一致を目指すと決まりません。意見が割れたときに誰が決めるのかを、場をつくる時点で明確にしておきます。
一般的にはPMが決定権を持つことが多いですが、事業インパクトが大きい判断は経営が引き取る、といった線引きも必要です。この線が曖昧だと、議論のたびに「誰が決めるのか」から始まることになります。
判断の基準そのものについては、開発する機能の優先順位を決める方法でフレームワークを整理しています。場をつくる前に基準を決めておくと、議論が「好き嫌い」ではなく「基準に照らしてどうか」になります。
営業要望を受け入れると決めたあと、それを特定顧客専用の実装にするか、設定で切り替えられる共通機能として作るかという判断が続きます。
booost technologies社は、導入事例を増やすために個社カスタマイズを積極的に受け入れた結果、顧客ごとにブランチを分けて15バージョンを並行管理する状態になり、共通機能を1つ追加するのに15個のプルリクエストが必要になったと自社の技術ブログ（2024年）で公開しています。同記事では当時の判断を事業スピードを優先した結果として振り返っており、判断そのものが不合理だったわけではありません。受け入れる基準と、後から共通化に戻す道筋が必要だったと考えることもできます。
前節で触れた2件目のように、要求を一段抽象化して共通機能に寄せられるかどうかが、この分かれ目になります。ただし個別実装をどこまで許容し、どの条件で共通化に戻すかという基準づくりは実装設計の話になるため、本記事では取り扱いません。受け取り方と返し方が整ったら、次に考える論点として覚えておいてください。
よくある質問
営業からの要望とCSからの要望、どちらを優先すべきですか？
一律の優劣はありません。営業要望は将来の売上に、CS要望はいまの売上につながるもので、事業フェーズによって重みが変わります。獲得を伸ばす局面では営業要望、解約率の改善が課題ならCS要望が相対的に重くなります。ただし読めない部分の種類が違います。営業要望には製品を使う前の発言が含まれるため導入後に使われないことがあり、CS要望は実際の利用体験に基づくぶん既存の使い方に偏ります。まだ顧客でない層のニーズは、構造上、営業経由でしか届きません。この違いを踏まえて重みづけしてください。
テンプレートを用意しても、営業やCSが入力してくれません。どうすればよいですか？
原因は2つに分かれます。項目が多すぎるか、入力した結果が返ってこないかです。前者は必須項目を絞ることで解決します。まずは「何をしようとしていたか」「いまどう困っているか」の2点だけ必須にして、残りは任意から始めてください。後者のほうが根が深く、入力しても判断が返ってこない状態が続くと、入力する意味がないと学習されます。見送った要望にも理由を返す運用をセットで始めることが、テンプレートを機能させる条件です。
見送った要望を、営業やCSにどう伝えればよいですか？
判断・理由・代替案の3点をセットで返します。理由は「優先度が低い」ではなく、「同じ課題を持つ顧客が現時点で1社、対応に2人月かかるため今期は見送る」のように具体的に書きます。根拠が共有されていれば、営業は顧客に対して優先順位の考え方まで説明できます。見送りを返さずに放置すると、同じ要望が繰り返し届き、やがて「要望を上げても無駄」という空気が生まれて要望自体が上がってこなくなります。
要望を集める仕組みは、どこから作ればよいですか？
入力フォームの項目を決めるところから始めるのが確実です。誰が言ったか、何をしようとしていたか、いまどう困っているか、いつまでに必要か。この4点が埋まっていれば、後から背景を聞き直す手間がなくなります。項目を増やしすぎると入力されなくなるので、最初はこの範囲に絞ってください。収集チャネルの一本化から判断基準の明文化までの全体像は、[機能要望管理とは？収集・整理・優先順位付けの基本](/learn/feature-request-management)で解説しています。
まとめ
営業・CS経由の要望は、必ず社内の誰かの解釈を通って届きます。誰がどんな立場で聞いた話なのかを踏まえること、「失注する」という主張を確かめること、要望を課題に変換する項目を入口で用意すること。この3つで、受け取る側の精度は大きく上がります。
そして見落とされがちなのが、返す側の工程です。見送った判断こそ理由とセットで返さないと、同じ要望が繰り返し届き、やがて要望自体が上がってこなくなります。それは平和になったのではなく、顧客の声が届かなくなっただけです。
要望を受け取る仕組みと、判断を返す仕組み。この両方が揃って初めて、営業・CSとプロダクトの間に信頼のループができます。
