営業時間外にZendeskの自動化条件を使用する方法：完全ガイド

Zendeskで時間ベースのルールを設定しようとしている場合、混乱する壁にぶつかったことがあるかもしれません。「Zendeskトリガー条件 ステータス変更からの時間」を検索しても、トリガーではなく自動化への参照が見つかり続けるでしょう。簡単に言うと、トリガーと自動化は完全に異なるツールであり、「時間経過」条件は自動化でのみ機能します。

このガイドでは、営業時間外のZendesk自動化条件について知っておくべきことをすべて説明します。これらの時間ベースのルールが実際にどのように機能するか、正しく設定する方法、経験豊富な管理者でさえつまずく一般的な落とし穴について学びます。また、最新のAIツールがこれらの自動化を補完し、よりインテリジェントなサポートワークフローを作成する方法についても見ていきます。

Zendeskのトリガーと自動化の理解

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

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

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

重要な違いは何でしょうか？トリガーはイベントに対応します。自動化は時間に対応します。チケットイベントに基づいて何かをすぐに実行する必要がある場合は、トリガーを使用します。特定の時間が経過した後に何かを実行する必要がある場合は、「時間経過」条件を持つ自動化を使用します。

これを理解するための簡単な方法は次のとおりです。トリガーは反応的であり（何かが起こったので、今すぐ行動する）、自動化は辛抱強い（適切なタイミングを待ってから行動する）です。

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

Zendeskは、自動化で使用できる包括的な時間ベースの条件セットを提供しています。これらの条件は、特定のチケットイベントからの経過時間を測定します。

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

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

割り当てと更新の条件：

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

タスクとSLAの条件：

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

重要な制限事項の1つは、「クローズからの時間」条件がないことです。チケットがクローズされると、永続的な記録になり、自動化によって変更できなくなります。これは、データの整合性を維持するための設計によるものです。

営業時間と暦時間

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

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

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

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

Zendeskが時間をカウントする方法：自動化サイクル

信頼性の高い時間ベースのルールを設定するには、自動化サイクルを理解することが重要です。実際にどのように機能するかを以下に示します。

自動化は、クローズされていないすべてのチケットに対して1時間に1回実行されます。条件が満たされたときにすぐに実行されるわけではなく、必ずしも毎時ちょうどに実行されるわけではありません。自動化は、各時間のどこかの時点で開始されます。たとえば、5分過ぎや38分過ぎなどです。

条件が満たされた後に自動化が最初に実行されるときは、「ゼロ」時間としてカウントされます。後続の毎時実行は、1時間としてカウントされます。これは、チケットが午前9時15分に保留になり、自動化が午前9時47分（32分後）に実行された場合、最初の実行は0時間としてカウントされることを意味します。午前10時47分の次の実行は1時間としてカウントされます。

条件で指定できるのは整数時間のみで、小数時間ではありません。この毎時サイクルは、タイミングがわずかにずれているように感じることがある理由を説明しています。イベントから正確に24時間後に自動化が発動することを期待している場合、自動化サイクルがいつ実行されるかに応じて、実際には24〜25時間後に発動する可能性があります。

各自動化は、1時間あたり最大1,000件のチケットに対してアクションを実行できます。条件を満たすチケットが1,000件を超える場合は、残りのチケットは次のサイクルまで待機します。ほとんどのチームにとってこれは問題ではありませんが、大規模なサポート業務では注意する必要があります。

最初の「時間経過」自動化の設定

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

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

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

ステップ2：新しい自動化を作成し、条件を設定します

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

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

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

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

ステップ3：無効化条件を設定します

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

標準パターンは簡単です。

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

タグが追加されると、チケットは条件を満たさなくなるため、自動化は再度発動しません。このパターンは、作成するほとんどすべての時間ベースの自動化に不可欠です。

ステップ4：アクションを定義します

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

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

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

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

営業時間外のZendesk自動化条件の一般的なユースケース

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

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

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

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

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

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

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

ベストプラクティスと一般的な落とし穴

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

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

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

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

「24より大きい」はこれを解決します。これは、24時間以上解決されたチケットに対してtrueと評価され、自動化に次の毎時実行でチケットをキャッチするための広い時間枠を与えます。

常に無効化条件を含める

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

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

1,000件のチケット制限の理解

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

これは小規模なチームにはめったに影響しませんが、大規模なサポート業務では注意する必要があります。1,000件のチケット制限は、アカウントごとではなく、自動化ごとであるため、複数の自動化を持つことは負荷を分散するのに役立ちます。

営業時間と暦時間

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

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

回避すべきその他の落とし穴

クローズされたチケットは更新できません。 自動化はクローズされたチケットでは実行されません。条件がクローズされたチケットと一致する場合、自動化は単にアクションを実行しません。

整数時間のみがサポートされています。 「保留からの時間が1.5である」を設定すると、Zendeskはこれを1時間として解釈します。整数時間の制約内で作業してください。

時間ベースの条件には配置制限があります。 これらは、「次のすべての条件を満たす」セクションでのみ使用でき、「これらのいずれかの条件を満たす」セクションでは使用できません。

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

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

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

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

チケットのイベントを確認します。 自動化をトリガーしたはずのチケットを開き、そのイベントログを表示します。チケットがいつ更新されたか、および自動化アクションが適用されたかどうかを正確に確認できます。これは、自動化が実行されているが、一致するチケットが見つからないかどうかを特定するのに役立ちます。

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

• 演算子として「より大きい」ではなく「である」を使用する
• 無効化条件が欠落しているか、正しくない
• チケットがクローズされているため、自動化による更新ができない
• 小数時間（整数に切り捨てます）
• 間違ったセクションの時間ベースの条件

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

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

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

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

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

時間ベースのルールが提供できるものを超えてZendeskワークフローにインテリジェンスを追加したい場合は、eesel AIをお試しください。既存の自動化をどのように補完するかを確認してください。

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

営業時間外のZendesk自動化条件を設定することは、常に手動で介入することなく、サポートキューを管理可能な状態に保つ最も効果的な方法の1つです。毎時サイクルがどのように機能するかを理解し、「である」ではなく「より大きい」を使用し、常に無効化条件を含めることで、必要なときに正確に実行される信頼性の高い自動化を構築できます。

48時間後に保留中のチケットを自動解決するなど、簡単な自動化から始めます。メカニズムに慣れたら、エスカレーションルールやSLA警告などのより洗練されたワークフローに拡張します。自動化は、慎重なトリガー設定またはインテリジェントなAIトリアージを通じて、適切なチケット分類と組み合わせると最適に機能することを忘れないでください。

重要なのは、小さく始めて、徹底的にテストし、時間の経過とともに自動化ライブラリを構築することです。将来の自分（とサポートチーム）はあなたに感謝するでしょう。

インテリジェントな自動化でZendeskの設定を強化する準備はできましたか？ eesel AIを無料でお試しください。AI搭載のトリアージと応答が、時間ベースの自動化とどのように連携するかを確認してください。または、デモを予約するして、特定のワークフローで実際に動作することを確認してください。