ZendeskのデータをAlteryxとTableauで分析・可視化して、今後のサポート業務に活かせるようにしてみた #Alteryx #Tableau
はじめに
どうも。DI部@大阪オフィスのtamaです。
私はDI部の製品サポートチームというところに所属しています。製品サポートチームは、TableauやAlteryx、CSAといった、弊社が扱っているデータ分析に関する製品のテクニカルサポートを行っています。
サポート業務にはZendeskを使用しているのですが、このZendeskに溜まったデータを使って、サポートチームの業務をもっと良いものにできないかと考えるようになってきました。
ということで本エントリでは「Zendeskからどういったデータが得られるのか」「Zendeskのどういったデータをチェックすればいいのか」「実際にZendeskからデータを取得してみた」といったあたりのことを、つらつらと書いていきたいと思います。
Zendeskのデータから知りたいことを決める
データ分析は目的を決めることが大事
いきなりデータを取得してみてもいいのですが、ここはデータ分析の基本にならって、まずはデータ分析の目的を決めたいと思います。…といっても、今回はとりあえずやってみるということを重きに置いてやっていきたいので、あまりじっくりコトコト考えずに、サクッと行きたいと思います。
とりあえず以下の課題を解決したい、という目的にします。
- もっと効率よくチケットを捌けるようにしたい
- ZendeskのヘルプセンターのFAQ記事をもっと充実させたい
とはいっても…
この課題を解決するためには、Zendeskのどのデータを見て、どういうアクションにつなげればいいのか、ぶっちゃけ、皆目見当がつきません。Zendesk側に何か資料がないか探してみました。すると…。
Zendeskのチェックするべき指標（KPI）
Zendesk社が参考となる資料を公開していた
Zendeskのドキュメントに、「とりあえずこの指標をみとかんかい」（超意訳）的なものがありました。
ZendeskのKPI（参考）
上記のドキュメントを参考に、指標についてまとめてみました。
| 指標 | 内容 | とるべきアクション |
|---|---|---|
| Peak times | 大量の新規チケットが発生する日時 | 最も忙しい時間帯や曜日を特定し、人員配置のニーズを予測する。 |
| First reply time | エージェントが初回返答するまでにかかった時間 | （そのチケットを参考に）効率的に顧客に返信できるようなマクロを作成する。 |
| One-touch tickets | 1度の返答で解決できたチケットの割合 | これらのトピックに関するコンテンツをFAQに追加して、これらのチケットをセルフで解決できるようにする。（Answer Botを使用して、知識ベースのセルフサービスコンテンツを宣伝する） |
| Public comments | エージェントとエンドユーザーの間でやり取りしたコメントの数 | 問い合わせフォームで顧客からより多くの情報を収集するようにして、エージェントとエンドユーザー間のやり取りを減らす。 |
| Reassignments | チケットがあるグループから別のグループに変更された平均回数 | トリガと自動化を駆使してチケットのルーティングを改善する |
| Reopens | チケット解決後、再開されたチケットの割合 | 「解決」について、エージェントとエンドユーザーの間で解釈の違いがあると考える。 頻繁にReopenされるトピックについて、メンバーと議論を実施する。 |
| Full resolution time | チケットが最後に「解決済み」に設定されるまでの時間 | Zendeskのインテグレーションアプリを導入して、作業時間を短縮する。 |
| Customer satisfaction (CSAT) | エンドユーザーの満足度が高いチケットの割合 | 顧客満足度が低下している場合、原因の詳細な調査が必要。 ・他の指標のいずれかの低下が、この問題の原因かどうか？ ・（サポート対象の）製品やサービスの一部に問題があるか？ データを基に、関係者で議論が必要。 |
| Backlog | 「解決済み」または「クローズ」のステータスではないチケット（つまり「新規」「オープン」「保留」のステータスのチケット）の数 | Backlogが増加→チームが管理できるキャパを超える→最終的に他の指標に影響する。 Backlogを、より適切に管理するためのオプションを検討する ・セルフサービス（ヘルプセンターのFAQなど）によってチケット起票を抑制する ・より多くのワークフローを管理するビジネスルールを作成する ・チームの規模を拡大する どの方法をするにしても、他の指標データを見て検討する必要あり |
解決したい課題と比べてみる
ZendeskのヘルプセンターのFAQ記事をもっと充実させたい
これはOne-touch ticketsという指標をチェックすることで、改善できそうです。一度の返信で解決したということは、その返信内容を人が送るのではなく、予めヘルプセンターに記載しておけば、FAQの充実にもつながるし、チケットの抑制することができそうです。
もっと効率よくチケットを捌けるようにしたい
これは色々ありますが、例えばFirst reply timeが長いチケットをレビューして、返答メッセージを用意するのに時間がかかったチケットがいくつかあった場合は、今後はマクロを用意して一発で回答できるようにする…みたいな対策が打てそうです。もちろん、全部をマクロ化していては本末転倒なので、ある程度はチームで議論する必要がありますが、このようなデータを用意することで、効率の良い話し合いができそうですよね。
Zendeskからどういうデータが取得できるのか確認する
Zendeskでチェックしたほうが良さげな指標は分かりました。次はその指標の取得方法を確認します。
基本的にAPIからとってくる
- API Docs - Zendesk APIs - Zendesk Developer Portal
- APIについて – Zendesk Support
- Zendesk API でチケットを確認する ｜ DevelopersIO
Zendeskに限らず、昨今のWebサービスは大体APIがあります。上記を参考にAPIにアクセスできるようにしておきます。
その他
Zendeskインサイト
Zendeskのメニューから、予め用意されたグラフを確認することもできます。
Zendesk Explore
Zendesk Exploreというサービスを使用して、予め用意された分析レポートを見ることができます。Zendesk SupportをProfessionalプラン以上で使っているユーザーは、Liteプランを無料で利用することができます。個人的には、インサイトよりオススメです。
今回やりたい分析に必要そうなAPIを特定する
さて、Zendeskデータの確認方法についてわかったところで、APIについてもう少し確認しましょう。今回取得したい指標を得るため、下記のAPIを使用します。
- Incremental Exports - Support API - Zendesk Developer Portal
- Incremental Ticket Export
- Incremental User Export
- Ticket Metrics - Support API - Zendesk Developer Portal
今回はチケットに関するデータと、問い合わせを行った顧客のデータを使用したいと思います。Ticket Metricsは、そのチケットに関する詳細情報（解決するまでに要した時間や初回返答するまでに要した時間など）が取得できるもので、今回の分析のキモとなります。注意点は、このAPIはアーカイブされたチケットは対象外ということです。
Archived tickets are not included in the response. See About archived tickets in the Support Help Center.
Zendeskでは、「終了済み」ステータスになってから120日経過したチケットは自動的にアーカイブされます。
ということなので、こういった指標の分析は多少最近のチケットが対象となります。
※Incremental Ticket Metric Event Exportを使用して、チケット毎の開始時間等を取得し、計算で全チケットのメトリクスを出すこともできますが、大変そうなので今回はパスしました。
Alteryxを使ってデータを取得する
使用するAPIを把握したので、いざデータを取得したいと思います。弊社の製品サポートの対象製品の1つにAlteryxがありますが、せっかくなので、「Alteryxを使って」「Alteryxサポートのデータを取得する」っていうことをやりたいと思います。
作成の大まかな流れ
- API毎のIterativeマクロを作成する
* 全データを取得するまで繰り返しAPIを叩く必要があるため 2. 各Iterativeマクロ経由で取得したデータを結合して分析用のデータを作成する
APIそれぞれのワークフロー（Iterativeマクロ）
Incremental Ticket Export
Incremental User Export
Ticket Metrics
全体ワークフロー
Iterativeマクロについて（繰り返しAPIを叩く）
上記の画像を見ればわかると思いますが、3つともほぼ共通した処理となっています（URLと途中のフィルタが違うだけ）。
APIにアクセスする部分
まずは、以下のツールでAPIからデータをとってきます。
- テキスト入力ツール
- ダウンロードツール
- JSONパースツール
- 「テキストを列に分割」ツール
テキスト入力ツールの内容は以下の通り（sort_byあたりのパラメータはお好みで）。APIトークンと管理者権限アカウントのメールアドレスが必要ですので、ご注意ください。
ダウンロードツールの設定は以下の通りです。「接続タブ」にもZendesk管理者アカウントの情報を入れる必要があります。Incremental Exportは、starttimeを指定する必要があります。
ループについて
Zendesk APIは、取得データのページングについて、ドキュメントに分かりやすくまとめてくれています。
When the response exceeds the per-page maximum, you can paginate through the records by incrementing the page parameter. Example: page=3. List results include next_page and previous_page URLs in the response body for easier navigation:
Stop paging when the next_page attribute is null. For more information, see Adding pagination to your code.
レスポンスにnext_pageというパラメータがあるのですが、次ページがある場合（もう一度APIを叩く必要がある）は、そのURLが入っています。次ページがない場合（全て取得し終わった=ループ終了）は、nullという仕様です。
「テキストを列に分割」ツール後のデータを確認すると、下記のようになっています。next_pageという値を使用してループの判断を行いたいので、フィルターツールで、JSON_Name1の値が「ticket metrics」かどうかで分けます。
後は簡単。クロスタブツール等で、next_pageがnullであれば処理終了、nullでなければセレクトツールで整えて再度リクエストを投げる…という形にします。
※ちなみに、筆者の環境ではNullではなく「空白かどうか」にすることで、正常に動作しました。
フィルターツールで、JSON_Name1の値が「ticket metrics」なデータは、取得したいデータ本体なので、そのデータは別途出力されるようにしておきます。
Iterativeマクロの詳細については下記も参考にしていただければ…。
Incremental Exportのループ
Incremental Export系のAPIは、アーカイブされたチケットも対象にできるため便利ですが、次ページがあるかどうかの判断が、他のAPIと若干異なります。
このAPIのレスポンスにはcountというパラメータがあります。これはそのリクエストで取得した件数が入っています。このAPIは最大1000件取得できるため、countが1000未満だったらループ終了…という処理にします。
先程の「next_pageがnullかどうか」という部分を、上記の処理に変えるだけで対応可能です。
全体ワークフロー（APIで取得したデータをまとめて出力）
データをまとめる部分
こちらは特に難しい処理はしていません。今回作った3つのIterativeマクロを配置し、それぞれとってきたデータをJOINしています。
- TicketとTicket Metrics
- ticket_idで結合
- 上記のUser
- requester_idで結合
APIから返ってくるタイムスタンプはUTCということで、変換をかましつつ、（Tableauで可視化したかったので）最後はhyper形式で出力しています。
データを確認する（可視化してみる）
Zendeskの見たいデータを取得するところまで来ました。後は、どういう風に確認していくか、です。ここは指標毎に手段を分けていきたいと思います。
Peak times, Backlog
Alteryxを使ってAPIからデータを持ってきといてアレですが、これはZendesk Exploreでサクッと確認します。
データがデータなので、マスクしまくりで何がなんやらわからない画像となっていますが、Ticketsタブで見られるダッシュボードで、よく問い合わせが来る時間帯と曜日はわかります。
BacklogもZendesk Exploreで確認できます。
オープン、保留中、待機中のチケット数の推移がわかります。これが多い状態が続いている場合、チケット起票を抑制する施策を考えたり、効率よくチケットを捌く方法を検討する必要があります。場合によっては人員増も検討します。
First reply time, One-touch tickets, Public comments, Reopens, Full resolution time
これらの指標は「これらの値が高い（低い）チケットはどのようなものがあるか」という視点でチェックしたいと思います。ですので、かっこいい視覚化を行うというより、単純にそれぞれに該当するチケットのリストがあればいいと考えました。
ですので、さきほどのAlteryxワークフローの中で、それぞれに該当するチケットをGoogleスプレッドシートに出力するようにしました。
上記は返信回数が多いチケット上位20件を出力する部分です（Public Comment数に該当する値は、別のAPIから計算する必要がありそうだったので、Replyという値で代用しました）。これらのチケット内容を確認したり、チームメンバーと振り返りを行ったりすることで、やり取り回数が多い原因を考えることができます。それが「回答に必要な情報を聞くために何回もやり取りしていた」ということであれば、問い合わせフォームでそれらを予め聞いておくようにすることができますね。
残りの指標についても同じ形でスプレッドシートに出力しています。例えば、One-touch tickets、つまり返答一発で回答できたチケットのリストは、FAQ記事の候補リストとして活用することができます。
Tableauで全体を可視化
リストの出力だけでは寂しいので、Tableauでダッシュボードも作ってみました。
データがデータだけに、マスクしまくりで何がなんやら（ry （ダミーデータを用意するのも面倒だったので…）
Zendesk Exploreと比べて、API→Alteryx→Tableauのいいところは、独自に用意した項目（問い合わせフォームの入力値）なども分析できるというところです。基本的な指標に加えて、問い合わせフォームで○○と回答されているチケットの解決時間は？といった分析ができます。
上記の各チケットリストから、行うべきをアクションを決めて、そのアクションの効果はどうだったのか？ということを確認したい時は、全体を俯瞰するようなダッシュボードがあるといいと思います。
2つ目の画像は、組織別に問い合わせ数を分けたものです。枠が大きいほど、問い合わせを多く行っている顧客となります。さらに、その組織の問い合わせの解決にかかった時間を色で表現しています。問い合わせ数×解決時間を確認することで、新たなインサイトが得られる…かも…（すみません、視覚化した段階で満足しちゃってます）。
おわりに
Zendeskのデータを、一切コードを書かずに可視化してみました。今回はZendeskの見たいデータを取得して可視化することをやってみました。しかし、可視化した結果は、業務に活かさないことには意味がありません。今後、どうやってこれらのデータを有効活用していくか…ということについて考えていかなければならないと思っています。
また、私が所属する製品サポートチームでは、（現時点では）顧客満足度という指標は使っていません。しかし、Zendeskを使用している方の多くは、顧客満足度を取得しているのではないでしょうか。この指標もAPIから取得できますので、ぜひ分析してみてください。
