口コミへの回答には、事実と評価の区別が必要だ

商談先が口コミを示したときは、気にしている点から確認を始めます。投稿の評価と確認できた事実を分け、判断に必要な情報を伝えます。

  • 確かめる懸念を決める　相手が知りたいのは、同じことが起きる可能性か、対応の姿勢か、業務への影響かを確かめると決めます。
  • 答える範囲を決める　商品の変更点や使い方を調べ、自社で確認できた事実と、確認できない事情を分けて答えると決めます。
  • 残す記録を決める　否定や弁解に偏らない説明の順序と、相手の理解と未確認の点の記録の仕方を決めます。

口コミへの疑問は、商品の評価だけとは限らない

同じ投稿を示されても、相手が気にしている点は異なります。投稿全体への賛否を述べる前に、知りたいことを絞ります。

  • 気になる箇所を特定する　投稿のどの記述が気になったのかを確認し、その箇所と相手の懸念を対応させます。
  • 知りたいことを分ける　同じ出来事が起きるかの心配、問題が起きた際の対応、業務への影響のどれを知りたいのか整理します。
  • 答える範囲を決める　相手の懸念に関係する情報から説明します。商品全体の長所を並べても、疑問への回答にはなりません。

相手の関心を整理する表

気にしている点確かめること注意
同じことの発生同じ出来事が起きる条件を知りたいか。条件が不明なまま、起きないと断定しません。
対応の姿勢案内や問題発生後の対応の何が気になるか。投稿者の感じ方を訂正しようとしません。
業務への影響どの業務に、どのような支障を懸念しているか。商品全体の説明に話を広げすぎません。
表は編集部作成の例です。

出来事の記述も、確認済みの事実とは限らない

投稿には、出来事の記述と、その出来事への評価や推測が混在します。何が書かれているかと、自社で裏付けられるかを分けて読みます。

  • 出来事を抜き出す　操作、発生した現象、対応の経過を抜き出します。投稿に記載があるだけでは、確認済みとは扱いません。
  • 評価を区別する　使いやすさや満足度は、投稿者による評価として扱います。その評価が正しいか間違っているかは判断しません。
  • 推測を事実に変えない　原因や意図についての推測を分けます。自社に都合のよい推測も、裏付けなしに説明へ加えません。

投稿内容を読み分ける表

内容の種類見分け方扱い
出来事の記述操作や現象、対応の経過が記されているか。確認の対象にし、裏付けの有無を別に記録します。
投稿者の評価使いやすさや対応への満足が述べられているか。投稿者の評価として、出来事とは分けます。
推測原因や提供側の意図を推し量っているか。確かめられない原因や意図を断定しません。
表は編集部作成の例です。

現在の仕様だけでは過去の出来事を否定できるとは限らない

投稿時点と現在で、機能や提供条件が変わっている場合があります。投稿された日と実際に利用した時期も区別して、変更の範囲を調べます。

  • 利用した時期を調べる　投稿された日だけで利用時期を決めません。当時の仕様を特定できない場合は、特定できなかったことを記録し、説明でもそのまま伝えます。
  • 変更の範囲を調べる　変更履歴や当時の資料で、何が変わったかを確認します。口コミに関係する変更かどうかも見極めます。
  • 過去と現在を分ける　当時と現在で仕様が異なることを、当時の出来事を否定する材料にはしません。変わっていない制約も説明に含めます。

商品の変更を確認する表

違いの種類確かめること伝え方
画面や機能当時と現在の操作や機能に変更があるか。変更した箇所と現在も残る制約を区別します。
提供条件利用できる範囲や条件が変わっているか。現在の条件が相手の利用にも当てはまるか示します。
対応の仕組み受付方法や対応手順に変更があるか。確認できた変更を示し、その変更で問題が起きなくなるとまでは言い切りません。
表は編集部作成の例です。

投稿者の使い方が相手の使い方と同じとは限らない

同じ商品でも、利用場面や設定によって起きることは異なります。投稿に書かれた前提と相手の使い方を比べ、不明な部分を補って解釈しません。

  • 利用場面を具体化する　どの業務で、何をしようとした際の出来事かを整理します。相手が想定する利用場面も確認します。
  • 設定の影響を調べる　動作に関係する設定や権限を確認します。投稿に記載がなければ、設定の誤りが原因とは決めません。
  • 利用者の条件を調べる　操作する人の役割や利用環境を確認します。経験不足など、書かれていない事情を推測しません。

使い方の前提を確認する表

前提確かめること注意
利用場面どの業務の、どの操作で起きたことか。前提が違うだけで、相手には無関係と決めません。
設定設定や権限が動作に影響しているか。投稿に書かれていない設定を推測して、原因にしません。
利用者誰が、どのような環境で利用したか。裏付けがないまま、利用者の経験や注意の不足を原因にしません。
表は編集部作成の例です。

回答で断定できる範囲は、確認した事実に限られる

自社の商品でも、個別の投稿に関する事情をすべて確認できるわけではありません。確認できたこと、確認できないこと、確認中のことを分けます。

  • 根拠を対応させる　答える内容ごとに、仕様資料や記録などの根拠を確認します。どの時点の情報かも明らかにします。
  • 不明な事情を残す　投稿だけでは特定できない利用状況や経緯は、不明として扱います。記録がないことだけで否定しません。
  • 確認中の扱いを決める　調べる対象、確認する担当、結果を伝える時期を決めます。確認中の見立てを確定情報として伝えません。

確認状況を区別する表

区分答え方注意
確認済みの事実根拠と対象の時期を添え、確認した範囲を示します。現在の仕様から個別の経緯まで断定しません。
確認できない事情何が不明で、なぜ判断できないかを説明します。発生を確認できないことを、起きなかったこととして答えません。
確認中確認の対象と、結果を伝える時期を示します。結論を先に約束せず、調査の結果を伝えます。
表は編集部作成の例です。

回答は相手の懸念に関係する事実から始める必要がある

答える際は、相手が気にしている点に関係する事実から説明します。確認した出来事、現在の違い、分からない点を混ぜずに扱います。

  • 確認した事実を認める　機能が動作しない条件や利用上の制約が確認できた場合は、その範囲を明示します。商品の長所を先に並べて、その説明を後回しにしません。
  • 違いの意味を示す　変更点が相手の懸念にどう関係するかを説明します。商品を変更したことだけを理由に、納得を求めません。
  • 不明点を明示する　分からない点は分からないまま伝えます。追加で確認できることがあれば、その対象も示します。

状況に応じた答え方の表

場面答え方避けること
事実を確認した確認した出来事と、影響が分かる範囲を説明します。事実として確認した範囲を超えて、評価や推測まで認めません。
現在は違いがある関連する変更点と、残っている制約を示します。変更を理由に、当時の出来事を軽く扱いません。
事情が分からない判断できない点と、確認可能な範囲を示します。推測で投稿を否定したり、自社を擁護したりしません。
表は編集部作成の例です。表は説明方針を整理した架空の例であり、回答文例ではありません。

良い口コミも、相手に同じ結果が出る根拠とは限らない

好意的な投稿があっても、相手の懸念に答えたことにはなりません。良い口コミも投稿者の評価として扱い、商品の説明は自社で確認した事実に基づけます。

  • 評価で評価を打ち消さない　良い口コミを持ち出して、示された口コミを退けません。相手が気にしている出来事への説明を続けます。
  • 書かれていない条件を補わない　好意的な評価にも、投稿者の利用場面や期待があります。書かれていない条件を都合よく補いません。
  • 事実で説明する　機能や提供条件は、自社の資料や記録で説明します。相手の使い方で確認が必要な点も残します。

良い口コミを扱う際の表

確かめること理由注意
投稿者の条件満足した理由や使い方が、相手と同じとは限りません。良い評価だけを抜き出し、結果を約束しません。
自社の確認事実商品について説明できる範囲を明らかにできます。投稿の評価と、自社で確認した事実を混ぜません。
相手の条件相手の業務で必要な確認事項を判断できます。好意的な投稿を理由に、必要な確認を省きません。
表は編集部作成の例です。

回答後の相づちだけでは、理解されたとは限らない

説明を終えても、断定していないことが確約として伝わる場合があります。相手がどう理解したかを聞き、残る懸念と追加で確認したい点を整理します。

  • 相手の理解を聞く　説明から何が分かり、何が分からないままかを、相手の言葉で整理してもらいます。その内容からずれを見つけます。
  • 残る懸念を分ける　情報不足なのか、制約が業務上気になるのかを区別します。同じ説明の繰り返しで納得を求めません。
  • 確認する対象を決める　追加で何が分かれば判断できるかを整理します。自社で追加確認する事項と、その結果を踏まえて相手が判断する事項を分けます。

説明後の理解を確認する表

確かめ方確かめることずれていたとき
相手の言い換え確認した範囲や条件付きの回答が伝わっているか。断定できる範囲と、不明な点を説明し直します。
残る懸念どの出来事や制約への懸念が残っているか。懸念の対象に戻り、関係する情報を示します。
確認したい点判断のために、何を追加で知りたいか。確認対象と方法を決め、対応できる範囲を示します。
表は編集部作成の例です。

条件付きで答えた内容は条件ごと記録する必要がある

商談中は条件付きで説明しても、提案書では結論だけが残ることがあります。説明した事実と根拠、回答の条件、未確認の点を記録し、提案書でも同じ条件をそろえます。

  • 懸念と回答を記録する　示された口コミの要点、相手の懸念、答えた内容を対応させます。投稿者の評価を自社の見解に変えません。
  • 根拠と条件を残す　参照した資料、確認した時点、説明の前提を残します。提案書でも、根拠が支える範囲を超えて書きません。
  • 未確認の点を引き継ぐ　未確認の点と確認担当、結果を伝える時期を記録します。解決済みのような表現がないか見直します。

回答を記録する表

記録項目書くこと理由
示された口コミ投稿を識別できる情報と、懸念に関係する要点を記します。後から別の投稿や別の論点と取り違えないためです。
説明した事実説明内容、根拠、確認時点、適用する条件を記します。提案書にも、確認した範囲を保って記載するためです。
未確認の点不明点、確認担当、結果を伝える時期を記します。確認が終わる前に、解決済みとして扱わないためです。
表は編集部作成の例です。

回答の整理表で、説明できる範囲と未確認の点が分かる

商談前には分かっていることを記入し、商談後には実際に答えた内容を追記します。空欄を推測で埋めず、不明な理由や確認の予定を残します。

  • 投稿と懸念を分ける　投稿の要点と、相手が気にしている点を別に書きます。出来事の記述、評価、推測も区別します。
  • 確認の根拠を書く　商品の違いや使い方の前提に加え、確認に使った資料と時点を記します。不明な条件は不明と書きます。
  • 回答後に更新する　実際の回答、相手の理解、残る懸念を追記します。未確認の点には確認担当と結果を伝える時期を記します。

口コミへの回答の整理表

記録項目記入欄記録項目記入欄
示された口コミの要点相手が気にしている点
出来事の記述・評価・推測の区別利用した当時と現在の違い
投稿の前提となる使い方確認済みの事実と確認に使った資料・時点
答えた内容と相手の理解残る懸念と未確認の点
確認担当と結果を伝える時期記録先
表は編集部作成の例です。出来事の記述は、裏付けを確認するまで確認済みの事実として扱いません。