すべてのサポートチケットが同じ応答時間を受けるに値するわけではありません。パスワードのリセットと完全なシステム停止は、非常に異なるエスカレーションパスをたどる必要があります。しかし、どちらも同じ優先度でキューに到着する可能性があります。これを間違えると、怒った顧客、SLAの未達、そして燃え尽きたエージェントにつながります。
Zendeskで優先度別にエスカレーションパスを設定することで、緊急の問題が適切な担当者にすぐに届き、ルーチンリクエストが標準のワークフローに従うようになります。このガイドでは、基本的なトリガーから高度な自動化まで、優先度に基づいたエスカレーションの設定について説明します。
Zendeskにおける優先度に基づいたエスカレーションについて
Zendeskには、低、普通、高、緊急の4つの優先度レベルがあります。それぞれが、問題の緊急度と影響に基づいて異なるエスカレーション動作をトリガーする必要があります。
ほとんどのチームが優先度をエスカレーションの応答にマッピングする方法は次のとおりです。
- 緊急 (Urgent): 重要な停止、セキュリティ侵害、またはビジネスオペレーションを停止させるもの。これらは標準キューを完全にバイパスし、マネージャーにすぐに通知する必要があります。
- 高 (High): 複数のユーザーまたは主要な機能に影響を与える重大な問題。数時間以内に上級エージェントまたは専門チームにエスカレーションします。
- 普通 (Normal): 解決が必要だが、作業を妨げるものではない標準のサポートリクエスト。標準の階層型エスカレーションに従います。
- 低 (Low): 一般的な質問と機能リクエスト。最小限のエスカレーションで、最初に利用可能なエージェントによって処理されます。
重要なのは一貫性です。あるエージェントが「ログインできない」を緊急とマークし、別のエージェントが普通とマークした場合、メトリクスは意味をなさなくなり、顧客は大きく異なるエクスペリエンスを得ることになります。そこで、明確なエスカレーションパスが全員の連携を支援します。
優先度、緊急度、影響のフレームワークの詳細については、チケットの優先順位付けに関する完全なガイドをご覧ください。
知っておくべき4つのタイプのエスカレーションパス
設定を行う前に、完全なシステムで連携する4つのエスカレーションタイプを理解してください。
機能的なエスカレーション (Functional escalation) は、必要な専門知識に基づいてチケットをルーティングします。技術的な問題は、一般的なサポートエージェントからエンジニアに移動します。請求に関する質問は、財務チームに送られます。エスカレーションパスは、階層ではなく、必要なスキルによって異なります。
階層的なエスカレーション (Hierarchical escalation) は、チケットを権限のチェーンに沿って移動させます。顧客がスーパーバイザーを要求した場合、またはエージェントが払い戻しを承認する権限を持っていない場合、チケットはより多くの意思決定権を持つ人にエスカレーションされます。
自動化されたエスカレーション (Automated escalation) は、時間ベースのルールとSLAのしきい値を使用して、人的介入なしにチケットを移動させます。高い優先度のチケットが4時間未解決のままになっている場合、自動化によって緊急に引き上げられ、チームリーダーに通知されます。
優先度のエスカレーション (Priority escalation) は、緊急度に基づいてチケットを迅速に処理します。緊急のチケットは、最前線のキューを完全にスキップし、上級エージェントまたは専門チームに直接送られます。これは、ほとんどの人が優先度別のエスカレーションパスについて話すときに意味することです。
ほとんどのチームは、4つのタイプすべてを一緒に使用します。チケットは、機能的なエスカレーション（技術チームへのルーティング）から始まり、SLAが危険にさらされると自動化されたエスカレーションがトリガーされ、顧客がマネージャーを要求すると階層的なエスカレーションで終わる可能性があります。
Zendeskで優先度に基づいたトリガーを設定する
トリガーは、優先度に基づいたエスカレーションの最初の防御線です。チケットが作成または更新されたときにすぐに発動し、緊急の問題をキューに置かれる前にルーティングします。
ステップ1：トリガー設定にアクセスする
管理センター (Admin Center) → オブジェクトとルール (Objects and rules) → ビジネスルール (Business rules) → トリガー (Triggers) に移動します。既存のトリガーのリストが表示されます。トリガーを追加 (Add trigger) をクリックして、新しいトリガーを作成します。
ステップ2：優先度に基づいたルーティングトリガーを作成する
優先度レベルに基づいてチケットを自動的にルーティングするトリガーを設定します。
次のすべての条件を満たす (Meet ALL of the following conditions) の下：
- チケット (Ticket) | 次の状態である (Is) | 作成された (Created)
- 優先度 (Priority) | 次の状態である (Is) | 緊急 (Urgent)
アクション (Actions) の下：
- グループ (Group) | サポートマネージャー (Support Managers)（またはエスカレーショングループ）
- タグを追加 (Add tags) | urgent_escalation
- 通知 (Notifications) | メールグループ (Email group) | サポートマネージャー (Support Managers)
上級エージェントグループにルーティングする高い優先度のチケットに対して、同様のトリガーを作成します。重要なのは、エスカレーションされたチケットを受け取る準備ができている専用のグループを用意することです。
ステップ3：VIP顧客トリガーを設定する
優先度は問題だけでなく、誰が報告したかにも関係します。VIP顧客のトリガーを設定します。
次のすべての条件を満たす (Meet ALL of the following conditions) の下：
- チケット (Ticket) | 次の状態である (Is) | 作成された (Created)
- 組織 (Organization) | 次の状態である (Is) | VIP顧客 (VIP Customers)（またはVIP組織名）
アクション (Actions) の下：
- 優先度 (Priority) | 高 (High)
- グループ (Group) | VIPサポートチーム (VIP Support Team)
- タグを追加 (Add tags) | vip_customer
これにより、最も価値のある顧客が、リクエストの言い回しに関係なく、適切な注意を払うようになります。VIP顧客ワークフローの詳細については、詳細な設定ガイドをご覧ください。
時間ベースのエスカレーション自動化を構築する
トリガーは即時のルーティングを処理します。自動化は、チケットが古くなった場合に何が起こるかを処理します。これにより、最初に重要としてフラグが立てられなかったために、チケットが未解決のままになるのを防ぎます。
ステップ1：SLAを認識した自動化を作成する
管理センター (Admin Center) → オブジェクトとルール (Objects and rules) → ビジネスルール (Business rules) → 自動化 (Automations) に移動します。トリガーとは異なり、自動化はスケジュール（1時間ごと）で実行され、時間ベースの条件を確認します。
ステップ2：「次のSLA違反までの時間」アラートを設定する
SLAが破られる前にチームに警告する自動化を作成します。
次のすべての条件を満たす (Meet ALL of the following conditions) の下：
- 次のSLA違反までの時間 (Hours until next SLA breach) | 次より少ない (Less than) | 2
- ステータスカテゴリ (Status category) | 次より少ない (Less than) | 解決済み (Solved)
- タグ (Tags) | 次のいずれも含まない (Contains none of the following) | sla_warning_sent
アクション (Actions) の下：
- 通知 (Notifications) | メールグループ (Email group) | （エスカレーショングループ）
- タグを追加 (Add tags) | sla_warning_sent
このタグは、自動化がチームに毎時間スパムを送信するのを防ぎます。SLAベースのエスカレーション自動化の詳細については、自動化ガイドをご覧ください。
ステップ3：優先度に基づいた時間エスカレーション
チケットが長期間放置された場合に優先度を上げる自動化を作成します。
通常の優先度のエスカレーションの場合：
- 作成からの時間 (Hours since created) | 次より大きい (Greater than) | 24
- 優先度 (Priority) | 次の状態である (Is) | 普通 (Normal)
- ステータス (Status) | 次の状態である (Is) | オープン (Open)
アクション (Actions)：
- 優先度 (Priority) | 高 (High)
- タグを追加 (Add tags) | auto_escalated
4時間後に緊急にエスカレーションする高いチケットに対して、同様の自動化を作成します。これにより、最初に緊急ではなかったという理由だけで、何も忘れられないようになります。Zendeskの自動化とその制限の詳細については、詳細な概要をご覧ください。
SLAをエスカレーションパスに接続する
SLAは、チケットへの応答と解決を約束する速さを定義します。エスカレーションパスは、これらのコミットメントと一致する必要があります。
一般的なSLAターゲットが優先度レベルにマッピングされる方法は次のとおりです。
| 優先度 (Priority) | 最初の応答 (First Response) | 解決時間 (Resolution Time) | エスカレーションのトリガー (Escalation Trigger) |
|---|---|---|---|
| 緊急 (Urgent) | 15〜60分 | 2〜4時間 | 即時マネージャー通知 |
| 高 (High) | 1〜4時間 | 8時間 | SLA経過時間の50％後にエスカレーション |
| 普通 (Normal) | 4〜12時間 | 24時間 | 24時間後にエスカレーション |
| 低 (Low) | 24時間 | 5営業日 | 自動エスカレーションなし |
SLAポリシーを設定するには、管理センター (Admin Center) → オブジェクトとルール (Objects and rules) → サービスレベルアグリーメント (Service level agreements) に移動します。適切なターゲットを使用して、優先度層ごとに個別のポリシーを作成します。
重要な統合ポイント：「最後のSLA違反からの時間」ではなく、自動化で「次のSLA違反までの時間」を使用します。前者は違反が発生する前に警告します。後者は、すでに失敗した後にのみ通知します。
完全なチュートリアルについては、Zendesk SLAポリシーの作成に関するガイドをご覧ください。
チームのエスカレーションビューを作成する
ビューは、エスカレーションされたチケットを管理するためのチームのダッシュボードです。エージェントが注意が必要なものを正確に把握できるように、専用のビューを設定します。
緊急/高い優先度キュー (Urgent/High priority queue)：優先度が緊急または高いすべてのチケットを表示し、次のSLA違反が昇順で並べ替えられます。これにより、最も時間的に重要なチケットが一番上に表示されます。
エスカレーションされたチケットビュー (Escalated tickets view)：エスカレーションタグ（「urgent_escalation」や「auto_escalated」など）でチケットをフィルタリングします。これにより、特別な処理のためにエスカレーションされたすべてのもののクリーンなリストが得られます。
VIP顧客ビュー (VIP customer view)：VIP組織からのチケットを作成日で並べ替えて表示します。上級エージェントは、これを1日を通して監視できます。
期限切れのエスカレーションビュー (Overdue escalations view)：SLAがすでに違反しているチケットをフィルタリングします。これらは、即時の注意と場合によっては管理者の関与が必要です。
これらのビューを管理センター (Admin Center) → ワークスペース (Workspaces) → エージェントツール (Agent tools) → ビュー (Views) で作成します。適切なグループと共有して、すべての人が自分の役割にとって重要なものを確認できるようにします。
一般的なエスカレーションの間違いとその回避方法
完璧な設定でも、人的要因がエスカレーションシステムを壊す可能性があります。
ルーチン問題を過剰にエスカレーションする (Over-escalating routine issues) と、チームはエスカレーションを無視するように訓練されます。他のすべてのチケットが緊急とマークされている場合、何も緊急ではありません。各優先度レベルの明確な基準を定義し、エージェントに責任を負わせます。
引き継ぎ中にコンテキストが欠落している (Missing context during handoffs) と、顧客は不満を感じ、解決が遅れます。チケットがエスカレーションされると、受信エージェントは必要なものをすべて持っている必要があります。内部メモを使用して、試行されたことと顧客が期待することを文書化します。
エスカレーションメトリクスを追跡しない (Not tracking escalation metrics) と、改善できません。エスカレーション率（成熟したチームの場合は15〜20％を目指す）、優先度別の平均解決時間、SLA違反率を監視します。緊急チケットがSLAを常に逃している場合は、より良いルールではなく、より多くの上級エージェントが必要です。
顧客に通知しない (Failing to notify customers) と、不安が生じます。チケットをエスカレーションするときは、何が起こったのか、いつ更新が期待できるかを顧客に伝えます。沈黙は、彼らの問題がドロップされたと思わせます。
AI自動化によるエスカレーションの合理化
手動での優先度の割り当てとルーティングは、小規模なチームに適しています。ボリュームが増加するにつれて、キーワードだけでなくコンテキストを理解するシステムが必要です。
当社のAIトリアージ (AI Triage)は、チケットの内容、感情、顧客履歴を分析して、優先度を提案または自動的に設定します。キーワードトリガーが見逃すニュアンスをキャッチします。たとえば、VIP顧客からの「料金について少し心配している」は、無料トライアルユーザーからの同じメッセージよりも高い優先度を保証する場合があります。
AIは、過去のチケット解決とエージェントのアクションから学習し、時間の経過とともに推奨事項を改善します。Zendeskと直接統合して、既存の優先度ワークフローを置き換えることなく強化します。
また、AIエージェント (AI Agent)を展開して、エスカレーションが必要になる前にルーチン問題を処理することもできます。一般的なリクエストを自律的に解決し、人間の注意を本当に必要とするものだけを、完全にコンテキストを保持したままエスカレーションします。
よくある質問
この記事を共有
Article by
Stevia Putri
Stevia Putri is a marketing generalist at eesel AI, where she helps turn powerful AI tools into stories that resonate. She’s driven by curiosity, clarity, and the human side of technology.
