こんにちは。MackerelチームCREの 
id:tukaelu です。
Mackerelでは、テクニカルサポート／カスタマーサポートをCRE（Customer Reliability Engineer）が担当しており、ユーザーからのさまざまな問い合わせに対応しています。
本記事では、Mackerelのようなエンジニア向けのSaaSにおいて、サポート業務の改善をどのように進めたか、その裏側をご紹介します。
サポート業務が抱えていた4つの課題
私は2019年5月に入社し、同月からサポート対応を担当しました。お問い合わせの対応を行っていく中で、以下のような課題を認識しました。
- 同じような内容の問い合わせを複数のユーザーから頻繁に受けている
- ヘルプページやFAQによる解決が可能な問い合わせを頻繁に受けている
- テクニカルサポートとしてのKPIを設計できていない
- サポートケース（問い合わせチケット）の管理が煩雑
このような課題はサービスのサポート業務に携わっている方なら共感いただける部分もあるかと思います。
CREは、日々増え続けるサポート業務だけではなく、セールス案件への同行やセミナーなどのイベント対応といった業務も担っています。そのため上記の課題にまとまったリソースを割くことが難しく、改善は後回しになってしまっていました。
Zendeskへの移行と体制の変更
サポート業務に使用しているサービスを、Zendeskに移行しました。 これは課題に対するアクションというより、当時使用していたサポートツールのサービス終了に伴うものでもありました。
以前に使用していたサポートツールはいわゆるレガシーなWebサービスで、サポートケースの管理機能面が非常に弱かったため、提供されている機能ではできないことも多く、スプレッドシートによる煩雑なサポートケース管理によって補っていました。
具体的には、チケットが起票されたらスプレッドシートに行を追加して、対応のたびにチケットURL／チケットごとの返信回数／規定時間内に返信できたか（OK/NG）などを記録し、集計していました。 人手で対応しているため、反映が漏れていたり、誤ってスプレッドシートを破壊してしまうこともありました。
Zendeskには標準でサポートケースの管理機能が備わっており、移行しただけで、特に意識することもなく、従来のスプレッドシート管理などを手放すことができました。
新しいサービスレベルの指標も計測
またサービスレベルの指標として、スプレッドシート時代には規定時間内の返信率しか計測できていなかったのですが、ZendeskのBIツールのExploreを使うことで、無料版の範囲でも新たに以下の項目を利用できるようになりました。
- 初回返信までにかかった時間（First reply time median）
- 初回回答で解決した割合（One Touch Tickets / Two Touch Tickets）
- 顧客満足度の割合（CSAT）
移行のきっかけこそツールのサービス終了に伴うものでしたが、適切なツールに切り替えるだけで業務効率などを大きく改善できました。このように新しいSaaSを導入してみるのも改善の一手かもしれません。
Zendeskの導入により、Mackerelのサポートとして実施できることが増えたので、引き続きZendeskを有効活用して改善を進めていくことにしました。
テクニカルサポート業務の専任
Zendeskへの移行と時期を同じくして、それまで業務の合間に行う状況だったテクニカルサポートについて、私が専任になりました。
以前に同じくCREの 
id:missasan が書いたように、CREが独立したチームとなったタイミングでプロダクトの価値全体を最大化することを目標とし、それを達成するため4つの軸で業務を分類しました。テクニカルサポートもこの1つです。
詳しくは次の記事を参照してください。
体制が変わり、それまでは他の業務と並行して行っていたテクニカルサポートに注力できることで、サポート業務自体の改善に使える時間が増えたことは大きかったです。
またテクニカルサポートのミッションとして「エフォートレスなサポート体験の提供」を掲げ、それを実現するために取り組みを進めていくことにしました。
エフォートレスなサポート体験を提供する
「エフォートレス」とは、カスタマーサクセス文脈で「努力を要しない」「イライラさせない」といったことを意味します。
Mackerelのユーザーの多くは、サービスを構成するアプリケーションやそのインフラに携わるエンジニアです。そうしたエンジニアがどのような流れでサポートにたどり着くのか？ 私達CREもエンジニアなので、まずは自分たちの場合はどうかを考えてみたところ、次のようになりました。
- 公式サイトの情報（ヘルプページ、FAQ、技術ブログなど）を検索する
- 個人の技術ブログや情報共有サイトなどを検索する
- サポートに問い合わせする
もちろんダイレクトでサポートに問い合わせる場合もあると思いますが、上記のような順に調べてみて分からなければサポートに問い合わせるというケースが多いのではないかと思います。
もしこの順を辿ってからサポートに問い合わせをしたのなら、ユーザーは既に答えに辿り着こうと3つのステップを踏む「努力」をした後であると言えます。
Zendesk社のレポートでは、「FAQやサポートなどのカスタマーサービスを利用する顧客の76%は、サポートとのやり取りを行うよりも自己解決を好む傾向にある」との結果が出ています。
▶ Support your support with self-service | Zendesk
この結果を参考に「エフォートレスなサポート体験＝問い合わせを必要とせずに解決できること」と位置づけ、FAQなどのコンテンツで自己解決してもらえるサポート環境を整える「セルフサービス化」に取り組むことにしました。
具体的には次のようなことを進めました。
ユーザーの困りごとをFAQに落とし込んでいく
FAQ（Frequently Asked Questions）は、その名の通り「よくある質問」です。サービスをローンチする際に想定される質問をFAQとして公開したものの、それ以降更新されていないこともよくあるでしょう。
MackerelのFAQも更新が頻繁には行われておらず、これが同じような問い合わせを頻繁に受け付ける原因にも少なからず繋がっていました。
サポートに蓄積された問い合わせはある意味「宝の山」で、FAQを作成するための豊富な元ネタとなります。 Mackerelでは、問い合わせのチケットに以下のようなサービスに特化した項目などをタグ付けして問い合わせの傾向を分析し、その結果などをもとにFAQを追加しています。
- どのような問い合わせか（インストールについて、設定について など）
- どのプラグインに関する問い合わせか（mackerel-plugin-linux、check-log など）
- どのマネージドサービスに関する問い合わせか（Amazon RDS など）
また、ユーザーがFAQを検索したキーワードも改善に欠かせない重要な項目です。 検索結果が0件となったキーワードをCREチームのSlackチャンネルに週次で通知して、このキーワードを見直しながらFAQを作成しています。
適切なタイミングでFAQをサジェストする
いくらFAQにコンテンツを追加しても、必要なタイミングで見てもらえないと意味がありません。 ユーザーがFAQを検索しても目的の記事に辿り着けなかったり、検索せずに問い合わせたりといった機会損失を減らしていく必要があります。
Zendeskの問い合わせフォームには、件名（Mackerelでは「お問い合わせの概要」）の内容に応じてFAQの記事をサジェストする機能があります。Mackerelではこれを有効活用することにしました。このサジェスト精度を高めることが、課題の1つである「ヘルプページやFAQで解決できそうな問い合わせ」の削減に有効だと想像できます。
これが機能するには、サジェストされるFAQのタイトルがユーザーの課題に直結するよう分かりやすく書かれている必要があるほか、ユーザー独自の言い回しにもある程度は対応しなければなりません。
例えば、MackerelではCPU使用率などのデータを「メトリック」と表記しますが、別のサービスでは「メトリクス」、人によっては「メトリックス」など、検索してもFAQに辿り着けないことがあります。このような同義語による検索結果でも差が生じないよう、用語の紐付けといったFAQのチューニングを定期的に行うようにしています。
これには、前述した検索結果が0件となったキーワード通知が非常に活躍しています。
セルフサービス化を評価する指標を設計する
セルフサービス化に取り組むからには、その効果測定も行いたい。しかし、ユーザーがFAQで自己解決したことを計測するのは難しく、以下のような課題がありました。
- FAQに記事が役に立ったことを評価する投票機能があるが利用されない
- 離脱率などのアナリティクスの項目では自己解決を計測できない
そのため自己解決したこと自体を計測するのではなく、別の指標を考えます。Zendeskがプラクティスとして掲げる「セルフサービススコア」を計測することにしました。
▶ セルフサービスを利用するカスタマーはどのくらいいるか？ – Zendeskヘルプ
具体的には「企業が用意したコンテンツを使用して問題を解決しようとしたユーザーの数を、問題の回答を求めてリクエストを送信したユーザーの数で割ったもの」がセルフサービススコアであり、次の式で算出できます。
FAQのユーザーの総数 ÷ チケットのユーザーの総数
Mackerelでは、前述した初回返信時間や初回回答による解決率などとあわせて、セルフサービススコアをサポートのサービスレベルとして計測しています。 このスコアを高めていくため、検索されやすく分かりやすいFAQが提供できるよう、日々アップデートを行っています。
最後に
本記事では、Mackerelのテクニカルサポートにおける改善の取り組みについて紹介しました。 取り組みを開始して以降、FAQへのアクセス数や新たに計測を始めたセルフサービススコアは順調に上昇しています。
この詳細は「Hatena Engineer Seminar #16 Mackerel チームの技術と働き方編」でも発表しています。こちらの資料もあわせてご確認ください。
はてなでは、 顧客の課題を一緒に読み解くCREの仲間を募集しています。
