Zendeskトリガー条件のステータス変更からの経過時間の使い方

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

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

このガイドでは、Zendeskの自動化で時間ベースの条件を使用する方法について説明します。利用可能な条件、正しく設定する方法、および後々頭痛の種にならないためのベストプラクティスを学びます。

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

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

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

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

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

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

Zendeskのネイティブ自動化は時間ベースのアクションをうまく処理しますが、一部のチームは、時間ベースのルールが開始される前に、よりインテリジェントなルーティングが必要になることに気付きます。そこで、eesel AIのようなツールが、最初のトリアージとカテゴリ化を処理することで、セットアップを補完し、自動化がタイミングベースのフォローアップに集中できるようにします。

eesel 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：「経過時間」条件の構成

「経過時間」条件を選択すると、「保留中からの経過時間」や「解決済みからの経過時間」などのオプションのドロップダウンから選択します。次に、演算子「である」、「より大きい」、または「より小さい」を選択します。詳細については、Zendeskの自動化条件リファレンスを参照してください。

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

ステップ4：繰り返しの実行を防ぐために無効化条件を追加します

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

常に無効化条件を含める

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

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

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

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

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

営業時間とカレンダー時間

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

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

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

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

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

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

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

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

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

eesel AIでZendeskワークフローを強化する

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

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

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

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

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

Zendeskの設定を強化する準備はできましたか？eesel AIを無料でお試しください今日からよりスマートな自動化を開始しましょう。または、デモを予約するeesel AIが既存のワークフローでどのように機能するかをご覧ください。