サポートタイムズ

サポートタイムズはカスタマーサポートの“今”を届けるメディアです。(Powered by CallConnect)

カスタマーサポートの未来を考えよう!

Powerd by CallConnect
Twitter Facebook

Zendesk のトリガーを使いこなせ!Zenlab trigger night イベントレポート

f:id:sennba3:20180210174827j:plain

みなさんこんにちは。編集部の畠です。

突然ですが、 Zendesk をご存知でしょうか。メールの返信からチャット、マーケティングまで様々な機能を提供しているカスタマーサポートツールです。

Zendesk について詳しくはこちら

Zendesk のサービスの中で最もポピュラーなのは、 Zendesk Support。問い合わせメールへの対応を効率化するのに役立つ様々な機能が提供されています。例えば、問い合わせメールに対し、テンプレートを適用する“マクロ機能”や問い合わせメールの内容を分析するための“インサイト機能”があります。
今回の Zenlab では、“トリガー”と呼ばれる、問い合わせメールへの自動返信や担当者の割当などを自由に設定できる機能にフォーカスしたお話が聞けるということで、 会場の Wantedly にやって参りました。

zenlab.connpass.com

トリガーの概要

まず、 Zenlab 発起人の冨樫さんから、トリガーの概要を解説していただきました。

f:id:sennba3:20180208163653j:plain

トリガーは一言でいうと、「X」が起こった時に「Yする」を設定できる機能です。

中身を自由に設定できるので、例えば「導入相談の問い合わせが届いたら」→「“新規顧客”というタグをつける」といったことを自動化することができます。

f:id:sennba3:20180208163709j:plain

トリガーは複数組み合わせることも可能で、例えば導入相談メールが届いたら、新規顧客というタグをつけ、さらにメールが届いてから3日後にお伺いのメールを送るといったことも可能になります。Zendesk Support のトリガー機能をうまく活用することによって、生産性の向上やカスタマーサービス品質の向上を実現することができます。

メンバー育成とクオリティ担保

最初の登壇者は、Wantedly の仲野さんと中島さん。

f:id:sennba3:20180208163738j:plain 仲野さん

仲野さんが Wantedly に入社した当時は、メール特化型のツールで対応していたそうです。その後サービスの成長とともにスタッフも増え、運用の効率化が必要になってきたため、 Zendesk を導入することにしました。

しかし、新しいスタッフが入社してくる中で下記の課題があったそうです。

  • 新人のメールスキルをどのように上げていくか?
  • 対応のクオリティをどのように担保していくか?

今回は、新人スタッフへのフィードバックやチェック体制の構築にトリガーを活用した事例をお話いただきました。

f:id:sennba3:20180208165638j:plain 中島さん

基本的にメールを送信する際には、シニアスタッフが内容をチェックするようにしています。 当時は Github 上でメールの内容をチェックし、コメントをしていたのですが、2つのツールを行ったり来たりするのが大変で、同時編集ができないことに不便さを感じていました。そこで、こうしたフローを Zendesk 上ですべて完結させられる状態を目指したそうです。

設定までの流れ

具体的には、「待機中」のステータスを有効にし、「待機中」のチケットのみを集めるビューを作成。
そして、内容のチェックが必要な新人スタッフのテキスト作成権限を「メモのみ」にし、ユーザーに直接返信(パブリック返信)ができないようにする。

トリガーの設定では、「待機中」で送信されたチケットに「need_approval」(要チェック)というタグをつける。

f:id:sennba3:20180208164711j:plain

そして、「need_approval」タグがついていて、「待機中」から「オープン」のステータスになったチケットに「remand」(差し戻し)タグをつけます。

f:id:sennba3:20180208164734j:plain

Zendesk でよく問題になるのが、社内コメントを間違ってユーザーに送ってしまうということなのですが、下記のようなフローにすることで、そういったミスをなくすことができました。

f:id:sennba3:20180208164644j:plain

結果として対応クオリティの均一化ができ、ユーザーの満足度アップにも繋がりました。また、チェックの件数や差し戻し率も出せるため、データに基いてメール対応を改善していけるようになりました。

トリガーを応対品質向上に活用した好例ではないでしょうか。

トリガーを0から作った話

続いてはエウレカの久保さん。
発表内容は「自社運用構築のためにデフォルトのトリガーを全部無視した話」。

f:id:sennba3:20180208164755j:plain

エウレカは Pairs というデーティングアプリを提供していますが、サポートに Zendesk を活用しています。 久保さんは初めて Zendesk に触ったとき、トリガーがデフォルトで7つ設定されていて、それがどのように動作しているか分からなかったため、途方にくれてしまったそうです。

そこで久保さんは一旦すべてのトリガーを取り払い、0から自社にあった設計をしていくことにしました。

f:id:sennba3:20180208164803j:plain

1番最初に行った設定は Zendesk のデフォルトの設定でもある「リクエスタに通知(ユーザーにメールを送る設定)」に条件を1つ追加しました。

f:id:sennba3:20180208164812j:plain

ステータスが「解決」のときのみにユーザーにメールが送信される仕組みになりました。
これによって、新規やオープンでユーザーに誤送信などをしてしまうリスクを下げることができました。

そして、現状では39個のトリガーを活用するまでになったそうです。
その過程でトリガーは、本来は開発が必要になるような設定を手軽に実現できてしまう素晴らしいものだという結論に至りました。

Zendesk ではトリガーがデフォルトで用意されているため、それをそのまま活用しているようなパターンも多いと思われます。しかし、0からやってみるというのは、サービスを理解するための方法としてはありなのかもしれませんね。

文字揺れをトリガーで分析するまで

3番手はクックパッドの立松さん。
発表内容は「お問い合わせの文面に合わせてトリガを発動させた話。」

f:id:sennba3:20180209174716j:plain

Zendesk は、メール本文の日本語検索が弱いため、探したい語句で検索しても出てこないという課題があります。

f:id:sennba3:20180208165401j:plain

クックパッドではスマートフォン向けアプリも提供していて、「機種変更」に関する問い合わせがくることもあるそうです。そんな時にユーザーからは「機種変更」「機種変」「端末を交換して〜」と表記揺れがある状態で問い合わせが届くため、後々同一の用件として集計するのが難しくなってしまいます。

f:id:sennba3:20180208165430j:plain

そこで、このような場合にどうしたら良いかということをZendesk社に問い合わせたところ、ヒントを得ることができました。
Zendesk の「ビュー」の設定においては、日本語検索や and or検索に対応していることがわかったのです。そこで、ビューの検索機能を活用し、ある程度の表記揺れがあっても同じ用件のメールとして集計できるようにしました。

f:id:sennba3:20180208165446j:plain

しかし、検索問題は解消されたものの、また別の課題がでてきました。
その課題というのが、ビューではインサイト(分析)で計測ができないということでした。

立松さんは、トリガーがビューが同じような条件設定でできているということに気づき、ビューで入れていたような条件をトリガーに入れることで、例えば機種変更関連の問い合わせのチケットフィールドを「機種変更に関する問い合わせ」に自動で切り替えることができます。

f:id:sennba3:20180209153008j:plain

そうすることで、トリガでタグを付け、お問い合わせの推移を分析の機能で測ることができるようになったのです。

f:id:sennba3:20180209153252j:plain

Zendesk にはトリガーや自動化、ビュー、それぞれの条件設定は確かに似ていますが、その後の活用方法によってどれを使うのが良いかも変わってくるんですね。奥が深い、、、

契約情報に応じて担当者を振り分ける

最後の登壇者は、トレジャーデータの髙橋さん。
トレジャーデータは、BtoB 向けのデータ分析サービスを世界的に展開しています。

f:id:sennba3:20180208165507j:plain

トレジャーデータでは、ユーザーからのお問い合わせが来た際に、ユーザーの契約情報に応じて担当者を振り分けたいという要望がありました。 理想としては、下記のように MRR (月次売上)が●●円以上のユーザーからの問い合わせだったらアラートを鳴らすといったことをトリガーで実現したいのですが、 MRR といった情報をユーザー情報に結びつけるのは簡単ではありません。

f:id:sennba3:20180208165524j:plain

ユーザーフィールドに、契約のプランや MRR を自動入力されるようにしたいのですが、ユーザーの詳細データがまとまっている Salesforce のアドオンでは入れられません。( Zendesk はメールアドレスのユーザー単位、 Salesforce は会社の契約単位なのでそのままでは結び付けづらい。)

そのため、Zendesk 、 Salesforce 、 MySQL の3つ情報をトレジャーデータ上で統合させて、必要な情報を Zendesk に書き込むという仕組みを構築しました。

f:id:sennba3:20180208165607j:plain

これによって当初の目的であった契約情報に応じて担当者を振り分ける、通知を鳴らすといったことができるようになったそうです。ちなみに、データ統合に関してはオープンソースがあり、データエンジニアが使用すれば1、2日で構築することも可能とのことです。

エンジニアリングが加わることで、サービス間のデータ連携の可能性を拡げることができるんですね。

まとめ

今回は Zendesk のトリガー機能にフォーカスした話でしたが、各社で設計が大きく異なっていました。0からトリガーを組んだ話からエンジニアリングを活用した力技の設計まであり、幅広い活用方法を知ることができました。

その一方で、自由度が高すぎるためにどうしたら良いか分からないといった悩みも登壇者や参加者から挙がっていました。 課題を解決しようと考えた時、設定の自由度が高いため、解決方法も数多く出てきます。 そのため、Zendesk をうまく活用するには、 Zendesk に関する十分な知識と設計力、センスが求められるのではないでしょうか。

今回のイベントでは、運用上の具体的な課題や課題解決に向けた設計について知ることができたため、Zendesk を実際に使っているユーザーにとっては非常に参考になったかと思います。

Zendesk を実際に使っている人の話を聞きたい、ユーザー同士で情報交換がしたいという方は、Zenlab に参加してみるといいのではないでしょうか。
次回は4月前半に開催予定とのことですので、興味のある方はこちらをチェクしてみてください。

以上、第2回目となる Zenlab のイベントレポートをお届けしました。