Mackerel ユーザーを支えるCREの取り組み

by Tsukasa Nishiyama

Slide 1

Slide 1 text

Mackerelユーザーを支えるCREの取り組み Hatena Engineer Seminar #16 2021.04.27

Slide 2

Slide 2 text

id:tukaelu (tuka) 2019年5月入社 Mackerel CRE (Customer Reliability Engineer) 自己紹介

Slide 3

Slide 3 text

Customer Reliability Engineer ?

Slide 4

Slide 4 text

https://hatenacorp.jp/recruit/career/cre CREについて

Slide 5

Slide 5 text

● カスタマーサクセス ○ テクニカルサポート、カスタマーサポートなど ● 顧客活動 ○ プリセールス、デモンストレーションなど ● 技術広報 ○ セミナー企画・講師、テクニカルライティングなど CREの業務内容

Slide 6

Slide 6 text

https://hatenacorp.jp/recruit/interview/cre CREインタビュー記事も公開されています！

Slide 7

Slide 7 text

● Mackerelのテクニカルサポートについて ○ どのようなことをしているのか ○ どのような課題を抱えていたのか ○ どのように改善に取り組んでいるのか ○ どのような指標を追っているか今日お話すること

Slide 8

Slide 8 text

Mackerelのテクニカルサポート

Slide 9

Slide 9 text

● Mackerelに関する問い合わせに対応 ○ 各種サポートチャネル ■ メール（問い合わせフォーム or DM） ■ Slack（主に社内からの問い合わせ） ○ 調査に伴う再現検証や仕様・実装の確認、エスカレーション ● 各チーム、プロダクトへのフィードバック ● 問い合わせに関する分析 ● FAQやヘルプページの新規作成、更新など… テクニカルサポートの主な業務内容

Slide 10

Slide 10 text

● 問い合わせ内容のコンテキスト ○ 「動かない原因はなんですか？」と言った質問 ■ OSやミドルウェアなど環境に関する情報がない ■ どのような手順を実施したかなど状況に関する情報がない ● 煩雑な問い合わせチケット管理 ○ SLO（目標時間内での返信率）、問い合わせ分類などをスプレッドシートによる”温かみのある運用”をしていた ● 同じような質問が何度も来るテクニカルサポートが抱えてきた課題

Slide 11

Slide 11 text

温かみのある対応…

Slide 12

Slide 12 text

改善の取り組み

Slide 13

Slide 13 text

● 2020年3月にこれまで使用してきたサービスの終了に伴い、別サービス（Zendesk）へ移行 ○ ユーザーには見えないサポート側から移行した ○ 実際は2019年末から動き始めて、2020年2月から運用開始 ● 2020年6月にユーザーにも見えるフロント側を刷新 ○ 新しい問い合わせフォームを設置 ○ FAQサイトをはてなブログからZendesk Guideに移行サポートツール移行に伴い改善が大幅に進む

Slide 14

Slide 14 text

● 問い合わせフォームの設置 ● チケット管理の自動化 ● 問い合わせに関する分析 Zendeskになり出来るようになったこと

Slide 15

Slide 15 text

● フォームに任意の項目が設置できるようになった ○ ただしMackerelではユーザー入力を必要最小限に留めている ○ 基本的にはCREが問い合わせ内容からカテゴリを分類 ○ 顧客情報をカルテ的に管理できるようになった ■ 環境に関する特異点などの記録に使用 ● ファイルの添付が可能となった問い合わせフォームの設置

Slide 16

Slide 16 text

問い合わせフォームの設置

Slide 17

Slide 17 text

● フォームに任意の項目が設置できるようになった ○ ただしMackerelではユーザー入力を必要最小限に留めている ○ 基本的にはCREが問い合わせ内容からカテゴリを分類 ○ 顧客情報をカルテ的に管理できるようになった ■ 環境に関する特異点などの記録に使用 ● ファイルの添付が可能となった → 「問い合わせ内容のコンテキスト」に関する課題が改善してきた問い合わせフォームの設置

Slide 18

Slide 18 text

● Zendeskの標準機能でチケットの管理ができた ○ ほぼ手放しとなり”温かみのある対応”からの解放 ○ スプレッドシートのように突如壊れることがない（安心） ● 任意のマクロを組むことで、定形作業を半自動化できた ○ 定型文の設定、ステータス変更 → 「煩雑な問い合わせチケット管理」に関する課題が解決！チケット管理の自動化

Slide 19

Slide 19 text

チケット管理の自動化

Slide 20

Slide 20 text

Good bye 温かみ... 👋

Slide 21

Slide 21 text

● スプレッドシート運用がネックとなり分析が行われてこなかった… ○ 過去に分析をしている形跡はあった ● サポートする立場として知りたかったことがいくつかあった ● 最短の対応で解決できているか ● 返信までどの程度お待たせしているか ● サポート対応への満足度 → ZendeskのBIツールの Explore を使うことにした問い合わせに関する分析

Slide 22

Slide 22 text

問い合わせに関する分析

Slide 23

Slide 23 text

● 「初回回答による解決率」を計測することにした ○ One Touch Ticket + Two Touch Ticketで計測 ■ Zendesk Explore標準の項目 ○ One/Two TouchとはサポートチケットがクローズするまでにCREが返信した回数 ● Two Touchも含めているのは解決した旨を返信いただいた際の対応も対象とするため最短の対応で解決できているか

Slide 24

Slide 24 text

● サポートからの初回返信時間を計測することにした ○ 問い合わせを受けてから返信するまでの時間の中央値（ﬁrst reply time median） ● Zendesk Exploreのプラクティスに乗っかった返信までどの程度お待たせしているか

Slide 25

Slide 25 text

● CSAT（顧客満足度アンケート）機能を利用することにした ○ 満足/不満の2択のアンケート（コメントも可） ● Zendesk以前はGoogleフォームで運用していた ○ チケットクローズのタイミングでフォームURLをお知らせ ○ 10段階評価のアンケート（コメントも可） ○ 回答率があまりよくなかった… サポート対応への満足度

Slide 26

Slide 26 text

これらを半期計測してみた ● 最短の対応で解決できているか ○ One/Two Touch Tickets の合計で計測 ● 返信までどの程度お待たせしているか ○ 初回返信時間の中央値で計測 ● サポート対応への満足度 ○ CSAT（顧客満足度アンケート）で計測

Slide 27

Slide 27 text

半期計測してみてどうだったか

Slide 28

Slide 28 text

最短の対応で解決できているか初回回答による解決率（One/Two Touch Tickets） ● 82%程度のチケットが初回回答で解決（クローズ）していた ● ただしユーザーから返信がなくクローズしたものも含むため、本当に解決したのかは不明 ○ 実際、チケットクローズの数日後に再オープンするチケットも数%あった

Slide 29

Slide 29 text

初回返信時間（中央値） ● 実績が160分前後となり、素早い対応が出来ていることがわかった ○ 目標を営業時間で250分としていたのでかなり早かった ● VoC（顧客の声）などでも素早く返信ができていることに満足されている企業／ユーザーが多くいた返信までどの程度お待たせしているか

Slide 30

Slide 30 text

CSAT（顧客満足度アンケート） ● 96.3%とかなり高い満足度ということがわかった ○ 全体の65%に送付して、そのうち13%の回答 ○ 以前送っていたGoogleフォームより回答率が高くなった ● サポート対応に関する評価を期待していたが、コメントを見るとサービスに関するものが多かったサポートへの満足度

Slide 31

Slide 31 text

半期回したまとめ【👍だった点】 ● サポートに関する計測／分析ができるようになった ○ サポート対応のサービスレベルを把握できるようになった ○ BIツールがあることで定量的な目標が立てやすくなった【🤔な点】 ● 初回回答による解決率／初回返信時間／CSATなどからは、根本的な改善に繋がる施策などを打ちづらかった

Slide 32

Slide 32 text

● 問い合わせ内容のコンテキスト【改善】 ○ 「動かない原因はなんですか？」と言った質問 ■ OSやミドルウェアなど環境に関する情報がない ■ どのような手順を実施したかなど状況に関する情報がない ● 煩雑な問い合わせチケット管理【解決】 ○ SLO（目標時間内での返信率）、問い合わせ分類などをスプレッドシートによる”温かみのある運用”をしていた ● 同じような質問が何度も来る【未解決】テクニカルサポートが抱えてきた課題

Slide 33

Slide 33 text

● FAQサイトがあまりメンテナンスがされていなかった ○ これまでのサポートはひたすら打ち返す対応をしていた ○ 本当に”よくある質問”が反映されていなそう ● ユーザーが適切なFAQにたどり着けていない可能性もありそう ○ FAQで解決できるお問い合わせもそれなりにあったなぜ同じような質問が何度も来るのか🤔

Slide 34

Slide 34 text

● Mackerelユーザーの多くが現役のエンジニア ○ アプリケーションエンジニア ○ SRE / インフラエンジニア ● エンジニアが利用している技術やサービスなどでわからないことがある場合、どのようなアクションを取るのか → エンジニアでもある自分達ならどうかを考えることにしたペルソナをゆるく考えてみた🤔

Slide 35

Slide 35 text

自分達ならどうするか… ● 公式サイトが提供するヘルプやFAQ、ブログなどを調べる ● それでもわからなければグーグル先生に頼る ○ 他のユーザーがブログなどで情報を公開をしてくれている ● あきらめてサポートに問い合わせるペルソナをゆるく考えてみた🤔

Slide 36

Slide 36 text

自分達ならどうするか… ● 公式サイトが提供するヘルプやFAQ、ブログなどを調べる ● それでもわからなければグーグル先生に頼る ○ 他のユーザーがブログなどで情報を公開をしてくれている ● あきらめてサポートに問い合わせる → まずは自分で調べる、サポートへの問い合わせは最終手段ペルソナをゆるく考えてみた🤔

Slide 37

Slide 37 text

● 問い合わせをせずに自己解決したいと考えているエンジニアの方は多くいるのではないか ○ メール対応でブロックされずに解決をしたい ● 実際に自己解決（セルフサービス）を好む人は統計上ではカスタマーサポートに問い合わせる人のうち76%ほどいるらしい（参考: Support your support with self-service | Zendesk ） → 次の半期は自己解決できるサポート環境を目指していくことにユーザーが自己解決できるように整えることに

Slide 38

Slide 38 text

● FAQの各記事に投票機能があるが基本的には投票してもらえない ● 同様にサポートから記事へのリンクを案内すると、記事の内容で解決ができたかポップアップ表示されるがクリックしてもらえない ● アナリティクスはPV数などは計測できるが解決にどの程度影響を与えたかを計測するのは困難自己解決したことをどのように計測するか

Slide 39

Slide 39 text

● 理想としては… ○ ユーザーは困った時にFAQにたどり着き ■ FAQへのアクセスが増える ○ 自己解決によりサポートに問い合わせをしてこない ■ 問い合わせチケットは増えない → セルフサービススコアという指標が存在し計測することにした理想の自己解決とは

Slide 40

Slide 40 text

“企業が用意したコンテンツを使用して問題を解決しようとしたユーザーの数を、問題の回答を求めてリクエストを送信したユーザーの数で割ったもの ” 算出式：ヘルプセンター(FAQ)のユーザーの総数 / チケットのユーザーの総数 Googleアナリティクスとヘルプセンター - パート1：適切な答えを得るための質問 – Zendeskヘルプセルフサービススコアとは

Slide 41

Slide 41 text

引用元: Be like BarkBox: Surpass customer expectations by scaling with smart self-service (ft. BarkBox) - Slideshare FAQのメンテナンス頻度とセルフサービススコアの関係性

Slide 42

Slide 42 text

引用元: Be like BarkBox: Surpass customer expectations by scaling with smart self-service (ft. BarkBox) - Slideshare FAQのメンテナンス頻度とセルフサービススコアの関係性 Mackerelは Fire & Forget に該当しそう

Slide 43

Slide 43 text

● 2020年8月半ばに計測した時は 9.3 だった ○ 既に Agile & Iterative (score: 8) を超えていた！？ ● スコアが高いのにはMackerel特有の理由がありそう ○ 監視SaaSという性質上、複数人がメーリングリストアドレスで問い合わせをしてくる事が多い ■ 「ヘルプセンター(FAQ)のユーザーの総数 / チケットのユーザーの総数」で算出セルフサービススコアを知る

Slide 44

Slide 44 text

● FAQによる自己解決を促す ○ FAQのコンテンツを充実させていく必要がある ■ FAQ、Googleのそれぞれで検索ヒット率を高める ○ 問い合わせフォームのサジェストからの遷移率を上げていくどうやってセルフサービススコアを向上させるか

Slide 45

Slide 45 text

ユーザーがFAQにアクセスする最後のチャンス… 問い合わせフォームのサジェスト機能

Slide 46

Slide 46 text

● チケットのカテゴリの細分化と可視化を行い、定期的にコンテンツの見直し（作成・更新）を実施。 ○ 問い合わせの種別 ○ 各種プラグイン ○ 各種インテグレーション ○ 各種クラウド製品 FAQをどのように改善していくか

Slide 47

Slide 47 text

FAQをどのように改善していくか ● FAQの検索結果が0件となったキーワードを週次でSlackに通知

Slide 48

Slide 48 text

● 検索結果が0件となるキーワードに該当しそうなFAQが… ○ ない：新規作成できそうか検討 ○ ある：FAQのチューニングをしてサジェスト精度を上げる ■ 「メトリクス」→「メトリック」に関連するFAQにヒットするように紐付けを行う FAQをどのように改善していくか

Slide 49

Slide 49 text

取り組みの結果

Slide 50

Slide 50 text

● FAQ移行前と比較すると2倍にコンテンツ数を増やすことができた ○ 分析の結果、求められるものを反映しやすくなった事が大きい ○ Zendesk内で完結している影響もありそう FAQコンテンツ数

Slide 51

Slide 51 text

● FAQ全体のPV数が増加トレンドにあることがわかった ● 問い合わせフォームからFAQの遷移も順調に伸びていた FAQへのアクセス

Slide 52

Slide 52 text

● 半期末（2021年1月末時点）で 12.45 に上昇 ○ 期初（2020年8月末時点）が 9.74 なので 2.7 ptほど上昇したセルフサービススコアが上昇した

Slide 53

Slide 53 text

まとめ

Slide 54

Slide 54 text

● 改善活動を始めて1年が経ち、着実にサポート環境が改善している ○ データをもとにしたユーザーが必要とするFAQなどの提供 ○ ユーザーによる自己解決（セルフサービス）で問い合わせ対応が減る分、CREはFAQなどの改善に時間が使える ● 今後もMackerelを快適に使っていただけるよう改善していきます！まとめ

Slide 55

Slide 55 text

ご清聴ありがとうございました