顧客の声は、仕様の一覧から投資の選択肢へ変換する
SMB顧客から要望が集まったとき、事業側が決めるのは実装の順番だけではありません。既存の使い方で解決する、範囲を区切って個別対応する、複数社で確かめる、共通の提供仕様へ組み込む、今回は見送る、という選択を比較します。要望を集める工程と、資源を投じる工程をつなぐ仕組みが必要です。
SMBを顧客とするエンタープライズ企業の営業責任者・営業企画・事業開発担当者を対象に、営業で得た知見を商品やサービスの投資判断へ渡す方法を整理します。話法の共有や営業個人の育成ではなく、顧客に何を共通して提供し、どこまで追加の約束を引き受けるかが本稿の主題です。
素材は、自社ノウハウにある営業情報の還流、課題と要件の確認、適合性、提供能力の考え方です。そこから複数顧客の要望を扱う運用へ展開した設計提案であり、商品開発の成功率を実証したものではありません。後述の件数は説明用の架空例です。
機能の名前をそろえる前に、業務の変化をそろえる
「一覧で見たい」「自動にしたい」といった要望の名前だけでは、何へ投資するべきかは決まりません。誰が、どの業務で、何に困り、今はどう補い、どの状態なら改善したと判断するかを確かめます。依頼された方法と、解きたい問題を別の欄に残すと、代替策を比較できます。
同じ帳票の要望でも、経営者の確認、現場の作業、外部への提出では、内容・頻度・正確さの条件が違う可能性があります。名称が同じという理由だけで統合せず、業務目的と適用条件が共通するものをまとめます。反対に、異なる機能の依頼でも、手作業の二重入力という同じ問題が起点なら、別の解決策でまとめられることがあります。
現在の提供内容で解決できるなら、説明や利用開始の支援を直す選択肢もあります。約束した範囲の不備で生じた要望は、新しい有料機能への需要と区別します。営業が推測した事業上の効果を顧客の発言へ混ぜず、未確認の点が残っているかまで事業側へ渡します。
多く聞いた要望と、広く成立する課題を分ける
件数には、同じ企業が複数回伝えた要望、営業担当が言い換えた記録、顧客が自ら挙げた要望、提示された案への賛同が混在します。発言数、企業数、条件の合う企業数を分け、同じ対象へ同じ問いを確かめた結果かを残します。声の大きな顧客や受注直前の案件だけで優先順位を決めないためです。
架空例として、意図的に選んだ40社へ対話し、ある要望に関する記録が14件あったとします。企業単位で重複を除くと8社、そのうち同じ業務条件の課題を確認できたのは5社、費用・役割・期間を含む限定試行を相談できたのは3社だったとします。8社の内訳は課題確認5社と詳細未確認3社、5社の内訳は試行相談3社と試行条件未確定2社です。
14件を14社として計算せず、5社を40社の市場需要率としても扱いません。対象が無作為に選ばれた市場標本ではなく、未確認は需要不在とも限らないためです。試行を相談できた3社についても、発注や支払いが決まったとはいえません。聞いた回数から投資判断までの間で、どの証拠が不足するかを明確にする例です。
| 残す情報 | 確認する内容 | 避けたい読み替え |
|---|---|---|
| 依頼と背景 | 誰がどの業務で何を変えたいか | 依頼された機能が唯一の解決策 |
| 同一性と共通性 | 企業ID、業務条件、発言と解釈 | 同じ名称なら同じ課題 |
| 証拠の段階 | 発言、試行相談、実利用、費用判断 | 好意的な反応を購入意思とする |
| 対象の偏り | 顧客群、選定理由、質問、未確認 | 会えた相手だけで市場需要を推定 |
個別対応・限定検証・標準化・見送りを選び分ける
個別対応は、特定顧客の条件で価値が明確であり、引き受ける範囲と負荷を限定できる場合に検討します。顧客固有の作業を共通機能の一部として隠すと、次の顧客への説明や保守で矛盾が生じます。対応する目的、期間、費用、変更する場合の窓口を、実行可能な範囲にそろえます。
限定検証は、共通する課題の仮説はあるが、解決方法や利用条件が未確認の場合です。すぐに恒久的な機能を作る前に、既存の手段や範囲を絞った提供で、目的の業務が変わるかを確かめる方法があります。ただし、裏側を人が補うなら、その作業と限界を明示し、自動化済みと説明しません。
標準化は、条件の共通性、顧客が得る価値、複数社への提供手順、変更と保守の責任を説明できる場合に検討します。一社で動いたことから全顧客へ展開せず、異なる条件で使えない範囲を先に示します。見送りや保留は、要望を否定する返答ではなく、現在の提供方針と資源配分の判断です。必要性はあっても自社で担うべきでない場合には、別の方法や提供範囲を案内します。
実装の前に、判断を変える検証を置く
検証計画では、誰のどの作業を、どの条件で変えられれば次へ進むかを決めます。「便利だと言われる」だけでは、現行手段からの変更、担当者の作業、費用負担の判断が残ります。顧客に求める準備や、検証を終える条件も示し、協力への同意を購入の約束と混同しません。
確認するのは、対象の業務が実際に進んだか、利用が一度で止まらないか、既存の工程を別の人へ押し付けていないか、提供側の追加作業は何かです。操作数や感想だけでなく、顧客が目的に沿って使えた事実を残します。観測期間が足りず継続は未確認なら、その段階での採用判断と、後で確認する条件を分けます。
投資には、作る時間だけでなく、運用、問い合わせ、教育、資料、仕様変更時の確認、既存顧客への影響を含めます。少人数の裏作業で成立した検証から、その時間が顧客数に比例して増えるかを確認します。既存の約束を果たすための工数を先に確保し、同じ専門担当の時間を複数の投資案へ重ねて配分しません。
| 判断する項目 | 検証で残す材料 | 次の判断への使い方 |
|---|---|---|
| 顧客の価値 | 目的の業務が変わったか、条件と限界 | 解決策を採用・修正・見送る |
| 再利用できる範囲 | 共通する作業と顧客固有の作業 | 個別対応と標準仕様を分ける |
| 維持する負荷 | 教育、問い合わせ、変更、裏側の作業 | 初期開発以外も含めて配分する |
| 約束と責任 | 提供可能な範囲、窓口、確認時点 | 未承認の将来仕様を販売しない |
営業の受付と、事業側の約束を切り離して運用する
営業は、顧客の目的、依頼された方法、代替手段、未確認事項、合意している範囲を記録します。営業企画は重複と対象の偏りを整理し、商品・提供部門は解決方法と運用負荷を検討します。事業責任者は、他の投資案や既存提供の改善と比べ、どこへ資源を置くかを判断します。要望を受け付けた時点で、納期や実装を確約しないことが前提です。
判断の記録には、対象となる課題、選んだ対応、選ばなかった案、根拠、条件、責任者、再確認の時点を残します。顧客へは、確認中、試行の相談、提供可能な範囲、今回は対応しない範囲を区別して返します。「社内へ伝えた」が「対応予定」と受け取られていないかも確認します。
採用後は、最初に要望を出した顧客だけで評価を終えません。適用条件を満たす他の顧客への利用と支援負荷、従来の業務への影響を点検します。標準化した仕様が合わなければ適用範囲を狭め、追加の開発や販売を止める判断へ戻します。売れたことだけで投資を正当化し続けず、提供後に分かった条件を次の判断へ使います。
実務で迷う論点：大口の要望、少数の声、販売時の説明
大口顧客の要望は優先すべきでしょうか。事業への影響は考慮しますが、その顧客専用の対応と、全体へ提供する投資を分けます。契約額が大きいことだけでは、共通性や保守の負荷は確かめられません。
少数の要望は見送るべきでしょうか。まだ会えていない顧客群や、新しい業務の兆候かもしれません。件数だけで捨てず、現在の対象からは見えにくい理由と、少ない資源で確認できる問いを整理します。仮説として残すことと、今すぐ作ることは別です。
検証中の内容を営業してもよいでしょうか。説明できるのは、現時点の提供範囲と確認できた条件です。検証していない効果や、承認されていない将来仕様を契約の前提にせず、顧客が判断に必要な不確かさも伝えます。
