このブラッシュアップでは、ワークフローを構築する際に考慮すべき以下の点について説明します。
このブラッシュアップセッションのパート1も必ずご覧ください。
その他のブラッシュアップに関する記事は、ブラッシュアップ関連のリソースをご覧ください。
パート1： トリガと自動化
前回のDonのブラッシュアップでは、理想的なZendeskインスタンスを構築するために必要な基本と、特定のニーズを満たすように構成する方法について触れました。今回は、理想的なワークフローを完成させるために必要なその他の情報について説明します。
トリガ
トリガはすばらしい機能です。トリガはイベントベースのシステムアクションで、チケットの作成時または更新時に実行されます。Zendeskでトリガの用途はたくさんありますが、次のカテゴリに分類できます。
- 特定のエージェントまたはエージェントのグループにチケットを割り当てる
- チケットのフィールド値を変更するか、タグを追加/削除する
- 作成または更新されたチケットのユーザー（またはターゲット）に通知する
- ユーザーまたは組織のフィールド値を変更する（チケットの更新のみ）
隠れた落とし穴：
Zendeskにはいくつかの標準のトリガがあり、非アクティブにしたり変更したりすることができます。本番環境に移行する前にトリガのリストをチェックしないと、不要な通知で受信トレイがいっぱいになる可能性があります。
デフォルトのトリガ「リクエスタへの通知 - コメント更新」は、アカウント内で最も重要なトリガです。これは、チケットのコメントをエンドユーザーに送信するトリガです。このトリガに変更を加えたり削除したりすると、エンドユーザーとのコミュニケーションに影響を与える可能性があるので注意が必要です。
1つのトリガにあまり多くのアクションを実行させないようにしてください。トリガが複雑になればなるほど、トラブルシューティングとメンテナンスが難しくなります。
Zendesk Supportが公開インスタンスで、登録不要で誰でもチケットを送信可能な場合、以下のプレースホルダを使用した初回返信トリガ（チケット作成時に起動）は、リレースパムのターゲットになる可能性があります。
- {{ticket.title}}
- {{ticket.requester.first_name}}
- {{ticket.requester.last_name}}
- {{ticket.requester.name}}
リレースパムとは、サードパーティ（この場合はZendesk）を経由して宛先にメールを送信することで、メールアドレスの送信元を隠してサードパーティになりすますことを指します。これらのプレースホルダは、誰でも任意のテキストやリンクを入力できる匿名エンドポイントを使用するため、リレースパムのターゲットになります。
アカウントがリレースパムのターゲットになるリスクを回避するには、「エンドユーザーのアクセス設定」で説明したように、インスタンスを非公開にするか、制限するように設定することを検討してください。それ以外の場合は、Zendesk Supportの公開インスタンスでは、上記のプレースホルダを件名や本文に使用せず、静的テキストを使用してください。これにより、たとえばチケットが作成されたときに送信されるメール通知で、「山田 太郎様」という敬称が「www.spam.com 様」に置き換えられることはなくなります。他のトリガ（最初の返信の後）でこれらのプレースホルダを使うことは、その時点で、そのやりとりが本物であることを証明したことになるので、許容されます。
ベストプラクティス：
命名規則を作成し、それを順守します。トリガの機能を名前で表すことが理想的です。トリガをクリックせずに機能の概要を把握できれば、時間をかなり節約できます。以下に例を示します。
優先度の設定 - 通常
スケジュールの設定 - 北米
グループへ割り当て - ティア1
リクエスタへの通知 - コメント更新
トリガのリストが1ページを超えるような場合は、命名規則が非常に重要になります。タイトルに基づいてトリガを検索できるからです。
トリガの順序も重要です。システムは、チケットが作成または更新されるたびに、すべてのトリガをチェックします。トリガを次のような順番にすることをおすすめします。
- チケット値の変更/更新を行うトリガ。優先度やステータス、その他のフィールド値などのチケット値を変更するトリガやチケットを追加するトリガをリストの先頭に追加します。これは、これらのトリガがチケットの割り当てや通知に影響する可能性があるためです。
- チケットを割り当てるトリガ。グループまたは個々のエージェントにチケットを割り当てるトリガは、チケットの他の値を更新するトリガの後に配置します。
- 通知を行うトリガ。ユーザーまたはターゲットに通知を送信するトリガは、リストの最後に置きます。これは、通知メールを送信する前に、システムに必要な変更を加えておきたいからです。
上記のそれぞれのカテゴリ内においても、条件が限定的なトリガほど先に、一般的なトリガほど後方に並べる必要があります。これにより、全体に影響を与えるトリガが、ターゲットを絞ったトリガの後に実行されるのを防ぎます。
トリガの条件はできるだけシンプルに、実行順序については入念に検討してください。トリガがシンプルであるほど、管理者の規模を変えたり変更した場合に管理しやすくなります。
確認事項：
- 一日の中で、エージェントはZendeskとメールのどちらを主に使用しているか？
- どのエージェントがメール通知を必要としているか？
- エージェントは通知をいつ受ける必要があるか？
- エンドユーザーにいつ通知する必要があるか？
- ワークフロー内のどの項目を自動化できるか？
- ワークフロー内のどの項目を自動化する必要があるか？
- 通知トリガにどのような名前を付けるべきか？
トリガの作成と管理の詳細については、こちらをご覧ください。
自動化
自動化は時間ベースのシステムアクションです。1時間単位で実行され、通常は時間ベースの条件が設定されています。自動化を使用すると、次のことができます。
- 特定のエージェントまたはエージェントのグループにチケットを割り当てる
- チケットのフィールド値を変更するか、タグを追加/削除する
- 作成または更新されたチケットのユーザー（またはターゲット）に通知する
- ユーザーまたは組織のフィールド値を変更する
自動化で実行できるアクションは、トリガで実行できるアクションと似ています。この2つの違いは、実行可能なアクションではなく、起動のための条件です。自動化を使用すると、イベントが発生してからx時間またはx時間経過したときにシステムアクションを実行できます。
隠れた落とし穴：
自動化は最多で1時間に1回しか実行されません。このため、優先度の高い更新を行う場合に、自動化を使用することは難しくなります。チケットの自動化が実行されてから1分後にチケットが届いたとします。1時間後に自動化が再び実行されるときに、そのチケットが「作成からの時間数がゼロ」と見なされることがあります。
ざっくりと幅のある時間ベースの条件（例：作成されてからの時間数 次より大きい X）ではなく、厳密な時間ベースの条件（例：作成されてからの時間数 次に等しい X）を設定すると、チケットが時間の条件を満たしていても、自動化の実行対象から外される可能性があります。これにより、重要な通知やチケットの更新が行なわれないおそれがあります。
ベストプラクティス：
自動化を作成する場合は、目的の結果に対してトリガと自動化のどちらが適切か検討します。多くの場合、トリガは条件を満たすと即座に実行されるので、より効果的です。
時間ベースの自動化を作成するときは、できるだけ「次に等しい」の条件ではなく、「次より大きい」や「次より小さい」の条件を使用します。これにより、自動化が実行されず、対象から漏れてしまうチケットが発生しません。なお、これを行う際には、ループを防止するために無効化条件とアクションを追加してください（必要に応じてシステムから警告されます）。
この作業を行うには、まず自動化の実行前にチケットにあってはならないもの（タグやフィールド値など）について条件をチェックし、次に、次回の自動化実行時にチケットを対象外にする変更を自動化に行なわせるようにします。これにより、自動化が複数回実行されなくなります。
自動化を使用してバンプ、バンプ、解決の自動ワークフローを作成することができます。これにより、リクエスタの応答がなかった場合でもチケットが対象から外されることがなくなり、こうしたチケットでビューが埋まるのを避けられます。
確認事項：
- トリガと自動化のどちらが適しているか？
- チケットが対象から外れたときに通知する、またはアクションを起こすためのシステムが必要か？
- チケットを「終了」にするまで、どのくらいの期間「解決済み」のステータスに置いておくか？
- 通知メールをどのような言葉使いにするべきか？
自動化の作成と管理の詳細については、こちらをご覧ください。
パート2： ビジネススケジュールとSLA
ビジネススケジュール
ビジネススケジュールは、トリガや自動化ほどの派手さはありませんが、ワークフローで重要な役割を果たします。ビジネススケジュールを設定すると、次のことが可能になります。
- 営業時間内または営業時間外にトリガや自動化を使用してシステムアクションを実行する
- 自動化およびSLA内の営業時間内に（カレンダー時間ではなく）時間を設定する
- SLAを通じて正確なサービス目標を提供する
隠れた落とし穴：
リストの最上位にあるスケジュールがデフォルトのスケジュールで、新しいチケットすべてに適用されます。スケジュールを組み替えることはできません。つまり、新しいスケジュールまたは既存のスケジュールをデフォルトのスケジュールに設定することはできません。新しいスケジュールをデフォルトとして設定するには、その上にあるすべてのスケジュールを削除する（または名前とプロパティを変更する）必要があります。
休日をスケジュールに追加することはできますが、翌年に引き継がれることはありません。したがって、毎年手動で設定する必要があります。
休日は、その分の日数がビジネススケジュールから差し引かれます。つまり、半日しか働かない場合でも、営業時間ベースのSLAが一日分休止することを意味します。（見方を変えれば、よいニュースかもしれません。）
スケジュールを複製することはできません。したがって、毎年、各スケジュールに休日を手動で入力する必要があります。
タイムゾーンを必ず設定します。スケジュールは、正しいタイムゾーンにある場合にのみ有効です。一部のプランタイプでは、個々のスケジュールごとにタイムゾーンを設定できます。それ以外のプランタイプでは、こちらでスケジュールを設定できます。
ベストプラクティス：
スケジュールの入力を開始する前に計画を立てます。まずデフォルトスケジュールを入力します。このスケジュールはデフォルトですべての新しいチケットに適用されます。つまり、営業時間を使用してチケットに適用されたSLAはこのスケジュールに従います。
複数のスケジュールを使用する場合は、トリガを使用してチケットにスケジュールを割り当てます。たとえば、チケットがグループxに割り当てられているときに、スケジュールxに割り当てるトリガを作成できます。すべてのスケジュールでこれを行うのであれば、どのスケジュールをデフォルトとして設定しても問題ありません。
スケジュールを複製することはできませんが、休日を複製することはできます。休日は手動で入力する必要がありますが、複製を作成して日付を変更することはできます。これは定期的な休日を設定するための最善の方法です。
休日を作成する場合、時間を減らすことはできません。全日がスケジュールから除外されます。これらの日は、どっちみち大きな量にはならなそうので、遅れを取り戻すための予備日として使用してください。
確認事項：
- エンドユーザーを24時間365日サポートするか？
- 特定の時間帯や曜日にしか対応できないチームがあるか？
- 全日休ではない休日があるか？
- スケジュールはいくつ作成する必要があるか？
ビジネススケジュール機能は、Teamプランでは利用できません。スケジュールの作成方法と管理方法の詳細は、こちらをご覧ください。
SLAポリシー
多くの企業では、顧客に対して、特定のイベントについての期限を取り決めています。
Zendeskサービスレベル契約により、サービス目標を追加してチケットの優先順位付けを行うことができます。追加可能な目標は次のとおりです。
- 初回返信時間：チケットの作成時刻からエージェントが最初のパブリックコメントを投稿するまでの時間
- リクエスタの待機時間：チケットが新規、オープン、保留中の各ステータスで費した時間の合計
- エージェント作業時間：チケットが新規およびオープンの各ステータスで費やした時間の合計
- 2回目の返信時間：エンドユーザーのコメント投稿から2回目のエージェントによるパブリックコメントを投稿するまでの時間
- 定期更新：エージェントのパブリックコメントと次のパブリックコメント投稿の間の時間
- 一時停止可能な更新：チケットが新規、オープン、および保留中のステータスにある場合の、エージェントからの各パブリックコメント間の時間。チケットが「待機中」ステータスになるたびに一時停止されます。
隠れた落とし穴：
Zendesk SLAでは、システム優先順位フィールドを使用する必要があります。チケットに優先度が割り当てられていない場合、SLAポリシーは適用されません。
SLAが営業時間に基づいており、複数のスケジュールが設定されている場合は、各チケットに適切なスケジュールが適用されていることを確認する必要があります。特に指定がない場合、各チケットはデフォルトのビジネススケジュールを使用します。
エージェントがチケットを作成した場合は（リクエスタをエンドユーザーに設定したとしても）、「初回返信時間」の目標は即座に満たされます。これは、チケットに入力した「説明」が、エージェントの最初のパブリックコメントとしてカウントされるためです。この目標は即座に満たされるため、このチケットが処理されたかのように見えます。
「2回目の返信時間」の目標は、社内チケットに対しては機能しません。この目標は、エンドユーザーがコメントしてから、エージェントが次にパブリックコメンを行うまでの時間を測定するので、エージェントがリクエストしたチケットはこの目標では無視されます。
1つのポリシー内で、すべての目標を使用しないでください。「リクエスタの待機時間」と「エージェントの作業時間」のどちらかを使用するか、または両方を使用しません。1つのポリシーでこれらの目標を両方とも使用する必要はなく、そのようにすると状況が複雑になります。
SLA違反は、トリガで使用するときの適格なイベントとして利用できません。つまり、「SLA違反後にただちに通知する」トリガを構築する方法はありません。
ベストプラクティス：
利用可能な目標は6つあります。1つのポリシーですべての目標を使用する必要はありません（使用すべきでもありません）。
「初回返信時間」（FRT）目標は、新しいチケットが適切な時間内に確実に処理されるようにするための優れた方法です。「2回目の返信時間」（NRT）目標も、同様の理由で同じくらい重要です。一般に、同じポリシー内のFRT目標とほぼ同じ、またはまったく同じNRT目標を構築することをお勧めします。
「エージェントの作業時間」（AWT）と「リクエスタの待機時間」（RWT）は、両方ともチケットを解決するのにかかる時間を測定するので、一方を選択するか、またはどちらも選択しないようにします。AWTはエージェントの観点から測定しているため、チケットが待機中または保留中のときは測定が一時停止されます。RWTはリクエスタの観点からこれを測定しているため、チケットが保留中の場合にのみ測定が一時停止されます。
「定期更新」と「一時停止可能な更新」は、両方ともエージェントが投稿したパブリックコメントの間隔を測定するので、一方を選択するか、またはどちらも選択しないようにします。
確認事項：
- 契約上、特定のサービス目標を達成するように義務付けられているか？
- 社内で達成を目指すサービス目標があるか？
- 複数のポリシーまたは包括的なポリシーが必要か？
- どのようにチケットの優先順位付けを決めているか？
- チケットの解決時間についてサービス目標を設定しているか？
設定している場合、リクエスタとエージェントのどちらの観点から測定すべきか？ - 全エンドユーザーを24時間365日サポートすることはできるか？
カレンダー時間とビジネススケジュールのどちらを対象に目標をチェックしたいか？
SLAポリシーはTeamプランでは使用できません。SLAを作成および管理する方法の詳細は、こちらをご覧ください。
パート3： マクロとビュー
マクロ
マクロは、チケットに対して一度に複数のアクションを実行できるエージェント実行型のスクリプトです。マクロで実行できるのは、エージェントが実行可能な操作のみです。また、チケットの変更は、エージェントがチケットを更新するまでは保存されません。
マクロを使用することでクリック操作の回数を減らし、エージェントの生産性を高めることができます。
マクロは次のことができます。
- コメントテキストを追加する
- チケットフィールドを更新する（ドロップダウンとチェックボックスのみ）
- チケットタグを追加または削除する
- CCを追加する
- 担当者を変更する
- チケットの件名（タイトル）を設定する
- チケットのコメントに添付ファイルを追加する
隠れた落とし穴：
マクロは基本的にエージェントのためのショートカット機能です。マクロは、現在のユーザーが実行可能な操作のみを実行できます。たとえば、チケットタグを編集する権限をエージェントが持っていない場合、そのエージェントがタグを追加または削除するマクロを実行しても、タグの追加も削除も行われません。
マクロは、テキスト、複数行のテキスト、日付、数値、または正規表現のチケットフィールドを更新しません。
ベストプラクティス：
ドロップダウンフィールドと同様に、マクロをネストできます。マクロのネストは、マクロを整理してきれいに保つのに最適な方法です。
1回のチケット更新で、複数のマクロを実行できます。つまり、さまざまなケースを想定してマクロを構築する必要はありません。複雑な処理にならないようにします。
プレースホルダを使用します。コメントの先頭に{{requester.first_name}}を置くことで、定型の文章もパーソナライズされたように見えます。また、チケットの件名を設定するときにプレースホルダを使用することもできます。
すべてのエージェントまたは特定のグループに、マクロを割り当てることができます。一部のエージェントだけにマクロを表示する必要がある場合は、マクロを対象のエージェントのみに制限するようにして、混乱を避けます。
マクロは検索することができます。チケットのマクロメニューを表示しているときに、マクロタイトルの入力を開始すると、メニュー内のマクロがフィルタリングされます。
マクロを簡単に検索可能にするには、命名規則を作成し、それを順守します。
一度に複数のチケットを更新するには、マクロを使用します。ビュー画面で、複数のチケットの横にあるチェックボックスをオンにして、画面右上の黒い「チケットを編集」ボタンを押します。。チケットの更新画面が開いたら、マクロを適用して送信します。
トリガと自動化は、マクロと並用できます。たとえば、トリガをすぐにアクティブにするタグを追加するマクロを使用することができます。あらゆる可能性を考えてみましょう。
確認事項：
- チケットでエンドユーザーから最もよく送られてくる問題は何か？
- コメントの本文には何を記述しているか？
- マクロでパブリックまたはプライべートのコメントを残したいか？
- どのエージェントを、どのマクロにアクセスさせるか？
マクロはすべてのプランで利用可能です。マクロを作成して管理する方法については、こちらをご覧ください。
ビュー
これから、最後の部分について説明します。ビューは、おそらくワークフローの最も重要な要素です。ビューにより、エージェントに表示されるチケットと、チケットの処理順序が決まります。
ビューはフォルダではありません。保存された検索、あるいはフィルタリングされたデータベースです。iTunesのスマートプレイリストに似ています。
隠れた落とし穴：
複雑すぎるビューを作成しないこと。ビューの条件が増えるほど、繰り返しフィルタリングされることになります。良いことかもしれませんが、間違いの元にもなります。条件が多すぎると、チケットを見失う可能性があります。
ビューの数が多すぎる場合、エージェントがチケットに適切に優先順位を付けることが難しくなる可能性があります。ビューの数を必要なものだけに絞ることでこれを避けることができます。
ブラウザを開いたままにしておいても、自動的には更新されません。ビューをクリックすることで（またはページを更新することで）更新されます。
ビューには1ページあたり30枚までのチケットしか表示されません。ビューが正しくソートされていないと、重要なチケットを見失う可能性があります。
ベストプラクティス：
マクロと同様に、ビューはすべてのエージェントまたは特定のグループに割り当てることができます。多くの場合、グループごとにカスタムビューを作成するのが適切です。こうすることで、各エージェントには関連する情報のみが表示されます。
SLAを使用している場合は、「次のSLA違反」でビューを並べ替えるのが適切です。こうすることで、次にSLA違反しそうなチケットから順に表示されるようになります。
Playボタンを使用します。ビューページの右上隅にあるPlayボタンをクリックすると、対応可能な次のチケットに移動します。
確認事項：
- どのようにチケットの優先順位を付けるべきか？
- 各グループにどのチケットを表示するか？
- どのようにチケットを分類するか？
ビューの作成と管理の詳細については、こちらをご覧ください。