Zendesk SLA が計算されない？実際に効果のある 7 つの解決策

SLA (Service Level Agreement) ポリシーを設定し、ターゲットを構成し、チケットに赤と緑のバッジが表示されることを期待していたのに、表示されなかった。あるいは、一部のチケットには表示されるが、他のチケットには表示されない。または、違反時間が完全に間違っているように見える。

これは、Zendesk (ゼンデスク) 管理者にとって最も一般的な不満の 1 つです。幸いなことに、SLA の計算問題のほとんどは、予測可能なカテゴリに分類されます。何を探すべきかを知っていれば、通常は 30 分以内に問題を診断して修正できます。

Zendesk SLA が計算されない 7 つの最も一般的な理由と、それぞれの修正方法について説明します。

クイック診断：Zendesk SLA が計算されない理由

具体的な修正に入る前に、次のチェックリストを実行して、どの問題に対処しているかを特定します。

• チケットに優先度が設定されていますか？ (「優先度」フィールドを確認)
• チケットは SLA ポリシーの条件に一致していますか？ (グループ、チャネル、タグ)
• 営業時間は正しく構成されていますか？
• チケットは SLA ポリシーが存在する前に作成されましたか？
• これはライブチャットまたはメッセージングチケットですか？
• エージェントもリクエスタですか？
• ポリシーは正しく順序付けられていますか？

これらのいずれかについて不明な点がある場合は、以下のセクションで、それぞれの確認方法と修正方法を正確に示します。

修正 1：すべてのチケットに優先度フィールドを設定する

これは、SLA が計算されない最も一般的な理由です。Zendesk SLA は、優先度レベルを中心に構築されています。ポリシーでは、緊急、高、通常、低の優先度に対して異なるターゲットを定義します。チケットに優先度が設定されていない場合、SLA はどのターゲットを適用するかを認識しません。

これが問題であるかどうかを確認する方法は次のとおりです。

1. SLA が表示されないチケットを開きます。
2. チケットのサイドバーにある「優先度」フィールドを確認します。
3. 「-」と表示されている場合、または空白の場合は、問題が見つかりました。

修正方法は、新しいチケットと既存のチケットのどちらを処理しているかによって異なります。

新しいチケットの場合： 優先度を自動的に設定するトリガーを作成します。[管理センター] > [オブジェクトとルール] > [トリガー] に移動します。チケットの作成時に発生し、「優先度」を「通常」（またはワークフローに適したデフォルト）に設定するトリガーを作成します。詳細な設定手順については、Zendesk のトリガーに関するドキュメント を参照してください。

既存のチケットの場合： 一括更新する必要があります。Zendesk の一括編集機能を使用するか、優先度が設定されていないすべてのチケットに優先度を設定する 1 回限りの自動化を作成できます。

プロのヒント：エージェントが常に手動で優先度を設定すると考えている場合でも、そのトリガーを設定してください。これは、SLA なしでチケットが抜け落ちるのを防ぐセーフティネットです。SLA の可視性の管理に関する詳細については、Zendesk ビューに SLA 列を追加する に関するガイドを参照してください。

修正 2：SLA ポリシーの条件を確認する

優先度が設定されていても、チケットがどのポリシーの条件にも一致しない可能性があります。SLA ポリシーは、条件を使用して、どのチケットに適用するかを決定します。一般的な条件は次のとおりです。

• グループの割り当て
• チャネル (メール、チャット、Web フォーム)
• タグ
• 組織

チケットがアクティブなポリシーのすべての条件を満たしていない場合、SLA は適用されません。

これをトラブルシューティングするには：

1. [管理センター] > [オブジェクトとルール] > [サービスレベルアグリーメント] に移動します。
2. アクティブな各ポリシーを開き、その条件を確認します。
3. これらの条件を、SLA が計算されないチケットと比較します。

たとえば、ポリシーに「グループはサポート」という条件があるが、チケットが「セールス」グループに割り当てられている場合、そのポリシーは適用されません。

ポリシーの順序も重要です。 Zendesk はポリシーを上から下へ評価し、最初に一致するポリシーを適用します。広範な条件を持つ一般的なポリシーが一番上にある場合、より具体的なポリシーが評価される前にチケットをキャッチしている可能性があります。

リスト内でドラッグしてポリシーの順序を変更します。最も具体的なポリシー (VIP 顧客や特定の組織向けのポリシーなど) を一番上に、包括的なポリシーを一番下に配置します。

修正 3：営業時間を正しく構成する

SLA ターゲットを設定するときは、カレンダー時間と営業時間のどちらかを選択します。この選択は、SLA の計算方法に大きな影響を与えます。

• カレンダー時間 は、24 時間年中無休ですべての時間をカウントします。
• 営業時間 は、定義されたスケジュール中のみをカウントします。

営業時間を選択したが、スケジュールを設定していない場合、またはチケットが正しいスケジュールに割り当てられていない場合、SLA は正しく計算されません。

営業時間のセットアップを確認するには：

1. [管理センター] > [オブジェクトとルール] > [営業時間] に移動します。
2. 少なくとも 1 つのスケジュールが定義されていることを確認します。
3. スケジュールに正しい曜日と時間が含まれていることを確認します。
4. 複数のスケジュールがある場合は、チケットが正しいスケジュールに割り当てられていることを確認します。

複数のスケジュール (異なるチームまたはタイムゾーン用) を使用している場合は、グループまたはその他の条件に基づいて、各チケットに正しいスケジュールを割り当てるトリガーが必要になる場合があります。

修正 4：遡及的な SLA の問題を処理する

これは、多くのアドミンを悩ませるシナリオです。今日 SLA ポリシーを設定したが、先週作成された数百枚のチケットがあるとします。これらのチケットを正しい優先度になるように一括更新し、SLA が表示されることを期待します。代わりに、奇妙な違反時間または SLA がまったく表示されません。

これは、SLA がほとんどの人が期待する方法で遡及的に適用できないために発生します。

既存のチケットに SLA ポリシーを適用すると、Zendesk は違反時間をチケットの作成時点からではなく、ポリシーが適用された時点から計算します。したがって、48 時間前に作成されたチケットは、「2 時間前」の違反時間を示す場合があります。これは、ポリシーを適用した時点であるためです。

Zendesk コミュニティのメンバーは、この問題を正確に説明しました。

違反は遡及的に適用できないため、すでに違反しているチケットの優先度を変更すると、違反時間がそのインスタンスとして定義されました。

Zendesk Community

ベストプラクティス： SLA ポリシーを有効にする前に、既存のすべてのチケットの優先度を更新します。すでに有効にしている場合は、ポリシーを一時的に無効にし、チケットデータを修正してから、再度有効にすることを検討してください。

SLA を設定する前にすでに違反していたチケットの場合、違反タイムスタンプを正確にすることはできません。今後、新しいチケットに対して SLA が正しく機能するようにすることに焦点を当ててください。

修正 5：チャネル固有の制限に対処する

すべてのチャネルが同じ SLA メトリクスをサポートしているわけではありません。これは、ライブチャットとメッセージングに特に当てはまります。

ライブチャット SLA はデフォルトで OFF になっています。 有効にするには：

1. チャットダッシュボードに移動します。
2. [設定] > [アカウント] > [SLA] に移動します。
3. 「ライブチャットの応答時間 SLA」をオンにします。

この設定がないと、ポリシーが正しく構成されていても、ライブチャットの会話で SLA データが生成されません。

メッセージングチャネルには異なる制限があります。 メッセージングチャネル (WhatsApp、Facebook Messenger、Web ウィジェットを含む) は、最初の応答時間または次の応答時間のメトリクスをサポートしていません。アクティブな会話中のエージェントの応答間の時間を測定する定期的な更新時間のみをサポートします。

SLA ポリシーが最初の応答時間と次の応答時間のターゲットのみを定義している場合、メッセージングチケットにはまったく適用されません。メッセージングチャネルの定期的な更新ターゲットを追加する必要があります。

修正 6：エッジケースを処理する

一部のチケットシナリオには、すぐに明らかにならない特別な SLA 動作があります。

作成時に解決されたチケット： チケットが「解決済み」ステータスで作成された場合、SLA はまったく適用されません。解決済みのステータスはすべての SLA ターゲットをすぐに満たすため、ポリシーはアクティブになりません。これは、自動化されたチケットまたはスパムフィルタリングでよく発生します。

リクエスタとしてのエージェント： エージェントがチケットのリクエスタでもある場合、多くの SLA ターゲットは計算されません。これにより、内部チケットが SLA メトリクスを歪めるのを防ぎます。

次の応答時間に影響を与える内部メモ： デフォルトでは、次の応答時間は、最も古い未回答の顧客コメントから次の公開エージェントコメントまでを測定します。顧客の返信が (自動化または手動操作によって) 内部メモになった場合、次の応答ターゲットがトリガーされない可能性があります。

SLA ポリシーの詳細設定でこの動作をカスタマイズできます。これらの返信が SLA ターゲットをアクティブにすることを保証するには、「エンドユーザーがチケットに返信し、その返信が内部メモとして追加された場合」オプションを有効にします。

サイド会話と子チケット： これらは、親チケットの SLA を自動的に継承しません。Zendesk の Jira 連携 またはサイド会話を使用している場合、これらの外部インタラクションは、特に構成しない限り、SLA ターゲットにカウントされません。

修正 7：SLA の設定を確認してテストする

上記の修正を適用したら、すべてが正しく機能していることを確認する必要があります。

テストチケットを作成する： テストする最も信頼できる方法は、SLA ポリシーのそれぞれに一致するチケットを作成することです。以下を確認してください。

• SLA バッジがチケットに表示される
• ターゲット時間が構成した内容と一致する
• カウントダウンが計算されている (停止していない)

Zendesk Explore を使用する： より広範なビューについては、Explore の SLA データセットを確認してください。以下を探してください。

• 「SLA が適用されていません」というチケット (ポリシーの一致の問題を示します)
• ポリシーごとの達成率 (ターゲットが現実的かどうかを示します)
• 違反傾向 (システムの問題を特定するのに役立ちます)

1 週間監視する： 変更を加えた後、数日間 SLA メトリクスを監視します。SLA が必要なチケットが表示されない場合、または予期しない違反時間があるチケットを探します。

7 つの修正をすべて確認しても問題が解決しない場合は、Zendesk サポートに連絡する時期かもしれません。管理インターフェイスに表示されないアカウント固有の構成の問題を調査できます。

AI 自動化で SLA 違反を防ぐ

Zendesk SLA が計算されない理由を修正することは重要です。しかし、SLA の構成が完璧であっても、まだ防御的な立場にあります。応答にかかる時間を追跡していますが、必ずしも応答が速くなっているわけではありません。

AI は方程式を変えます。

eesel AI では、自動化を通じて SLA 違反が発生する前にチームが防止できるよう支援しています。SLA を監視するだけでなく、ルーチンチケットを即座に処理することで、一貫して SLA を満たすことができます。Zendesk 連携 の仕組みについて詳しくはこちらをご覧ください。

Zendesk 連携 での仕組みは次のとおりです。

AI エージェントによる即時の最初の応答： 最も一般的な SLA 違反は、最初の応答時間です。AI エージェント は Zendesk と直接連携して、一般的なチケットに数秒で応答します。パスワードのリセット、注文状況の検索、払い戻しのリクエスト。これらは数時間ではなく、すぐに処理されます。

AI コパイロットによる迅速な解決： 人間の注意が必要な複雑なチケットの場合、AI コパイロット は返信を下書きし、ナレッジベースから関連情報を取得します。エージェントは検索に費やす時間を減らし、解決に費やす時間を増やします。これにより、次の応答時間と合計解決時間のメトリクスが直接改善されます。

リスクゼロのセットアップ： ライブになる前に、eesel AI が過去のチケットでどのように機能するかをテストできます。シミュレーションを実行して SLA メトリクスへの影響を確認し、自信がついたら徐々に自動化を増やします。

ここでの変化は、違反を追跡することから、違反を防止することです。AI がルーチンチケットを即座に処理すると、人間のエージェントは SLA ターゲット内で複雑な問題を処理する能力を獲得します。

AI が SLA パフォーマンスにどのように影響するかを確認したいですか？ 価格を確認 して、過去のチケットで eesel AI を試してください。ほとんどの違反が防止可能であることがわかるでしょう。