Zendeskのステータス変更からの自動化条件の使い方

多忙なサポートキューを管理している場合、次のようなシナリオに直面したことがあるでしょう。顧客がフォローアップに数日間返信せず、そのチケットがそこに座っているだけで、ビューを散らかしている。または、オープンになってから時間が経ちすぎているチケットについて、チームメイトに催促する必要があるかもしれません。これはまさに、Zendeskの自動化条件が役立つ場面です。

問題は、一般的な混乱点があることです。多くの人が「Zendeskトリガー条件ステータス変更からの時間」を検索しますが、実際に必要なのはトリガーではなく、自動化です。トリガーと自動化は、Zendeskで完全に異なる目的を果たしており、その違いを理解することが、実際に機能するワークフローを構築するための鍵となります。

このガイドでは、Zendeskの自動化で時間ベースの条件を使用する方法について説明します。利用可能な条件、それらを正しく設定する方法、および後々頭痛の種にならないようにするためのベストプラクティスを学びます。また、eesel AIのAIツールがこれらの自動化を補完し、よりインテリジェントなサポートワークフローを作成する方法についても見ていきます。

Zendeskにおけるトリガーと自動化の理解

混乱を解消しましょう。トリガーと自動化はどちらもZendeskの自動化ツールですが、完全に異なるタイムラインで動作します。

トリガーはイベントベースです。 チケットに何かが起こった瞬間に発動します。チケットが作成、更新、または何らかの方法で変更されると、トリガーはすぐに条件を評価し、数秒以内にアクションを実行します。顧客が件名に「緊急」という単語を含むチケットを送信した場合、トリガーはそれをすぐに優先キューに割り当て、上級エージェントに通知できます。遅延はありません。

自動化は時間ベースです。 スケジュールに基づいて実行され（通常は1時間に1回）、時間の経過を伴う条件を確認します。これが「時間経過」条件が存在する場所です。自動化は、トリガーでは処理できない「X日後にフォローアップ」のようなシナリオに最適です。

短いバージョンは次のとおりです。チケットイベントに基づいて何かをすぐに発生させる必要がある場合は、トリガーを使用します。特定の時間が経過した後に何かを発生させる必要がある場合は、「時間経過」条件を持つ自動化を使用します。

「時間経過」条件は、基本的に時間の経過が必要なため、自動化でのみ利用可能です。トリガーは、チケットが変更された瞬間の現在の状態のみを調べるため、ステータス変更から何時間経過したかを知ることができません。

Zendeskのネイティブ自動化は時間ベースのアクションをうまく処理しますが、一部のチームは、これらの時間ベースのルールが発動する前に、よりインテリジェントなルーティングが必要になることに気づきます。そこでeesel AIがお手伝いできます。AIトリアージは、最初の分類とルーティングを処理することで、設定と並行して動作し、自動化がタイミングベースのフォローアップに集中できるようにします。

Zendeskで利用可能な「時間経過」条件

Zendeskは、自動化で使用できる包括的な時間ベースの条件セットを提供しています。利用可能なものは次のとおりです。

ステータスベースの条件：

• 作成からの時間
• オープンからの時間
• 保留からの時間
• 待機からの時間
• 解決済みからの時間
• ステータスカテゴリ[カテゴリ名]からの時間

割り当てと更新の条件：

• 割り当てからの時間
• 更新からの時間
• リクエスタからの更新時間
• 担当者からの更新時間

タスクとSLAの条件：

• 期日からの時間（タスクチケットの場合）
• 期日までの時間
• 最後のSLA違反からの時間
• 次のSLA違反までの時間

重要な注意点の1つは、「クローズからの時間」条件がないことです。チケットがクローズされると、自動化によって変更できなくなるため、この条件は役に立ちません。

営業時間と暦時間

ProfessionalまたはEnterpriseプランを使用している場合は、Zendeskアカウントで営業時間と休日を設定できます。これにより、時間ベースの条件を設定するときに重要な選択肢が得られます。

暦時間は、経過するすべての時間（24時間365日）をカウントします。48時間後にアクションを実行するように自動化を設定した場合、週末や休日に関係なく、正確に48時間後に発動します。

営業時間は、定義された営業時間内の時間のみをカウントします。サポートチームが平日の午前9時から午後5時まで勤務し、自動化を24営業時間に設定した場合、3営業日が経過するまで発動しません。

どちらを使用する必要がありますか？それはあなたのサポートモデルによって異なります。営業時間内に顧客への応答を約束する場合は、SLAとエスカレーションの自動化に営業時間を使用します。古いチケットをクローズするなどの一般的なハウスキーピングには、通常、暦時間の方が理にかなっています。

Zendeskが時間をカウントする方法

自動化サイクルを理解すると、発生する癖を説明するのに役立ちます。自動化は約1時間に1回実行されますが、必ずしも毎時ちょうどに実行されるとは限りません。条件が満たされた後に自動化が最初に実行される時間は、「ゼロ」時間としてカウントされます。後続の毎時実行は、1時間としてカウントされます。

これは、チケットが午前9時15分に保留になり、自動化が午前9時47分（32分後）に実行された場合、最初の実行は0時間としてカウントされることを意味します。午前10時47分の次の実行は1時間としてカウントされます。条件で指定できるのは整数時間のみで、分数ではありません。したがって、「保留からの時間が1時間である」を設定するには、最初の自動化の実行から少なくとも1時間経過している必要があります。

ステップバイステップ：最初の自動化の作成

顧客が48時間応答しなかった後、保留中のチケットを解決する実用的な自動化を作成する手順を説明します。これは、時間ベースの条件の最も一般的なユースケースの1つです。

ステップ1：管理センター > オブジェクトとルール > ビジネスルール > 自動化に移動します

まず、Zendesk管理センターを開きます。「オブジェクトとルール」で、「ビジネスルール」を見つけて、「自動化」をクリックします。これにより、Zendeskが作成したデフォルトのものを含む、アカウント内の既存のすべての自動化のリストが表示されます。

ステップ2：条件を追加します

「自動化を追加」をクリックして、新しい自動化を作成します。「次のすべての条件を満たす」セクションと「これらのアクションを実行する」セクションが表示されます。条件セクションで、ルールを作成します。

自動解決の例では、次の条件を追加します。

• チケット：ステータスカテゴリ | である | 保留中
• チケット：ステータスカテゴリ保留からの時間 | より大きい | 48
• チケット：タグ | 次のいずれも含まない | auto_solved

ステータス条件は、保留中のチケットのみを調べるようにします。時間条件は、48時間のしきい値を設定します。タグ条件は無効化であり、この自動化がチケットごとに1回のみ実行されるようにします。

ステップ3：「時間経過」条件を設定します

「時間経過」条件を選択すると、「保留からの時間」や「解決済みからの時間」などのオプションのドロップダウンから選択します。次に、「である」、「より大きい」、または「より小さい」の演算子を選択します。

重要なヒントは、「である」の代わりに、できる限り「より大きい」を使用することです。自動化は1時間ごとに実行されるため、「24である」条件は、チケットがその状態で正確に24時間経過した場合にのみtrueと評価されます。自動化が23.5時間で実行され、次に24.5時間で実行される場合、その正確なウィンドウを逃します。「24より大きい」は、24時間を超えたすべてのチケットをキャッチし、自動化を発動するためのより広いウィンドウを提供します。

ステップ4：無効化条件を追加します

無効化条件は、自動化が同じチケットで繰り返し実行されるのを防ぐものです。それがない場合、「保留からの時間が48より大きい」を満たすチケットは、保留中の状態が続く限り、毎時間自動化をトリガーします。

標準パターンは次のとおりです。

1. 特定のタグが存在しないことを確認します（例：「次のいずれも含まない：auto_solved」）
2. 自動化が発動したときに、同じタグをアクションとして追加します

タグが追加されると、チケットは条件を満たさなくなるため、自動化は再度発動しません。

ステップ5：アクションを定義して保存します

「これらのアクションを実行する」セクションで、何を実行するかを追加します。

• チケット：タグを追加 | auto_solved
• チケット：ステータスカテゴリ | 解決済み
• 通知：ユーザーメール | （リクエスタとCC） | [カスタムメッセージ]

通知はオプションですが、推奨されます。チケットが自動的に解決されたことを顧客に知らせる（そして、返信して再度開くことができる）ことは、チケットをサイレントにクローズするよりも優れたエクスペリエンスを提供します。

「自動化を作成」をクリックすれば完了です。自動化は、次の1時間ごとのサイクルで実行を開始します。

Zendeskのステータス変更からの自動化条件に関する重要なベストプラクティス

何百もの自動化を設定した後、経験豊富なZendesk管理者は、いくつかの教訓を苦労して学びました。注意すべき点は次のとおりです。

「である」ではなく「より大きい」を使用する

これは、時間ベースの条件で最も一般的な間違いです。「解決済みからの時間が24である」を使用すると、Zendeskに正確に24時間のマークでそのチケットをキャッチするように依頼しています。ただし、自動化は1時間ごとに（常に予測可能な時間とは限りません）実行されるため、その正確なウィンドウを見逃すのは簡単です。

自動化が23.5時間で実行される場合、条件は満たされません。次に24.5時間で実行される場合、「24である」条件はもはやtrueではありません。チケットは自動化をトリガーしません。

「24より大きい」はこれを解決します。24時間以上解決されたチケットに対してtrueと評価され、自動化が次の1時間ごとの実行でそれをキャッチするための広いウィンドウが提供されます。

常に無効化条件を含める

無効化条件がない場合、自動化は同じチケットで繰り返し実行されます。「オープンからの時間が8より大きい」場合にタグを追加してマネージャーに通知する自動化を想像してみてください。無効化がない場合、チケットのステータスが変更されるまで、マネージャーは毎時間通知を受け取ります。

タグパターン（不在を確認し、アクションとして追加）は、最も信頼性の高い無効化です。タグはステータスが変更されてもチケットに保持されるため、自動化は1回のみ実行されます。

1000チケットの制限を理解する

Zendeskの自動化は、自動化サイクルごとに1000件のチケットしか処理できません。条件を満たすチケットが1000件を超える場合、残りのチケットは次の1時間ごとのサイクルを待ちます。

これは小規模なチームにはめったに影響しませんが、大規模なサポート運用ではこれを念頭に置いておく必要があります。1000チケットの制限は、アカウントごとではなく、自動化ごとであるため、複数の自動化を持つことで負荷を分散できます。

営業時間と暦時間

どちらを使用しているかを明示的にします。「保留からの時間が24より大きい」を設定し、営業時間を使用している場合、それは実際には1暦日ではなく、3つの8時間の営業日を意味します。期待が一致しない場合、これはエージェントと顧客の両方を混乱させる可能性があります。

特に、ブランドやチームごとに異なるスケジュールがある場合は、どの自動化が営業時間を使用し、どの自動化が暦時間を使用するかを文書化します。

「時間経過」条件の一般的なユースケース

時間ベースの自動化は非常に用途が広いです。サポートチームがそれらを使用する最も一般的な方法は次のとおりです。

保留中のチケットの自動解決。 顧客に情報を要求し、応答がない場合は、48〜72時間後にチケットを自動的に解決します。これにより、顧客が返信して再度開くことができるようにしながら、キューをクリーンに保ちます。

リマインダーメールの送信。 自動解決する前に、24時間でフレンドリーなリマインダーを送信します。「これについてまだサポートが必要かどうかを確認しています。ご連絡がない場合、24時間後にこのチケットは自動的にクローズされます。」

停滞したチケットのエスカレーション。 チケットが（保留中ではなく）4〜8時間オープンになっている場合、優先度に応じて、自動的に上級エージェントにバンプするか、マネージャーに通知します。これにより、何も見過ごされないようにします。

解決済みのチケットのクローズ。 Zendeskのデフォルトの自動化は、96時間後に解決済みのチケットをクローズします。このタイミングをカスタマイズしたり、クローズする前に満足度調査を送信するなどの追加のアクションを追加したりできます。

保留中のチケットのフォローアップ。 サードパーティを待っている場合、チケットは忘れられがちです。保留ステータスが48時間経過した後、担当者に通知するように自動化を設定します。

SLA違反の警告。 「次のSLA違反までの時間」条件を使用して、チケットがSLA制限に近づいているときにエージェントに警告を送信し、違反する前に応答する時間を与えます。

自動化が機能しない場合のトラブルシューティング

自動化が期待どおりに機能しない場合は、問題を診断する方法を次に示します。

条件が実際に満たされているかどうかを確認します。 自動化をトリガーしたはずのチケットを開き、すべての条件を手動で確認します。ステータスは期待どおりですか？十分な時間が実際に経過しましたか？それをブロックしている可能性のあるタグはありますか？

無効化条件が実行をブロックしていないことを確認します。 無効化タグを追加したが、自動化が実行されなかった場合は、そのタグが他の手段（別の自動化、トリガー、または手動）で追加されたかどうかを確認します。

自動化の実行履歴を確認します。 Zendeskは、自動化のリビジョン履歴に自動化アクティビティのログを保持します。どの自動化がいつ実行され、処理したチケットの数を確認できます。これは、自動化が実行されているが、一致するチケットが見つからないかどうかを特定するのに役立ちます。

一般的な間違いに注意してください。

• クローズされたチケットは、自動化によって更新できません。条件がクローズされたチケットと一致する場合、自動化は単にそれに対してアクションを実行しません。
• 小数時間はサポートされていません。「保留からの時間が1.5である」を設定すると、Zendeskはこれを1時間として解釈します。
• 時間ベースの条件は、「次のいずれかの条件を満たす」セクションでは使用できません。「次のすべての条件を満たす」セクションにある必要があります。

eesel AIによるZendeskワークフローの強化

Zendeskのネイティブ自動化は、時間ベースのアクションに強力ですが、チケットがすでに適切に分類およびルーティングされている場合に最適に機能します。そこで私たちがお手伝いできます。

eesel AIはZendeskと直接統合して、自動化が開始される前にインテリジェンスレイヤーを処理します。時間ベースのルールのみに依存する代わりに、AIエージェントはチケットの意図、感情、緊急度を分析して、すぐにスマートなルーティングの決定を行うことができます。

連携の仕組みは次のとおりです。eesel AIは受信チケットを読み取り、顧客が実際に必要としているものに基づいて適切なチームにルーティングします。次に、時間ベースの自動化は、スケジュールに従ってフォローアップ、リマインダー、およびエスカレーションを処理します。その結果、チケットが適切な人に迅速に届き、自動化がタイミングを処理するワークフローが実現します。

たとえば、4時間オープンになっているチケットをエスカレーションするだけでなく、eesel AIトリアージに優先度の高い問題をすぐに特定させ、上級エージェントにルーティングさせ、自動化ですべての標準的なフォローアップシーケンスを処理させることができます。

今すぐZendeskワークフローの自動化を開始しましょう

Zendeskのステータス変更からの自動化条件を設定することは、サポートキューを管理可能な状態に保つための最も効果的な方法の1つです。重要なのは、トリガーと自動化の違いを理解し、時間条件に「である」ではなく「より大きい」を使用し、繰り返しの実行を防ぐために常に無効化条件を含めることです。

シンプルに始めましょう。非アクティブ状態が48時間経過した後に保留中のチケットを解決する基本的な自動化は、すぐに価値を提供し、キューをクリーンに保ちます。メカニズムに慣れたら、複数の条件とアクションを使用して、より洗練されたワークフローを構築できます。

時間ベースのルールが提供できるよりもインテリジェントな自動化が必要な場合は、eesel AIがZendeskと連携して、ルールベースのトリガーが苦労するニュアンスのあるルーティングと分類を処理します。eesel AIがZendeskの設定をどのように強化できるかをご覧ください。