将来の機能の提供を約束しない

機能追加の質問に答えるときは、公開できる予定と未決定の要望を分けます。今の商品で導入を判断できる情報を渡すために、商談での対応を決めます。

  • 予定と要望を分ける　公開してよい予定の伝え方と、未決定の要望を持ち帰る方針を決めます。
  • 今の商品で判断してもらう　必要な機能を確かめ、今できること・できないこと・代わりの方法を説明します。
  • 書面と記録の扱いを決める　将来の機能を提案書や見積に書かず、伝えた内容と相手の判断、要望の渡し先を記録します。

将来の機能への期待が、導入の前提になることがある

機能追加を約束すると、今はない機能が導入の前提になり得ます。提供できなければ、業務の計画だけでなく、説明への信頼にも影響します。

  • 導入の前提を見直す　追加されることを前提に導入を決めていないかを確かめます。
  • 社内の決定と区別する　商談での約束だけでは、開発する内容や優先順位は決まりません。
  • 期待だけで進めない　機能追加の予定が変わっても、相手が今の商品でできることを基に導入を判断できるかを確認します。

将来の機能を約束した場合に起こり得ること

起きること相手に起きること防ぎ方
導入の前提になるまだ提供されていない機能を使う前提で、業務計画を立てます。今の商品で導入できるかを確かめます。
社内の方針と食い違う商談で聞いた内容と、商品担当の説明が異なります。公開してよい予定だけを伝えます。
約束した機能を提供できない業務計画を見直すことになり、説明への信頼も揺らぎます。変更の可能性と現在の提供内容を伝えます。
表は編集部作成の例です。

公開できる予定と未決定の要望を分ける

社内で話題になっていることと、商談で公開してよいことは別です。機能ごとの状態と公開できる範囲を、商品担当と確認しておきます。

  • 公開の可否を確認する　開発が決まっていても、未公開の情報を商談で伝えてよいとは限りません。
  • 検討と決定を区別する　検討中の機能や寄せられた要望を、追加予定として扱いません。
  • 説明の参照元を決める　商談では、社内で指定した最新の公開情報を参照します。

機能追加に関する情報の区分

区分商談で言えること注意
公開済みの予定公開情報にある内容を、認められた範囲で伝えます。公開後に内容が変更されていないかも確認します。
社内決定・未公開公開が認められるまでは、予定の詳細を伝えません。社内決定を公開の許可と捉えません。
検討中状態の公開が認められていれば、未決定であることを伝えます。検討中の機能について、追加される予定だと伝えません。
要望のみ追加は決まっておらず、要望として扱うことを伝えます。要望の受付を開発決定と結び付けません。
表は編集部作成の例です。

その機能が導入判断に必要かを確かめる

機能名だけでは、導入に欠かせない条件なのかは分かりません。必要な理由と必要になる期限、機能がない場合の判断を確かめます。

  • 必要な理由を聞く　どの業務で使い、何ができれば困りごとを解消できるのかを確認します。
  • 必要になる期限を聞く　相手の業務上の期限を確認します。その期限を機能追加の約束に置き換えません。
  • 機能がなくても導入するかを聞く　今の商品でも導入を検討できるか、追加されることが導入の条件かを確認します。

機能への要望と導入条件の確認

確かめること内容確認できなかった場合
必要な理由対象の業務と、実現したい結果を確認します。機能名だけで代わりの方法を選びません。
必要な期限業務上いつまでに使える必要があるかを確認します。導入に間に合うと判断しません。
ない場合の判断機能がなくても導入を検討できるかを確認します。追加への期待を導入の意思と捉えません。
表は編集部作成の例です。

公開できる予定は範囲と変更の可能性を伝える

公開できる予定も、現在使える機能とは分けて説明します。決まっている範囲と未決定の部分、変更の可能性を一緒に伝えます。

  • 決定した範囲を示す　公開情報にある対象や機能の内容を説明し、記載のない仕様を補いません。
  • 未決定の部分を示す　利用条件や細かな動作など、公開情報に記載がなく、社内でも決まっていない部分を明らかにします。
  • 変更の可能性を示す　予定が変わる可能性を添え、今の商品でも導入を判断できるかを確認します。

公開できる予定を伝える要素

伝える要素内容避けること
決まった内容公開が認められた対象と機能の範囲を伝えます。相手の要望に合わせて仕様を付け足しません。
未決定の内容決まっていない部分を区別して伝えます。未決定の部分を推測で埋めません。
変更の可能性内容が変わる可能性を予定と一緒に伝えます。変更の可能性を添えても、提供を約束したことにはなりません。約束する言い方をしません。
現在との違い今は利用できないことを明示します。現在の商品の機能として紹介しません。
表は編集部作成の例です。

未決定の機能は要望として持ち帰る

追加が決まっていない機能は、要望として持ち帰ることを伝えます。要望を社内に渡すことと、開発に採用されることや回答が得られることは別だと分けて扱います。

  • 持ち帰る目的を伝える　商品担当へ要望を共有するために持ち帰り、機能追加の約束はしません。
  • 回答を期待させない　社内での扱いが決まっていない段階で、採否の回答が得られると約束しません。
  • 判断条件も社内に渡す　必要な理由と導入への影響を添え、機能名だけの要望にしません。

未決定の要望を持ち帰る際の対応

場面すること注意
要望を聞いた必要な理由を整理し、要望として持ち帰ると伝えます。持ち帰ることを採用の見込みとして伝えません。
採用を求められた追加は決まっていないことを説明します。相手の導入を条件に、機能の開発を約束しません。
回答を求められた回答できる内容の有無を商品担当に確認します。回答が得られると先に約束しません。
社内に共有する要望と導入条件を指定の渡し先へ届けます。相手が機能追加を期待していることを、社内の決定として扱いません。
表は編集部作成の例です。

今できることとできないことを明確に伝える

今の商品で判断してもらうには、実現できる範囲を具体的に示す必要があります。現在の機能で実現できること、追加の設定や手作業で要望のどこまでを満たせるか、実現できないことを分けます。

  • 現在の機能を説明する　相手が行いたい業務に沿って、現在利用できる機能と利用条件を説明します。
  • 設定や作業を明らかにする　追加の設定や手作業が必要なら、行う人と作業内容を伝えます。
  • できない部分を明示する　要望のうち現在の商品では実現できない部分を示し、将来の機能で補えるという説明はしません。

現在の商品で説明する範囲

区分伝えること注意
今できること現在の機能で実行できる業務と利用条件を伝えます。提供していない機能を含めません。
設定の変更で満たせる部分必要な設定と、設定後も残る制約を伝えます。設定だけで要望をすべて満たすと決め付けません。
手作業で満たせる部分必要な手作業と、その作業を行う人を伝えます。手作業を商品の自動処理として説明しません。
できないこと現在の商品では実現できない部分を伝えます。機能追加を前提に、できることとして扱いません。
表は編集部作成の例です。

代わりの方法は条件と残る制約まで示す

希望された機能がなくても、目的を満たす別の方法が見つかることがあります。必要な作業や条件、実現できない部分まで示して判断してもらいます。

  • 目的に合う方法を探す　現在の別機能や運用の変更で、相手が必要とする結果を得られるかを確認します。
  • 負担と制約を説明する　追加作業や使える条件を伝え、希望した機能との違いを明らかにします。
  • 使える方法かを確かめる　代わりの方法を相手の業務で続けられるかを聞き、導入条件を満たすか確認します。

代わりの方法を示す際の確認

代わりの方法示すこと注意
別の機能を使う現在の機能で実現できる結果と操作を示します。希望された機能と同じだと説明しません。
運用で対応する手作業の内容と、作業を行う人を示します。相手が続けられる負担かを確認します。
他の商品や手段と組み合わせる組み合わせる相手と、作業の分担を示します。連携できるかを確認せずに提案しません。
方法が見つからない確認した範囲では目的を満たす方法が見つからなかったと伝えます。将来の機能を代わりの方法として勧めません。
表は編集部作成の例です。

提案書や見積に将来の機能を書かない

将来の機能を書面に入れると、今回購入する商品の内容として読まれ得ます。この資料では、提案書や見積には現在提供できる内容と条件だけを書く方針を採ります。

  • 現在の提供内容を書く　利用できる機能、必要な設定や作業、利用条件を記載します。
  • 公開予定も書き込まない　公開できる予定でも、提案書や見積の本文や注記、参考欄には入れません。
  • 記載を求める理由を聞く　将来の機能の記載を求められたら、導入に欠かせない条件なのかを確認します。

提案書や見積を作る際の対応

場面すること記録
現在の機能を書く提供できる内容と利用条件を記載します。提示した資料を保存します。
将来の機能について聞かれた書面に入れず、公開情報は別に案内します。案内した公開情報の参照元を残します。
記載を求められる記載する理由と、追加なしでの導入可否を確認します。求められた内容と判断条件を残します。
機能の追加が導入の条件今の商品では条件を満たさないことを相手と確認します。相手が導入を進めるかどうかの判断を残します。
表は編集部作成の例です。

説明と判断を記録し要望を商品担当に渡す

商談後は、聞かれた機能だけでなく、伝えた内容と相手の判断を残します。商品担当には、その記録を基に要望と必要な理由を渡します。

  • 説明した範囲を残す　参照した公開情報と、未決定の内容や変更の可能性をどう説明したかを記録します。
  • 相手の判断を残す　今の商品で導入を進めるのか、機能がないため判断を保留するのかを記録します。
  • 商品担当への共有を残す　要望を渡した商品担当の氏名と、要望を記録した場所を残し、開発が決まった情報とは分けて管理します。

商談記録と商品担当への共有項目

記録項目書くこと
聞かれた機能求められた動作と、対象となる業務を書きます。
必要な理由実現したい結果と、業務上必要になる期限を書きます。
伝えた内容公開情報の参照元、未決定の部分、変更の可能性について説明した内容を書きます。
現在の対応範囲今できること、できないこと、示した代わりの方法を書きます。
相手の判断相手が導入を進めるかどうかと、その理由を書きます。未確認なら未確認と記します。
要望の渡し先共有した商品担当と記録の場所、要望として渡した内容を書きます。
表は編集部作成の例です。

機能追加を聞かれたときの対応を決める

ここまでの内容を、自社の商品と商談の進め方に合わせて書き出します。公開情報の確認先から要望の渡し先まで、実際に使う名前や場所を記入します。

  • 自社の情報で埋める　公開予定を確認する資料、公開の可否を確認する相手、要望の渡し先を具体的に書きます。
  • 相手に確かめる項目を決める　必要な理由と期限、機能がなくても導入するかを、商談でどう確かめ、どこに記録するかを決めます。
  • 商談で使えるかを見直す　現在の商品と公開できる予定の範囲で説明できているか、将来の機能を約束する記載がないかを確認します。

将来の機能を聞かれたときの対応メモ

項目記入する内容自社の方針
社内での区分公開済み・社内決定で未公開・検討中・要望のみの区分と確認先を書きます。
確かめること必要な理由、必要な期限、機能がない場合の導入判断を、商談で確かめる方法を書きます。
伝え方の方針公開予定に添える情報と、未決定の要望を持ち帰る際の方針を書きます。
今の商品での説明できること、できないこと、代わりの方法とその条件を書きます。
提案書の書き方現在の提供内容を書く方針と、将来の機能の記載を求められた際の対応を書きます。
記録先と渡し先説明と相手の判断の記録先、商品担当へ要望を渡す方法を書きます。
表は編集部作成の例です。自社の対応方針を記入して使います。