「ログインできない」
その一文を、あなたは何度レポートに書いてきただろうか。
件数は増えている。
ユーザーは困っている。
重要度も高いはずだ。
それでも、何も変わらない。
それは、声が弱いからではない。
件数が足りないからでもない。
判断できる単位になっていないからだ。
VOCが“感想扱い”になる理由
多くのCS現場では、VOCはこう扱われる。
- 問い合わせ件数ランキング
- フリーコメントの抜粋
- 「最近多い」という報告
しかしこれらは、すべて結果の集計にすぎない。
「ログインできない」というWHAT（何が起きたか）だけでは、
- なぜ発生したのか
- どこに構造的な欠陥があるのか
- 何を変えれば再発しないのか
が見えない。
そのため、報告は「参考情報」で終わる。
声は“行動データ”にも宿っている
ユーザーは、必ずしも言葉で不満を表明しない。
検索して、見つからず、
FAQを読んで、離脱し、
再検索し、
それでも解決できず、
ようやく問い合わせる。
この一連の行動は、
すべて“体験のログ”である。
たとえば、
- 特定クエリのゼロヒット率が高い
- 該当FAQの直帰率が高い
- BAD評価が継続的に80％を超えている
これらは単なる数値ではない。
「理解できなかった」という行動上の証言だ。
VOCとは、問い合わせ本文だけではない。
行動ログも含めた“体験の結果”である。
WHATだけでは改善できない
「ログインできない」
このWHATを分解すると、
- パスワード誤入力
- 登録メールの誤認
- IDと外部アカウントの混同
- 初回ログイン導線の不明瞭さ
など、複数のWHYが存在する。
WHATの件数を見ていても、改善単位は見えない。
しかしWHYに分解すると、
- FAQで解決可能な問題
- UIで解決すべき問題
- 仕様変更が必要な問題
が分かれる。
改善は、ここからしか始まらない。
「データで語る」とは、件数を出すことではない
よく言われる。
「感覚ではなくデータで語れ」
しかし、件数を出すことが“データで語る”ではない。
データで語るとは、
- どの構造で
- どのWHYが
- どの行動ログと結びついているか
を示すことだ。
たとえば、
特定画面での離脱率上昇
＋
関連FAQのBAD評価80％超
＋
問い合わせ理由のWHYが「操作誤認」
この三点が重なったとき、
初めて“構造上の欠陥”として説明できる。
これが、提案に変わる単位である。
VOCは拾うだけでは意味がない
ひと昔前のCSは、
- 問い合わせをエスカレーションする
- レポートを提出する
ここで終わっていた。
しかし、それでは改善は再現しない。
必要なのは、
✔ どのログを記録するか
✔ どの単位で分類するか
✔ どう可視化するか
✔ 改善後をどう検証するか
までを設計すること。
VOCは「声」ではなく、
改善設計の材料である。
CSが届けるべきもの
CSが届けるのは、
- 問い合わせ件数でも
- 不満の抜粋でもない。
届けるべきは、
体験の構造である。
どこで迷い、
なぜ理解できず、
どの設計が不足していたのか。
そこまで翻訳してはじめて、
CSは“対応部門”から“提案部門”になる。
コメント