見出し画像
Photo by featurecompass

ZendeskのTicketAuditsAPIを使ったら、「これまでの当たり前」を見直せた話

土日は飲んでいます

この記事を3行でまとめると

  • 行動をデータ化すると目に見えない課題が見えてくる

  • データ集計方法を見直すと、本当に取りたいデータなのか再定義できる

  • データ集計は機械に任せよう

50名くらいのベンチャー企業の一人情シスをやっています。

現職では、Zendeskを使ってCS対応をしています。
CSチームでは、CPH（Call Per Hour：1時間当たり対応件数）を生産性指標としています。（CPHの詳細）
今回は、そのCPH算出を手動→自動化させたことで、月20時間以上の削減に加えて、顕在化していなかった課題が見えたことを書いてみます。

きっかけは、CSチームのメンバーからの「CPHの集計が手動でしんどい…😓」という相談でした。

こちらのMIXIさんの記事を参考に実装しました。

自動化する前の課題

Zendeskはさまざまなプラグインが用意されており、Zendesk上の対応時間計測のために、Time Trackingというプラグインを導入しています。

出典：Zendeskのヘルプページ

各CSメンバーの対応ごとに、対応時間が記録されているのですが（上記キャプチャ参照）、各メンバーがスプレッドシートにチケットURLとそれら対応時間を手動入力し、それらを集計してCPHを算出していました。
その結果、以下の課題が出ていました。

  • 月間2~3時間/人の入力時間が発生（メンバーは約10名）

  • 月間4~5時間の集計時間が発生

  • 人間が入力するため、数値型が異なり集計できないデータの発生（00:15:00と00:15が乱立しており、15分と15秒で集計されてしまう）

  • 人間が入力するため、入力漏れや入力ルールの認識違いが生まれており、正しくデータを集計できない

改善要件

Time Trackingのデータを全て自動集計して、自動でCPH算出させれば、上記の全てが改善されるので、まずは「DailyでのCPHの自動算出」を改善要件としました

「DailyでのCPHの自動算出」への取り組み

  • Time TrackingのデータをAPIで集計する

  • CSのリードメンバーと連携して、CPH算出方法やその結果が変わることを各メンバーへ説明

  • 既存CPH算出ロジックの解明

  • CSメンバーのZendeskの使い方やルールの理解

Time TrackingのデータをAPIで集計する

実装環境としてはGASを使いました。スプレッドシートでまとめたいCSチームのニーズもあったため、検証的にGASとZendeskAPIで実装しました。
（現在AWSにリプレイス中です）

APIはZendesk AuditsのAPIを使いました。
APIを投げると以下のようなjson形式で（大量の）プロパティが返ってきますので、それらをmapやらfilterやらを使って加工して、スプシに格納しています。（監査ログですもんね..）
現在はDailyでバッチ処理が動いて、前日のデータがスプレッドシートに自動反映されています。

// 公式ドキュメントのサンプルです
  
"author_id": 35436,
  "created_at": "2009-07-20T22:55:29Z",
  "events": [
    {
      "attachments": [],
      "body": "Thanks for your help!",
      "id": 1564245,
      "public": true,
      "type": "Comment"
    },
    {
      "body": "Ticket #47 has been updated",
      "id": 1564246,
      "subject": "Your ticket has been updated",
      "type": "Notification"
    }

CSのリードメンバーと連携して、CPH算出方法やその結果が変わることを各メンバーへ説明

手動入力だったが故に、人間の曖昧なルールにも柔軟に対応できていました。（ステータスがYYYYでかつ、XXXXがhugahugaな場合は、入力しないなど）
ただ、自動算出になるとそういった人間の曖昧ルールへの適応が難しいです。自動算出になることでどのくらい既存算出ロジックとの差分が出るか、メンバーの評価にはどう影響するかなどをCSのリードメンバーと話ながら進めていきました。（協力的なCSメンバーに大感謝でした）

既存CPH算出ロジックの解明

既存算出ロジックと自動算出の差分がどこにあるのかを説明するだけではなく、CSがCPHを計測する目的に対して、既存算出ロジックはもちろん、自動算出ロジックも適切なロジックなのかを判断するために解明していました。
泥臭く、社内ドキュメントや既存スプレッドシートの関数との睨めっこです。

CSメンバーのZendeskの使い方やルールの理解

既存CPH算出ロジックの解明とも近い部分もありますがロジック解明よりも今回の自動化の結果、オペレーションが崩れ、改悪とならないことに責任を持つことが目的です。

  • 自動化することで、オペレーションが崩れてしまうことはないか

  • 特定の必須オペレーションがあり、対応する特定メンバーに対して不公平に対応時間が多く集計されてしまうことはないか

  • 自動算出した際の異常値には、考えられるオペレーション背景はあるのか

結果

DailyでのCPHの自動算出

他業務とも並行しながらですが、3週間ほどでDailyでのCPHの自動算出は実装できました。結果として、月20時間ほどの工数削減となりました。
（CPHも0.2ptほど上がりましたが、自動化のおかげと言えるかはもう少し様子見です）
現在は、スプレッドシートに集計し、各メンバー毎・全体のCPHをピボットテーブルで自動算出しています。（早くAWS環境にリプレイス完了したい…）

副次的効果

APIからAudits=操作ログを集計できているため、Zendesk上でのメンバーの行動と時間がデータ化されるようになりました。
その結果、これまで顕在化していなかった課題や疑問にも気づけるようになりました。

  • 特定カテゴリーのマクロが高頻度で使用されており、そのマクロが使用されるオペレーションの一部が非効率になっている可能性がある

  • 特定メンバーの引き継ぎメモの作業時間が想像よりも多くなっており、何か負荷がかかっている可能性がある

  • この集計方法って、実態のオペレーションを測る集計方法として合っている？ etc….

今後の取り組み

CPHの自動化をリリースしてまだ1ヶ月経っていないため、ここから本番です。
自動化した結果、各メンバーの生産性や労働環境は改善されたのか、継続的なオペレーション改善に繋げることができそうかなどなど….行動と時間がデータ化されたことでの効果を最大限に活かせるようにしていきたいです。

現在は、スプレッドシート×ピボットテーブルで算出していますが、BIツールと繋げたり、SQLでデータ分析を行えることで、お問い合わせの種別や時間、カテゴリによってクイックに分析できるようなデータ基盤を作っていきたいと思います。





この記事が気に入ったらサポートをしてみませんか？