お仕事にて、Q&A サイトをオンプレミスの Web システムから Zendesk に移行しました。
しばらく運用していて、気づいた反省点などを残しておこうと思います。検討している方などの参考になれば幸いです。
正直、本来はできていて当然なものもあるかとは思いますが、そこはご容赦いただければと…
パッケージ導入／移行でも良く聞く話
なるべく標準的なフローにあわせる
トリガやマクロといった機能を駆使すれば結構複雑なワークフローも実現できます…が、当たり前ですがやりすぎると煩雑になりスパゲッティ化します。変更影響把握とかもややこしくなりますので、ほどほどにしましょう。
現行踏襲に固執しない
業務フローだけでなく分析項目なども、現行踏襲に固執しない方がよいと思います。なるべくシンプルに、めったに使わない機能／項目は一度見送る。チケット情報は JSON なので、項目の追加もオンプレで RDB でやっていたときに比べれば楽 (※) です。そのためにも、意思決定者も上手く巻き込んでいきたいですね。
(※) 追加は容易なのですが、チケットが凍結した後は編集ができず、遡ってデータを入れることができないのは注意です。まぁそういうところは割り切りをするのが良いかなと。
なお、現行踏襲に固執されて複雑になるようなら、それは Zendesk を選択するべきではないのかもしれないです。
イマドキのスタイルに変える話
クラウドを受け入れる
SaaS なので、こちらが想定していないタイミングで微細な変更があったりします。実際、意識していない間に UI が変わってたりもしました。こちらもユーザーも、そういうもんだと受け入れる心が必要です。
改修時の意思決定やリリース作業を軽くする
できれば、こちらの改修速度も軽く速くしておきたいです。API が結構しっかり用意されているので、試験環境で確認⇒本番環境へデプロイ といったリリース手順を取る場合は、設定確認～設定変更～反映は頑張って API を活用するのも良いかと。
総合テストは、おそらくブラウザ中心になるため自動化がしんどいですが、「何かあっても復旧できればよい」マインドにして、なるべく軽くしておくと良いと思います。
自動化はしやすい、完璧を求めない
API やチャット連携も豊富なため、自動化できる部分は多いと思います。
機械による自動化については、完璧を求める人もいると思いますが、ある程度「コンピュータに任せ、何か起こったら人間が謝ればよい」マインドも必要になってくるんじゃないかと思っています。
Zendesk 特有？のポイント
「ライトエージェント」は意外とやりたいことができない
チケット一覧といったビューなどの設定や、分析ツールである Explorer の利用にかなりの制約があります。「回答を送る人数分だけエージェント買う」という構成は多いような気がしますが、データ分析者や意思決定者はエージェント権限を持っておいたほうが良いです。
やりとりは長くしすぎない方がよい？
これは賛否両論あると思いますが、やり取り (社内メモなど) が多いとスクロールが大変で、双方のユーザビリティが悪くなります。情報量とのトレードオフだと思いますが、やっぱり短い方がチケットの内容を把握しやすいです。
回答レビューは別のツールでやったほうがよい？
これも、使い方によって賛否両論あると思いますが、Zendesk ではインタラクティブなレビューをすることを想定して作られていないと感じます。プルリク的なことや回答文案の版管理もできませんし。
また、上記の通りチケットのスレッドが長くなる原因にもなります。レビューはチャットツールなどでやったほうが良いと思います。
分析ツールを覗いておいた方がよい
デフォルトで分析ダッシュボードが用意されており、結構色々なデータが取れます。その取得条件とチケット対応のワークフローの想定があっているか、検証して確認しておいた方がよいです。対応時間の算出方法とか。
ビューは四半期くらいのスコープにしか使えない
ビューを使うと色々な条件でチケットを一覧化することができますが、「凍結されてから 120日経過したチケット」は表示対象から除外されます。つまり、半年前のデータをビューで見たときに、既に表示されなくなっているチケットがチラホラある状況になります。ビューから CSV を吐いて集計していたりすると罠に掛かります。
検索の頭が地味に悪い
特に、記事の数が多いと顕著だと感じます。Frequently な Q&A が多いならいいかもしれませんが、そうでない場合は結局よくわからん検索結果になってしまい、ひとつもクリックすらされない可能性があります。もしかしたら、数を絞ったり、タイトルを工夫したり、記事内容としての最適化はまだまだ欠かせないのかもしれません。