Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

2 2018年にiOSエンジニアとしてメルカリ 福岡 オフィスに入社、その後色々あって現在は CRE/CX-PlatformのEngineering Manager. 
 音楽とアイドルとSplatoonと野鳥が好きで す。
 Yuki Takahashi (@ukitaka)


Slide 3

Slide 3 text

3 今日の話 メルカリのお問い合わせ対応ツール(以下、Contact-Tool) を 作っている僕らのチームが、どのようにデータを活用しながら CSの生産性改善を行っているのか、その環境やツールについて 簡単に紹介します。

Slide 4

Slide 4 text

4 Contact-Toolについて ● Contact-Toolを内製しているメインの理由は、メルカリというプロダクトに最適 化されたお客様体験を提供するため ● とはいえお客様体験だけを追い求めればよいというわけではない ● CSの方々に使ってもらうために、ツールとして効率性・生産性・コストなどに責任 を持つ必要がある お客様体験の改善と生産性の改善

Slide 5

Slide 5 text

5 画像
 良いコンタクトセンターが考慮すべきこと お客様に価値を届けるためには、効率性を 考えなければいけません。 効率的な運用ができないと、コスト面で会 社にとっての負担が大きくなってしまうばか りか、お客様に良い体験を提供することす らままならなくなってしまいます。 なのでツールとしても効率性に責任を持つ 必要があります。 「コールセンターマネジメント 戦略的顧客応対 理論と実践」 からの引用

Slide 6

Slide 6 text

6 生産性を図るための指標の1つ: AHT ● AHT = 1件のお問い合わせの対応にかかる平均時間 ● ものすごく単純化すると、すべてのお問い合わせに返信するためには、 お問い 合わせ数 × AHT 秒分の時間が必要になる ● これに応じて必要人員が計算され、その人数に応じたコストがかかってくる構造 AHT (Average Handling Time)

Slide 7

Slide 7 text

7 お問い合わせ数 × AHT コスト削減へのアプローチ (お客様側) ● VoCを元にプロダクト改善を行い、お困りごと自体を減らす ● ガイドやチャットボットによって自己解決率をあげる

Slide 8

Slide 8 text

8 お問い合わせ数 × AHT コスト削減へのアプローチ (ツール側) ● ツールのUIや機能によって対応を効率化する ● CSの方々のオペレーションを改善する

Slide 9

Slide 9 text

9 ここまでのまとめ ● お問い合わせ対応ツールとして、お客様体験の向上だけでなく、効率性・生産性 ・コストに責任をもつ必要がある ● 効率性・生産性を改善し、コスト削減につなげるために、ツールとして追うべき指 標の1つにAHT(Average Handling Time) がある

Slide 10

Slide 10 text

10 生産性改善に取り組むための仕組み

Slide 11

Slide 11 text

11 生産性改善に取り組むための仕組み ● AHTを計測し、そのデータを集めることができる必要がある ● そこから仮説をたて、改善し、効果を検証する ● それを繰り返すことで成果を積み重ねていく 計測して改善する

Slide 12

Slide 12 text

12 生産性改善に取り組むための仕組み ● データ計測: FE/BEでのロギングの仕組み ● データ収集: CloudSQLからBigQueryに集めるpipeline ● 分析環境: BigQuery, AI Platform Notebooks ● 可視化: Looker, AI Platform Notebook 利用しているツール・仕組み

Slide 13

Slide 13 text

13 Contact-Toolのアーキテクチャについて 自分自身でデータストアをもつ

Slide 14

Slide 14 text

14 Contact-Toolのアーキテクチャについて FE/BEがわかれている

Slide 15

Slide 15 text

15 HTを計測するためのログの仕組み ● Backendでのログ ○ アクションしたログが確実に存在するが、APIが叩かれる単位でしかログが 取れない ● Frontendでのログ ○ 細かい操作のログまで取れるが、欠損・遅延も起こる ○ クライアントPCの時刻設定に依存してしまう ● 基本はBackendのログを使いつつ、詳細な分析が必要な場合にはFrontend のログを組み合わせて使う Frontend/Backendそれぞれでログの仕組み(自作) を持つ

Slide 16

Slide 16 text

16 参考: なぜGoogle AnalyticsやDatadog UX Monitoring を活用しないか？ ● Google AnalyticsやDatadog User Monitoringなど、代替となるツールは いくつかある ● しかし個人情報を扱う業務の性質上、セキュリティ的なリスクや、そもそも外部に アクセスできないなどのシステム的な制約があった ● 結果として自作することになった

Slide 17

Slide 17 text

17 データを収集するための仕組み ● 前提として、メルカリはマイクロサービスアーキテクチャを採用している ● 先程あげたようなログも一度Contact-ToolのCloudSQLに保存された後、分 析のためにBigQueryに集められる ● Cloud Composer / Cloud Dataflow等を組み合わせたパイプラインの仕組 みを弊社データプラットフォームチームが提供している BigQueryに集められる

Slide 18

Slide 18 text

18 データを収集するための仕組み (参考記事) メルペイにおける大規模バッチ処理 メルカリ・メルペイの成長を支える データ基盤と はどんなものか

Slide 19

Slide 19 text

19 データ分析する環境について ● BigQueryのdataViewer権限を持っている人であれば、自由にデータを使っ た分析が行える ● クエリで完結するようなシンプルな分析であればBigQueryを使うことが多い ● 一方でRやPythonを使って高度な分析を行いたい場合もある BigQueryとNotebookの２つの環境

Slide 20

Slide 20 text

20 データ分析する環境について ● AI Platform Notebooks = Google Cloud Platformのマネージド型の JupyterLab ノートブック インスタンス ● BigQueryへのアクセスが可能 ● ローカルマシンでの分析も可能ではあるが、チームの共通の分析環境を設ける ことで、分析作業の属人化を防ぐ ● 分析の過程や考えをそのままシェアできるのもGood 高度な分析環境としてのAI Platform Notebooks

Slide 21

Slide 21 text

21 データを可視化するツール Looker CloudSQL BigQuery

Slide 22

Slide 22 text

22 Looker

Slide 23

Slide 23 text

23 まとめ ● データ計測: FE/BEでのロギングの仕組み ● データ収集: CloudSQLからBigQueryに集めるpipeline ● 分析環境: BigQuery, AI Platform Notebooks ● 可視化: Looker, AI Platform Notebook 利用しているツール・仕組み

Slide 24

Slide 24 text

24 ありがとうございました