VoC(顧客の声)プログラム実践ガイド:2026年版

VoC(顧客の声)プログラムの本当の姿

VoC(顧客の声)プログラム(VoCと略されることが多い)とは、単なるアンケートではありません。すべてのチャネルで顧客が言っていることに耳を傾け、それを理解し、その結果として製品やサービスを変えていくために企業が構築する、繰り返し動く仕組みです。

「プログラム」という言葉が重要な意味を持っています。一度きりのアンケートはスナップショットにすぎません。プログラムとは、オーナーがいて、実施のペースが決まっていて、顧客へのフィードバックの仕組みがある、継続的なループのことです。この最後の部分こそ、ほとんどのチームが省いてしまう部分であり、実は最も重要な部分です。

4つのステージに分けると、具体的な形が見えてきます。

1. 収集:顧客がすでに話している場所からフィードバックを集める。
2. 分析:引用の山ではなく、順位付けされた定量的なテーマに整理する。
3. 行動:上位のテーマに対して、製品、ドキュメント、プロセスを修正する。
4. ループを閉じる:顧客の声によって何が変わったのかを顧客に伝える。

どのステージも省くと、全体が機能しなくなります。分析せずに収集すれば、コメントの山に埋もれます。行動せずに分析すれば、とても高価なダッシュボードが出来上がるだけです。ループを閉じずに行動すれば、顧客は自分の発言が何かに繋がったと知る機会を失い、やがて発言をやめてしまいます。

ほとんどのプログラムが静かに失敗する理由

私がよく目にする、居心地の悪いパターンがあります。チームがVoC(顧客の声)プログラムを立ち上げ、大規模なアンケートを送り、まずまずの回答率を得て、レポートを作成します。半年後には、それによって変わったことを誰も一つも挙げられず、回答率は急落しています。

ほとんどの場合、原因は3つの失敗パターンに絞られます。

用意した質問にしか耳を傾けていない。 アンケートはあなたが考えた質問を聞くものです。あなたが思いつかなかった質問については、何も分かりません。分かりにくい請求書に静かに腹を立てている顧客は、NPSアンケートには答えませんが、それについてのチケットは必ず開きます。プログラムがアンケートだけなら、フィルターがかかった、自ら選んだ一部の顧客の声しか聞いていないことになります。

スコアで止まってしまう。 NPS42やCSAT4.1のような数字は答えのように感じられるため、チームはそれをゴールとして扱ってしまいます。しかし、スコアは実は最も使えない部分です。その裏にある自由記述のコメント、つまりその数字になった理由こそが、行動すべき対象です。そのテキストを大量に読むのは大変なので、ほとんどのチームは一部だけを抜き出して「代表的なもの」として扱ってしまいます。

ループを閉じない。 これが静かな殺し屋です。時間をかけてフィードバックをくれた顧客が、何も起きないのを見ると、「あなたに話すのは無駄だ」という教訓を学びます。そうして、最も熱心だった顧客ほど静かに離れていくように仕向けてしまうのです。フィードバックをリテンションのワークフローに組み込んでおけば、リスクのあるアカウントを早期に発見できるか、解約フォームで初めてその理由を知ることになるかの違いが生まれます。

一貫して言えるのは、VoC(顧客の声)プログラムの価値は、収集した後に何をするかで決まるということです。収集そのものは、簡単な10%の部分にすぎません。

チャネル:顧客の声はどこにあるのか

何かを分析する前に、顧客の声がどこにあるのかを知る必要があります。それは、ほとんどのチームが最初に使うアンケートツールよりも、はるかに多くの場所に散らばっています。

• サポートチケットとメール。 最も豊富な単一の情報源です。求められてもいないのに具体的で、顧客が今まさに抱えている本当の問題に直結しています。
• ライブチャットのログ。 スピーディーでカジュアルで、正式なアンケートには決して現れないような小さな不満がたくさん詰まっています。ライブチャットの対応削減のデータは、フィードバックデータとしても使えます。
• CSATとNPSのアンケート。 特に解決後のCSATアンケートや定期的なNPSアンケートは、傾向を見るという意味では今も有効です。ただし、スコアだけを全てだと思わないようにしましょう。
• オンラインレビュー。 G2、Capterra、Trustpilot、アプリストアなど。公開されていて影響が大きく、顧客が面と向かって言うことよりも本音に近いことが多いです。
• SNSとコミュニティ。 フィルターのかかっていないチャネルです。あなたに向かって話していないときに、人々が実際に言っていること。
• 営業と解約時の電話。 もう少しで購入しそうだった理由、そして実際に離れていった理由です。通常はCRMの中に眠っていて、サポートの誰も読んでいません。

目標は、これらを一つの場所に集約することです。そうすれば、チケットの中の請求に関する苦情、請求についての星1レビュー、請求についての解約時の電話が、3つの無関係なデータ点ではなく、同じテーマとして表れるようになります。

プログラムをステップごとに構築する

調査部門は必要ありません。必要なのは、決まったペースで動くループです。ここでは、それでも機能する最も無駄のないバージョンを紹介します。

1. オーナーとペースを決める

オーナーがいないプログラムは、アンケートが入ったフォルダにすぎません。誰かが週次または月次のレビューの責任者となり、そのレビューは「時間ができたら」ではなく、カレンダーに沿って行われる必要があります。小規模なチームでは、すでにカスタマーサービスを担当している人がこれを兼任することが多いです。

2. まず既存のフィードバックを一つにまとめる

何かを購入する前に、すでに手元にあるものを一つにまとめましょう。ヘルプデスクには数か月から数年分のチケットがあります。レビューページは公開されています。CRMには解約に関するメモがあります。これらを一つのビューにまとめることは、新しいピカピカのアンケートよりも価値があり、かかるのは時間だけです。これこそ、連携されたカスタマーサービスソフトウェアのスタックが真価を発揮する場面です。

3. 生のフィードバックを順位付けされたテーマに変える

このステップは、以前は誰かが何千件ものコメントを読む必要がありました。今はAIによるテーマ分析がすべてを読み込み、件数と感情の情報を付けたうえで、順位付けされたトピックにクラスタリングしてくれます。

求めるべき出力は、「顧客は請求について不満そうだ」ではなく、「請求関連の混乱、問い合わせの23%、今月は感情スコアが8%下落」のような形です。誰かに修正の予算を出してもらうよう説得する場面では、定量的なデータは常に質的なデータに勝ります。自動化されたチケットの分類とチケットのタグ付けは、これに直接つながります。

4. 上位のテーマに対して行動する

上位2〜3個のテーマを選び、実際に何かをしましょう。請求関連の混乱というテーマであれば、請求書を書き直す、ナレッジベースの記事を更新する、あるいはチェックアウトの手順を修正することを意味するかもしれません。繰り返し出てくる「注文はどこにあるのか」というテーマであれば、より良いプロアクティブなメッセージングを意味するかもしれません。業務に関わるものはカスタマーサービスのワークフローに流し込み、実際に担当者へ割り振られるようにしましょう。

5. 声に出してループを閉じる

何が変わったのかを顧客に伝えましょう。変更履歴のメモ、レビュアーへの返信、問題を指摘してくれた人へのメールなど。「あなたはXを教えてくれた、私たちはYを直した」という一言は、カスタマーエクスペリエンスの中で最も使われていない言葉であり、アンケート回答者をファンに変える一言でもあります。

AIが計算式を変える場所

VoC(顧客の声)プログラムが歴史的に失敗してきた理由は、実はありふれたものです。フィードバックを大量に読むのはコストがかかるため、チームは一部を抜き出して推測していました。AIはその制約を取り払い、プログラムのあり方そのものを変えます。

40件のコメントを読んで推測する代わりに、40,000件すべてを読みます。四半期ごとのレポートの代わりに、急上昇が起きた当日にフラグを立てる感情分析が手に入ります。一人のアナリストの解釈の代わりに、すべてのチケットにわたって一貫したクラスタリングが得られます。これは、AIによるカスタマーサービスの指標や、より大きな流れであるカスタマーサービスにおけるAIの広がりの中で見られる、同じ変化です。

ここにはもっと大きな話があります。それは私がサポートチームで最も大切だと思っている点です。AIエージェントとVoC(顧客の声)プログラムは、本来同じシステムであるべきです。チケットに回答するために読み込んでいるAIは、すでにすべてのチケットを読んでいます。その同じ理解力を「人々は何に苦労しているのか」に向けることは、エージェントが接続されてしまえばほとんどコストがかかりません。聞くことと解決することが、二つの別々のプロジェクトではなくなるのです。

同僚のAmoghは、何か月も顧客との電話に耳を傾けた後、このパターンを率直に言い表しました。人々は本当に、心から、過去のチケットでAIを学習させたいと思っている、と。その直感は正しく、それは自動化のための直感であると同時に、VoC(顧客の声)のための直感でもあります。それらのチケットこそがコーパスなのです。eesel AIがチケットの履歴で学習するとき、それは回答の仕方を学びながら同時に、顧客が実際に何について連絡してくるのかを地図化しているのです。

このループが実際に成果を生むという証拠は、実際の導入事例に表れています。例えばGridwiseは、すぐに結果を目にしました。

"In the first month, eesel is resolving 73% of our tier 1 requests... we saw results quickly during our 7-day trial."

Kim Simpson, Gridwise (case study)

この73%は解決率を示す数字ですが、それらのチケットを解決している同じエンジンが、どのティア1のテーマが多いのかも教えてくれます。つまり、プログラムと自動化が互いを強化し合う関係になるのです。同様に、Global Paymentsはドキュメント全体から回答を探す際に最大80%の時間削減を報告しています。

追うべき指標

VoC(顧客の声)プログラムには、小さくて誠実なスコアカードが必要です。追う指標が多すぎると誰も見なくなり、間違った指標を追うと見せかけの最適化になってしまいます。

最後の行がすべてを物語っています。ほとんどのチームはCSATを小数点第1位まで即答できますが、それによって何を実際にリリースしたかは一つも答えられません。この比率を逆にできれば、プログラムはその名にふさわしいものになります。より詳しい内訳については、AIによるカスタマーサービスの指標についての記事で、どの数字を信頼すべきかをさらに深く解説しています。

避けるべきよくある間違い

• 常に全員に対してアンケートを送ってしまう。 アンケート疲れは実際に起こります。だらだらと続けるより、回数を減らしてタイミングを絞ったアンケートの方が効果的です。
• すでに持っているチャネルを無視してしまう。 自分たちのサポートチケットを読む前にフィードバックツールを購入しているなら、そもそも始める場所を間違えています。
• ダッシュボードを成果物だと思ってしまう。 本当の成果物は、実際にリリースされた変更と顧客へのメッセージです。ダッシュボードはあくまで手段です。
• 感情データを読まずに放置してしまう。 感情スコアの低下が月次レポートで初めて表面化するなら、それは1か月遅れで気づいたことになります。アラートは、Slackのようにチームがすでに使っている場所に流しましょう。
• プログラムを別のサイロとして運用してしまう。 プログラムは、脇に置いた四半期ごとの調査活動としてではなく、ヘルプデスクやエスカレーションのフローに組み込んだときに最も効果を発揮します。

プログラムのAI部分にはeeselを試してみてください

VoC(顧客の声)プログラムのほとんどはプロセスです。オーナーを決め、実施ペースを選び、ループを閉じる。以前はデータチームが必要だった部分、つまりすべてのチケットを読み込み、順位付けされたテーマに変える部分は、eesel AIが標準でやってくれます。

既存のヘルプデスク(Zendesk、Freshdesk、Gorgias、Help Scout、HubSpot、そして100以上の連携)に接続し、過去のチケットで学習することで初日から顧客が何について連絡してくるのかを理解し、そのすべてに対してテーマ分析を実行します。テーマを見つけ出すのと同じエージェントが、その裏にあるチケットも解決するため、聞くことと答えることが二つではなく一つのワークフローになります。料金は1チケットあたり0.40ドルの利用量ベースで、席数に応じた費用はかかりません。本番導入前に、過去のチケット履歴に対してシミュレーションを行い、どんなテーマが見つかるかを確認することもできます。

聞くことと解決することを一つにまとめたいなら、eeselを試してみてください。無料です。