Zendesk SLA違反時にマネージャーに通知する方法:完全ガイド

Stevia Putri

Stanley Nicholas
Last edited 2026 2月 20
Expert Verified
サポートチケットがSLAに違反しようとしている場合、1分1秒が重要になります。しかし、Zendeskでは、手遅れになる前にマネージャーに通知したり、緊急チケットをエスカレーションしたりする方法が明確ではありません。
誰もチケットが放置されていることに気づかなかったために、貴重な顧客を失う可能性があります。または、回復するには手遅れな、違反が発生してから数時間後にSLA違反を発見するかもしれません。
幸いなことに、チケットがSLA制限に近づいているときにチームに警告する自動通知を設定できます。このガイドでは、単純な自動化から高度な統合まで、Zendesk SLA違反についてマネージャーに通知する3つの方法について説明します。

Zendesk SLA違反通知について
設定に入る前に、何に取り組んでいるのかを明確にしましょう。ZendeskのSLAポリシーは、チケットの優先度に基づいて応答と解決の目標を定義します。チームがこれらの時間枠内に応答しない場合、SLAは違反します。
ネイティブのZendeskはSLAパフォーマンスを追跡しますが、問題が発生した場合にマネージャーに積極的に通知することはありません。エージェントはチケットビューでSLAタイマーを確認できますが、マネージャーはレポートを実行するか、顧客が不満を言うまで問題について知らないことがよくあります。
この可視性のギャップが、通知ワークフローが重要な理由です。違反が発生した後で発見する代わりに、チームが行動する時間を与えるアラートを取得できます。選択するアプローチは、チームの規模、技術リソース、およびどれだけ緊急に対応する必要があるかによって異なります。
方法1:SLAアラートにZendesk自動化を使用する
最も一般的なアプローチは、Zendesk自動化を使用することです。これらは、時間ベースのビジネスルールであり、1時間ごとに条件を確認し、満たされた場合に行動を起こします。
**理解すべき重要な制限:**自動化は1時間に1回実行されます。つまり、SLAが違反した正確な瞬間に通知を受けることはできません。条件が満たされてから1時間以内に通知されます。

ステップ1:新しい自動化を作成する
管理センター(Admin Center) > オブジェクトとルール(Objects and rules) > ビジネスルール(Business rules) > **自動化(Automations)**に移動し、**自動化を追加(Add automation)**をクリックします。
他の管理者がその目的を理解できるように、「SLA違反が近づいていることをチームに通知する」のような明確な名前を付けます。
ステップ2:条件を設定する
**次のすべての条件を満たす場合(Meet all of the following conditions)**で、次の条件を追加します。
| 条件(Condition) | 演算子(Operator) | 値(Value) |
|---|---|---|
| チケット:次のSLA違反までの時間(Ticket: Hours until next SLA breach) | より少ない(Less than) | 2 |
| チケット:ステータスカテゴリ(Ticket: Status category) | より少ない(Less than) | 解決済み(Solved) |
| チケット:タグ(Ticket: Tags) | 次のいずれも含まない(Contains none of the following) | sla_alert |
**次のSLA違反までの時間(Hours until next SLA breach)**条件が重要です。必要な警告の量に基づいて、値(この例では2時間)を変更します。緊急のチケットの場合は、1時間が必要になる場合があります。通常の優先度の場合は、4時間が有効な場合があります。
**ステータスカテゴリが解決済みより少ない(Status category Less than Solved)**条件が必要です。自動化は、この条件または同様の条件(特定のタイプ、グループ、または担当者条件など)なしでは保存されません。
**タグ条件(Tags condition)**は、重複した通知を防ぎます。自動化が起動するとsla_alertタグを追加するため、同じチケットで再度実行されることはありません。
ステップ3:通知アクションを設定する
**次のアクションを実行する(Perform these actions)**で、以下を追加します。
グループメール通知の場合:
- 通知:グループメール(Notifications: Group email)| (割り当てられたグループ)(assigned group)
- メール件名:
SLA違反間近:{{ticket.id}} - メール本文:
これは、あなたのグループに割り当てられたチケットが
SLA違反時間に近づいていることを通知するものです。
チケット:{{ticket.link}}
SLA違反までの残り時間:2時間未満
迅速に解決または対処されるように、このチケットを優先してください。
個々のマネージャー通知の場合:
- 通知:ユーザーメール(Notifications: User email)| (特定のマネージャーを選択)(select specific manager)
重複排除タグを追加します:
- チケット:タグを追加(Ticket: Add tags)|
sla_alert
このタグにより、自動化がチケットごとに1回だけ起動することが保証されます。これがないと、マネージャーは同じチケットについて1時間ごとに通知を受け取ることになります。
ステップ4:違反後の通知を作成する(オプション)
SLAがすでに違反している場合も知りたい場合があります。次の条件で2番目の自動化を作成します。
| 条件(Condition) | 演算子(Operator) | 値(Value) |
|---|---|---|
| チケット:最後のSLA違反からの時間(Ticket: Hours since last SLA breach) | より少ない(Less than) | 1 |
| チケット:ステータスカテゴリ(Ticket: Status category) | より少ない(Less than) | 解決済み(Solved) |
| チケット:タグ(Ticket: Tags) | 次のいずれも含まない(Contains none of the following) | sla_breach_alert |
違反がすでに発生したチケットを追跡するには、別のタグ(sla_breach_alert)を使用します。これは、緊急の対応が必要なチケットと、違反後の顧客コミュニケーションを特定するのに役立ちます。
方法2:マネージャー固有のエスカレーションワークフロー
基本的な自動化はすべての人に通知します。しかし、エージェントとマネージャーで異なるアラートが必要な場合はどうでしょうか?または、エージェントに最初に警告し、何も起こらない場合はマネージャーに警告するエスカレーションチェーンはどうでしょうか?
ステップ1:グループベースの通知を設定する
すべての人に通知する代わりに、通知を特定のグループにルーティングします。Zendeskでは、「マネージャー(Managers)」グループを作成するか、既存のチームリーダーグループを使用できます。
自動化アクションを設定する場合:
- 通知:グループメール(Notifications: Group email) | マネージャー(Managers)(割り当てられたグループの代わりに)
これにより、チーム全体ではなく、マネージャーのみがアラートを受信することが保証されます。
ステップ2:タグを使用してエスカレーションチェーンを構築する
高度なエスカレーションのために、異なる時間に起動する複数の自動化を作成します。
自動化1:エージェント警告(違反の4時間前)
- 条件:次のSLA違反までの時間(Condition: Hours until next SLA breach)| より少ない(Less than)| 4
- アクション:割り当てられたエージェントにメールを送信(Action: Email assigned agent)
- タグ:
sla_agent_alert
自動化2:マネージャーエスカレーション(違反の1時間前)
- 条件:次のSLA違反までの時間(Condition: Hours until next SLA breach)| より少ない(Less than)| 1
- 条件:タグ(Condition: Tags)| 含む(Contains)| sla_agent_alert(エージェントがすでに通知されていることを確認)
- アクション:マネージャーグループにメールを送信(Action: Email manager group)
- タグ:
sla_manager_alert
このパターンにより、マネージャーが関与する前に、エージェントがチケットを解決する時間を与えます。エージェントが4時間以内にチケットを処理した場合、マネージャーはアラートを受け取りません。
ステップ3:カスタムフィールドを使用して高度なルーティングを行う
さらに制御するために、「エスカレーションティア(Escalation Tier)」というカスタムドロップダウンフィールドを作成し、次のような値を使用します。
- 標準(チームリーダーに通知)(Standard (notify team lead))
- VIP(マネージャーにすぐに通知)(VIP (notify manager immediately))
- クリティカル(ディレクター+マネージャーに通知)(Critical (notify director + manager))
次に、自動化に条件を追加します。
- チケット:エスカレーションティア(Ticket: Escalation Tier)| である(Is)| VIP
これにより、同じ自動化フレームワーク内で、異なる顧客を異なるエスカレーションパスにルーティングできます。
「SLA違反前のトリガー(Triggers before SLA breach)」機能の使用
最近、Zendeskは、トリガー(すぐに起動する)がSLA条件で動作することを可能にする新しい機能を展開しています。これにより、自動化による1時間の遅延の問題が解決されます。
Zendeskインスタンスを確認してください:管理センター(Admin Center) > オブジェクトとルール(Objects and rules) > ビジネスルール(Business rules) > **トリガー(Triggers)**に移動し、SLA関連の条件を探します。トリガーで「次のSLA違反までの時間(Hours until next SLA breach)」が利用可能な場合は、1時間ごとのバッチの代わりにリアルタイム通知を使用できます。
設定は自動化と似ていますが、トリガーは条件が満たされるとすぐに起動します。これにより、1時間ごとのケイデンスの制限ではなく、真のリアルタイムエスカレーションが可能になります。
方法3:Slackおよびサードパーティ統合
メール通知は埋もれてしまいます。チームがSlackを使用している場合は、代わりに(またはメールに加えて)アラートが必要になる場合があります。
オプションA:ネイティブZendesk Slack統合
ZendeskはSlackと接続するネイティブのSlack統合を提供していますが、SLA通知には制限があります。チケットイベントについて通知できますが、SLA固有のしきい値アラートは組み込まれていません。
Slackで基本的なチケット通知が必要な場合は、これでうまくいきます。SLA違反警告の場合は、より高度なものが必要になります。
オプションB:しきい値ベースのSlackアラート用のGeckoboard
GeckoboardはZendeskに接続し、定義したしきい値をメトリックが超えたときにSlackに通知をプッシュします。
設定プロセス:
- ZendeskアカウントをGeckoboardに接続します
- 監視するメトリック(「SLA違反が近づいているチケット」など)を示すウィジェットを作成します
- 警告しきい値を定義するステータスインジケーターを設定します
- **Slack通知を追加(Add Slack notification)**をクリックして、アラートをチャネルにルーティングします
メトリックがステータスインジケーターに違反すると、通知はすぐにSlackに送信されます。
Slack通知のユースケース:
- キューボリュームアラート:「オープンチケットが15を超える場合にアラート(Alert when open tickets > 15)」
- 応答時間アラート:平均初回応答時間がターゲットを超えた場合に通知する
- SLA違反アラート:SLAターゲットに近づいている、または違反しているチケットを監視する
- 満足度アラート:CSATがしきい値を下回った場合に追跡する
ここでの利点は、しきい値ベースのインテリジェンスです。すべてのチケットの更新についてpingされる代わりに、チームは運用メトリックが実際に注意を必要とする場合にのみアラートを受け取ります。
オプションC:クリティカルなエスカレーションのためのPagerDuty
(特に営業時間外に)即時の人的対応が必要な緊急のSLA違反の場合、PagerDuty統合が理にかなっています。この設定には、より多くの技術的な構成が必要ですが、真のエスカレーション管理を提供します。
ステップ1:ZendeskでHTTPターゲットを作成する
管理センター(Admin Center) > 設定(Settings) > 拡張機能(Extensions) > **ターゲットを追加(Add target)**に移動します
- 名前:PagerDuty
- URL:
https://events.pagerduty.com/v2/enqueue - メソッド:POST
- コンテンツタイプ:JSON
ステップ2:ターゲットに通知するトリガーを作成する
エスカレーションするタイミングの条件を設定します(たとえば、チケットが「SLA違反」グループに移動された場合)。
アクションで、次を選択します。
- 通知:ターゲットに通知(Notifications: Notify target)| PagerDuty
JSON本文:
{
"dedup_key": "{{ticket.id}}",
"routing_key": "YOUR_PAGERDUTY_ROUTING_KEY",
"event_action": "trigger",
"payload": {
"summary": "SLA違反:{{ticket.title}}",
"source": "Zendesk",
"severity": "critical",
"custom_details": {
"priority": "{{ticket.priority}}",
"ticket_id": "{{ticket.id}}",
"requester": "{{ticket.requester.name}}"
}
},
"client_url": "{{ticket.link}}",
"client": "Zendesk"
}
PagerDutyは、オンコールルーティング、エスカレーションポリシーを処理し、必要に応じて誰かが起こされるようにします。
オプションD:D7 Networks経由のSMS
(特に常にコンピューターの前にいるとは限らないマネージャーに)SMSアラートが必要なチームの場合、D7 Networksは、Zendesk SLAが違反した場合にSMSを送信できるActiveCampaign統合を提供しています。
ワークフロー:
- ZendeskチケットSLAが違反する
- ActiveCampaignワークフローがトリガーされる
- D7 Networksがマネージャーの電話にSMSを送信する
- メッセージには、チケットIDと簡単な詳細が含まれています
SMSの例:アラート:チケット#12345がSLAに違反しました。至急対応が必要です。
これは、メールやSlackが見過ごされる可能性のある営業時間外のクリティカルなサポートに特に役立ちます。
よくある間違いとトラブルシューティング
適切な設定でも、うまくいかないことがあります。最も一般的な問題は次のとおりです。
重複した通知が受信トレイに殺到する タグ条件とタグアクションを追加するのを忘れました。通知を送信するすべての自動化には、タグを使用した重複排除ロジックが必要です。条件が「次のいずれも含まない(Contains none of the following)」と表示され、アクションが同じタグを追加することを確認してください。
自動化がまったく起動しない Zendeskには、少なくとも1つの時間ベースの条件または条件を無効にするアクションが必要です。次のいずれかがあることを確認してください。
- ステータスカテゴリ(Status category)| より少ない(Less than)| 解決済み(Solved)
- またはタイプ/グループ/担当者条件(Type/Group/Assignee condition)
- さらに、その値を変更する対応するアクション
通知が遅れて到着する 自動化は1時間ごとに実行されることを忘れないでください。「違反まで1時間未満(Less than 1 hour until breach)」を設定した場合、通知は違反がすでに発生した後に到着する可能性があります。1時間の遅延を考慮してしきい値を設定してください。
トリガーと自動化の混同 トリガーは、チケットイベントですぐに起動します。自動化は、1時間ごとに条件を確認します。SLA通知の場合、通常は自動化が必要です(新しい「SLA違反前のトリガー(Triggers before SLA breach)」機能が有効になっている場合を除く)。
設定のテスト これらの通知に依存する前に、常にサンプルチケットでテストしてください。
- テストチケットを作成する
- SLAポリシーをトリガーするように優先度を設定する
- 自動化が実行されるのを待つ(または「一致のプレビュー(Preview match)」機能を使用する)
- 通知が受信されたことを確認する
- 重複を防ぐためにタグが追加されたことを確認する
AI自動化によるSLA違反の防止
通知はリアクティブです。本当の目標は、違反を完全に防止することです。ここでeesel AIが登場します。

eesel AIでは、最前線のサポートを自動的に処理するためにZendeskと直接統合するAIチームメイトを構築しました。違反が近づいているチケットについて警告するだけでなく、AIエージェントは数秒以内にお客様に応答します。eeselを設定する必要はありません。採用すると、数週間ではなく数分でビジネスを学習します。
仕組みは次のとおりです。
即時の初回応答により、FRT違反が解消される パスワードのリセット、注文状況、または一般的なトラブルシューティングの質問に関するチケットが届くと、AIエージェントは数秒以内に応答します。これらのチケットの初回応答時間は事実上ゼロになります。
AIコパイロットが解決時間を短縮する 人間のエージェントを必要とする複雑な問題の場合、AIコパイロットは、ヘルプセンター、過去のチケット、および接続された知識ソースから取得して応答を下書きします。エージェントは回答を探す時間を短縮し、実際に問題を解決する時間を増やします。

シミュレーションモードで移行のリスクを軽減する 本番稼働する前に、eesel AIを過去のチケットで実行して、そのパフォーマンスを正確に確認できます。お客様がAI応答を見る前に、SLAメトリックへの影響を測定します。
その結果、SLA制限に近づくチケットが最初に少なくなります。通知は、主要な防御策ではなく、バックアップになります。
eesel AIは数分でZendeskに接続します。既存のチケットとマクロからトーンを学習するため、応答は一般的なチャットボットではなく、チームのように聞こえます。また、シミュレーションモードを使用すると、自動応答を有効にする前に、実際のチケット履歴でパフォーマンスを確認できます。
今すぐSLA違反通知を設定する
Zendesk SLA違反についてマネージャーに通知するための3つのアプローチができました。
-
ネイティブ自動化は、ほとんどのチームで機能します。これらは無料で、組み込みであり、基本的なエスカレーションを処理します。ただし、1時間の遅延制限を覚えておいてください。
-
マネージャー固有のワークフローにより、より細かく制御できます。グループルーティングとエスカレーションチェーンを使用して、適切な人に適切なタイミングで通知します。
-
Slack、PagerDuty、SMSなどのサードパーティ統合は、メールだけでは不十分な場合に、リアルタイムアラートと営業時間外の対応を提供します。
どれを選択する必要がありますか?小規模なチームと営業時間内の対応がある場合は、ネイティブ自動化から開始します。より迅速な対応または24時間365日のエスカレーションが必要な場合は、SlackまたはPagerDuty統合を追加します。また、SLAリスクに達するチケットの数を減らしたい場合は、eesel AIを検討してください。
重要なのは、明日のレポートで違反を発見するのではなく、違反が発生する前に可視性を得ることです。今週通知を設定し、いくつかのチケットでテストして、チームに必要な早期警告システムを提供してください。
単に追跡するのではなく、SLA違反を防止する準備はできましたか?eesel AIを無料でお試しください。AIを活用した応答が今日の初回応答時間をどのように改善できるかをご覧ください。
よくある質問
この記事を共有

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.


