カスタマーサポートにおいて、
問い合わせは“起点”のように扱われがちです。
問い合わせが発生した。
対応する。
KPIを確認する。
しかし本当に、問い合わせは始まりなのでしょうか。
ここを構造として整理します。
問い合わせは「最初の行動」ではない
問い合わせは、
ユーザーが最初に取る行動ではありません。
ユーザーは通常、次のようなプロセスを経ています。
状況を認識する
↓
解決手段を探す
↓
情報に接触する
↓
理解し、判断する
↓
行動を選択する
この最後の「行動選択」の一つが問い合わせです。
つまり、問い合わせは
プロセスの入口ではなく、最終地点に位置しています。
問い合わせ件数をKPIとしてどう扱うべきかについては、上位思想で整理しています。
問い合わせが発生する条件
問い合わせが発生するのは、主に次のどちらかです。
- 自己解決が成立しなかった
- 問い合わせのほうが合理的だと判断された
どちらも、
その前段階で何らかの摩擦が起きています。
探せなかった。
読んだが判断できなかった。
情報が不足していた。
構造が分かりづらかった。
問い合わせは、摩擦そのものではありません。
摩擦が“表面化した結果”です。
問い合わせを起点にすると何が起きるか
問い合わせを起点にKPIを設計すると、
視点はどうしても「対応後」に寄ります。
平均応答時間
解決までの時間
対応件数
満足度
これらは重要です。
しかしいずれも、
問い合わせが発生した後の世界を測る指標です。
その前に何が起きていたのかは、見えません。
これは、
火災報知器を見て火事を分析するのと似ています。
報知器は原因ではありません。
燃焼の結果です。
問い合わせも同じです。
問い合わせの前にある「見えない世界」
問い合わせの前には、必ず次の段階があります。
- 必要な情報にたどり着けたか
- 検索は機能していたか
- 記事は判断材料になっていたか
- 次の行動が明確だったか
このプロセスが成立していれば、
問い合わせは自然と減ります。
成立していなければ、
問い合わせは増えるか、
あるいは離脱に転じます。
重要なのはここです。
問い合わせが増えたことではなく、
なぜそこに至ったのか。
問い合わせが減ったことではなく、
本当に迷いが解消されたのか。
問い合わせは「構造のシグナル」
問い合わせ件数は、
削減対象ではありません。
体験構造の状態を知らせるシグナルです。
増えているなら、
どこかで摩擦が起きている。
減っているなら、
自己解決が成立しているか、
あるいは離脱が増えている可能性もある。
だから問い合わせは、
単独で評価する指標ではありません。
プロセス全体の中で読むべき数値です。
では、このプロセスをどう設計するのか。
フォーム直結を避け、ヘルプをポータル化する具体設計はこちら。
結論
問い合わせは、
カスタマーサポートの出発点ではありません。
ユーザー行動の最終地点で発生する結果です。
だから見るべきは、
問い合わせの「数」ではなく、
問い合わせに至るまでの「構造」です。
ここを分解しない限り、
KPIは対応管理の数字にとどまります。
ここを分解したとき、
はじめてカスタマーサポートは
体験設計の仕事になります。
コメント