サポートへの問い合わせ、商談での要望、インタビューの記録には、顧客が何に困っているかを知る材料があります。
顧客の声(Voice of the Customer、VOC)は、こうした情報を集め、顧客のニーズとして整理し、製品やサービスの改善に使う取り組みです。
記録を蓄積するだけでなく、発言の背景を確かめて開発の判断につなげます。

原文と解釈を分けて残す

予約システムに「予約一覧を印刷したい」という要望が届いたとします。
聞き取りをすると、受付担当者は通信障害が起きたときも、来店する顧客を確認したいと考えていました。
この場合、原文はそのまま残し、「通信できないときにも当日の予約を確認できる」というニーズを別に記録します。
印刷機能、端末内への保存、障害時の閲覧手段などを比較するためです。

ASQの解説も、収集した声から、特定の機能や技術に依存しない顧客ニーズを整理する方法を示しています。
ただし、印刷物を店内の別の担当者に渡す必要もあるなら、その用途を消してはいけません。
一つの要望に複数の目的が含まれる場合は、それぞれの目的と条件を分けて記録します。

実務では、次の項目を一緒に残すと、後から判断の根拠をたどれます。

  • 顧客の発言や観察した事実と、その記録元。
  • 顧客の役割、利用場面、問題が起きた日時。
  • 解釈したニーズと、まだ確認できていない点。
  • 現在の対処方法、発生頻度、困った結果。
  • 類似する記録と、対応方針を決める担当者。

件数をそのまま優先順位にしない

問い合わせが多い問題と、多くの顧客が困っている問題は、必ずしも一致しません。
同じ顧客から繰り返し連絡が来る場合もあれば、使うのをやめた人が何も伝えない場合もあります。
集計するときは、問い合わせの件数と、影響を受ける顧客の数を区別します。
情報を集めた経路ごとに、誰の声が入りやすいかも確認します。

先ほどの予約システムなら、印刷の要望が多いかだけでなく、通信障害の頻度、業務が止まる時間、予約を確認できない店舗の範囲を調べます。
すでに代替手段がある店舗と、受付業務が止まる店舗では影響が異なります。
顧客の声は優先順位を考える材料であり、要望された機能をすべて作る約束ではありません。

対応を見送る場合も、理由を記録します。
対象顧客から外れる要望なのか、別の方法ですでに対処できるのかを区別すると、同じ声が届いたときにも判断を引き継げます。

対応後の変化を確かめる

改善したら、その機能を公開したかに加えて、元の問題が軽くなったかを確認します。
障害時に予約を確認できる手段を用意したなら、担当者がその手段を使えたか、受付を続けられたかを調べます。
結果を元の記録に結びつけると、次の判断にも使えます。
継続的な収集と対応は顧客フィードバックシステム、聞き取りの方法はデプスインタビューを参照してください。

参考資料