zendeskはかれこれ2年くらい使っているんですが、運用課題がどんどん増えていってしまった話
初note投稿です。
2年くらい付き合っているzendeskのアドベントカレンダーに参加することになり、今回書くことになりました。
株式会社ベーシックで私のzendesk運用経験で感じたことを書きたいと思いますが、個人的な見解として、読んでいただければ幸いです。
zendeskをかれこれ2年くらい使ってきた中で、失敗談を共有する形で、みなさんの運用の参考としてほしいです。
目次は以下のとおりです。
この記事を書こうと思った背景
11月のzenlabのzendesk勉強会で発表をさせていただきまして、なんとか活用しています！って内容だったんですが、どちらかと言うとつまづいていることのほうが多かったりして、その話をしたほうがよかったなぁと内心、後悔していたので、いい機会と思い、まとめてみました。
どういう内容かと言いますと、zendeskはかれこれ2年くらい使っているんですが、導入担当ではなかったりするので、そもそもなんでzendesk使っているんだっけ？とそもそもの目的を見失ってきたり…。
また、zendeskの運用は複数の人が担当してきたため、「あれ…、この設定ってどこでやっているんだっけ…？」とか闇になっている部分が増えてくることが多くなってきてなかなか運用改善に踏み切れなかったり…。
これからzendesk活用する人もいると思い、しくじり先生的なポジションで、こんな失敗はしてはいけないとの内容を展開していきたいと思います。
同じツールを長年使い続けると、本来の目的を見失いがち問題
ツールの目的を明文化できていると良いなと
私がzendeskを触り始めたのは約2年前で、そのときには既にzendeskが導入されており、当たり前のように運用に組み込まれていました。
なので、当たり前のように使い続けていたわけなんですが、そういえば本来の目的ってなんだっけと見失いがちになります。
とにかく回答時間を短くしようとか、満足度をあげようとか、良いことはできるだけ形にしたいですが、派生的に生まれた目的を突き詰めると、別のツールが向いていたりとかの話になってしまいます。
ここで、言いたいのは、ツールの導入目的をしっかりと残さないとなということです。これは他のツールも含めて、ツールの目的を明文化できていると良いなと思います。
zendesk導入背景（伝聞）
私が株式会社ベーシックに入ったときは既にzendesk利用でしたが、zendesk以前の運用では、チャットツールを利用してサポートをしており、顧客ごとにルームを作って、サポートメンバー全員で、そのルームを確認しては対応するといった流れでした。
問い合わせ対応向けではないサービスだったので、誰がチェックしているのか、誰が対応に動いているのかわからない状態で、また、回答フォーマットも用意なく、それぞれの知見でその場で回答しなきゃいけないので、対応の漏れや、回答の精度を高めるのも大変だったんじゃないかと想像しています。
zendesk導入目的（伝聞からの再定義）
上記の状態を解決するべくzendeskを導入したと聞いていますが、改めて私の方で目的としては、お客様に素早く、漏れなく、正しい回答をすることができ、運用改善もしやすいとの目的が果たせるためと考えています。また、回答内容を分析できるので、プロダクト改善にまでつなげることも期待しています。
Zendesk導入目的に照らし合わせた使い方
どんな使い方をしたいかは以下。
・お客様に素早く対応したい
・漏れなく対応したい
・正しい回答をしたい
・運用改善を図りたい
・お客様に素早く対応したい
当社のサポートメンバーは、社内のヘルプデスク、ヘルプページの作成と業務もある中で、問い合わせが来たらすぐに対応する必要があります。現状は、zendeskではSlack連携をしているので業務をしていても、すぐに気付けるようにしています。
・漏れなく対応したい
問い合わせを漏れなく対応することに関しては、zendeskでは、問合せが分散せずに、一覧性があるビューを作れるので見落とす恐れが無いです。また、問合せの性質によって、ビューを作れるので、効率的に漏れなく問い合わせ対応することができます。
・正しい回答をしたい
当社の場合、多機能のプロダクトかつ、機能追加されたりもするので、回答の精度を上げる取り組みも必要です。1人が回答を作ることで、zendeskにはその回答パターンが蓄積されるので、全員分のナレッジを作るような一挙両得な役割をしてくれ、回答精度を上げていくことができます。
zendeskは対応したチケットのタイトル、本文が検索できるので、誰が対応したとしても、既に回答されていれば、どんな回答を誰にしたのかを確認することができます。
・運用改善を図りたい
zendeskではタグ付けが便利で、問合せの回答時に自動でタグ付をする機能があります。どんな問い合わせが多いのかなどをまとめることができたり、チケットの対応ステータスを管理することができたり、ヘルプページが充実していない問合せのフラグ付をしたりと、運用改善にも結びつけることができます。
あとは、問合せの傾向を把握することで、最終的には顧客が困らずにプロダクトを利用するゴールに近づけるのではと考えています。
＜タグ分けのイメージ＞
基本的な内容ばかりですが、まずは上記の目的を果たすことをzendeskの役割と考えています。別の目的が発生した場合は、柔軟に対応していこうと考えていますが、上記と照らし合わせていきながら、進めたいなと思っています。
Zendeskとプロダクトの連携開発はシンプルに。基本はzendeskの設定で乗り切れ
後々、変更するのはユーザーに影響が
当社の場合、プロダクトの管理画面内からzendeskの問い合わせフォーム投稿できるように開発をしています。問い合わせの時点で、入力項目に応じてカスタムフィールドに項目が入り、その項目に応じてトリガー設定でビューの区分けがされるように設定しています。
ただ、開発当時と、今では問合せの区分も変わってきます。zendeskの方で、トリガー設定により区分けすることもできるので、はじめはゆるめの開発連携でも良かったかもなと感じています。
連携開発は最小限にして、まずはzendesk側の設定を把握した上で、業務上、重要度が高い連携開発を追加していったほうが良いかと思います。
開発してしまったものを修正するには当然開発メンバーのリソースも必要ですが、後々変更するのはユーザーに影響が出てしまうので、慎重に進める必要も出てきちゃいます。
Zendeskを当時の業務に最適化をすると、今の業務では最適化ではない問題
ツールの設定を属人化させないで、ドキュメント化
今回の内容の中で1番言いたい内容なんですが、当社もサポートの形をどんどん見直していっているんですが、サポートの形が変わったら、当たり前のことで運用も見直さないといけません。
例えば、zendeskの中で、対応している範囲が変わったら、zendeskの各種設定も見直したほうが良いです。
既に別ツールでやり取りが進んでいて、zendeskでは使わない設定が残っていると、引き継いだ人が削除していい設定なのかどうかが判断できず、運用が非効率になってしまいます。せめて、ツールの設定を属人化させないで、ドキュメント化しておきたいです。
担当が複数人に渡ると、どこで設定しているのかがわからない問題
何回も言いたいのは、ツールの設定を属人化させないで、ドキュメント化
当社では、zendeskは導入した担当1と、活用しようとした担当2と、更に活用しようとした担当3と、そろそろ見直しが必要だと感じて設定をちょこっと見直しをした私（担当4）と、最近抜本的に見直しをしてくれた担当5、くらいになってきており、これが独自で開発したシステムだったら、もはや手を付けたくない仕様になると思うんですが、ツールもそうなんじゃないかと。
担当者それぞれがzendeskを最適化しようとしたはずなんですが、いろんな設定が入っていると、シンプルな設定もどこに影響するのか分からないのでなかなかできない状態に陥ります。
大事だと思っているので、何回も言いたいのは、ツールの設定を属人化させないで、ドキュメント化をしたいです。
運用シートの作成、要は運用が全て
色々と運用課題が溜まって来ていましたが、目的と照らし合わせ、運用シートを作ることにより、設定分からない問題や、業務のズレを解消することができました。
組織でツールを使っている以上、目的などの明文化やドキュメント化は、長期的にメリットがあると言えます。
色々書きましたが、単に運用を怠っていると上記の問題に当たってしまうだけなんですが、目的と照らし合わせつつ、今一番最適な運用はどういう形なのかを考えて、ツールと付き合っていくべきですよね。
当然見直しにはコストがかかるので、何でも見直すと大変なことになりますが、ある程度のスパンで検討していくべきだったなと思い、今回書かせていただきました。
長文になりましたが、読んでいただいた方、ありがとうございます！
noteを書いてみて、自分の振り返りに良かったので、今後も前向きに更新を検討したいと思います。
最後に、今回のアドベントカレンダーの企画「Zendesk Support/Guide/chat/talk/Explore Advent Calendar 2019」の紹介です。
ぜひ確認してみてください！