CSの生産性改善を支える分析環境 Mercari CS/CRE Tech Talk #1

Transcript

1. 1 CSの生産性改善を支える分析環境 Mercari CS/CRE Tech Talk #1 @ukitaka
2. 2 2018年にiOSエンジニアとしてメルカリ 福岡 オフィスに入社、その後色々あって現在は CRE/CX-PlatformのEngineering Manager. 
 音楽とアイドルとSplatoonと野鳥が好きで す。
 Yuki Takahashi (@ukitaka)

3. 3 今日の話 メルカリのお問い合わせ対応ツール(以下、Contact-Tool) を 作っている僕らのチームが、どのようにデータを活用しながら CSの生産性改善を行っているのか、その環境やツールについて 簡単に紹介します。
4. 4 Contact-Toolについて • Contact-Toolを内製しているメインの理由は、メルカリというプロダクトに最適 化されたお客様体験を提供するため • とはいえお客様体験だけを追い求めればよいというわけではない • CSの方々に使ってもらうために、ツールとして効率性・生産性・コストなどに責任 を持つ必要がある お客様体験の改善と生産性の改善
5. 5 画像
 良いコンタクトセンターが考慮すべきこと お客様に価値を届けるためには、効率性を 考えなければいけません。 効率的な運用ができないと、コスト面で会 社にとっての負担が大きくなってしまうばか りか、お客様に良い体験を提供することす らままならなくなってしまいます。 なのでツールとしても効率性に責任を持つ 必要があります。 「コールセンターマネジメント 戦略的顧客応対 理論と実践」 からの引用
6. 6 生産性を図るための指標の1つ: AHT • AHT = 1件のお問い合わせの対応にかかる平均時間 • ものすごく単純化すると、すべてのお問い合わせに返信するためには、 お問い 合わせ数 × AHT 秒分の時間が必要になる • これに応じて必要人員が計算され、その人数に応じたコストがかかってくる構造 AHT (Average Handling Time)
7. 7 お問い合わせ数 × AHT コスト削減へのアプローチ (お客様側) • VoCを元にプロダクト改善を行い、お困りごと自体を減らす • ガイドやチャットボットによって自己解決率をあげる
8. 8 お問い合わせ数 × AHT コスト削減へのアプローチ (ツール側) • ツールのUIや機能によって対応を効率化する • CSの方々のオペレーションを改善する
9. 9 ここまでのまとめ • お問い合わせ対応ツールとして、お客様体験の向上だけでなく、効率性・生産性 ・コストに責任をもつ必要がある • 効率性・生産性を改善し、コスト削減につなげるために、ツールとして追うべき指 標の1つにAHT(Average Handling Time) がある
10. 10 生産性改善に取り組むための仕組み
11. 11 生産性改善に取り組むための仕組み • AHTを計測し、そのデータを集めることができる必要がある • そこから仮説をたて、改善し、効果を検証する • それを繰り返すことで成果を積み重ねていく 計測して改善する
12. 12 生産性改善に取り組むための仕組み • データ計測: FE/BEでのロギングの仕組み • データ収集: CloudSQLからBigQueryに集めるpipeline • 分析環境: BigQuery, AI Platform Notebooks • 可視化: Looker, AI Platform Notebook 利用しているツール・仕組み
13. 13 Contact-Toolのアーキテクチャについて 自分自身でデータストアをもつ
14. 14 Contact-Toolのアーキテクチャについて FE/BEがわかれている
15. 15 HTを計測するためのログの仕組み • Backendでのログ ◦ アクションしたログが確実に存在するが、APIが叩かれる単位でしかログが 取れない • Frontendでのログ ◦ 細かい操作のログまで取れるが、欠損・遅延も起こる ◦ クライアントPCの時刻設定に依存してしまう • 基本はBackendのログを使いつつ、詳細な分析が必要な場合にはFrontend のログを組み合わせて使う Frontend/Backendそれぞれでログの仕組み(自作) を持つ
16. 16 参考: なぜGoogle AnalyticsやDatadog UX Monitoring を活用しないか？ • Google AnalyticsやDatadog User Monitoringなど、代替となるツールは いくつかある • しかし個人情報を扱う業務の性質上、セキュリティ的なリスクや、そもそも外部に アクセスできないなどのシステム的な制約があった • 結果として自作することになった
17. 17 データを収集するための仕組み • 前提として、メルカリはマイクロサービスアーキテクチャを採用している • 先程あげたようなログも一度Contact-ToolのCloudSQLに保存された後、分 析のためにBigQueryに集められる • Cloud Composer / Cloud Dataflow等を組み合わせたパイプラインの仕組 みを弊社データプラットフォームチームが提供している BigQueryに集められる
18. 18 データを収集するための仕組み (参考記事) メルペイにおける大規模バッチ処理 メルカリ・メルペイの成長を支える データ基盤と はどんなものか
19. 19 データ分析する環境について • BigQueryのdataViewer権限を持っている人であれば、自由にデータを使っ た分析が行える • クエリで完結するようなシンプルな分析であればBigQueryを使うことが多い • 一方でRやPythonを使って高度な分析を行いたい場合もある BigQueryとNotebookの２つの環境
20. 20 データ分析する環境について • AI Platform Notebooks = Google Cloud Platformのマネージド型の JupyterLab ノートブック インスタンス • BigQueryへのアクセスが可能 • ローカルマシンでの分析も可能ではあるが、チームの共通の分析環境を設ける ことで、分析作業の属人化を防ぐ • 分析の過程や考えをそのままシェアできるのもGood 高度な分析環境としてのAI Platform Notebooks
21. 21 データを可視化するツール Looker CloudSQL BigQuery
22. 22 Looker
23. 23 まとめ • データ計測: FE/BEでのロギングの仕組み • データ収集: CloudSQLからBigQueryに集めるpipeline • 分析環境: BigQuery, AI Platform Notebooks • 可視化: Looker, AI Platform Notebook 利用しているツール・仕組み
24. 24 ありがとうございました