Zendeskビジネスルールにおけるスケジュール条件の使用方法

Zendesk（ゼンデスク）のビジネスルールにおけるスケジュール条件は、単純な時間ベースのアクションをはるかに超えた、高度なワークフローの可能性を切り開きます。サポート業務を自動化する際に、実際の稼働時間、祝日、および地域差を考慮に入れることができます。

24時間365日稼働していないサポートチームを管理している場合、または異なるタイムゾーンに複数のチームがある場合は、これらの条件を活用する方法を理解することが不可欠です。このガイドでは、Zendeskのトリガー、自動化、およびSLAポリシー全体でスケジュール条件を設定および使用するために知っておくべきすべてのことを説明します。

Zendeskはルールベースの基盤を提供しますが、eesel AIのようなツールは、これらの機能と連携して、時間ベースのワークフローを補完するインテリジェントなインテントベースのルーティングと自動化を追加できます。

Zendeskビジネスルールとスケジュールについて

スケジュール条件に入る前に、各要素がどのように組み合わさるかを明確にすることが重要です。Zendeskビジネスルールは、ヘルプデスクの自動化エンジンです。トリガー（イベントベース、即時発動）、自動化（時間ベース、1時間ごとに実行）、およびSLAポリシー（ターゲットベース、パフォーマンス測定）の3種類があります。

スケジュールは、チームが実際に作業している時間を定義します。スケジュールがない場合、Zendeskは暦時間（24時間365日）で動作します。スケジュールを設定すると、定義された作業時間中の時間のみをカウントするビジネスアワーの計算が有効になります。

この区別は重要です。暦時間には、夜間、週末、および祝日が含まれます。ビジネスアワーは、実際の可用性を尊重します。顧客が金曜日の午後5時にチケットを送信し、チームが週末に作業しない場合、暦時間では土曜日と日曜日がSLAターゲットに対してカウントされます。ビジネスアワーは、月曜日の朝まで時計を一時停止します。

スケジュールは、管理センターのオブジェクトとルール > ビジネスルール > スケジュールで設定します。この機能を使用するには、Professionalプラン以上が必要です。Enterpriseプランでは複数のスケジュールが許可されており、異なる時間帯を持つさまざまな地域または部門にチームがある場合に重要になります。

Zendeskの営業時間とスケジュールを設定する

スケジュールの作成は簡単ですが、経験豊富な管理者でもつまずくニュアンスがあります。正しく設定する方法を次に示します。

まず、管理センター > オブジェクトとルール > ビジネスルール > スケジュールに移動します。「スケジュールを追加」をクリックし、チームにとって意味のある名前（「サポートチーム - 米国東部」など）を付け、適切なタイムゾーンを選択します。このタイムゾーン設定は非常に重要です。顧客に対する実際の営業時間帯を決定します。

「週間スケジュール」セクションには、時間を設定するための視覚的なインターフェイスが表示されます。時間ブロックをドラッグして、開始時間と終了時間を15分単位で調整できます。各間隔は、少なくとも1時間以上である必要があります。営業時間が深夜に及ぶ場合（午後10時から午前6時など）、暦日で区切られた2つの別々の間隔を作成する必要があります。Zendeskでは、日付の境界を越える間隔は許可されていません。

1日の時間を削除するには、時間ブロックのXをクリックします。その日は「休業」と表示されます。休業日に時間を追加するには、その日の行の任意の場所をクリックするだけです。

週の時間を設定した後、「祝日」タブで祝日を追加できます。「祝日を追加」をクリックし、名前を付けて、開始日と終了日を選択します。祝日は最大2年前までスケジュールでき、必要に応じて複数日にまたがることもできます。重要な制限事項：祝日は、営業時間だけでなく、暦日全体を対象としています。月曜日が祝日の場合、午前9時から午後5時までの時間帯だけでなく、1日全体が祝日と見なされます。

Enterpriseプランでは、リストの最初のスケジュールがすべてのチケットのデフォルトになります。異なるスケジュールを異なるチケットに適用するには、トリガーを作成する必要があります。これについては、次のセクションで説明します。

トリガーでZendeskビジネスルールのスケジュール条件を使用する

Zendeskのトリガーはイベントベースです。チケットが作成または更新されるとすぐに発動します。トリガーのスケジュール条件を使用すると、イベントが営業時間中、祝日、または特定のスケジュール内で行われたかどうかに基づいてロジックを構築できます。

最も一般的に使用される条件は、「チケット：営業時間内ですか？」です。これは、チケットイベントが発生した時間に基づいて「はい」または「いいえ」を返します。実用的なユースケース：営業時間外に送信されたVIPチケットのエスカレーション。たとえば、「チケット：営業時間内ですか？～いいえ」と「優先度～緊急」の条件と、オンコールマネージャーに通知するアクションを含むトリガーを作成できます。

もう1つの便利な条件は、「チケット：祝日ですか？」です。これは、スケジュールされた祝日の暦日全体に対して「はい」に設定されます。これを使用して、祝日の人員削減を説明する自動返信を送信したり、プライマリチームが不在の場合にチケットを別の方法でルーティングしたりできます。

複数のスケジュールを持つEnterpriseプランでは、2つの追加条件があります。「チケット：スケジュール」は、現在チケットに適用されているスケジュールを確認します。「チケット：（スケジュール）内」を使用すると、チケットに適用されているスケジュールだけでなく、任意のスケジュールに対してチケットの時間を比較できます。これはグローバルチームにとって強力です。チケット自体がロンドンチームに割り当てられている場合でも、チケットがシドニーの営業時間中に作成されたかどうかを確認できます。

自動返信トリガーの実用的な例を次に示します。

• **条件：**チケットが作成された、営業時間内ですか？～いいえ
• アクション：「お問い合わせありがとうございます。営業時間外にお問い合わせいただきました。チームがオンラインに戻ったら対応いたします。」のようなメッセージをユーザー（リクエスター）にメールで送信します。

トリガーと自動化のスケジュール条件の主な違いは、タイミングです。トリガーは、チケットが作成または更新された時点で条件を評価します。自動化は、現在の時間に対して条件を定期的にチェックします。トリガー条件の詳細については、Zendeskのトリガーに関するドキュメントを参照してください。

Zendeskビジネスルールのスケジュール条件を使用して時間ベースの自動化を構築する

自動化は、スケジュール条件がチケット管理の継続的な管理に役立つ場所です。トリガーとは異なり、自動化は1時間ごとのサイクルで実行され、条件に対してすべてのチケットをチェックし、条件が満たされたときにアクションを実行します。

Zendeskには、自動化のための「～時間経過」条件のスイートが用意されています。これらには、作成からの時間、オープンからの時間、保留からの時間、解決からの時間、割り当てからの時間、更新からの時間などがあります。これらのそれぞれについて、暦時間ではなくビジネスアワーで計算するバリアントを選択できます。

多くの管理者がつまずく重要な部分は、自動化が約1時間ごとに実行されることです。これは、「解決からの時間～24時間」のような「～である」条件を使用する場合、タイミングの問題があることを意味します。自動化が23.5時間で実行され、次に24.5時間で実行される場合、条件がtrueとして評価されない可能性があります。Zendeskは、信頼性の高い自動化の発動のために、「～である」の代わりに「～より大きい」条件を使用することを公式に推奨しています。

もう1つの重要な概念は、無効化条件です。「～より大きい24」を使用すると、チケットステータスが変更されない限り、条件はtrueのままになります。無効化条件がない場合、自動化は同じチケットで毎時間実行されます。標準的なパターンは、「タグに次のいずれも含まれていない：reminder_sent」のようなタグ条件を追加し、アクションとして「タグを追加：reminder_sent」を含めることです。これにより、自動化がチケットごとに1回だけ発動することが保証されます。

一般的な自動化のユースケースは、顧客の非アクティブ後に保留中のチケットを自動的に解決することです。

• **条件：**ステータス～保留中、保留時間 > 48（ビジネス）、タグに次のいずれも含まれていない：auto_solve_pending
• **アクション：**ステータス～解決済、タグを追加：auto_solve_pending

自動解決が発生する前にリマインダーを送信するコンパニオン自動化でこれを構築できます。

• **条件：**ステータス～保留中、保留時間 > 24（ビジネス）、タグに次のいずれも含まれていない：pending_reminder_sent
• **アクション：**ユーザー（リクエスター）に穏やかなリマインダーをメールで送信、タグを追加：pending_reminder_sent

「～時間経過」条件には、28日間（672時間）の最大ルックバックがあることに注意してください。自動化は、このウィンドウを超えるチケットでは発動しません。これは、古いチケットが突然アクションをトリガーするのを防ぐための意図的な設計上の選択です。

スケジュールをZendesk SLAポリシーと統合する

SLAポリシーは、ビジネスアワーが顧客に直接影響を与える場所です。SLAポリシーを作成するときに、「営業時間」を「ビジネスアワー」または「暦時間」のいずれかに設定できます。ほとんどのチームにとって、ビジネスアワーは、実際に作業している時間に基づいて現実的な期待値を設定するため、適切な選択です。

SLAポリシーは、スケジュールとともに優先度を評価します。緊急、高、通常、および低優先度のチケットに対して異なる目標時間を設定できます。スケジュールは、これらの時間のカウント方法を決定します。金曜日の午後4時に作成された4時間の初回応答目標を持つチケットは、暦時間では月曜日の朝に違反する可能性がありますが、週末をカウントしないビジネスアワーでは目標を十分に満たしている可能性があります。

複数のスケジュールを持つEnterpriseプランでは、SLAポリシーはチケットに適用されているスケジュールを使用します。これにより、地域SLAが有効になります。ヨーロッパの顧客はヨーロッパの営業時間に基づいてターゲットを設定でき、米国の顧客は同じチームが両方のチケットを処理する場合でも、米国の時間に従うことができます。

経験豊富なZendeskコンサルタントからのベストプラクティスは、違反時間で昇順にソートされたSLAベースのビューを作成することです。これにより、エージェントは常に、最新または最高の優先度だけでなく、次に違反する可能性が最も高いチケットを確実に確認できます。これにより、チケットがコミットメントに対する実際の緊急度に基づいて処理される、より公平なワークフローが作成されます。

eesel AIでは、SLAポリシーとAI搭載のトリアージを組み合わせて、割り当てられる前にチケットをインテリジェントにルーティングするチームを見てきました。AIトリアージ製品は、コンテンツとインテントに基づいてチケットにタグを付け、ルーティングし、優先順位を付けることができます。これは、時間ベースのSLAルールと連携して、適切なチケットが適切なタイミングで確実に注意を払われるようにします。

Zendeskビジネスルールのスケジュール条件を使用する際の一般的な落とし穴

経験豊富な管理者でも、スケジュール条件で問題が発生します。最も一般的な問題とその回避方法を次に示します。

**「～である」条件のタイミングの問題：**自動化は1時間ごとのサイクルで実行され、正確な瞬間を見逃す可能性があるため、「解決からの時間～24時間」を使用することは信頼できません。常に代わりに「～より大きい」を使用してください。正確なタイミングが必要な場合は、正確に24にヒットしようとするのではなく、バッファー（「～より大きい23」など）を組み込みます。

**無効化条件の欠落：**繰り返し実行を防ぐ方法がない場合、自動化は一致するすべてのチケットで毎時間実行されます。常にタグベースの無効化子を含め、そのタグをアクションとして追加します。

**Enterpriseでのスケジュールなしのチケット：**複数のスケジュールがあるが、それらを割り当てるトリガーを作成していない場合、チケットはスケジュールなしで作成される可能性があります。これにより、ビジネスアワーの計算が中断されます。チケットがデフォルトであっても、スケジュールが割り当てられていることを常に確認してください。

祝日の取り扱いに関する混乱：「祝日ですか？」の条件は、営業時間だけでなく、暦日全体に対して「はい」と評価されます。月曜日の営業時間が午前9時から午後5時で、月曜日が祝日の場合、条件は日曜日の午後10時と火曜日の午前6時にもtrueになります。

28日間の制限：「～時間経過」条件は、672時間（28日間）を超えて遡ることができません。数か月間保留になっているチケットで自動化しようとしている場合、自動化はそれらを認識しません。

**クローズされたチケットの不変性：**Zendeskでチケットがクローズされると、自動化によって更新できなくなります。これは、データの整合性を維持するための設計によるものです。長期的なフォローアップが必要な場合は、フォローアップ期間が経過するまでチケットを解決済みのままにするようにワークフローを構築します。

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

Zendeskのルールベースの自動化は強力ですが、自然な制限があります。明示的に定義したロジックに従います。「注文番号12345の払い戻しリクエスト」に関するチケットが、最前線のキューをスキップして財務部門に直接送信する必要がある請求の問題であることを理解できません。

これは、eesel AIのようなAIツールがZendeskのネイティブ機能を補完する場所です。AIエージェントは、メタデータフィールドだけでなく、メッセージコンテンツから顧客の意図を理解するためにZendeskと直接統合されます。

組み合わせの仕組みを次に示します。Zendeskビジネスルールは、構造化された時間ベースのワークフローを処理します：SLA、営業時間外のルーティング、保留中のチケットのクリーンアップ。AIレイヤーは、ニュアンスのあるコンテンツベースの決定を処理します：問題の種類に基づくルーティング、感情に基づく優先順位付け、注文番号とアカウントの詳細の自動抽出。

たとえば、営業時間外に作成されたすべてのチケットを「翌日」キューにルーティングするZendeskトリガーがあるとします。次に、AIエージェントはそのキューを確認し、言語とコンテキストに基づいて実際に緊急であるチケットを特定し、ルールベースのロジックが朝まで待機する場合でも、それらをオンコールチームにプッシュできます。

当社のプラットフォームは過去のチケットから学習するため、ビジネス固有の言語とプロセスを理解できます。「払い戻しリクエストが30日を超える場合は、丁寧に拒否してストアクレジットを提供する」のようなエスカレーションルールを、複雑なトリガー条件を構築せずに、わかりやすい英語で定義できます。

Zendeskビジネスルールのスケジュール条件をすでに使用している場合は、AIレイヤーを追加すると、ルールだけでは対処できないエッジケースと例外を処理できます。