Zendesk SLAのリセット（返信またはステータス）：完全ガイド

Zendeskでサービスレベルアグリーメント（SLA）を管理するのは、煙を掴むような感覚かもしれません。ポリシーを設定し、ターゲットを定義し、タイマーが刻々と過ぎていくのを見守ります。しかし、予期せぬことが起こります。チケットの優先度が変わったり、顧客から返信不要なメッセージが届いたり、チームがチケットを保留中にしたりします。すると突然、SLAタイマーが予想外の動きをするのです。

Zendesk SLAタイマーがリセットされる場合と一時停止される場合を理解することは、単なる技術的な詳細ではありません。それは、正確なレポート作成と、リーダーシップチームにメトリックが「間違って」見える理由を手動で説明するのに毎週何時間も費やすこととの違いです。このガイドでは、これらのメカニズムがどのように機能するかを正確に解説し、自信を持ってポリシーを設定できるようにします。

違いを理解する：リセット vs 一時停止

具体的なメトリックに入る前に、2つの根本的に異なる動作を明確にしましょう。

**リセット（Reset）**とは、タイマーが再びゼロからカウントを開始することを意味します。経過時間はすべて消去され、SLAは新たに開始されます。これは、特定のイベントが新しい測定サイクルをトリガーしたときに発生します。

**一時停止（Pause）**とは、タイマーが一時的に停止するものの、中断した場所を記憶していることを意味します。条件が変化すると、タイマーは一時停止した場所から正確に再開されます。時間が失われたり、追加されたりすることはありません。

この区別が重要な理由はここにあります。タイマーがリセットされると、チームは完全に新しいターゲットウィンドウを取得します。一時停止すると、元の締め切りがまだ迫っているので、プレッシャーがかかり続けます。どの動作がどのメトリックに適用されるかを誤解すると、誤った安心感や不必要なパニックにつながります。

Zendesk SLAのステータスによる一時停止：タイマーが一時的に停止する場合

解決メトリックは、返信メトリックとは異なる動作をします。エージェントのアクションでリセットされるのではなく、チケットのステータスに基づいて一時停止します。これは、作業が必ずしも継続的ではないサポートワークフローの現実をより良く反映しています。

リクエスタの待機時間（Requester Wait Time）

リクエスタの待機時間（Requester Wait Time）は、顧客がチケットのライフサイクル全体でチームを待つ合計時間を測定します。巧妙な点は、チケットが保留中のステータス（顧客からの返信待ち）の場合に自動的に一時停止することです。

タイマーは、チケットが新規、オープン、または保留中の場合に実行されます。保留中にマークすると、一時停止が有効になります。顧客が返信し、ステータスがオープンに戻ると、タイマーは中断した場所から正確に再開されます。

このメトリックは、パフォーマンスの最も顧客中心のビューを提供します。これは、「この人は実際にどれくらい私たちを待ったのか？」という質問に答えます。「チケットはどれくらい存在したのか？」ではありません。

エージェントの作業時間（Agent Work Time）

エージェントの作業時間（Agent Work Time）は、一時停止の概念をさらに進めます。チケットが新規またはオープンのステータスの場合のみ時間をカウントし、保留中と保留の両方で一時停止します。

なぜ違いがあるのでしょうか？保留は通常、サプライヤー、配送業者、別の部門など、サードパーティを待っていることを意味します。他の誰かを待っている場合、チケットを積極的に処理していないため、メトリックはチームに対してカウントされるべきではありません。

このメトリックは、チケットを外部にエスカレーションするチームにとって特に役立ちます。エージェントが実際に作業できるチケットの時間のみを測定します。

一時停止可能な更新（Pausable Update）

一時停止可能な更新（Pausable Update）は、両方のカテゴリの概念を組み合わせたものです。定期的な更新（Periodic Update）と同様に、エージェントのコメント間の時間を測定します。ただし、解決メトリックと同様に、チケットが保留中の場合に一時停止します。

ターゲットは、エージェントがチケットが新規、オープン、または保留中の場合に最初の公開コメントを作成したときにアクティブになります。チケットが保留中になると一時停止します。チケットがオープンまたは保留に戻ると再開されます。

注意すべき点の1つは、エージェントが公開コメントを送信し、同じアクションでステータスを保留中に変更した場合、一時停止可能な更新メトリックは、チケットが最初に公開コメント付きで新規、オープン、または保留中で送信されるまで適用されないことです。これにより、メトリックがすぐに開始されることを期待する一部のチームがつまずきます。

一般的なエッジケースと回避策

明確なルールがあっても、現実のシナリオではSLAの追跡が複雑になります。ここでは、サポートチームが遭遇する最も一般的なエッジケースを紹介します。

「返信不要」のシナリオ

エージェントがチケットを解決します。顧客は単純な「ありがとう」またはソリューションが機能したことを確認する返信をします。技術的には、未回答の顧客コメントがあるため、これにより新しい次の返信時間のターゲットが作成されます。しかし、返信するのは気まずく、不必要に感じます。

顧客が本当に新しい問題について再度コメントすると、SLAタイマーは新しい問題の説明ではなく、元の「ありがとう」メッセージからカウントされます。これにより、誤った違反レポートが作成され、メトリックが歪められます。

1つの回避策として、短い公開コメントを追加（SLAを満たす）し、すぐに非公開にして顧客に表示されないようにするマクロを使用します。別のアプローチでは、顧客が別のメッセージを送信した場合にトリガーを使用して元に戻す、次の返信時間を強制しない別のSLAポリシーにチケットを一時的に移動します。

優先度の変更と誤った違反

チケットは、24時間の解決ターゲットを持つ通常の優先度で入ってきます。調査後、より緊急であることに気付き、4時間のターゲットを持つ高い優先度に変更します。問題は？チケットがすでに通常の優先度で違反している場合、チケットが高い優先度のターゲットで適切に処理されている場合でも、その違反はレポートに残ります。

Zendeskは、新しい優先度のターゲットを今後適用しますが、過去の違反データを遡及的に調整しません。これにより、SLAパフォーマンスを正確に報告しようとするチームに頭痛の種が生じます。

一部のチームは、優先度が大幅に変更された場合に完全に新しいチケットを作成することでこれを回避しますが、これにより会話履歴が失われます。他のチームは、どの違反が「正当」であるか、または「優先度の変更によるアーティファクト」であるかをメモするために、個別の追跡スプレッドシートを維持します。

再オープンされたチケット

解決済みのチケットが再オープンされると、異なるメトリックは異なる動作をします。

• 初回返信時間と次の返信時間：公開顧客コメントで再オープンされた場合、新しいターゲットをアクティブにします
• 定期的な更新と一時停止可能な更新：エージェントの公開コメントで再オープンされた場合にのみ、新しいターゲットをアクティブにします
• エージェントの作業時間とリクエスタの待機時間：同じターゲットを再アクティブ化し、解決済みのステータスの時間を一時停止として扱います
• 合計解決時間：チケットの作成からカウントを継続し、解決済みの時間を一時停止として扱います

これらのニュアンスを理解することは、再オープンされたチケットが奇妙なSLA動作をするように見える理由を説明するのに役立ちます。

SLAポリシーを設定するためのベストプラクティス

リセットと一時停止のメカニズムを理解した後、実際にどのようにポリシーを設定する必要がありますか？ここでは、苦労して学んだチームからの実践的な推奨事項を紹介します。

シンプルに始めましょう。初回返信時間と1つの解決メトリック（通常、リクエスタの待機時間が最も顧客中心の選択肢です）を選択します。次の返信時間や定期的な更新などの複雑さを追加する前に、これらの基本に慣れてください。

営業時間と暦時間を慎重に決定します。営業時間は、夜間や週末をカウントしないため、チームにとってより公平です。しかし、顧客は暦時間を経験します。金曜日の夕方に送信されたチケットは、営業時間の時計があまり進んでいなくても、週末ずっと開いているように感じます。一部のチームは、内部レポートには営業時間を使用し、顧客向けのコミットメントには暦時間を使用します。

ポリシーを正しく順序付けます。Zendeskは上から下へ評価し、最初に一致するものを適用します。最も制限の厳しいポリシーを上部に、より広範な包括的なポリシーを下部に配置します。一般的な間違いは、特定のポリシーが評価される前に、一般的なポリシーがすべてに一致することです。

チャネルの違いを考慮してください。チャットの会話は、メールチケットとは異なる期待を持っています。チャットには5分の初回返信時間が必要ですが、メールには1時間のターゲットが必要になる場合があります。条件を使用して、異なるチャネルを異なるポリシーにルーティングします。

願望的な目標ではなく、実際の能力に基づいて現実的なターゲットを設定します。一貫して違反するSLAは、SLAがないことよりも悪いです。チームにメトリックを無視するように訓練し、守られていないコミットメントを見る顧客との信頼を損ないます。

AIによるZendesk SLAパフォーマンスの向上

SLAのメカニズムを理解することは重要です。しかし、それらのターゲットを簡単に達成できたらどうでしょうか？

最新のAIツールは、チケットをより迅速かつ一貫して解決するのに役立ちます。eesel AIは、AIエージェントとAIコパイロットを提供し、Zendesk統合と直接連携してメトリックを改善します。

当社のAIエージェントは、一般的で反復的な質問に即座に対応します。顧客がパスワードのリセット、注文状況、または基本的なトラブルシューティングについて質問しますか？数時間ではなく数秒で正確な回答が得られます。これらのチケットの初回返信時間は事実上即時になり、ルーチンな問題が人間のキューに到達することがないため、解決時間が短縮されます。

人間のタッチが必要な複雑な問題については、当社のAIコパイロットが、ナレッジベース、過去のチケット、および接続されたドキュメントから情報を取得して応答を下書きします。エージェントは最初から始めるのではなく、レビューして送信します。これにより、エージェントの作業時間が短縮され、顧客はより迅速に回答を得ることができます。

ライブになる前に、過去のチケットでAIをシミュレートできます。既存のSLAターゲットに対してどのように実行されたかを正確に確認してください。最善を願うのではなく、実際のデータに基づいて構成を調整します。

Zendeskと直接統合されているため、複雑な設定やワークフローの変更はありません。既存のSLAポリシーは常に測定を続けますが、数値はより良く見えます。