更新日：2026年8月16日
顧客の要望の管理とは、寄せられた機能追加や改善の希望を記録・分類し、対応の優先順位を決めることです。
要望をそのまま開発すると、使われない機能が増えます。
1社の要望が他の顧客にも当てはまるとは限りません。判断の基準が必要です。
見込み客を育てる仕組みは、マーケティングオートメーションのページでご紹介しています。 MA（シナリオ配信）の機能を見る
要望が寄せられる経路
| 経路 | 特徴 |
|---|---|
| サポートへの問い合わせ | 困っている状態で出る |
| 商談・失注時 | 導入の条件になっていることがある |
| 定期面談 | — |
| アンケート | — |
| 解約時 | 最も重要 |
| 営業経由 | — |
すべてを1か所に集めてください。担当者のメモに散らばっていると、件数が数えられません。
記録する項目
| 項目 | 用途 |
|---|---|
| 要望の内容 | — |
| 要望の背景（何に困っているか） | 別の解決策が見つかることがある |
| 要望元（顧客名、契約金額） | — |
| 件数 | 複数から出ているか |
| 商談・解約への影響 | — |
| 受け付けた日 | — |
「要望の背景」を必ず聞いてください。要望どおりに作らなくても、別の方法で解決できることがあります。
優先順位の基準
| 基準 | 高い | 低い |
|---|---|---|
| 要望の件数 | 複数社から | 1社のみ |
| 契約への影響 | 解約・失注の理由 | — |
| 対象の広さ | 多くの顧客に効く | 特定の使い方のみ |
| 開発の工数 | 小さい | 大きい |
| 戦略との一致 | 注力領域 | — |
| 代替手段の有無 | ない | ある（運用で回避できる） |
「1社のみの要望」を安易に開発しないでください。その1社のためだけの機能は、他の顧客には不要で、製品を複雑にします。
要望どおりに作らない判断
| 状況 | 対応 |
|---|---|
| 背景の課題を別の方法で解決できる | その方法を提案 |
| 既存機能で対応できる | 使い方を案内 |
| 運用で回避できる | 手順を提案 |
| 特定の使い方に依存している | 対応しない |
| 製品の方向と合わない | 対応しない |
| 工数に見合わない | — |
「既存機能で対応できる」ケースは意外に多くあります。要望が来たらまず、既存の方法で解決できないかを確認してください。
顧客への伝え方
| 判断 | 伝え方 |
|---|---|
| 対応する | 時期を伝える（確約できない場合はその旨も） |
| 検討中 | 「要望として記録しました」 |
| 既存機能で対応可能 | 使い方を案内 |
| 対応しない | 理由を伝える |
| — | 「検討します」で放置しない |
「検討します」で放置しないでください。顧客は待ち続け、実装されないまま更新時期を迎えます。
対応しないと伝えるとき
- 理由を説明する：「特定の使い方に依存するため」
- 代替の方法を示す：あれば
- 曖昧にしない：「難しい」で終わらせない
- 今後の可能性に触れる：状況が変われば
- 他の要望への対応を示す：無視していないことを
対応しないことを伝えても、多くの場合は理解されます。曖昧なまま待たせるほうが不信につながります。
開発側との共有
| 共有すること | 形式 |
|---|---|
| 要望の一覧 | 件数順 |
| 要望の背景 | — |
| 契約への影響 | 解約・失注につながったか |
| 対応の優先順位案 | — |
| — | 定例で共有 |
件数と背景をセットで渡してください。要望の文言だけでは、開発側が判断できません。
実装したあとにやること
| やること | 理由 |
|---|---|
| 要望元に連絡する | 「ご要望が実装されました」 |
| 他の要望元にも連絡する | — |
| 失注先にも連絡する | 再検討の機会 |
| 記事・資料を更新する | — |
| 営業に共有する | 訴求に使える |
| 利用状況を見る | 本当に使われているか |
「機能不足」で失注した相手に連絡してください。その機能が実装されたことは、再接触の明確な理由になります。
見込み客を育てる仕組みは、マーケティングオートメーションのページでご紹介しています。 MA（シナリオ配信）の機能を見る
まとめ
- 要望をそのまま開発しない
- 要望は1か所に集める
- 「要望の背景」を必ず聞く
- 1社のみの要望を安易に開発しない
- 既存機能で対応できるケースは意外に多い
- 「検討します」で放置しない
- 実装したら失注先にも連絡する
よくある質問
顧客の要望はすべて開発すべきですか？
すべきではありません。1社の要望をそのまま開発すると、他の顧客には不要な機能が増え、製品が複雑になります。複数社から同じ要望が出ているか、契約への影響があるか、対象が広いか、工数に見合うかで優先順位を付けてください。
要望をどう記録すればよいですか？
1か所に集め、「要望の背景」も併せて記録してください。背景（何に困っているか）が分かると、要望どおりに作らなくても別の方法で解決できることがあります。あわせて要望元、件数、商談や解約への影響も記録してください。
対応しない場合、どう伝えればよいですか？
理由を説明し、代替の方法があれば示してください。「特定の使い方に依存するため対応が難しい」といった形です。曖昧に「検討します」と答えて放置するほうが不信につながります。顧客は待ち続け、実装されないまま更新時期を迎えます。対応しないことを明確に伝えても、多くの場合は理解されます。
要望が実装されたあとは何をすべきですか？
要望元と、同じ要望を出していた他の顧客、そして「機能不足」で失注した相手に連絡してください。特に失注先への連絡は、再接触の明確な理由になります。あわせて記事や資料を更新し、営業にも共有してください。実装後に利用状況を確認し、本当に使われているかも見てください。
