はじめに
こんにちは！スマートバンクでカスタマーサポート（CS）を担当しているnumaです。
先日問い合わせの分類と可視化の重要性や意義について、カスタマーサポートのnyancoによる記事「問い合わせの分類と可視化の方法」が公開されました。
今回はより具体的なアクションとして、Zendeskでお問い合わせ内容の集計方法を見直し、お問い合わせのトレンドやユーザーの課題を見える化するためにやったことを紹介します。
これからサポート運用を構築しようとしている方、定量データの取得・運用方法に迷っている方、Zendeskの活用方法に困っている方などのお役に立てたらうれしいです！
お問い合わせ集計の課題感
スマートバンクで提供している「B/43」では、サービスリリース当初からお問い合わせ窓口としてメールフォームを用意しており、メール対応のオペレーションにはZendeskを利用しています。
以前からお問い合わせ件数の簡単な集計はおこなわれており、サービス拡大に伴って業務量が増加していそうだ、ということは把握できていました。
しかし、どんなお問い合わせが増えているのか、その増加量はサービスの成長に対して適切なのか、といった具体的な分析ができず、そもそも「現在のお問い合わせオペレーションに問題があるのかどうか」が正確に判断できない状態でした。
また、「ユーザーの皆さんが遭遇する問題の原因を突き止め、サービス改善に繋げる」というアクションがしづらいのも気がかりでした。こちらもデータがなければ、本当に改善が必要な問題なのか、どのような優先度で対応するべきなのかを判断することができません。
このような「問い合わせは増えてきてるし対応工数も重くなってきてる気がするし、運用上もサービス上もなんかやった方がいいのかも。でも何が問題なんだろうねえ〜」状態を脱却すべく、「お問い合わせをより精確に集計・可視化し、サービスや運用の改善に活用できる基盤を作ること」を目的に、データ集計の仕組み化をおこないました。
集計方法の変更点
集計を仕組み化するために、具体的にやったことは主に以下の3つです。
1. スタッフ選択用の問い合わせカテゴリの追加
ここが今回の肝なので、ステップに分けてご紹介します。
（1）運用変更の方針決め
当初おこなわれていたお問い合わせ件数の集計では、ユーザーさんがお問い合わせフォームで選択したお問い合わせカテゴリをカウントしていました。そのため、こちらの意図したカテゴリを選択されていないケースも多く、実際にはどんなお問い合わせが多いのかを正確に把握することができていませんでした。
そこで、お問い合わせ対応を行うスタッフがメール対応時にお問い合わせ内容に即した集計カテゴリを選択し、このカテゴリを集計対象とする運用に変更しました。
これで、ユーザーさんが選択したカテゴリが社内的には意図しないものになっていたとしても、スタッフが分類し直した適切な基準に基づいて集計ができるようになります。
（2）各カテゴリの粒度、項目の決定
スタッフ選択用のカテゴリは3階層に分けて分類し、より具体的にデータを取得できるようにしました。
例えば、「カードが届かない」というお問い合わせ一つ取っても、発送直後でまだ手元に届いていないだけなのか、指定した配送先住所が間違っていたのか、そもそもカード発行申請が正常に完了しておらずカード発送に進んでいないのか、などその原因はさまざまです。
どんな理由でのお問い合わせが多いかの原因を特定し、必要に応じて対策や改善に繋げやすいよう、分類の粒度を定めていきました。
また、各カテゴリの具体的な選択項目は、過去の問い合わせでよく発生している内容を採用しました。妄想で選択項目を設定してしまうと、適切なカテゴリがなくて正しい集計ができなかったり、スタッフがカテゴリ選択に迷ってしまってオペレーションに時間がかかったりするためです。
ちなみに3階層での分類にしたのは、これまでの経験からなんとなく取り回ししやすそうだったからです。問い合わせを1件ずつ精査しても苦にならないくらいのボリュームの場合は、いったん1〜2階層でも事足りるのでは、と思います。
※ もちろん、このカテゴリ分類だけで原因を特定できない問題もあります。その戦いの歴史はまた改めて…
（3）Zendeskの実装：カスタムフィールドの追加
Zendesk上の実装としては「カスタムフィールド」を利用しています。3階層のカテゴリ名を「大カテゴリ」「中カテゴリ」「小カテゴリ」とし、それぞれ「エージェントのみ選択可能」なフィールド（ユーザーには表示・選択されない）として追加しました。
選択漏れ防止のため、メール返信対応を完了させる場合は3つすべてのカテゴリ選択を必須とするよう設定しています。
なお、Zendeskにはタグ機能もあり、タグを集計に使っているケースもあるかと思いますが、スタッフが都度カテゴリ選択する運用にはフィールドの方が操作しやすいため、今回はフィールドを採用しています。
※ちなみにタグはスポットで発生した事象の集計をするのに使っています。また改めてご紹介するかもしれません
2.受発信カテゴリの追加
当初の運用では、ユーザーさんから届いたメールと、こちらから連絡事項がありユーザーさん宛に送ったメールを区別する仕組みがなく、集計上も両方を合わせた件数しか取得できていませんでした。
ユーザーさんの問題やそのボリュームを把握するためには、ユーザーさんから届いたチケット件数のみを集計したいため、受信チケットと発信チケットを区別する「受発信」カテゴリを追加しました。
スタッフがお問い合わせ返信の度にこのカテゴリを選択するのは手間なので、新規チケットを着信した際には「受信」、サポート側でチケットを作成した場合は「発信」が自動選択されるよう、Zendeskのトリガを設定しています。
3.Zendesk Exploreのレポーティング
カテゴリの集計結果は、Zendeskのレポーティング機能である「Zendesk Explore」を用いてグラフ化し、自動更新されるダッシュボードを作成しています。
集計はフィールドを用いておこなっており、現在、お問い合わせカテゴリを活用したレポート例として以下のものを出力しています。
- お問い合わせ件数
- 大カテゴリごとの問い合わせ件数（月次、週次、日次）
- 中カテゴリごとの問い合わせ件数（週次）
- 小カテゴリごとの問い合わせ件数（週次）
- 初回返信時間（お問い合わせを受信してから最初にユーザーさんに返信するまでの時間）
- カテゴリごとの初回返信時間（月次、週次）
集計したデータの活用方法
これでユーザーさんから届くお問い合わせ内容ごとのボリュームやトレンドをより精確に把握できるようになりました！
これらのデータは、以下のようなシーンで日常的に活用しています。
1.定期的なデータの振り返り
得られたデータを元にお問い合わせ内容のトレンドをチェックし、定期的におこなっているCS内や全社でのミーティングで共有しています。
特定のカテゴリのお問い合わせが増えている・初回返信時間が顕著に延びている場合は、関連しそうなリリースやトピックが発生していないか確認したり、該当のお問い合わせチケットを1件1件精査して原因を特定します。
特定した原因に応じて、対応方針・フローを整備し周知する、サービスの要改善項目として他チームに連携する、一過性のトピックとして特に対応しない などのアクションを決めています。
2.Zendesk ExploreのデータをLooker Studioに流し込んでダッシュボード化
Zendesk ExploreはZendeskのデータを自動更新してくれるとても便利な機能ですが、当然ながらZendesk上のデータしか取り扱えません。
そのため、例えばアクティブユーザー数に対するお問い合わせ率など、Zendesk外のサービス固有のデータと掛け合わせて出す指標については、ExploreのデータをGoogleスプレッドシートにエクスポートしてLooker Studioに繋ぎこむことで可視化しています。
→ Looker Studioの運用については、今後nyancoが記事化する予定です
「見える」は「わかる」
お問い合わせオペレーションの改善とサービス全体の改善、どちらにおいても、いま起きていることを「見える」ようにすることが不可欠です。現状が見えることで、次にやるべきことがより明確に「わかる」ようになります。
集計方法の見直しから約1年経過し、データも蓄積されてきました。さらに深いインサイトを得られることを楽しみに、今後も運用していこうと思います◎
