商談で聞いた改善要望を社内で検討できる形にする

この機能が欲しいという言葉だけでは、変更が必要な理由を判断できません。利用場面と困っていることを聞き、社内で検討してほしいことを書いて渡します。

  • 発言の整理方法を決める　質問・不具合の申告・改善要望を区別し、相手の発言と自分の解釈を書き分けます。
  • 追加で聞く内容を決める　変更を求める理由と利用場面を聞き、要望が実現しない場合に起きることを確かめます。
  • 社内への渡し方を決める　整理票に記入する内容と、社内に求める判断を決めます。相手への回答をどう扱うかは社内で決める手順にします。

発言だけを転送すると、検討に必要な背景が伝わらないことがある

仕様を変えてほしいという言葉をそのまま転送しても、何に困っているのかが伝わらないことがあります。背景を添え、発言の種類を示し、発言と自分の解釈を分けて渡します。

  • 背景を添える　変更の希望だけでなく、どの業務で何が困るのかを書きます。
  • 発言の種類を示す　使い方への質問なのか、動作の問題なのか、変更の希望なのかを確認します。
  • 推測だと分かるようにする　商談への影響など、自分で補った意味を相手の発言として書かないようにします。

転送時に抜けやすい情報

営業担当者の伝え方社内の担当者が困ること防ぎ方
背景が抜ける何のために変えるのかを判断できません。利用場面と困る理由を添えます。
種類が混ざる説明・調査・改善検討のどれが必要か判断に迷います。発言の種類を確認して書きます。
解釈が混ざる営業担当者の推測を、相手の意向として扱ってしまいます。発言と解釈を別の欄に書きます。
表は編集部作成の例です。情報が足りない場合は、推測で埋めずに未確認と記します。

質問・不具合の申告・改善要望を区別する

似た言い方でも、使い方を知りたい場合と変更を求めている場合があります。発言の意図を確かめてから、社内で決めた窓口へ渡します。

  • 質問かを確かめる　今の機能や操作でできることを尋ねているなら、まず使い方の確認として扱います。
  • 不具合の申告を分ける　説明と実際の動作が違うという申告は、発生状況を添えます。不具合とは断定しません。
  • 変更の希望を確かめる　今の仕様を理解したうえで変更を求めているかを聞き、改善要望として記録します。

発言と社内の渡し先

発言の種類例渡す先
質問保存した一覧をどこから開くのかを尋ねる発言使い方を案内する窓口へ渡します。
不具合の申告保存できると説明を受けたのにエラーになるという申告動作を調査する窓口へ渡します。
改善要望保存した一覧を部署内で共有できるようにしてほしいという要望商品の改善を検討する窓口へ渡します。
未確認この一覧は共有できないのかという発言（質問か要望か不明）意図を聞いてから渡す先を決めます。
表は編集部作成の例です。発言に質問と変更の希望が含まれる場合は、内容を分けて記録します。

相手の発言と自分の解釈を分けて残す

共有できると助かるという発言を、共有できなければ導入しないと書き換えると、意味が変わります。実際の発言、自分の解釈、未確認の点を分けて残します。

  • 実際の発言を残す　相手が述べた内容を記録します。正確な言葉を残せていない場合は、要約と明記します。
  • 自分が補った意味を分ける　重要そうだと感じた理由や商談への影響の見立ては、自分の解釈として書きます。
  • 未確認の点を残す　聞けていないことは未確認と記し、次に確かめる内容を書きます。

発言と解釈の書き分け

区分書くこと記録と確認のしかた
相手の発言引用：部署内で一覧を共有できると助かります（相手の言葉のまま）引用か要約かを明記します。
自分の解釈部署内で作業を引き継ぐ際に困っている可能性があります。どの作業で共有したいかを聞きます。
未確認の点共有できないことが導入判断に影響するかは未確認です。導入判断との関係を相手に聞きます。
表は編集部作成の例です。強い要望だと感じても、相手が述べていない条件を付け足さないようにします。

変更を求める理由と利用場面を聞く

欲しい機能の名前だけでは、社内の担当者はその変更が適切かを判断できません。どの業務で誰が使い、今はどう進め、なぜ困っているのかを聞きます。

  • 使う場面を聞く　作業の流れのどこで使いたいかを聞き、利用する人の役割を記録します。
  • 今の進め方を聞く　現在の操作や受け渡し方を聞き、希望する状態との違いを書きます。
  • 困る理由を聞く　便利だからという理由で終えず、今の方法で何が起きるために変更したいのかを確かめます。

利用場面を聞く質問

聞くこと確かめ方記録
どの業務か使いたい作業を尋ねます。案件を引き継ぐときに使います。
誰が使うか操作する人と内容を見る人を尋ねます。一覧に入力する担当者と、案件を引き継いで受け取る担当者が使います。
今の方法現在の渡し方を尋ねます。一覧を別の記録に転記して渡しています。
困る理由今の方法で困ることを尋ねます。転記した後に一覧を直しても、引き継いだ相手に伝わりません。
表は編集部作成の例です。実際に起きている場面と、今後使いたいと考えている場面を区別します。

要望が実現しない場合に何が起きるかを確かめる

必要だという言葉だけでは、業務への影響は分かりません。止まる作業、現在の回避方法、影響を受ける範囲を具体的に聞きます。

  • 止まる作業を聞く　作業を続けられないのか、手間をかければ続けられるのかを分けて記録します。
  • 回避方法を聞く　現在の方法で進められる場合も、残る負担や困りごとを聞きます。
  • 影響する範囲を聞く　誰のどの作業に影響するかを確かめます。購入や継続の判断への影響も推測せずに聞きます。

要望が実現しない場合の確認

確かめること内容注意
止まる作業引き継ぎそのものができないかを聞きます。不便であることと、作業が止まることを分けます。
回避方法別の記録を作れば進められるかを聞きます。回避できるだけで問題が解消したと判断しません。
影響の範囲引き継ぐ人や確認する人への影響を聞きます。部署全体の問題だと推測して広げません。
判断への影響購入や継続を判断する条件なのかを聞きます。未確認のまま失注や解約の理由にしません。
表は編集部作成の例です。相手が希望する方法が商品にない場合も、別の方法で目的を満たせないかを社内で確かめます。

実現する方法を営業担当者が独断で決めない

共有ボタンを付けてほしいという発言は、実現方法の希望を含む発言です。その方法で何をしたいのかを聞き、方法の判断は社内の検討に委ねます。

  • 希望した方法を残す　相手が挙げた方法は、そのまま記録します。社内で決定した方法とは区別します。
  • 方法の先の目的を聞く　その方法でできるようにしたい作業を聞き、目的を別に書きます。
  • 方法の判断を委ねる　既存機能や別の方法で目的を満たせるかも含め、営業担当者は社内の担当者に判断を求めます。

方法を決めずに渡す書き方

避けること代わりにすること理由
仕様を決める相手が希望した方法（共有ボタン）と、達成したい目的（一覧の変更を引き継ぎ先へ伝える）を分けて書きます。社内の担当者が、目的を満たす別の方法も検討できるためです。
可否を即答する実現できるかは未確認と記録します。商品の制約や他の利用場面を確認する必要があるためです。
別案を確約する既存機能や別の方法で目的を満たせるか、確認を依頼します。別の方法でも相手の業務で使えるとは限らないためです。
表は編集部作成の例です。社内への記載は、作る方法の指定ではなく、判断してほしい内容にします。

社内で検討してほしいことを明らかにする

要望がありましたという報告だけでは、何を判断すればよいか分かりません。渡す先に応じて、求める判断とその判断に必要な情報を添えます。

  • 求める判断を書く　現在の機能で対応できるか、改善の検討対象にするかなど、判断してほしいことを書きます。
  • 判断に要る情報を添える　発言、利用場面、困る理由、業務への影響を添え、不明点も明記します。
  • 回答期限の有無を書く　相手が回答を求める日と理由を記録します。希望日までに回答できるか、対外的に回答してよいかの判断は営業責任者に求めます。

渡す先ごとの依頼内容

渡す先検討してほしいこと添える情報
案内の窓口今の機能や使い方で目的を満たせるかを確認してもらいます。現在の操作と、実現したい作業を添えます。
調査の窓口説明と動作の違いについて、調査に必要な情報を確認してもらいます。期待した動作、実際の動作、発生状況を添えます。
改善の窓口改善の検討対象にするか、追加で何を確認すべきかを判断してもらいます。利用場面、理由、影響、関連する記録を添えます。
営業責任者相手への回答の要否と、希望日までに回答できるかを判断してもらいます。回答の希望日と理由、これまでのやり取りを添えます。
表は編集部作成の例です。窓口の名称や役割は、自社の体制に合わせて置き換えます。

他の商談の記録を確かめ、相手には受け取ったことを伝える

似た発言が見つかっても、同じ業務上の要望とは限りません。目的と利用場面を比べて社内へ添えます。相手には要望を受け取ったことを伝え、社内で決まる前に検討や実現を約束しません。

  • 関連する記録を探す　機能名だけでなく、目的や困っている作業でも探し、元の商談記録を確認します。
  • 同じ要望の基準を決める　同じ要望とする条件や、同じ相手からの再申告の数え方を社内で決めます。
  • 受け取ったことを伝える　要望を受け取ったことを伝えます。社内で決まる前に、検討することや実現することを約束しません。

記録の確認と受領時の対応

場面することしないこと
記録を探すとき目的・利用場面・業務への影響を読み比べます。同じ機能名だけで同じ要望と判断しません。
再申告のとき以前の記録と関連付け、状況の変化を残します。同じ相手からの再申告を、別の要望として数えません。
社内へ渡すとき似ている点と異なる点、元の記録の場所を添えます。関連する記録だけで対応の優先順位を決めません。
相手に伝えるとき要望を受け取ったことを伝えます。社内で決まる前に、検討の開始や採用、実現方法を約束しません。
表は編集部作成の例です。他の商談の記録が見つからなかった場合も、検索した範囲を残します。

検討結果を相手にどう伝えるかは社内で決める

社内の検討結果を、そのまま相手に送れるとは限りません。相手に回答を約束している場合はその期日を守り、約束していない場合は伝えるかどうか、伝える内容の範囲、伝える人を社内で決めます。

  • 伝えるかを決める　相手に回答を約束している場合は、約束した内容と期日に沿って伝えます。約束していない場合は、結果とこれまでのやり取りを踏まえて連絡の要否を決めます。
  • 伝える範囲を決める　社内の案や見通しを、決定事項として伝えないようにします。回答に使う表現も確認します。
  • 伝える人を決める　伝える人と時期を決めます。伝えない場合も、理由と今後の問い合わせへの対応を残します。

検討結果と回答の扱い

検討結果相手への扱い記録
情報が足りない追加で聞く内容と、確認する人を決めます。不足している情報と確認先を残します。
既存機能で対応相手の利用場面で使えるかを確認し、案内内容を決めます。案内する操作と、できる範囲を残します。
改善を見送る伝えるかどうかと、伝えられる理由を決めます。回答の要否、理由、伝える人を残します。
判断を保留する現状を伝える必要があるかを決めます。保留の理由と、再確認する条件を残します。
変更方針が決まる対外説明できる範囲を確認してから回答します。承認された回答内容、伝える人、時期を残します。
表は編集部作成の例です。回答を求められている場合は、その扱いも含めて社内で決めます。

改善要望を整理票に書いて社内へ渡す

聞き取った内容を整理票に書き、社内で求める判断を明記します。未確認の欄を残したまま渡す場合は、何を追加で聞く必要があるかも書きます。

  • 発言と種類を記入する　相手と商談日を記し、発言を引用か要約か分かる形で残します。種類が不明なら未確認とします。
  • 背景と影響を記入する　利用場面、変更を求める理由、実現しない場合に起きることを書きます。
  • 検討と回答の扱いを書く　判断してほしいことと関連する商談記録を添え、相手への回答について決まっている範囲を書きます。

改善要望の整理票

項目記入欄
相手の発言・種類相手・商談日：／発言：（引用・要約）／種類：質問・不具合の申告・改善要望・未確認
利用場面と理由業務：／使う人：／今の進め方：／変更を求める理由：／相手が希望した方法：／達成したい目的：
実現しない場合止まる作業：／回避方法と残る負担：／影響の範囲：／購入・継続判断への影響：
解釈と未確認点自分の解釈：／未確認の点：／追加で聞く内容：
社内への検討依頼渡す先：／判断してほしいこと：／関連する商談記録と共通点・相違点：
相手への回答回答の希望日・理由：／既に伝えた内容：／社内で決めた回答の要否・範囲・伝える人・時期：
表は編集部作成の例です。空欄は未確認・該当なし・社内判断待ちなど、状態が分かる言葉で埋めます。