「正しい答え」が、顧客に届かないのはなぜか
更新日:6月14日
問いが浅ければ、世界も浅くなる——何を聞くかで、見える現実は変わる
「ご案内した手順で解決しますよ」。オペレーターはそう伝え、顧客も「わかりました」と答えた。手続きとしては、何も間違っていません。それなのに、電話を切った後の顧客には、どこか釈然としない気持ちが残っていました。問題は解決したはずなのに、満たされていない。こうした場面は、多くのカスタマーサポートで日々起きています。
応対の正確性、回答の一貫性、処理時間の短さ。カスタマーサポートの品質は、こうした指標で管理され、着実に改善されてきました。誤った案内や不適切な対応は、かつてと比べれば大幅に減っています。
それなのに、顧客との関係が深まっている実感がない。問題は解決しているはずなのに、どこか納得感が伴わない。こうした違和感は、むしろ増えているのではないでしょうか。
この違和感の正体は、回答の質ではなく、「問いの質」にあります。カスタマーサポートは正しい答えを出すことに長けてきました。ただ、そもそも何を問うべきかという前提がずれていれば、いかに正確な回答であっても、顧客の現実には届かないのです。
現象に答えるか、文脈に応じるか
「ログインできない」という問い合わせがあったとします。多くのオペレーターは、IDやパスワードの確認、再設定の案内を行います。業務としては正しく、効率的です。
ただ、ここで扱われているのは「現象」です。顧客にとっての問題は、「ログインできないこと」そのものではなく、その結果として「何かを達成できないこと」にあります。期限が迫っているのでしょうか、他の手段がないのでしょうか、それとも漠然とした不安を感じているのでしょうか。文脈によって、求められる対応はまったく変わります。
ジョブ理論という考え方があります。顧客は製品やサービスを「買う」のではなく、「片付けたい用事」を解決するために利用している、という見方です。ログインしたいのは目的ではなく手段であり、その先に本当の用事があります。現象に正しく答えることと、その用事に応じることは、似ているようで本質的に異なります。前者は処理であり、後者は理解です。
現在の多くのカスタマーサポートは、処理には強いものの、理解には十分に踏み込めていません。それは個人の能力の問題というより、「何を問うか」という設計の問題です。
観察と解釈は、別のものです
「ここで、二つの異なる姿勢を区別しておきたいと思います。観察と解釈です。
観察とは、顧客の行動やデータを把握することです。何を問い合わせたか、どのチャネルを使ったか、どれくらいの頻度で接触しているか。事実を正確に捉える、大切な営みです。
解釈とは、その行動の背景にある意図や目的を読み解こうとすることです。なぜその問い合わせをしたのか。その裏にどんな状況や感情があるのか。観察された事実を出発点に、その意味を考える姿勢です。
この二つは連続しているようで、実際には大きな断絶があります。観察だけでは本質に届きません。かといって、観察を経ずに解釈に走れば、それは単なる思い込みになってしまいます。
事実を丁寧に捉えた上で、その奥の意味を問う。この往復こそが、顧客理解の核心です。
VOCは増えているのに、なぜ理解は深まらないのでしょうか
通話ログ、チャット履歴、アンケート。多くの企業が膨大な顧客の声を蓄積しています。VOC(顧客の声)の可視化レベルは、飛躍的に向上しました。
ところが、その活用の多くは「何が起きたか」の分類にとどまっています。問い合わせ理由の集計、クレーム件数の推移、満足度スコア。これらは観察としては有効ですが、解釈には至っていません。事象を整理することと、顧客を理解することは違うのです。
あるEC企業では、返品に関するVOCを分析した際、従来は「サイズ違い」に分類されていた不満を深掘りしました。すると、顧客が本当に困っていたのは「自分に合うサイズを判断する手段がないこと」だとわかりました。問い合わせの表面ではなく、その奥の文脈を問い直したことで、製品ページの改善という根本的な対策につながったのです。
VOCは答えそのものではなく、「なぜそれが起きたのか」を探るための手がかりです。問いが浅いままでは、どれだけ声を集めても、その手がかりは活かされません。
問いの質は、組織の設計に規定されます
そして最も重要な点があります。問いの質は、個々のオペレーターのスキルだけで決まるものではない、ということです。
カスタマーサポートがどんな問いを立てるかは、組織の設計そのものによって規定されています。処理時間を重視するKPIのもとでは、短く済む問いが優先されます。誤りを減らす評価制度のもとでは、確実に答えられる問いに収束します。マニュアルや教育体系も、どんな問いが許容され、どんな問いが排除されるかを静かに決めています。
つまり、現場が浅い問いしか立てられないとすれば、それは現場の責任ではなく、そう仕向けている構造の結果です。深い問いを期待するなら、深く問うことが評価され、許容される設計が必要になります。
自社のカスタマーサポートは、どんな問いを前提に設計されているでしょうか。現象を処理する問いでしょうか、それとも文脈を理解する問いでしょうか。もしまだ答えが明確でないのであれば、「問いそのもの」を見直すところから始めてみてはいかがでしょうか。



