2020年04月30日
「Zendesk」はじめました
PowerCMS 製品サポートでは、2009 年から十年以上、Backlog を使って運用を行っておりました。累計起票数は 25,000 件近くに上ります。Backlog は様々なジャンルで利用可能な、優秀なサービスであり、これを使って顧客対応を管理・運用している会社も多いと思います。
しかし、実際のところ、Backlog はプロダクト開発向けチケット管理システムの色合いが強く、これを顧客サポートとして利用する場合、「運用でカバー」せざるをえない場面が増えてきます。また、実績の計測に不向きであることも弱点のひとつで、分析に際して「こんな感じだと思う」「肌感覚ではこうだ」などと、会話の輪郭がぼやけがちです。
これらの状況を踏まえ、サポートデスクに特化したサービスである「Zendesk Support」に移行しました。これに際して社内で検証し、整理したことをご紹介したいと思います。
運用課題の整理
Backlog を流用した運用には多くの課題がありました。主だったものは下記のようになります。
- お客様からのメールの内容を、コメントとして手動で課題に転記していたため、「ちゃんと転記されているか」をチェックする必要があった
- 現在、ボールをお客様と弊社のどちらが持っているかを手動で設定する必要があったため、「ちゃんと正しいステータスになっているか」をチェックする必要があった
- 実績の把握にあたっては、エクスポート CSV を目視確認する必要がある
- キャッチボールの回数が多い課題
- ボールを持っている時間が長い課題(土日祝や連休を除外するため、営業日単位で計測する必要があったり、お客様がボールを持っている時間を除外する必要がある)
- 特定のスタッフの知見やリソースに偏った、リスキーな体制になっていないか(最終的な対応者だけでなく、途中の変遷についても把握する必要がある)
- お客様からの評価をいただく機能がなかった
もちろん暫定的な解決策として、例えばダブルチェックができるよう、チェック担当を決めて毎日二日分のチェックをするなどしていましたが、これを行うことによる時間的ロスや、担当スタッフのスキルセットとのミスマッチについても考慮が必要で、またそもそも機能がないと実現できないようなことはどうにもなりません。
Zendesk Support により、これらの課題が概ね解決されました。
Zendesk Support での解決方法
整理した運用課題をもとにサービス選定と検証を行いました。もちろん他サービスとの比較も行いましたが、趣旨と異なるのでここでは触れず、結果として Zendesk Support の導入によってどういう解決がもたらされたかについて記載します。
メールの自動登録とステータス変更
お客様からメールをいただくと、チケットに自動登録されるとともに、チケットのステータスが「オープン」にセットされます。「オープン」は「ボールを弊社が持っている」ということを意味しています(反対に、お客様がボールを持っている状態を「保留中」と呼びます)。メールの送信もチケットの画面から行うことができます。
機械的に行われるので漏れがなく、煩わしい日々のチェック業務からスタッフを開放してくれました。これだけでも導入の価値があります。
複数の操作をひとまとめにする「マクロ」
メールの定型文挿入とともに、チケットへのタグのセットなどをまとめて行ってくれる機能です。タグは、後述の「ビュー」と相まって、現状の把握とタスクの明確化に役立ちます。例えば「一報済み」「パートナー」「障害」「3回以上」「一ヶ月以上」「後追い」「渡邊」などのタグを設定しています。後述の「トリガ」「自動化」でもセットすることができます。
タグ「渡邊」は、スタッフの渡邊に一度でもチケットの担当を回したことを意味するもので、そのチケットの割合を「渡邊率」と呼んでいます。満足度評価を高く維持しながら「渡邊率」を下げることが課題のひとつであったことから導入されました。
数値的目標を作る「ビュー」
運用にあたり、最も重要なのがこの「ビュー」になります。「フィルタ」と呼ぶこともできそうですが、各「ビュー」一覧では、フィルタした結果の件数が表示されており、例えば「担当者が未割り当てのチケット」や「自分の未解決チケット」はもちろん、「チケットのオープン化から(土日祝を除いた)1.5 営業日以上未返信」「チケットが保留中になってから 3 営業日以上経過で、お客様に後追い連絡をしていないもの」など、「この数字を少なくする」「ゼロを維持する必要がある」といったような、サービスレベル向上と紐づく数値的目標を作ることができます。
「トリガ」と「自動化」による操作のフォロー
後追い連絡をしたら「後追い」タグを削除したり、「回答、対応を急いでいる」チケットが起票されたら優先度を高くする、といったように、様々な動作にフックして処理をさせるのがトリガです。これに対して、自動化は「チケットがオープン状態になってから 1.5 営業日経過でタグ『要返信』を追加」したり、「保留中になってから 3 営業日経過でタグ『後追い』を追加」といったことができます。これらを使って適切にタグを設定し、「ビュー」を組み立てるのが Zendesk Support 運用のキモと言えるでしょう。
Slack との連携
社内で利用している Slack に下記のチャンネルを作りました。
- チケットのアップデートを流すチャンネル
- お客様のよい評価だけを流すチャンネル
前者により、Zendesk Support の個々のチケットの画面を開いたり、メールのやりとりを確認することなく状況をチェックできるようになりました。また後者により、常に幸せな気分で業務を行うことができるようになりました(感じ方には個人差はありますが、毎日が複数の納期であるサポート業務において、一定水準のメンタル的健康を保つために非常に重要なことです)。
※ 悪い評価については別途レビューの機会を設けております
評価機能については、合わせて下記をご覧ください。ご協力いただけますと幸甚です。
検証期間と導入準備
専任スタッフを一人アサインし、通常業務を行いながらチームで議論を重ね、三ヶ月程度で導入しました。メールが自動でチケット化されるため、Backlog からのチケット引っ越しは行っていません。
検証に尽力してくれたスタッフは技術者ではありませんが、サービスの中で使われている語句やそのニュアンスを理解してしまえば、主要な各機能を検証し、チームの課題に照らし合わせて仕組みづくりを行うことができるようになっています。
Zendesk Support の弱点
サポート業務をビジネスの主軸に置くことができない場合はなかなか導入に踏み切れない価格帯だと思いますが、これに加え、Zendesk Support はサポートスタッフ単位の課金になるため、気軽に追加することができません。アプリにも同単位での課金があるものが多く、スタッフ数とアプリ数がともにコストを上昇させます。
その他
実は、Zendesk Support の導入は三回目のトライでした。今回サービスに触れたときの率直な感想として、かなりよくなったと感じました。代理店として株式会社エクレクト様にご協力いただくことができたのも大きく、安心して導入に踏み切ることができました。
今後とも PowerCMS 製品サポートをよろしくお願いいたします。
コメントを投稿する