パワハラ・カスハラ対策しているのに、無くならないのはなぜ
新しい商品やサービスを考えるとき、マーケティング施策を検討するとき、業務改善を進めるとき。
私たちは、さまざまな情報を集めながら「おそらく、顧客はこう考えているのではないか」「このサービスなら、このニーズに応えられるのではないか」と考えます。
これが、いわゆる「仮説」です。
そして、その仮説が本当に正しいのかを、データや調査、実験などによって確かめ、必要に応じて仮説を修正していく。
これが「仮説検証」です。
仮説検証は、マーケティングや新規事業だけのものではありません。
商品開発、サービス改善、営業、業務設計、組織づくりなど、「まだ答えが分からないもの」に対して、考えたことを実際の事実で確かめていくための考え方です。
ただし、顧客についての仮説を検証する場合、一つ考えてみたいことがあります。
それは、
「顧客について立てた仮説を、実際の顧客との会話で確かめることはできないのかか」
ということです。
この記事では、まず一般的な仮説検証について整理したうえで、顧客の声を使って仮説を検証する方法、そしてコールセンターを「顧客の声を集めて報告する場所」ではなく、「顧客との会話を通じて仮説を確かめる場所」として活用する考え方について説明します。
仮説検証とは
仮説検証とは、ある問題や現象に対して「こうではないか」という仮の答えを立て、その答えが実際の事実と合っているのかを確かめることです。
例えば、新しいサービスを企画するとします。
顧客への調査や市場データなどから、
「この顧客層は、価格よりも手軽さを重視しているのではないか」
という仮説を立てたとします。
しかし、仮説はあくまでも仮の答えです。
そこで、アンケートやインタビュー、Web上の行動データ、実際の利用状況などを調べ、その仮説がどの程度当てはまるのかを確かめます。
結果によっては、
「価格よりも手軽さを重視している」
という仮説が支持されるかもしれません。
反対に、
「手軽さだと思っていたが、実際には価格と安心感の組み合わせが重要だった」
と分かるかもしれません。
その場合は、最初の仮説を修正します。
つまり仮説検証は、
仮説を立てる → 確かめる → 結果を見る → 仮説を修正する
という繰り返しです。
最初から正解を当てることが目的ではありません。
むしろ、分からないことについて仮説を置き、事実を使って少しずつ確かめていくことに意味があります。
なぜ仮説検証が必要なのか
事業やサービスを考えるとき、最初から正解が分かっていることはほとんどありません。
だからといって、何も考えずに商品やサービスを作ることもできません。
そこで必要になるのが仮説です。
「顧客はこういうことを求めているのではないか」
「この問題を解決すれば、顧客に選ばれるのではないか」
「この説明方法なら、顧客に理解してもらえるのではないか」
と考える。
しかし、仮説を立てただけでは、まだ事実ではありません。
仮説をそのまま正しいものとして扱ってしまうと、企画や開発の方向がずれていた場合、そのずれに気づくまでに大きな時間やコストがかかります。
だからこそ、できるだけ早い段階で仮説を確かめる。
仮説検証には、
- 不確実なことを整理する
- 思い込みだけで意思決定することを防ぐ
- 問題の方向性を早く確認する
- 必要に応じて計画を修正する
- 大きな投資をする前に可能性を確かめる
といった意味があります。
重要なのは、「正解を一度で出すこと」ではありません。
間違っていたことを早く知り、次の仮説に進めることも、仮説検証の重要な価値です。
仮説検証はどのような流れで行うのか
一般的な仮説検証は、次のような流れで考えることができます。
1. 現状や問題を把握する
まず、「何が分かっていないのか」「何を明らかにしたいのか」を整理します。
例えば、
「新しいサービスを作ったが、本当に顧客が必要としているのか分からない」
「問い合わせが多いが、その背景に何があるのか分からない」
といった状態です。
2. 仮説を立てる
現状や集めた情報をもとに、
「もしかすると、こういう理由なのではないか」
という仮説を立てます。
ここで重要なのは、仮説を「事実」と混同しないことです。
「顧客はこう考えているはず」
ではなく、
「顧客はこう考えているのではないか」
と置いてみる。
3. 検証方法を決める
次に、その仮説をどうやって確かめるのかを考えます。
例えば、
- アンケート
- インタビュー
- Web調査
- 市場データの分析
- 実験
- MVP
- 実際の利用状況の観察
- 顧客との会話
などがあります。
4. データや事実を集める
決めた方法によって情報を集めます。
ここで重要なのは、「仮説に合う情報だけを集める」のではなく、仮説と異なる結果も含めて確認することです。
5. 仮説と結果を比較する
実際に得られた結果と、最初に立てた仮説を比較します。
仮説どおりだったのか。
一部だけ合っていたのか。
まったく違っていたのか。
それを確認します。
6. 仮説を修正する
検証結果から、新しい仮説を立てます。
つまり、
仮説 → 検証 → 修正 → 再検証
というサイクルを回します。
この繰り返しによって、最初は曖昧だった顧客理解や問題の捉え方が、少しずつ具体的になっていきます。
顧客についての仮説は、どうやって検証するのか
ここから、少し話が変わります。
例えば、商品開発やマーケティングを担当しているとします。
顧客アンケートを実施する。
Web上の情報を調べる。
市場データを分析する。
顧客インタビューを行う。
競合サービスを調べる。
こうした情報を組み合わせて、
「顧客は、このようなことを求めているのではないか」
という仮説を作ります。
これは非常に重要なプロセスです。
しかし、ここで一つの壁があります。
調査によって「〇〇かもしれない」までは分かっても、
実際に顧客がその場面に直面したとき、本当にそのように考え、行動するのか
というところまでは、必ずしも分かりません。
例えば、
「顧客は、この機能を求めている」
というアンケート結果があったとします。
しかし、実際に商品を利用するときには、その機能よりも別のことを気にしているかもしれません。
あるいは、
「この説明なら分かりやすい」
と考えて作った説明が、実際の顧客との会話では伝わらないかもしれません。
つまり、
調査で得られる「顧客の声」と、実際の顧客との会話で出てくる「顧客の反応」は、必ずしも同じではありません。
だからこそ、顧客についての仮説を検証するなら、実際の顧客との接点を使う方法も考える必要があります。
顧客の声(考え)を「実際の会話」で検証する
顧客の声を知る方法には、さまざまなものがあります。
アンケートも、インタビューも、Web調査も重要です。
一方で、企業と顧客が実際に会話する場面には、別の情報があります。
例えば、
「この商品は返品できますか」
という質問があったとします。
FAQに書かれている返品条件を説明すれば、質問そのものには答えられます。
しかし、顧客が本当に知りたいことは、
「返品できるかどうか」だけではないかもしれません。
「思っていた商品と違ったので、返品したい」
「家族に合わなかったので、どうすればいいか知りたい」
「返品したいわけではないが、このまま使って大丈夫なのか確認したい」
など、質問の背景には異なる事情がある可能性があります。
つまり、顧客との会話には、
顧客が何を言ったのか
だけではなく、
なぜそれを言ったのか
何を確認したかったのか
何が分かれば納得できるのか
という情報があります。
これは、アンケートの回答だけでは見えにくい情報です。
だから、顧客について立てた仮説を検証する方法として、
実際の顧客との会話を使う
という考え方があります。
では、顧客との会話をどこで行うのか
ここで、コールセンターが一つの選択肢になります。
コールセンターには、日々さまざまな顧客から電話が入ります。
顧客が何を知りたいのか。
何に困っているのか。
どこで説明が分かりにくくなるのか。
どのような確認をすると話が進むのか。
どこで会話が止まるのか。
こうしたことが、実際の顧客との会話の中に現れます。
つまりコールセンターは、単に「問い合わせに答える場所」ではありません。
企業が顧客と直接会話する場所でもあります。
そう考えると、コールセンターを顧客理解や仮説検証のための接点として活用する方法が見えてきます。
ただし、ここで一つ問題があります。
「仮説検証したいので、報告書を作ってください」では意味がない
企画や開発、マーケティングの担当者が、
「この仮説を確かめたい」
と思ったとします。
そこでコールセンターに、
「このテーマについて顧客の声を集めて、報告書にしてください」
と依頼したらどうなるでしょうか。
コールセンターでは、本来の顧客応対に加えて、
- 対象となる応対を探す
- 顧客の発言を整理する
- 内容を分類する
- 件数を集計する
- 傾向を分析する
- 報告書にまとめる
- 依頼した部署へ報告する
といった仕事が発生します。
これでは、仮説検証を速くしたいのに、コールセンター側の仕事を増やすことになります。
また、報告書が完成するまで、仮説を立てた側は結果を待たなければなりません。
これでは、仮説検証のサイクルそのものが遅くなります。
そこで発想を変えます。
「報告書を作ってもらう」のではなく、「通常の顧客応対そのものを仮説検証に使う」
という考え方です。
日々発生する通常の顧客応対そのものを、仮説検証にする
例えば、企画・開発・マーケティングの担当者が、
「顧客は、この順番で説明すれば理解しやすいのではないか」
という仮説を持っていたとします。
あるいは、
「この質問を先に確認すれば、顧客が本当に困っていることが分かるのではないか」
という仮説でも構いません。
「この提案をすると、顧客は別の選択肢を希望するのではないか」
という仮説でも構いません。
こうした仮説を、実際の顧客との会話として設計します。
例えば、
質問 → 確認 → 分岐 → 次の質問 → 提案
という会話の流れにします。
そして、それを通常のコールセンター応対の中で使います。
すると、仮説を検証するために、別途アンケートや調査を設定しなくても、実際の顧客との会話の中で反応を見ることができます。
ここが大きな違いです。
仮説を「トークスクリプト」にして、実際の顧客で試す
ここでいうトークスクリプトは、単に「このセリフを言ってください」という台本ではありません。
重要なのは、
- 何を確認するのか
- なぜ確認するのか
- どの順番で聞くのか
- 顧客の反応によって次に何を選ぶのか
- どの条件なら別の方法へ進むのか
といった、会話の運びです。
つまり、トークスクリプトそのものを、
「この方法なら顧客の期待を理解できるのではないか」
という仮説として扱うことができます。
そして、実際の顧客との会話で使ってみる。
そこでオペレーターが、
「こちらの会話の方が顧客の反応に合っている」
と感じれば、そのスクリプトを選択する。
反対に、
「この方向では合わない」
となれば、別のスクリプトへ進む。
大きくズレれば、前に戻って修正する。
この実際の選択や修正を、次の会話に反映できるようにする。
そうすると、仮説検証が「一度だけ行う調査」ではなくなります。
実際の顧客との会話を使って、繰り返し仮説を確かめる仕組みになります。
コールセンターの負担を増やさずに仮説検証を行う
ここは、従来のVOC活動との違いとして重要です。
仮説検証のたびに、
「顧客の声を集めてください」
「このテーマについて分析してください」
「報告書を作ってください」
と依頼するのではありません。
通常の顧客応対の中に、仮説を組み込む。
そのため、コールセンターが仮説検証のためだけに新しい報告業務を追加で行う必要がありません。
企画・開発・マーケティングなどが知りたいことを、自分たちの仮説として会話に組み込んで試す。
そして、実際の応対データを必要な人が確認する。
つまり、
「コールセンターに顧客の声を集めてもらう」のではなく、「コールセンターで起きている顧客との会話を、会社自身が学習材料として使う」
ということです。
この違いは、仮説検証のスピードにも影響します。
仮説検証のために、コールセンターから報告してもらう必要がない
従来の流れでは、
仮説を立てる
↓
コールセンターへ依頼する
↓
顧客の声を集める
↓
整理する
↓
報告書を作る
↓
企画・開発・マーケティングが確認する
↓
次の仮説を考える
という時間が必要になります。
一方、顧客との会話そのものを仮説検証に使えるようにすれば、
仮説を立てる
↓
会話として設計する
↓
顧客との応対で試す
↓
実際の応対データを見る
↓
仮説を修正する
↓
次の応対で試す
というサイクルに近づけることができます。
しかも、必要な人が実際の応対を確認できるので、コールセンターが毎回、内容を別の報告書に編集して渡す必要もありません。
これは単に「情報収集を効率化する」という話ではありません。
仮説検証のための時間そのものを短くする可能性があります。
AIコーチングエンジンなら、顧客との会話を仮説検証に使える
この考え方を実際の仕組みとして実現する方法の一つが、「AIコーチングエンジン」です。
AIコーチングエンジンは、AIが顧客に対して「正解」を判断するシステムではありません。
判断はヒト・意思決定はヒト。
ここは重要な考え方です。
推進チームが、
「この質問を先に確認したらどうか」
「この説明の流れなら顧客の意図を理解できるのではないか」
「この条件なら、この選択肢を提示した方がよいのではないか」
といった仮説を立てます。
その仮説を、実際の会話としてトークスクリプトにします。
そして、コールセンターで顧客との応対に使います。
実際のオペレーターの選択が、次のナビゲーションを変えていく
AIコーチングエンジンでは、複数のトークスクリプトを用意し、それぞれにスコアを持たせることができます。
モニターには、スコアの高い順にスクリプトが表示されます。
顧客との会話の中で、オペレーターが、
「今の顧客の反応なら、こちらが近い」
と感じたスクリプトを選択します。
その選択が、そのスクリプトのスコアに反映されます。
つまり、実際の顧客応対の中で選ばれたものほど、次の応対で選ばれやすくなっていきます。
反対に、選択されないものは相対的に下がっていきます。
さらに、大きなズレがあり、オペレーターが前の段階に戻って修正した場合には、その行動もスコアに反映されます。
つまり、
実際の顧客との会話の中で、人がどう選択したのか、どこで戻ったのか
が、次のナビゲーションに反映されます。
AIが、
「このスクリプトが正解です」
と決めているわけではありません。
実際の人の選択と修正行動が、次の会話を変えていく。
ここに、この仕組みの特徴があります。
新しい仮説を意図的に試すこともできる
ここで、もう一つ重要なことがあります。
新しく作ったトークスクリプトには、最初から十分なスコアがありません。
既存のスクリプトに200点、300点といったスコアが蓄積されていると、新しいスクリプトを追加しただけでは、なかなか上位に表示されない可能性があります。
しかし、新しいスクリプトは「まだ試していないからスコアが低い」だけかもしれません。
そこで推進チームが、
「この新しい仮説を意図的に試してみよう」
と判断した場合には、新しいスクリプトのスコアを書き換え、実際の応対で試すこともできます。
つまり、
自然に選ばれるのを待つだけではなく、人が「この仮説を試す」と決めて、顧客との会話に載せることができる。
これも、AIに意思決定を任せないからこそできることです。
仮説検証に、コールセンターを巻き込むのではない
ここまで読んで、
「コールセンターの仕事が増えるのでは」
と思うかもしれません。
しかし、考え方は逆です。
コールセンターに、
「仮説検証のための仕事を追加する」
のではありません。
普段行っている顧客応対そのものを、会社の仮説検証に活用する。
そのため、推進チームにはコールセンターやSVだけではなく、企画、開発、マーケティングなどのメンバーが参加できます。
それぞれが、
「顧客について、こんな仮説を持っている」
というものを持ち寄る。
それを会話として設計する。
実際の顧客との応対を見る。
そして、顧客がどう反応したのかを確認する。
これなら、企画・開発・マーケティングの担当者自身が、顧客の期待を知るためのプロセスに参加できます。
コールセンターから加工された二次的な報告を受け取るだけではありません。
実際の顧客との会話という一次データに触れることができます。
顧客との会話を使うと、仮説検証だけで終わらない
ここが、この方法のもう一つの面白いところです。
仮説を検証していると、当初想定していた問題とは別のことが見えてくる場合があります。
例えば、
「この質問への回答が分かりにくい」
と思っていたら、実はWebサイトの説明が分かりにくかった。
「オペレーターの説明が不足している」
と思っていたら、契約条件そのものが顧客に伝わりにくかった。
「問い合わせが多い」
と思っていたら、商品そのものに分かりにくさがあった。
このように、顧客との会話を丁寧に見ていくと、問題の原因がコールセンターの中だけにあるとは限りません。
商品、サービス、契約、販売時の説明、Web、業務ルール、物流、社内連携など、会社のさまざまな場所に原因があることがあります。
だからこそ、コールセンターを「問題を処理する場所」だけとして見るのではなく、
会社が顧客から学ぶための入口
として見ることができます。
顧客理解を深めると、AHTが長くなるのでは
ここで、コールセンターではよく出てくる疑問があります。
「顧客の背景まで確認するようにしたら、AHTが長くなるのではないか」
確かに、必要のない質問を増やせば、応対時間は長くなります。
しかし、顧客理解とは、何でも質問すればよいということではありません。
重要なのは、
必要なことを、必要な順番で確認することです。
例えば、顧客が「もう使いたくありません」と言ったとします。
ここで、
「承知しました」
だけで終われば、顧客が何に困っているのか分かりません。
一方で、何も考えずに質問を増やせば、時間だけがかかります。
必要なのは、
「なぜそう感じたのか」
「どこで問題が起きたのか」
「顧客は何を実現したかったのか」
を、必要な順番で確認することです。
そのためには、質問一つひとつに目的が必要です。
仮説検証を繰り返せば、
「この場面では、何を確認すれば顧客の期待を理解できるのか」
が少しずつ明確になります。
すると、不要な質問や説明、行ったり来たりする会話を削ぎ落とせます。
結果として、
顧客理解を深めながら、AHTを無意味に肥大化させない
という方向を目指せます。
「顧客満足を上げるには時間をかけるしかない」
「効率化するには顧客理解を浅くするしかない」
という二択ではありません。
顧客理解とコールセンターの効率化は、必ずしも対立しません。
仮説検証を繰り返すほど、顧客期待に沿った応対に近づいていく
仮説検証の目的は、単に「仮説が正しかったか、間違っていたか」を判定することではありません。
顧客について立てた仮説を実際の顧客との会話で確かめれば、
「この質問では顧客の意図が分からない」
「この順番なら必要な情報を確認できる」
「この説明では伝わりにくい」
「この確認をすると、顧客が本当に求めていることが見えてくる」
といったことが分かってきます。
そして、その結果を次の応対に反映する。
これを繰り返していけば、応対は少しずつ、
会社が想定した顧客に合わせる応対
から、
実際の顧客が求めていることに合わせる応対
へ近づいていきます。
その結果として、顧客満足度を高めることにもつながります。
そして、不要なやり取りが減れば、コールセンター側の生産性にもつながります。
つまり、
顧客にとって良い応対と、コールセンターにとって効率の良い応対を、同時に目指すことができます。
「AIが学習する」のではなく、「会社が顧客から学び続ける」
AIコーチングエンジンについて説明すると、
「AIが学習して、どんどん賢くなる仕組みですか ?」
と思われるかもしれません。
しかし、少し違います。
AIが自動的に「正解」を決め続けることが目的ではありません。
人が仮説を立てる。
その仮説を会話として設計する。
実際の顧客との会話で試す。
オペレーターが選択する。
必要なら戻って修正する。
その結果を見て、推進チームが次の仮説を考える。
そして、また次の顧客との会話で試す。
つまり、
AIが学習し続けるのではなく、会社が顧客から学び続ける。
ここに、この方法の本質があります。
顧客との応対そのものが、次のナレッジを生み出す場所になります。
仮説検証に「終わり」はあるのか
仮説検証を、
「最終的な正解を見つけるための作業」
と考えると、いつか終わりが来ます。
しかし、顧客の期待は変化します。
商品もサービスも変わります。
市場も変わります。
顧客の置かれている環境も変わります。
だから、会社が顧客期待に応えようとする限り、
「これで完全に正解」
というところで止める必要はありません。
むしろ、
仮説を立てる → 顧客との会話で試す → 結果を見る → 次の仮説を立てる
という循環そのものに意味があります。
だから、この方法は「完成したトークスクリプトを作ること」がゴールではありません。
顧客との会話を使って、会社が学び続ける仕組みを作ること。
そこに価値があります。
こんな状態なら、仮説を顧客との会話で確かめる方法を考えてみてください
もし、次のようなことを感じているのであれば、一度、顧客との会話を仮説検証に使う方法を考えてみてもよいかもしれません。
- 顧客アンケートや市場調査は行っているが、最後の確信が持てない
- 顧客インタビューでは意見を聞けるが、実際の利用場面で確かめられない
- 「顧客はこう考えているはず」という仮説をもとに企画を進めている
- 商品やサービスを提供した後になって、想定と顧客の反応が違うことに気づく
- VOCは集まっているが、企画や開発に活かすまでに時間がかかる
- コールセンターへ報告書作成を依頼すると、コールセンターの負荷が増える
- 顧客理解を深めたいが、AHTが長くなることが心配
- FAQやマニュアルを増やしても、顧客との会話のズレがなくならない
- ベテランが行っている質問や確認の仕方を、組織として再現したい
- 顧客の反応を見ながら、質問や説明の方法を改善したい
- 企画・開発・マーケティングの担当者自身が、実際の顧客との会話を見たい
こうした課題は、単純に「コールセンターの教育を強化する」というだけでは解決できない場合があります。
なぜなら、問題がコールセンターの中だけにあるとは限らないからです。
顧客が何を期待しているのか。
その期待に対して、会社は何を提供しようとしているのか。
その間に、どこにズレがあるのか。
そこから考える必要があります。
仮説検証を、顧客期待に応えるための仕組みに変える
仮説検証は、企画やマーケティングのためだけの手法ではありません。
顧客について立てた仮説を、実際の顧客との会話で確かめることができれば、コールセンターは単なる問い合わせ対応の場所ではなくなります。
顧客が何を求めているのかを知る。
そのために必要な質問や確認を考える。
実際の会話で試す。
顧客の反応を見る。
次の応対に反映する。
そして、そこからまた新しい仮説を立てる。
この循環を会社の中に作ることができれば、顧客の声は「集めて終わる情報」ではなくなります。
会社が次の行動を決めるための一次情報になります。
そして、最終的に目指すところは、コールセンターを効率化することだけでも、AIを導入することだけでもありません。
会社として顧客期待に応えること。
そのために、顧客との接点をどう活かすのか。
もし今、
「顧客について立てた仮説を、実際の顧客との会話で確かめてみたい」
「コールセンターに追加負荷をかけずに、顧客の反応を企画や開発に活かしたい」
「顧客理解を深めながら、コールセンターの生産性も高めたい」
と考えているのであれば、まずは現在どのような仮説を持っているのか、整理するところから始めてみてください。
その仮説は、どの顧客に対して、どのような会話で確かめられるのか。
どの質問をすれば、顧客の背景や期待が分かるのか。
どの反応を見れば、仮説を修正すべきなのか。
そして、その結果を次の顧客との会話にどう反映するのか。
こうした設計まで考えることで、仮説検証は「調査して報告書を作る仕事」から、顧客との会話を通じて会社が学び続ける仕組みへ変わっていきます。
なお当社では、コールセンターにおける顧客との会話を、質問・確認・会話の流れ・分岐・選択基準などの形に構造化し、実際の応対で活用しながら改善していく「AIコーチングエンジン」を提供しています。
もし、現在取り組んでいる顧客理解や仮説検証について、
「調査まではできるが、実際の顧客で確かめるところが難しい」
「VOCを集めても、企画や開発につながらない」
「コールセンターの負荷を増やさずに、顧客との会話を会社の改善に活かしたい」
という課題があれば、一度お聞かせください。
どのような仮説を、どのような顧客との会話で確かめられるのか。
そこから一緒に考えることができます。
