社内チーム向けにZendeskグループSLAポリシーを設定する方法

サポートチームがエンジニアリングにチケットをエスカレーションする場合、その引き継ぎにはどのくらいの時間がかかるでしょうか？ 財務部門が払い戻しを承認する必要がある場合、応答の合理的な期間はどのくらいでしょうか？ それこそが、ZendeskグループSLA（Service Level Agreement：サービス品質保証）ポリシーが追跡するように設計されているものです。

グループSLA（運用レベル契約（Operational Level Agreements：OLA）とも呼ばれます）は、チケットが社内チームに滞留する期間を測定します。 最初の返信時間などの顧客向けの指標を追跡する通常のSLAとは異なり、グループSLAは社内の説明責任に焦点を当てています。 これらは、チケットが解決に向けて部門間を通過する場合に特に役立ちます。

このガイドでは、それらの設定方法、使用するタイミング、および注意すべき点について説明します。

ZendeskグループSLAポリシーとは何ですか？また、なぜ重要なのでしょうか？

Zendeskの通常のSLAポリシーは、顧客に対するチームのコミットメントを測定します。応答の速さ、更新頻度、および問題の解決速度です。 グループSLAポリシーは、異なる目的を果たします。 チケットが特定の社内グループに割り当てられたままになる期間を追跡します。

ここに区別があります。

メトリックタイプ	測定するもの	例
通常のSLA	顧客向けの応答時間	「1時間以内の最初の返信」
グループSLA	社内チームの所有時間	「Tier 2チームは4時間以内に解決または再割り当てする」

グループSLAは、1つのメトリックのみを追跡します。それは所有時間です。 これは、チケットがグループに割り当てられてから、別のグループに再割り当てされるか、解決されるまでの時間を測定します。 チケットが再度開かれた場合、そのグループの新しい所有時間クロックが開始されます。 Zendeskのドキュメントによると、所有時間はすべてのグループSLAポリシーの中核となるメトリックです。

なぜこれが重要なのでしょうか？ チケットがチーム間（サポートからエンジニアリング、サポートから財務、Tier 1からTier 2）を移動する場合、グループSLAは各チームがチケットを保持する期間に関する透明性を作成します。 これは、次のことに役立ちます。

• 部門間のワークフローのボトルネックを特定する
• 顧客の約束とは別に、社内の期待値を設定する
• 解決プロセスのチームの役割に対して責任を負わせる
• 特定のチームが圧倒されている場合を特定する

一般的なユースケースは次のとおりです。

• エスカレーションワークフロー：Tier 2またはエンジニアリングがエスカレーションされたチケットを保持する期間の追跡
• 承認プロセス：要求に対する財務または法務チームの応答時間の測定
• 複数地域間の引き継ぎ：異なるタイムゾーンの地域チーム間で渡されるチケットの管理
• 社内IT要求：ITに割り当てられた人事またはその他の部門のチケットの追跡

前提条件と設定要件

グループSLAポリシーを作成する前に、次のものが必要です。

Zendesk Enterpriseプラン グループSLAは、Zendesk Suite Enterprise（年間請求で$169/エージェント/月）またはEnterprise Plusプランでのみ利用できます。 Professional以下のプランを使用している場合、管理設定に[グループSLA]タブは表示されません。

Zendeskで作成されたグループ グループSLAポリシーを作成する前に、少なくとも1つのグループを設定する必要があります。 グループはシステム全体の基盤です。 まだグループを作成していない場合は、最初に[管理センター] > [人] > [グループ]に移動します。

優先度フィールドの構成 グループSLAを含むすべてのSLAポリシーは、システムのデフォルトの[優先度]フィールドに依存します。 カスタム優先度フィールドは機能しません。 チケットに優先度を設定していない場合、SLAは適用されません。 ほとんどのチームは、トリガーを使用してチケットが作成されたときに優先度を自動的に設定します。

営業時間（推奨） 厳密には必須ではありませんが、営業時間を設定すると、SLAクロックがチームが実際に作業している場合にのみ実行されるようになります。 これらは、[管理センター] > [オブジェクトとルール] > [ビジネスルール] > [スケジュール]で設定できます。

スケジュールに関する1つの注意点：複数のスケジュール（異なる地域またはチーム向け）がある場合は、トリガーを使用して正しいスケジュールをチケットに割り当てる必要があります。 そうしないと、スケジュールなしでチケットが作成され、SLAが正しく計算されない場合があります。 Zendeskでスケジュールを設定するの詳細をご覧ください。

最初のグループSLAポリシーを作成するためのステップバイステップガイド

前提条件を満たしたら、グループSLAポリシーの設定は非常に簡単です。

ステップ1：管理センターでグループSLAに移動する

Zendeskアカウントにログインし、次の場所に移動します。

管理センター > オブジェクトとルール > ビジネスルール > サービスレベル契約

「SLAポリシー」（顧客向けのSLA用）と「グループSLA」（社内チームの追跡用）の2つのタブが表示されます。 グループSLAをクリックします。

ステップ2：新しいポリシーを作成する

ポリシーを作成をクリックします。 次のものを提供する必要があります。

• ポリシー名：「Tier 2サポート - 所有時間」または「財務承認 - SLA」のような説明的な名前を使用します。
• 説明（オプション）：このポリシーが対象とする内容と、適用されるチームに関するコンテキストを追加します。

次へをクリックして、条件に進みます。

ステップ3：グループ条件を設定する

ここで、このポリシーが適用されるグループを定義します。 グループ条件で、1つまたは複数のグループを選択します。

いくつかの重要な注意点：

• グループを選択しない場合、ポリシーはすべてのチケットに適用され、グループが割り当てられるたびに測定が開始されます。
• 同じ目標時間を共有する場合、単一のポリシーに複数のグループを含めることができます。
• ポリシーは上から下の順に適用されるため、特定のポリシーを一般的なポリシーの上に配置します。

必要に応じて追加の条件を追加し、次へをクリックします。

ステップ4：所有時間ターゲットを構成する

[グループSLAメトリック]セクションで、[ターゲットを追加]をクリックし、[所有時間]を選択します。 次に、各優先度レベルのターゲットを設定します。

優先度	目標時間	営業時間
緊急	[選択]	ビジネスまたはカレンダー
高	[選択]	ビジネスまたはカレンダー
通常	[選択]	ビジネスまたはカレンダー
低	[選択]	ビジネスまたはカレンダー

現実的なターゲットの設定：何を使用すればよいかわからない場合は、最初のレベルの所有権に対して2-4-8-16パターンから始めます。緊急の場合は2時間、高い場合は4時間、通常の場合は8時間、低い場合は16時間です。 これらを1か月間実行し、Zendesk Exploreで実際のパフォーマンスを確認してから、調整します。

追加をクリックし、次にポリシーを保存をクリックします。

ステップ5：ポリシーを正しく順序付ける

保存後、リストにポリシーが表示されます。 覚えておいてください：ポリシーは上から下の順に適用されます。 チケットの条件に一致する最初のポリシーが適用されるポリシーです。

（「財務グループ - 高優先度」のような）特定のポリシーと（「すべてのグループ - デフォルト」のような）一般的なポリシーがある場合は、特定のポリシーを最初に配置します。

実際の例とユースケース

さまざまなチームが実際にグループSLAをどのように使用しているかを見てみましょう。

例1：Tier 1からTier 2へのエスカレーション

SaaS企業には、2層のサポート構造があります。 Tier 1は基本的な質問を処理し、より詳細な調査が必要な技術的な問題を特定します。 Tier 1がTier 2にエスカレーションする場合、緊急チケットの場合は30分、高優先度の場合は2時間のグループSLAターゲットを設定します。

これにより、Tier 2は複雑な調査に集中している場合でも、エスカレーションを迅速に認識できます。 グループSLAは、1時間以内に最初の返信を約束する顧客向けのSLAとは異なります。

例2：財務承認ワークフロー

eコマース企業のサポートチームは、最大$100の標準的な払い戻しを処理できます。 それを超えるものはすべて、財務承認が必要です。 サポートが高額の払い戻し要求を財務グループに割り当てると、グループSLAの測定が開始されます。

財務チームには、払い戻しを承認してチケットをサポートに戻すか、追加情報を要求するために、4時間（営業時間内）があります。 これにより、顧客に内部タイムラインを公開することなく、説明責任が生まれます。

例3：ITヘルプデスクの引き継ぎ

中規模企業は、顧客サポートと社内ITの両方にZendeskを使用しています。 人事が新しい従業員のラップトップ設定のためにITにチケットを送信すると、グループSLAはITがそのチケットを保持する期間を測定します。

ITはエスカレーションされた顧客の問題も処理するため、社内作業と社外作業で異なるポリシーがあります。 グループSLAを使用すると、要求のタイプに基づいて異なる所有時間ターゲットを設定できます。

例4：複数地域間の引き継ぎ

グローバル企業には、米国、ヨーロッパ、およびアジア太平洋地域にサポートチームがあります。 ヨーロッパで作成されたチケットを（専門的な製品知識のために）米国のチームが処理する必要がある場合、引き継ぎによってグループSLAがトリガーされます。

受信チームは所有権を取得するための明確なターゲットを持ち、タイムゾーン間のスムーズな移行を保証し、引き継ぎ中にチケットが失われるのを防ぎます。

グループSLAを成功させるためのベストプラクティス

チームがグループSLAをどのように使用しているか、何が機能するか（および何が機能しないか）を確認した後、主な推奨事項を次に示します。

シンプルに始める 初日にすべてのグループのポリシーを作成しようとしないでください。 引き継ぎ時間が最も重要な1つまたは2つのグループを選択し、基本的なターゲットを設定して、1か月間実行します。 後でいつでも複雑さを追加できます。

営業時間を一貫して使用する チームが24時間年中無休で利用できない場合は、SLAにそれを反映させる必要があります。 スケジュールされていない午前2時に応答しなかったことでチームを判断することは役に立ちません。 スケジュールに営業時間を設定し、SLAポリシーに接続します。

トリガーを介して優先度を設定する グループSLA条件は、優先度のみを使用できます（他のチケットフィールドは使用できません）。 基準に基づいて優先度を自動的に割り当てるトリガーを設定し、SLAにその優先度を参照させます。 これにより、SLAポリシーをクリーンで一貫性のある状態に保ちます。 自動化とトリガーに関するZendeskのドキュメントには、これらのワークフローの構成に関する追加のガイダンスが記載されています。

SLAベースのビューを作成する エージェントのプライマリビューに「グループSLA」列を追加し、昇順で並べ替えます。 これにより、違反に最も近いチケットが最初に表示され、エージェントが緊急チケットと通常優先度のチケットの両方で公平に優先順位を付けるのに役立ちます。

四半期ごとにレビューする チームのキャパシティとチケットの複雑さは時間とともに変化します。 3か月ごとにグループSLAターゲットを確認するようにカレンダーリマインダーを設定します。 ターゲットに一貫して到達できない場合は、非現実的な可能性があります。 常に大幅に上回っている場合は、期待値を厳しくすることができます。

QAプログラムと組み合わせる グループSLAは時間的プレッシャーを生み出します。 送信されている実際​​の応答を確認する品質保証プロセスがあることを確認してください。 そうしないと、エージェントは時計を打ち負かすためだけに返信を急ぐ可能性があります。 目標は、より速いかつより良いサポートであり、単により速いだけではありません。

一般的な制限事項と回避策

グループSLAは便利ですが、展開する前に理解しておくべき重要な制限事項があります。

制限事項：エスカレーションとプライマリ所有権の区別がない

グループSLAは、すべての割り当てを同じように扱います。 チームにエスカレーションされたチケットと、チームが直接受信するチケットは、同じ所有時間クロックを開始します。 これは、階層化されたサポート構造の問題です。

回避策：エスカレーションを受信し、直接作業を処理するチーム用に2つのグループを作成します。 例：

• 直接的な従業員のリクエストの場合は「IT」（グループSLAなし）
• 他のサポートチームからのチケットの場合は「IT - エスカレーション」（グループSLAあり）

これにより、エスカレーションされた作業にのみ所有時間ターゲットを適用できます。

制限事項：外部エスカレーションを追跡できない

Side Conversations経由でベンダーに、またはJira統合経由でエンジニアリングに、またはSlack経由でマーケティングにエスカレーションする場合、グループSLAはそれらを追跡できません。 それらはZendeskグループの割り当てでのみ機能します。

回避策：外部エスカレーションのプレースホルダーグループを使用します。 Jiraにエスカレーションする場合は、「保留中 - エンジニアリング」グループにチケットを割り当てます。 エンジニアリングが応答したら、実際のエンジニアリンググループに再割り当てします。 手動ですが、外部の待ち時間を追跡できます。

制限事項：優先度のみの条件

グループSLAポリシーは、条件で優先度のみを使用できます。 チケットタイプ、組織、またはカスタムフィールドに基づいて異なるターゲットを直接設定することはできません。 Zendesk SLAドキュメントでは、トリガーとSLAがどのように連携するかについて説明しています。

回避策：トリガーを使用して、基準に基づいて優先度を設定します。 例：

• トリガー：「チケットタイプがバグで、組織がVIPの場合、優先度を緊急に設定する」
• グループSLA：「緊急チケットの場合、Tier 2の所有時間は1時間です」

これにより、複雑なロジックがトリガーに移動し、SLAポリシーがシンプルに保たれます。

制限事項：通常のSLAとは別

グループSLAと顧客向けのSLAは、完全に別のシステムです。 チケットには両方を適用できますが、それらは個別に測定されます。 「最初に違反するSLA」でソートする単一のビューを作成することはできません。

回避策：補完的なポリシーを設計します。 4時間のグループSLA違反が発生することが問題である場合は、顧客向けのSLAにまだ時間が残っている場合でも、その前にエスカレーションまたは通知するように自動化を設定します。

グループSLAの監視とレポート

ポリシーの設定は作業の半分にすぎません。 また、それらに対するパフォーマンスを追跡する必要があります。

Zendesk ExploreのグループSLAダッシュボード Enterpriseプランでは、Exploreに事前構築されたグループSLAダッシュボードにアクセスできます。 これは以下を示しています。

• グループSLAターゲットを満たすチケットの割合
• グループおよび優先度別の違反率
• 時間経過に伴う傾向

Zendesk Exploreドキュメントでは、SLAメトリックインスタンス属性を使用してカスタムレポートを作成する方法について説明しています。

より詳細なデータが必要な場合は、「SLAメトリックインスタンス」属性を使用してカスタムレポートを作成することもできます。 プログラムによるアクセスの場合、グループSLAポリシーAPIを使用すると、ポリシーをリスト、作成、更新、および削除できます。

グループSLA列をビューに追加する チケットビューでは、次のターゲット違反までのカレンダー時間を示す「グループSLA」列を追加できます。 この列でビューを昇順に並べ替えて、最初に注意が必要なチケットを表示します。

所有時間計算の理解 所有時間は、グループが割り当てられたときに開始され、チケットが次のいずれかになったときに終了します。

• 別のグループに再割り当てされた
• 解決済み
• クローズ済み

チケットが再度開かれた場合、現在それを保持しているグループに対して新しい所有時間期間が開始されます。

キャパシティプランニングに違反データを使用する 特定のグループが所有時間ターゲットに一貫して違反している場合、それはシグナルです。 彼らは以下を必要とするかもしれません：

• 追加の人員配置
• チケットをより効率的に処理するためのトレーニング
• 調査時間を短縮するためのより良いドキュメント
• ボトルネックを排除するためのプロセス改善

AI自動化によるSLAパフォーマンスの向上

グループSLAは内部の引き継ぎ時間を測定するのに役立ちますが、それらを短縮するのには役立ちません。 それが、AIツールがSLA戦略を補完できる場所です。

方法は次のとおりです。AIが一般的な最前線の質問に即座に対応すると、それらのチケットはTier 2または他のグループにエスカレーションする必要がなくなります。 内部の引き継ぎを必要とするチケットが少なくなるため、所有時間メトリックが向上します。

eesel AIはZendeskと直接統合して、チームがSLAターゲットをより迅速に満たすのを支援します。 AIエージェントは、人間の関与なしに、一般的なチケット（パスワードのリセット、注文ステータス、基本的なトラブルシューティング）を数秒で解決できます。 これにより、顧客向けのSLAが向上し、グループ追跡が必要なチケットの量が削減されます。

人間の注意が必要なチケットの場合、AIコパイロットは、ヘルプセンターの記事、過去のチケット、および接続された知識ソースからプルすることで、返信を即座に作成します。 これにより、エージェントが調査と執筆に費やす時間が短縮され、所有時間ターゲットをより一貫して満たすのに役立ちます。

また、シミュレーションモードを使用して、AIがライブになる前にSLAパフォーマンスにどのように影響するかをテストすることもできます。 Zendeskを接続し、過去のチケットでシミュレーションを実行して、既存のSLA構成とともに予測される解決率を確認します。 Zendesk SLA追跡のガイドで詳細をご覧ください。