SendGridのCREチームの取り組み -お問い合わせ対応-
SendGridサポートエンジニアのキクタローです。米国ではなくSendGridの国内代理店である構造計画研究所で働いています。
私が所属しているクラウドビジネス部のCRE室では、日本のSendGridユーザの方々[1]に向けて日本語によるサポートを提供しています。今回はサポートのメインである"お問い合わせ対応"についてチームの取り組みを紹介します。他社さんのCREがどういった取り組みをされているのかとても興味があるので気軽にコメントをいただけると嬉しいです🙇
サポートに対する想い
お問い合わせ対応の話に入る前に少しだけサポートにおいて大切にしている想いについて触れます。CRE室ができたのは2年ほど前で、私は初めて室長というチームをリードする立場になりました。最初は何をどうリードすればよいかわからず、CRE（Customer Reliability Engineering）の始まりと言われるGoogleの記事を何度も読み返しました。
個人的に一番印象に残ったのは次の言葉です。
There's only one true and proper mission of a support function in this day and age:
Drive Customer Anxiety -> 0
今、この時代において、真に適切なサポート チームのミッションはたった 1 つです。
それは、お客様の不安をゼロにすることなのです。
お客様の不安をゼロにするサポートを提供するには、チームメンバー1人1人の不安もゼロでなければならない。そう考えて、チームの一体感やコミュニケーション、心理的安全性を強く意識してチーム作りを行いました。CRE室ができる前からそういった意識の高い部門でしたが、メンバー同士の支え合いが増えたことで、後ほど紹介する取組みに磨きがかかったと感じています。
お問い合わせの流れ
まずはじめに、お問い合わせに回答するまでの流れを紹介します。
- お客様がWebフォームからお問い合わせをする
- Zendeskにチケットが起票される
- サポート担当者がチケットを取る
- サポート担当者が回答を作成してレビューに回す
- レビューでNGがでたら修正を行いOKになるまで4を繰り返す
- 必要に応じて米国SendGridに問い合わせをして、得た情報を回答に反映する
- レビューがOKになったらお客様に返信する
SendGridはメール送信のSaaSなので一見シンプルにみえると思いますが、
- エンジニア向け（SMTP, Web API）とマーケタ向け（ブラウザから一斉送信）の両機能がある
- SPFやDKIMに対応する上でDNSサーバへの設定が必要
- 宛先によってはメールが届かない（特にキャリア系）、迷惑メール扱いになってしまう
- 大量配信がうまくいかない
などのつまづきポイントがあるので、それなりの数のお問い合わせが来ます。
こだわっていること
ここからはサポートをする上で皆がこだわっている点を挙げていきます。
レビュー
レビューは日本でのビジネス立ち上げ当初から一番こだわっているポイントです。サポートに問合せをしたことがある方は、微妙な回答が返ってきて困った経験が一度はあるのではないでしょうか（私は結構あります）。聞きたいこととズレた回答がきたり、何を言っているかよくわからない回答がきたりするのはサポートのユーザ体験として一番良くないことだと思っています。これを回避するには
- お客さんの質問の意図をしっかり把握する
- 正確な情報を伝える
- 誰が読んでも誤解のない、わかりやすい言葉・文章で回答を伝える
ことが大切です。
1人で回答を作成していると客観的な目線で内容を評価するのは難しいので、第三者によるレビューを取り入れて適切な回答になっているかチェックしています。レビュア、レビュイという呼び方をしてしまうと上下関係があるような錯覚をしがちですが、お客さんの状況は回答を作成する担当者が一番把握しています。あくまでもレビュイが主体でレビュアがフォローするというフラットな関係であることを全員の共通認識としています。
レビューはZendesk上で行っていて「承認待ち」や「承認済み」などのタグをつけてビューを分けることで実現しています。手作業でタグをつけるとミスが発生しやすいため、承認に回すマクロや承認、否認のマクロを用意して自動的にタグがつくようにしています。
レビューを介さずお客さんに回答を送ることは基本的にありません。直近1ヵ月の統計データを確認したところ、お客さんに返すコメント(Public Comment)に対して約3倍のレビューコメント(Internal Comment)がありました。
月によってバラつきはありますが概ね3～4倍程度です。
それだと初回応答が遅くなるのでは？というご意見もあると思います。もちろんレビューなしで回答する場合と比べたら遅いです。でも、その時間より一回の回答でお客さんにより適切な回答を送ることを優先しています。ちなみに直近1月における初回応答時間の中央値は3時間半くらいで、1時間以内に返す割合は月の平均で14%～19% なのでそこまで悪くない数値だと思っています。
属人化の回避
チームではサポート業務の属人化回避を大切にしていて、次のようなルールで運用しています。
- サポートはシフト制にして日ごとに担当者を変える
- レビュアとレビュイを兼任している人は役割を日ごとに切り替える
- シフトを基本とするけれど状況に応じて切り替える
お問い合わせの内容ごとの担当者は設けていないので、全員がなんでも回答できる（誰かが急に休んでも代替可能で品質が担保される）チーム構成になっています。その状態を維持するために、マクロや手順書のメンテナンス、オンボーディングやOJTの教育コンテンツの充実化、週次のサポートミーティングやツール[2]による情報共有、辺りにかなり力を入れています。
また、心理的安全性の確保も大切にしていて、
- 新しく入ったメンバーがわからないことをいつでも気軽に聞けるようにクローズドな専用チャットを設ける
- レビュアが判断に迷ったときに他のレビュアに相談しやすくするレビュア用チャットを作る
といったことも実施しています。この辺りはメンバーから挙がった声が元でボトムアップにできた仕組みです。
セルフサービス
これまで紹介した取り組みでお問い合わせの回答の質を高める一方、お客様ご自身で問題解決できる、いわゆるセルフサービスな環境づくりにも力を入れています。たとえば次のようなものは、よくある質問やブログにして公開するようにしています。
- お問い合わせの回数が多いもの
- 検索に引っかからなかった単語に関連するもの
ドキュメントの多くは米国のものをベースとしていますが、お問い合わせ同様にチームメンバで翻訳・レビューを行って単純な英訳にはならないように心がけています。ドキュメンテーションに関する話はまた別途紹介できればと思います。
おわりに
以上、SendGrid CREチームのお問い合わせ業務に関する紹介でした。現状はCSATやNPSなどでフィードバックをいただく仕組みを取り入れていないので紹介した取組みの定量的な評価ができていません。今後はその点に注力していく予定です。
今回はお問い合わせにフォーカスした内容でしたが、今後、ドキュメンテーションや情報共有、オンボーディングなどについてもまとめていく予定です。
Discussion