Zendesk SLAターゲットの所有時間について理解する：完全ガイド

サポートチームがエンジニアリングにチケットをエスカレーションする場合、SLA（サービスレベルアグリーメント）を満たす責任は誰にあるのでしょうか？顧客が待っていて、チケットが3つの異なる社内チームの間を行き来している場合、遅延の責任を誰が負うかをどのように追跡しますか？ここで、ZendeskのグループSLAターゲット所有時間が役立ちます。

グループSLA（運用レベル合意またはOLAとも呼ばれます）を使用すると、チケットが特定の社内チームにどれくらいの期間滞留するかを測定できます。顧客への応答時間を約束する通常のSLAとは異なり、グループSLAは内部の引き継ぎと所有権を追跡します。これらは、階層化されたサポート、部門を跨ぐワークフロー、または他の部門との厳格な内部SLAを持つ組織に特に役立ちます。

Zendesk SLAターゲットの所有時間の仕組み、構成方法、およびAIを活用したソリューションでそれを拡張する場合について説明しましょう。

Zendesk SLAターゲットの所有時間とは？

Zendeskの通常のSLAは、顧客からのメッセージとチームの応答の間の時間を追跡します。これらは外部へのコミットメントであり、顧客に表示され、サービスの約束に関連付けられています。グループSLAは異なる方法で機能します。チケットが特定のエージェントグループに割り当てられたままになっている時間を測定し、顧客向けのメトリクスではなく、内部の説明責任を追跡します。

所有時間メトリクスは、チケットがグループに割り当てられてから、別のグループに再割り当てされるか、解決されるまでの期間を特に測定します。これは、Zendeskが「運用レベル合意」（OLA: Operational Level Agreement）と呼ぶものです。チーム間の内部契約と考えてください。Tier 1がTier 2にエスカレーションする場合、両者はTier 2が問題を解決するのにどれくらいの時間があるかを正確に把握しています。

グループSLAが役立つのは次のような場合です。

• チケットが一次サポートから専門チームにエスカレーションされる多層サポート構造
• サポート、エンジニアリング、製品、または運用を含む部門を跨ぐワークフロー
• 外部チームの応答時間を追跡する必要があるベンダーまたはパートナーへのエスカレーション
• 異なる部門の解決時間を測定する内部ITヘルプデスク

重要な注意点が1つあります。グループSLAは、ZendeskのEnterpriseプランでのみ利用可能です。Suite Professional（年間エージェントあたり115ドル）以下のプランを使用している場合、この機能にアクセスできません。Suite Enterprise（年間エージェントあたり169ドル）以上が必要になります。

グループSLAの所有時間の仕組み

所有時間がいつ開始および停止するかを理解することは、グループSLAを効果的に使用するために重要です。タイマーは、チケットがグループSLAポリシーの条件に一致するグループに割り当てられた瞬間から開始されます。チケットが解決されるか、別のグループに再割り当てされると停止します。

具体的な例を挙げます。チケットが一次サポートグループに到着するとします。ポリシーでは、Tier 1がチケットを解決するのに4時間かかると規定されています。エージェントはそれがバグであることに気づき、2時間後にエンジニアリングにエスカレーションします。所有時間は2時間で停止し（4時間のターゲット内）、エンジニアリンググループの新しいタイマーが開始されます。エンジニアリンググループには8時間のターゲットがある場合があります。

チケットが再度開かれた場合はどうなりますか？チケットがエンジニアリングによって解決されたが、顧客が修正が機能しなかったと報告した場合、チケットがエンジニアリングに再割り当てされると、所有時間がリセットされます。これにより、チームがチケットを早期に解決済みとしてマークすることでシステムを悪用することを防ぎます。

また、営業時間と暦時間を選択する必要があります。

Zendeskでは、Enterpriseプランで複数の営業時間スケジュールを使用できます。そのため、グループごとに異なる勤務時間を設定できます。APACサポートチームはシンガポール時間の午前9時から午後6時まで営業し、エンジニアリンググループは米国太平洋時間の勤務時間に従う場合があります。

グループSLAと通常のSLAは、同じチケットに共存できます。顧客には24時間の初回応答時間のコミットメントが表示され、内部的にはエンジニアリングが修正を提供するのに8時間かかると追跡している場合があります。両方のタイマーは独立して動作します。Zendeskのドキュメントで標準SLAポリシーの詳細をご覧ください。

所有時間を使用したグループSLAポリシーの設定

グループSLAの構成を開始する前に、いくつかの準備が必要です。

1. Suite Enterpriseプラン以上（年間エージェントあたり169ドル）
2. Zendeskにグループが既に作成されていること（管理センター > ユーザー > グループ）
3. チケットの優先度フィールドが入力されていること（通常、リクエストタイプまたはフォームに基づいて優先度を設定するトリガーを使用）

詳細な設定手順については、ZendeskのグループSLAドキュメントを参照してください。

これらの前提条件が整ったら、所有時間ターゲットを使用してグループSLAポリシーを構成する方法は次のとおりです。

ステップ1：SLA設定に移動する 管理センター > オブジェクトとルール > ビジネスルール > サービスレベルアグリーメントに移動します。ページの上部にある[グループSLA]タブをクリックします。

ステップ2：新しいポリシーを作成する [ポリシーを追加]をクリックし、わかりやすい名前を付けます。「エンジニアリングエスカレーションSLA」または「Tier 2所有権ターゲット」のような名前を付けます。後で複数のポリシーを管理する場合に、明確な名前が役立ちます。

ステップ3：条件を定義する これにより、ポリシーが適用されるチケットが決まります。特定のグループ、グループのセット、または特定の条件に一致するチケットをターゲットにできます。一般的な条件は次のとおりです。

• グループが「エンジニアリング」または「製品」である
• 優先度が「高」または「緊急」である
• チケットステータスが「解決済み」未満である

ステップ4：所有時間ターゲットを設定する ここで、各グループの時間を定義します。Zendeskでは、優先度に基づいて異なるターゲットを設定できます。

ステップ5：営業時間または暦時間を選択する タイマーを継続的に実行するか（暦時間）、勤務時間中のみ実行するか（営業時間）を選択します。営業時間を使用するには、Zendeskで営業時間スケジュールが構成されている必要があることに注意してください。

ステップ6：ポリシーを保存して順序付けする ポリシーの順序が重要です。Zendeskは最初に一致するポリシーを適用し、チェックを停止します。最も具体的で制限的なポリシーを上部に配置し、より広範な包括的なポリシーを下部に配置します。

所有時間メトリクスとレポートについて

グループSLAの実行を開始したら、パフォーマンスを追跡する必要があります。Zendeskには、所有時間メトリクスを監視するためのいくつかの方法が用意されています。

SLA列を含むチケットビュー チケットビューにグループSLA列を追加して、違反リスクを一目で確認できます。違反にどれだけ近いかでチケットを並べ替えることができるため、エージェントは緊急の注意が必要な作業を優先できます。

Zendesk Exploreダッシュボード Zendesk ExploreのグループSLAダッシュボードは、集計レポートを提供します。次のようなメトリクスが表示されます。

• 達成率: 所有時間ターゲットを満たしたチケットの割合
• 平均解決時間: チケットが各グループに通常滞留する時間
• 違反率: グループがターゲットを逃す頻度

インスタンスベースのレポートとチケットベースのレポート インスタンスベースのレポートは、同じチケットが同じグループに複数回入る場合でも、チケットがグループに入るたびに追跡します。チケットベースのレポートは、すべてのインスタンスでチケットがグループに費やした合計時間を調べます。ほとんどのチームは、各引き継ぎを個別にキャプチャするため、運用レビューにインスタンスベースのレポートを使用します。

メトリクスを確認するときは、パターンを探します。

• 特定のグループが一貫して違反していますか？より多くのリソースまたは異なるターゲットが必要になる場合があります。
• チケットがグループ間を繰り返し行き来していますか？エスカレーション基準を明確にする必要がある場合があります。
• 時間帯のパターンはありますか？特定の時間帯にカバレッジギャップがある可能性があります。

グループSLA実装のベストプラクティス

SLA構成に関する数十のサポートチームとの連携の後、成功した実装と不満の残る実装を区別するいくつかのパターンを特定しました。

最初に優先度トリガーを設定する グループSLAが機能する前に、チケットに優先度が必要です。フォームの選択、リクエストタイプ、またはキーワードに基づいて優先度を自動的に設定するトリガーを作成します。エージェントが手動で優先度を設定すると、一貫性のない結果と信頼性の低いSLAデータが得られます。

会話チャネルとチケットチャネルを区別する チャットおよびメッセージングの会話は、メールチケットとは異なるリズムを持っています。4時間の所有時間ターゲットは、メールチケットには意味があります。解決に10分かかる可能性のあるライブチャットの場合、同じターゲットは意味がありません。同期チャネルには、個別のポリシーまたは異なる計算方法を検討してください。

2-4-8-16ルールを開始点として使用する 多くのチームは、重大度に基づいた階層化されたターゲットで成功を収めています。

• 緊急：2時間
• 高：4時間
• 通常：8時間
• 低：16時間

実際のチームの能力と顧客の期待に基づいてこれらを調整します。誰もが無視する不可能なターゲットを設定するよりも、寛大に始めて締め付ける方が良いでしょう。

最も制限的なポリシーから最も制限の少ないポリシーに順序付けする Zendeskは最初に一致するポリシーを適用し、停止します。「優先度の高いエンジニアリングチケット」の特定のポリシーと「すべてのエンジニアリングチケット」の一般的なポリシーがある場合は、特定のポリシーを最初に配置します。

エージェントのSLAベースのビューを作成する 各グループに、違反リスクでソートされた、自分のチケットのみを表示する専用ビューを提供します。これにより、エージェントは自分に適用されないチケットを調べなくても、何が緊急であるかを確認できます。

複数チームのワークフローを慎重に処理する チケットを複数のグループ（サポート→エンジニアリング→QA→サポート）を順番に移動する必要がある場合は、各引き継ぎに個別のポリシーが必要か、フロー全体をカバーする単一のポリシーが必要かを検討してください。

非難することなく説明責任を作成する SLAはコーチングツールであり、罰則メカニズムではありません。チームが定期的に違反する場合、会話はエージェントのパフォーマンスではなく、リソースの制約、プロセスの改善、または非現実的なターゲットについて行う必要があります。

グループSLAの一般的な課題と解決策

慎重に計画しても、チームはグループSLAで特定の課題に直面します。最も一般的な課題とその対処方法を次に示します。

課題：割り当てとエスカレーションの混乱 エージェントは、適切なコンテキストやドキュメントなしに、チケットを別のグループに再割り当てするだけで「エスカレーション」することがあります。受信グループは履歴のないチケットを受け取り、SLAタイマーは理解できないものから開始されます。

解決策：一次サポートとエスカレーションされたチケットに個別のグループを作成します。専門グループへの再割り当てを許可する前に、特定のフィールド（エスカレーションの理由や顧客への影響など）を必須にするマクロを使用します。コンテキストのない再割り当てはソリューションではなく、プロセス障害であることをエージェントにトレーニングします。

課題：外部エスカレーション Zendeskの外部のチームにエスカレーションする場合はどうなりますか？エンジニアリングのJiraチケットを作成したり、製品チームとのSlackスレッドを開始したりする場合があります。外部からの応答を待っている間、Zendeskチケットはサポートグループにありますが、グループSLAは刻々と進んでいます。

解決策：「保留中のエンジニアリング」または「製品待ち」のようなプレースホルダーグループを作成します。外部にエスカレーションする場合は、チケットをプレースホルダーグループに再割り当てします。これにより、元のグループのSLAタイマーが一時停止し、外部依存関係の新しいタイマーが開始されます。一部のチームは、チケットが外部キューに消えないように、設定された時間後にチケットを再割り当てする自動化を作成することさえあります。

課題：一次サポートの所有時間 一次サポートチームは、顧客からの情報を待っているため、所有時間ターゲットに苦労することがよくあります。顧客が返信しないため、チケットが24時間保留になる可能性があり、その後、エージェントがそれを取得して10分で解決します。エージェントが何も悪いことをしていなくても、SLAは違反を示しています。

解決策：応答時間だけでなく、予想される解決時間に基づいて現実的なターゲットを設定します。営業時間を使用して、営業時間外がチームに不利にならないようにすることを検討してください。一部のチームは、SLAを一時停止する「保留中の顧客」ステータスを作成しますが、これには慎重なトリガー構成が必要です。

課題：ポリシーの競合と順序付けの問題 複数のグループSLAポリシーに一致するチケットは、混乱を招く可能性があります。「エンジニアリング」にあり、優先度が「高」のチケットは、2つの異なるポリシーに一致する可能性があり、リストの最初のポリシーのみが適用されます。

解決策：ポリシーを定期的に監査します。各ポリシーがターゲットとする条件を文書化します。エッジケース（複数のポリシーに一致する可能性のあるチケット）をテストして、どちらが適用されるかを確認します。「ANY」条件ではなく「ALL」条件を使用して、一致をより具体的にすることを検討してください。

AIを活用したソリューションでネイティブSLAを超える

グループSLAは、内部の説明責任を追跡するのに強力ですが、制限があります。時間を測定します。その時間を消費するプロセスを改善しません。引き継ぎを追跡しますが、削減しません。ボトルネックを特定しますが、解決しません。

これは、AIチームメイトがSLA戦略を強化できる場所です。

eesel AIでは、Zendeskに直接接続するサポートチーム向けのAIチームメイトを構築しました。グループSLAを置き換えるものではありませんが、そもそも所有時間ターゲットを困難にする根本的な原因の多くに対処します。

チケットの自動ルーティングのためのAIトリアージ 当社のAIトリアージ製品は、受信チケットを読み取り、適切なグループに自動的にルーティングします。エージェントが誰が処理する必要があるかを判断している間、チケットがチーム間を行き来する代わりに、AIは最初に正しく割り当てます。これにより、引き継ぎの総数が減少し、所有時間が内部のピンポンで1日後にではなく、開始されるはずのときに開始されるようになります。

自律的な解決のためのAIエージェント 当社のAIエージェントは、最前線のサポートチケットをエンドツーエンドで処理します。解決できるチケット（通常は一般的なリクエストの60〜80％）の場合、エスカレーション、引き継ぎ、追跡する所有時間はありません。AIは問題を解決し、チケットを閉じます。グループSLAは、人間の専門知識が本当に必要な複雑なエッジケースにのみ関連します。

リアルタイムのパフォーマンスインサイト Zendeskのレポートは過去のSLAパフォーマンスを示していますが、当社のAIは現在何が起こっているかをリアルタイムで可視化します。実際に違反する前に、違反のリスクがあるチケットを確認し、事後的に違反を確認するのではなく、積極的に介入できます。

組み合わせはうまくいきます。グループSLAは発生する引き継ぎを追跡し、AIは必要な引き継ぎの総数を減らします。両方を使用しているチームは、より速く作業しているからではなく、AIがキューを詰まらせていた簡単な作業を処理しているため、所有時間メトリクスが改善されることがよくあります。

AIがZendesk SLA戦略をどのように補完できるかを知りたい場合は、Zendesk統合の詳細はこちらをご覧ください。また、料金をご覧になり、当社の定額料金モデルがエージェントごとのライセンスとどのように比較されるかをご確認ください。

Zendesk SLAを最大限に活用する

グループSLAターゲットの所有時間は、内部の説明責任を果たすための貴重なツールですが、適切に運営されているサポート業務のほんの一部にすぎません。重要なポイントを次に示します。

願望的な目標ではなく、実際のチームの能力に基づいて現実的なターゲットから始めます。達成不可能なSLAは無視されます。達成可能なものは改善を促進します。

メトリクスを定期的に監視しますが、パフォーマンスクラブとしてではなく、コーチングツールとして使用します。質問は常に「これをどのように改善しますか？」でなければなりません。「誰が違反の責任者ですか？」ではありません。

複雑なワークフローにはAI拡張を検討してください。一般的なチケットで5つの異なるグループにわたって所有時間を追跡している場合、問題は人ではなくプロセスである可能性があります。eesel AIのようなAIチームメイトは、現在複数の引き継ぎを必要とするルーチンワークを処理できるため、人間のチームは実際に専門知識を必要とするものに集中できます。

SLAは目的を達成するための手段であることを忘れないでください。目標は完璧なSLA達成ではありません。顧客の問題を迅速かつ効果的に解決することです。場合によっては、任意の期限を満たすために急ぐのではなく、問題を適切に解決することを意味する場合、違反が正しい結果になることがあります。

AIがチームのターゲットをより一貫して達成するのにどのように役立つかを知りたい場合は、eesel AIを無料でお試しください。AIチームメイトがサポート業務をどのように変革できるかをご確認ください。