必須条件は相手が欠かせないと確認した条件で決まる

聞き取った要望をすべて必須にすると、提案に欠かせない条件が見えにくくなります。必要になる業務と、満たせない場合の影響から整理します。

  • 必須に残す根拠を決める　要望の強さではなく、欠かせない理由と満たせない場合の影響を判断の根拠にします。
  • 条件が必要な範囲を決める　どの使い方で必要かを明記し、必須条件と選ぶ理由になる希望条件を分けます。
  • 提案に記す内容を決める　相手が確認した条件、自社商品の対応、未確認の点を区別して提案書に残します。

強く求められた要望も、必須条件とは限らない

聞き取った要望には、欠かせない条件と、あれば便利な機能が混ざっています。繰り返された回数や言い方の強さだけでは、必須と判断できません。

  • 挙がった条件を残す　まずは要望として記録します。必要性を確認する前に、必須の扱いにしないようにします。
  • 強さを根拠にしない　強い表現には、過去の不便さや使い慣れた方法への希望が含まれることがあります。
  • 必要な理由へ戻る　欠かせないと考える理由が分かるまで、必須か希望かの判断を保留します。

要望の出方と確認の方向

要望の出方起こり得ること確かめること
強く求める過去の不便さが表現に出ている場合があります。今回も欠かせない理由があるか
多く挙げる思いついた便利な機能が含まれる場合があります。それぞれが必要になる業務は何か
繰り返し挙げる使い慣れた方法を続けたい希望が含まれる場合があります。同じ方法でなければ困るのか
表は編集部作成の例です。

条件の必要性は誰がどの仕事で使うかで決まる

同じ機能でも、使う人や仕事によって必要性は変わります。要望の名前だけを残さず、誰がどの仕事のどんな場面で使うかを書き添えます。

  • 実際に使う人を確認する　要望を伝えた人と、実際に使う人を区別します。使う人の役割まで記録します。
  • 必要な仕事を定める　便利になるという説明で止めず、どの作業を行うための条件なのかを明らかにします。
  • 必要になる場面を絞る　通常の作業で使うのか、特定の処理で使うのかを分け、要望と業務の関係を残します。

要望に業務の説明を添える

確かめること理由記録
誰が使うか発言者と利用者が同じとは限りません。実際に使う部署と役割を書きます。
どの仕事か必要性を作業に沿って判断します。条件が必要になる作業を書きます。
どんな場面か常に必要か、特定の場面だけで必要かを区別します。必要になる状況とタイミングを書きます。
表は編集部作成の例です。

条件の区分は満たせない場合の影響で決まる

条件がないと困るという説明だけでは、購入に欠かせないかは判断できません。業務が成り立たないのか、手間が残るのか、別の方法で対応できるのかを分けます。

  • 止まる業務を特定する　どの作業ができなくなり、その後の仕事に何が起きるのかまで記録します。
  • 残る手間を具体化する　誰にどんな作業が残るかを明らかにします。手間が残るだけで希望と決めないようにします。
  • 代わりの方法を検討する　別の方法がある場合も、実際に運用できるかを相手に確認してから条件を分類します。

影響から条件の扱いを考える

影響の型確かめること条件の位置づけ
業務が成り立たないできなくなる作業と代替の可否必須の候補とし、必要性を確認します。
手間が残る残る作業と運用上許容できる範囲手間を許容できるかで判断します。
代わりの方法がある実行する人と継続できる手順代替を受け入れられるかで判断します。
表は編集部作成の例です。

今のやり方の継続は、購入の必須条件とは限らない

現在の手順には、守る必要がある部分と、慣れているため続けたい部分があります。同じやり方を求める理由を分け、購入後も欠かせない条件を取り出します。

  • 継続したい理由を分ける　慣れているから続けたいのか、関連する業務のために変えられないのかを区別します。
  • 変えてよい範囲を記録する　手順を変えられる場合は、認められる変更の範囲を記録します。変更可能と推測しないようにします。
  • 変えられない根拠を残す　他部署への引き渡しなど、変えられない理由を具体化し、必要な条件として書き直します。

現行手順から必要な条件を取り出す

区別する点確かめること注意
今の方法の継続同じ方法を続けたい理由慣れだけを必須の根拠にしません。
変えてよい部分変更を受け入れられる範囲変更後の作業も確認します。
変えられない部分変更で支障が出る業務現行手順の全部が必須とは限りません。
表は編集部作成の例です。

必須条件は欠くと検討できないと相手が確認した条件に限られる

業務と影響を整理できても、営業側の判断だけで必須にはできません。その条件を欠く商品でも検討できるかを含め、購入に欠かせないという認識を相手と確認します。

  • 理由の理解を確認する　必要な業務と満たせない場合の影響の整理が、相手の認識と合っているかを確認します。
  • 欠く場合の判断を残す　その条件がない商品でも検討できるなら、必須とする理由を見直します。
  • 未確認を必須にしない　その条件を欠く商品は検討できないと相手が確認した条件だけを必須として残します。判断待ちの条件には未確認と記します。

確認結果を条件の区分に反映する

場面すること記録
理由を整理した業務と影響の理解を相手に確認します。確認した理由と相手の役割を残します。
欠く場合を考える条件がない商品でも検討できるか確認します。検討できるかと、その理由を残します。
判断が定まった必須・希望・未確認を区別します。区分と確認日を残します。
表は編集部作成の例です。

一部で必要な条件は当てはまる使い方を添える必要がある

特定の部署や作業だけで必要な条件もあります。必要になる使い方と今回の導入対象を照らし合わせ、条件が当てはまる範囲を絞って記録します。

  • 全体に必要かを分ける　すべての利用者や業務に必要なのかを確認します。一部の要望を全体の条件に広げないようにします。
  • 一部でも必須は残す　対象が一部でも、その使い方が今回の導入に含まれ、欠かせないなら必須として扱います。
  • 対象外の条件を分ける　今回使わない業務の条件は別に記録します。対象に加わった場合は必要性を確認し直します。

使い方ごとに条件の範囲を定める

条件の範囲確かめること提案での扱い
全体に当てはまる対象となる利用者と業務今回の導入全体の条件として記します。
一部の使い方だけ必要となる部署・作業・場面該当する使い方とともに記します。
今回の対象外今回使わないことを確認できるか今回の購入条件とは分けて記します。
表は編集部作成の例です。

希望条件には商品を比べるときに重視する理由が要る

必須ではないという判断は、選定に関係しないという意味ではありません。あれば望ましい理由を残し、必須を満たした商品を比較するときの材料にします。

  • 望ましい理由を残す　なくても検討できることを確認したうえで、どの業務で役立つため希望するのかを記録します。
  • 比較で重視する点を残す　同じ必須条件を満たす商品でも、希望への対応は異なります。商品を比べるときに重視する点を残します。
  • 将来の希望を分ける　将来の業務で使いたい条件は、必要になる場面とともに残します。今回の必須条件へ加えないようにします。

希望条件を選定の材料として残す

希望条件の種類扱い注意
あれば望ましい望ましいと考える業務上の理由を書きます。必須でないことを理由に除きません。
比較の材料商品を比べるときに重視する点を書きます。必須条件への対応と混ぜません。
将来の希望必要になる使い方と時期の見通しを書きます。今回必要な条件として扱いません。
表は編集部作成の例です。

相手の必要性と自社商品の対応は別に確認する必要がある

相手にとって必要かどうかと、自社商品で満たせるかどうかは別の確認です。対応しやすさに合わせて、必須や希望の区分を書き換えないようにします。

  • 必要性は相手に確認する　業務上の理由、満たせない場合の影響、条件の区分は相手に確認します。
  • 自社商品の対応は自社で調べる　利用条件や制限を含め、実際に対応できる範囲を確認します。確認できない点は未確認と記します。
  • 代替には再確認が必要だ　別の方法で対応できても、必要性が消えるわけではありません。相手がその方法を採用できるか確認します。

確認する内容と役割を分ける

確認する人確認すること注意
相手業務上の必要性と条件の区分商品で対応できるかとは分けます。
自社商品で対応できる範囲と制限未検証の対応を可能と書きません。
相手と自社代替方法の実行可否と受け入れ可否対応できるだけで了承済みにしません。
表は編集部作成の例です。

提案書には条件の区分と判断理由を残す必要がある

条件名だけを提案書に並べても、必須とした理由や未確認の点は伝わりません。区分、必要な範囲、自社商品の対応を分け、判断をたどれる記録を残します。

  • 必須の根拠を添える　必須条件には、必要な業務と満たせない場合の影響を添えます。特定の使い方に限られる場合も明記します。
  • 希望と未確認を分ける　希望には比較で重視する点を、未確認には確認する内容と確認先を記します。未確認を対応可能として記載しません。
  • 変更の理由も残す　誰にいつ確認したかと、記録先を残します。条件が変わった場合は、変更理由を提案書と商談記録に反映します。

提案書と商談記録に残す内容

記録項目書くこと理由
必須条件必要な業務、欠く場合の影響、使う範囲必須とした根拠を示します。
希望条件望ましい理由と比較で重視する点比較で重視する点を残します。
未確認の点確認内容、確認する人、確認する時期推測による判断を防ぎます。
商品の対応対応可否、利用条件、確認の根拠条件の区分と対応可否を分けます。
確認の記録確認相手、確認日、変更理由、記録先判断の経緯をたどれるようにします。
表は編集部作成の例です。

整理表を書くと判断理由の空白と未確認の点が分かる

要望ごとに、必要な業務から提案への反映先までを横に並べます。空欄を推測で埋めず、相手への確認と自社での確認を進めるための記録として使います。

  • 要望ごとに記入する　条件をまとめすぎず、それぞれに業務と影響を書きます。必須か希望かだけの一覧にしないようにします。
  • 判断の空白を見つける　理由や使い方が不明な条件は未確認にします。相手の確認待ちか、自社の調査待ちかも記します。
  • 提案書の記載箇所を残す　整理表の内容を提案書へ反映し、どこに書いたかを記録します。条件を更新したら、提案書にも反映します。

必須条件と希望条件の整理表

相手が挙げた条件必要になる業務満たせない場合の影響現行のやり方との関係必須か希望か必要になる使い方自社商品の対応未確認の点記録先
整理表は編集部作成の記入欄です。相手が挙げた条件ごとに1行ずつ記入します。