Zendesk SLAポリシーのフィルター条件：完全ガイド

ZendeskでSLAポリシーを誤ると、チームが達成不可能な目標に溺れたり、重要なチケットが抜け落ちたりする可能性があります。どちらのシナリオも、不満を抱えた顧客とストレスを感じるエージェントという同じ結果になります。

各SLAポリシーに設定するフィルター条件によって、どのチケットにどのサービスレベル契約が適用されるかが決まります。これを正しく設定すると、チームは明確で達成可能な目標を持つことができます。間違えると、過剰な約束をするか、期待を下回る結果になります。

このガイドでは、Zendesk SLAポリシーのフィルター条件について知っておく必要のあるすべてのことを説明します。利用可能な条件タイプ、さまざまなシナリオに合わせて条件を構成する方法、SLAがあなたのために機能し、あなたに逆らわないようにするためのベストプラクティスを学びます。

Zendesk SLAポリシーのフィルター条件とは？

SLAポリシーのフィルター条件とは、特定のサービスレベル契約がどのチケットに適用されるかを決定するルールです。これらをゲートキーパーと考えてください。チケットが条件に一致すると、SLAポリシーがアクティブになり、その目標に対する追跡が開始されます。

Zendeskのすべてのフィルター条件は、チェックするフィールド、比較する演算子、および一致させる値という同じ構造に従います。次のようになります。

{ "field": "type", "operator": "is", "value": "incident" }

フィルターは、次の2つのロジック配列に編成されます。

配列 (Array)	ロジック (Logic)	意味 (What it means)
all	AND	チケットが一致するには、この配列のすべての条件がtrueである必要があります
any	OR	チケットが一致するには、この配列の少なくとも1つの条件がtrueである必要があります

SLAポリシーの順序は重要です。Zendeskは上から下へ評価し、条件が一致する最初のポリシーを適用します。つまり、最も具体的なポリシーを一番上に置き、より広範な包括的なポリシーを一番下に置く必要があります。

ポリシーメトリクスは、実際に測定するものを定義します。最初の応答時間、次の応答時間、解決時間などです。各メトリクスは、チケットの優先度に基づいて異なるターゲットを持つことができます。また、営業時間のみをカウントするか、24時間体制でカレンダー時間をカウントするかを選択することもできます。

利用可能なZendesk SLAポリシーのフィルター条件タイプ

Zendeskは、チケットをターゲットにするための広範な条件を提供します。これらは、ビジネスルール（トリガー、自動化、ビュー、およびSLA）全体で共有される条件と、SLAポリシーに固有の条件の2つのカテゴリに分類されます。完全な技術的な詳細については、Zendesk Conditions Referenceを参照してください。

共有条件

これらの条件は、SLAポリシー、トリガー、自動化、およびビュー全体で機能します。

フィールド (Field)	演算子 (Operators)	フィルター対象 (What it filters)
group_id	is, is_not	特定のエージェントグループに割り当てられたチケット
assignee_id	is, is_not	特定のエージェントに割り当てられたチケット
requester_id	is, is_not	特定のリクエスターからのチケット
organization_id	is, is_not	特定の組織からのチケット
current_tags	includes, not_includes	特定のタグの有無にかかわらずチケット
via_id	is, is_not	特定のチャネルを通じて作成されたチケット
recipient	-	チケットが送信されたメールアドレス
custom_fields_{id}	is, is_not	カスタムチケットフィールドの値

SLA固有の条件

これらの条件は、SLAポリシーフィルターでのみ使用できます。

フィールド (Field)	演算子 (Operators)	フィルター対象 (What it filters)
ticket_type_id	is, is_not	質問（1）、インシデント（2）、問題（3）、またはタスク（4）
current_via_id	is, is_not	最新の更新に使用されたチャネル
exact_created_at	less_than, greater_than, etc.	チケット作成のタイムスタンプ
custom_status_id	is, is_not	カスタムチケットのステータス値

via_idとcurrent_via_idの違いに注意する価値があります。via_id条件は、チケットが最初にどのように作成されたかを確認し、current_via_idは、最新の更新がどのように行われたかを確認します。たとえば、メールとして開始されたチケットとチャットに移行されたチケットを区別する場合に重要になります。

効果的なZendesk SLAポリシーのフィルター条件を作成する方法

実際に機能するSLAポリシーを構築するには、計画が必要です。実用的なアプローチを次に示します。

ステップ1：ポリシー構造を計画する

Zendeskに触れる前に、サポート構造をマッピングします。

• どの顧客セグメントが異なる応答時間を必要としていますか？（VIP、エンタープライズ、無料ティア）
• どのチャネルが異なる期待を持っていますか？（チャットとメール）
• 異なるチケットタイプは異なる扱いを保証しますか？（インシデントと質問）
• どのチームがどのような種類の作業を処理しますか？

このマッピングがポリシー構造になります。一意の組み合わせごとに独自のポリシーが設定されます。

ステップ2：SLAポリシービルダーに移動する

Zendesk管理センターで、オブジェクトとルール>ビジネスルール>サービスレベル契約に移動します。[ポリシーを作成]をクリックして、構築を開始します。詳細な設定手順については、Zendesk SLAポリシーの公式ドキュメントを参照してください。

ステップ3：フィルター条件を構成する

まず、「すべて」の条件から始めます。これらは必須の基準です。たとえば、このポリシーがVIP顧客のみに適用される場合は、次を追加します。組織は「VIP顧客」です。

次に、オプションの基準に「いずれか」の条件を追加します。チケットに「緊急」のタグが付いている場合、または特定の組織からのものである場合に、ポリシーを適用することもできます。

一般的な条件の組み合わせには、顧客層SLAの組織ベースのフィルタリング、チーム固有の内部SLAのグループベースのフィルタリング、異なる応答の期待値のチャネルベースのフィルタリング、および柔軟なルーティングのタグベースのフィルタリングが含まれます。

ステップ4：ポリシーメトリクスを設定する

このポリシーで追跡するメトリクスを選択します。

メトリクス (Metric)	最適な用途 (Best for)
最初の応答時間 (First reply time)	最初の顧客への応答 (Initial customer acknowledgment)
次の応答時間 (Next reply time)	継続的な会話の応答性 (Ongoing conversation responsiveness)
リクエスターの待機時間 (Requester wait time)	顧客の総待機時間 (Total customer waiting time)
総解決時間 (Total resolution time)	問題の完全な解決 (Complete issue resolution)
定期的な更新時間 (Periodic update time)	長期的な調査中に顧客に情報を提供し続ける (Keeping customers informed during long investigations)

各優先度レベルのターゲットを設定します。一般的な開始点は次のとおりです。

優先度 (Priority)	最初の応答 (First reply)	次の応答 (Next reply)
緊急 (Urgent)	15分	30分
高 (High)	1時間	2時間
通常 (Normal)	4時間	8時間
低 (Low)	24時間	48時間

チームが24時間年中無休のサポートを提供していない場合は、営業時間を選択します。これにより、エージェントが実際に作業できる時間のみがカウントされるようになります。

一般的なZendesk SLAポリシーのフィルター条件の例

理論は役に立ちますが、具体的な例を使用すると実装が簡単になります。4つの一般的なシナリオを次に示します。

例1：VIP顧客ポリシー

プレミアムサポート契約を結んでいる顧客の場合：

すべての条件：

• 組織は「VIP顧客」であるか、タグに「premium-support」が含まれています

メトリクス：

優先度 (Priority)	最初の応答 (First reply)	次の応答 (Next reply)
緊急 (Urgent)	15分	30分
高 (High)	30分	1時間
通常 (Normal)	1時間	2時間

VIPチケットが一般的なポリシーの前にキャッチされるように、このポリシーをリストの一番上に配置します。

例2：チャネル固有のポリシー

チャネルが異なれば、期待も異なります。チャットでの会話は、メールよりも迅速な応答が必要です。

メッセージングポリシー（すべての条件）：

• Viaは「チャット」またはViaは「メッセージング」

メールポリシー（すべての条件）：

• Viaは「メール」

メッセージングのターゲットをメールよりも積極的に設定します。顧客はチャットではほぼ瞬時の応答を期待しますが、メールではより辛抱強く待つことができます。

例3：グループSLAを使用した内部チームSLA

グループSLAは、顧客向けのメトリクスではなく、内部チームのパフォーマンスを追跡します。エンタープライズプランでのみ利用できます。

グループSLAフィルター：

• グループは「Tier 2 Support」

グループSLAで使用できる唯一のメトリクスは、グループ所有時間です。これは、チケットが解決または再割り当てされる前に、そのグループに留まる時間を測定します。

例4：インシデントのエスカレーションパス

重大なインシデントには、厳密な追跡が必要です。

すべての条件：

• 優先度は「緊急」であり、タイプは「インシデント」です

解決前でも顧客が進行状況の更新を受け取るように、定期的な更新ターゲットを追加します。

Zendesk SLAポリシーのフィルター条件のベストプラクティスとトラブルシューティング

十分に計画されたSLAポリシーでも、問題が発生する可能性があります。一般的な落とし穴を回避する方法を次に示します。

ポリシーの順序付け

最も一般的な間違いは、ポリシーの順序付けが不適切なことです。Zendeskは最初に一致するポリシーを適用し、検索を停止することを忘れないでください。VIP顧客向けの特定のポリシーがある場合は、一般的な「すべてのチケット」ポリシーの前に表示する必要があります。

推奨される順序：

1. VIP/エンタープライズ顧客ポリシー
2. 特定のチャネルポリシー（チャット、電話）
3. 特定のチケットタイプポリシー（インシデント）
4. 一般的なポリシー（包括的）

適切な順序付けにより、適切なチケットが適切なサービスレベルを取得できるようになります。

SLAでのトリガーの使用

効果的なパターンの1つは、SLA評価の前にトリガーを使用してチケットの優先度を設定することです。これにより、SLA条件が簡素化されます。

たとえば、次の場合は優先度を「緊急」に設定するトリガーを作成します。

• 件名に「停止」が含まれているか
• 組織は「VIP顧客」です

次に、SLAポリシーは、複雑な条件の組み合わせを管理するのではなく、優先度でフィルタリングするだけです。

ライブに移行する前にテストする

新しいSLAポリシーをアクティブ化する前に、必ずサンプルチケットでテストしてください。以下を確認してください。

• 適切なチケットが適切なポリシーに一致する
• ポリシーが正しい順序で適用されている
• ターゲットが過去のデータに基づいて現実的である

一般的な問題と解決策

問題 (Issue)	考えられる原因 (Likely cause)	解決策 (Solution)
ポリシーが適用されない (Policy not applying)	順序またはロジックエラーが間違っている (Wrong order or logic error)	より具体的なポリシーが最初に表示されることを確認します。AND/ORロジックを確認します
複数のポリシーが適用されているように見える (Multiple policies seem to apply)	最初の試合のみがカウントされます (Only first match counts)	順序を確認します。条件が広すぎるかどうかを検討します
SLAクロックが間違っているように見える (SLA clock seems wrong)	営業時間の設定ミス (Business hours misconfiguration)	スケジュールの割り当てと営業時間の設定を確認します
グループSLAの競合 (Group SLA conflicts)	通常のSLAとグループSLAの混同 (Confusion between regular and Group SLAs)	これらは個別に追跡されることを忘れないでください。グループSLAは所有時間のみを測定します

追加のトラブルシューティングのヒントについては、これらのSLAポリシーのベストプラクティスを確認してください。

AIを使用した大規模なSLAの管理

サポート業務が拡大するにつれて、SLAポリシーを手動で管理することが難しくなります。パフォーマンスを監視し、傾向を特定し、実際のデータに基づいてターゲットを調整する必要があります。

これは、AI搭載ツールが役立つ場所です。eesel AIでは、インテリジェントな自動化を通じてサポート業務をより効率的にすることに特化しています。

当社のAIは、チケットの内容を分析し、SLA評価の前に優先度の調整を自動的に提案できます。手動トリガーのみに依存する代わりに、AIはチケットのコンテキストを読み取り、見逃される可能性のある緊急信号を識別します。

SLA違反に苦労しているチームのために、当社のプラットフォームは、ターゲットが見逃される前に、違反後にではなく、プロアクティブなアラートを提供します。これにより、エージェントは違反に対応するのではなく、適切なチケットを優先する時間を得ることができます。

Zendeskと直接統合するため、AIレイヤーが上に追加のインテリジェンスを追加している間、既存のSLAポリシーは引き続き機能します。AIがSLA管理をどのように最適化できるかに関心がある場合は、AI Agentの機能の詳細をご覧ください。

Zendesk SLAを最大限に活用する

適切に構成されたSLAポリシーは、サポートチームの運用方法を変革します。あいまいな「迅速に対応する」という指示を、明確で測定可能なターゲットに置き換えます。リーダーシップにパフォーマンスの可視性を提供します。そして、チームが常に満たすことができる顧客の期待を設定します。

設定するフィルター条件が基礎となります。時間をかけて適切に計画し、徹底的にテストし、パフォーマンスデータに基づいて定期的に確認してください。

サポート業務をさらに進めたい場合は、AIが既存のZendesk設定をどのように拡張できるかを検討してください。eesel AIは、チームがヘッドカウントを比例的に増やすことなく、増え続けるサポートボリュームを処理できるようにするために構築されました。eeselを無料で試すか、デモを予約するして、特定のワークフローでどのように機能するかを確認できます。