ZendeskグループSLAフィルターをグループIDで使用する方法：完全ガイド

Zendesk（ゼンデスク）で社内チームのパフォーマンスを管理することは、適切な指標がなければ当て推量のように感じられることがあります。標準のSLAポリシーは、顧客への対応速度を追跡しますが、社内チームが引き継ぎやエスカレーションをどれだけ効率的に処理しているかはわかりません。そこで、グループSLAポリシーが登場します。

グループSLAを使用すると、チームがチケットを解決するか、引き渡すまでにどれくらいの時間チケットを所有すべきかについて、特定の目標を設定できます。それらを機能させるための鍵は何でしょうか？グループIDでフィルタリングすることです。このガイドでは、グループIDの検索から、実際にアカウンタビリティを促進するポリシーの設定まで、適切なグループIDフィルターを使用してグループSLAポリシーを設定する方法を正確に説明します。

必要なもの

始める前に、基本的な事項がカバーされていることを確認してください。

• Zendesk Enterprise（エンタープライズ）またはEnterprise Plus（エンタープライズプラス）プラン（グループSLAは下位層では利用できません）
• Zendesk（ゼンデスク）アカウントへの管理者アクセス
• 追跡するチームのグループID
• ワークフローにとって理にかなっている所有時間ターゲットの大まかなアイデア

Professional（プロフェッショナル）またはSuite Growth（スイートグロース）をご利用の場合は、最初の返信時間や解決時間などの顧客対応メトリクスに標準SLAを使用できます。ただし、社内グループの所有時間を追跡するグループSLAには、Enterprise（エンタープライズ）へのアップグレードが必要です。

グループSLAポリシーと標準SLAの違いについて

Zendesk（ゼンデスク）の標準SLAポリシーは、顧客対応のコミットメントを測定します。最初にどれだけ迅速に対応するか、フォローアップにどれだけ迅速に返信するのか、問題を完全に解決するのにどれくらいの時間がかかるかなどです。これらは、優先度、チャネル、顧客タイプなどの条件に基づいてチケットに適用されます。

グループSLAは異なる方法で機能します。顧客の待ち時間を追跡する代わりに、単一のメトリクスであるグループ所有時間を通じて社内チームのパフォーマンスを測定します。これは、グループがチケットを解決するか、他の場所に再割り当てするまで、特定の担当者グループがチケットを保持する時間を追跡します。

これが重要な理由を次に示します。Tier 1サポートチームが複雑な問題をTier 2にエスカレーションすると想像してください。Tier 1に初期トラブルシューティングを試みてもらいたいのですが、エスカレーションも迅速に行われるようにしたいと考えています。グループSLAは、「Tier 1は30分以内に緊急チケットを解決またはエスカレーションする必要があります」のような目標を設定できます。これがないと、顧客が待っている間、チケットがTier 1のキューに数時間座っている可能性があります。

設定の主な違いは何でしょうか？グループSLAポリシーには、group_idフィルターが必要です。適用するグループを指定せずに作成することはできません。標準SLAは、「優先度が高い」または「チャネルがメールである」などのより広範な条件を使用できます。

ステップ1：Zendesk（ゼンデスク）グループIDを見つける

グループSLAを設定するには、グループIDを知っている必要があります。これらを見つけるための3つの方法を次に示します。

方法1：管理センターのURL経由（最も簡単）

管理センター>人>グループに移動します。すべての担当者グループのリストが表示されます。グループをクリックして、編集ページを開きます。ブラウザのURLを確認してください。グループIDは末尾の数字です。

https://your-subdomain.zendesk.com/admin/people/teams/groups/10001/edit

この例では、グループIDは10001です。

方法2：Groups API（グループAPI）経由

すべてのグループIDをプログラムで取得する必要がある場合は、List Groups（グループのリスト）エンドポイントを使用します。

GET /api/v2/groups.json

これにより、すべてのグループとそのIDを含むJSONレスポンスが返されます。これにアクセスするには、APIトークンと適切な認証情報が必要です。

方法3：管理センターからエクスポート

一部のZendesk（ゼンデスク）プランでは、管理センターからグループデータをエクスポートできます。すべてのグループとIDのスプレッドシートが必要な場合は、管理センター>人>グループでエクスポートオプションを確認してください。

**プロのヒント：**グループ名とIDを含む共有参照ドキュメントを作成します。チームは、グループSLAだけでなく、トリガー、自動化、API統合にもこれらのIDが必要です。

ステップ2：グループIDフィルターを使用してグループSLAポリシーを作成する

実際のセットアップに移りましょう。グループIDでフィルタリングするグループSLAポリシーを作成する方法を次に示します。

1. 管理センター>オブジェクトとルール>ビジネスルール> SLAポリシーに移動します。
2. ポリシーの作成をクリックし、グループSLA（標準SLAではない）を選択します。
3. 「Tier 1エスカレーションSLA」または「財務チームの対応目標」のように、ポリシーに明確な名前を付けます。
4. グループIDを使用してフィルター条件を設定します。

フィルターは魔法が起こる場所です。グループSLAポリシーには、フィールド「group_id」を持つ少なくとも1つの条件が必要です。JSON構造は次のとおりです。

{
  "filter": {
    "all": [
      { "field": "group_id", "operator": "includes", "value": [10001] }
    ]
  }
}

利用可能なオペレーター：

• includes - チケットに割り当てられたグループが、値配列内のいずれかのグループと一致します。
• not_includes - チケットは、値配列内のいずれのグループにも割り当てられていません。

値配列に複数のグループIDを含めることができます。

{ "field": "group_id", "operator": "includes", "value": [10001, 10002, 10003] }

これにより、同じグループSLAが、すべての地域Tier 1グループなど、複数の関連チームに適用されます。

5. ポリシーの位置を設定します。グループSLAは上から下の順に適用され、最初に一致するポリシーが優先されます。より具体的なポリシー（VIPグループSLAなど）を一般的なポリシーの上に配置します。

ステップ3：グループSLAターゲットを構成する

フィルターを設定したら、実際に測定するものを定義する時間です。グループSLAは、1つのメトリクスgroup_ownership_timeのみを提供します。

このメトリクスは、チケットがグループに割り当てられてから、そのグループがチケットを解決するか、別のグループに再割り当てするまでのクロック時間を測定します。チケットがグループ外に再割り当てされるとクロックが一時停止し、戻ってくると再開します。

各優先度レベル（低、通常、高、緊急）について、分単位でターゲットを設定します。次のターゲット例を検討してください。

**営業時間と暦時間：**クロックが24時間365日稼働するか、営業時間中のみ稼働するかを決定します。社内引き継ぎの場合、チームがSLAを夜通し「待つ」ことができないように、暦時間の方が理にかなっていることがよくあります。顧客対応のコミットメントの場合、通常は営業時間の方が公平です。

API（API）を介してターゲットを構成するには：

{
  "policy_metrics": [
    {
      "priority": "urgent",
      "metric": "group_ownership_time",
      "target": 600,
      "business_hours": false
    },
    {
      "priority": "normal",
      "metric": "group_ownership_time",
      "target": 7200,
      "business_hours": false
    }
  ]
}

ステップ4：グループSLA列をビューに追加する

ポリシーの作成は戦いの半分にすぎません。担当者は、これらのSLAが実際に機能していることを確認する必要があります。チケットビューにグループSLA追跡を追加する方法を次に示します。

1. 管理センター>オブジェクトとルール>ビューに移動します。
2. 既存のビューを編集するか、新しいビューを作成します。
3. 書式設定オプションセクションで、列の追加をクリックします。
4. 列リストからグループSLAを選択します（これは標準SLA列とは異なります）。
5. 並べ替え>グループSLAを昇順で設定します。

グループSLAで昇順に並べ替えるということは、違反に最も近いチケットが最初に表示されることを意味します。これにより、担当者はチケットの作成時間だけでなく、社内の締め切りに基づいてキューの優先順位を付けることができます。

**ベストプラクティス：**グループSLA列を表示する各グループ専用のビューを作成します。Tier 1の担当者は、Tier 1のグループSLAターゲットを確認する必要があります。Tier 2に到着したエスカレーションされたチケットは、Tier 2のターゲットを表示する必要があります。

注：グループSLAと標準SLAは別の列です。両方を同時に並べ替えることはできないため、特定のビューごとにどちらのメトリクスが重要かを決定します。

ステップ5：グループSLA違反の自動化を設定する

ビューは担当者がSLAを監視するのに役立ちますが、自動化はしきい値に達したときにアクションを実行できます。グループSLA違反を中心に自動化を構築する方法を次に示します。

Zendesk（ゼンデスク）は、グループSLAに2つの自動化条件を提供します。

• 次のグループSLA違反までの時間 - これを使用して違反を防ぎます。
• 最後のグループSLA違反からの時間 - これを使用して違反したチケットをキャッチアップします。

一般的な自動化ワークフロー：

• **VIPエスカレーション：**VIP顧客のチケットがグループSLAに違反する30分前になったら、Slack（スラック）チャネルに通知し、上級担当者に再割り当てします。
• **優先度の引き上げ：**メールチケットがグループSLAターゲットに違反した場合、より迅速な割り当てを確保するために、その優先度を自動的に上げます。
• **マネージャーアラート：**チケットがグループSLAに1時間以上違反した場合、チケットの詳細を記載したメールをサポートマネージャーに送信します。

**重要な制限：**SLAまたはグループSLA違反ステータスに基づいてトリガーを作成することはできません。自動化（時間ベースのルール）のみがSLAを参照できます。つまり、SLAが違反した瞬間にアクションをすぐにトリガーすることはできません。時間ベースの自動化条件を使用する必要があります。

API（API）を使用してグループSLAポリシーを管理する

複数のグループSLAを管理したり、外部ツールと統合したりするチームの場合、API（API）は完全なプログラム制御を提供します。

すべてのグループSLAポリシーを一覧表示します：

curl https://your-subdomain.zendesk.com/api/v2/group_slas/policies \
  -H "Content-Type: application/json" \
  -u email@example.com/token:API_TOKEN

ポリシーを作成します：

curl https://your-subdomain.zendesk.com/api/v2/group_slas/policies \
  -H "Content-Type: application/json" \
  -X POST \
  -d '{
    "group_sla_policy": {
      "title": "Tier 1 Escalation",
      "filter": {
        "all": [{ "field": "group_id", "operator": "includes", "value": [10001] }]
      },
      "policy_metrics": [
        { "priority": "urgent", "metric": "group_ownership_time", "target": 600, "business_hours": false }
      ]
    }
  }' \
  -u email@example.com/token:API_TOKEN

フィルター定義を取得します：

curl https://your-subdomain.zendesk.com/api/v2/group_slas/policies/definitions \
  -H "Content-Type: application/json" \
  -u email@example.com/token:API_TOKEN

定義エンドポイントは、利用可能なすべてのフィルターフィールドとオペレーターを返します。これは、カスタム統合を構築している場合に役立ちます。

一般的な問題とトラブルシューティング

適切な設定でも、グループSLAは予期しない動作をする可能性があります。最も一般的な問題とその修正方法を次に示します。

グループSLA列がビューに表示されない これはほとんどの場合、Enterprise（エンタープライズ）プランを利用していないことを意味します。管理センター>アカウントでサブスクリプションレベルを確認してください。グループSLAはEnterprise（エンタープライズ）のみです。

ポリシーがチケットに適用されない group_idの値を確認してください。管理センターでグループを表示するときのURLのIDが正しいです。また、チケットがトリガーまたは手動割り当てによって実際にそのグループに割り当てられていることを確認してください。

所有権とエスカレーションの混同 グループSLAは、チケットが作成時に受信したか、別のチームからのエスカレーションによって受信したかに関係なく、グループがチケットを所有する合計時間を測定します。つまり、Tier 2のグループSLAクロックは、顧客が最初に連絡したときではなく、エスカレーションされたチケットを受信したときに開始されます。一部の管理者は、異なるターゲットを持つ「Tier 2エスカレーション」のような別のグループを作成します。

外部エスカレーションが追跡されない グループSLAはZendesk（ゼンデスク）内でのみ機能します。Jira（ジラ）、Slack（スラック）、またはSide Conversations（サイドカンバセーション）を介してチームにエスカレーションする場合、その時間は測定されません。カスタムフィールドまたは内部メモを使用して、外部引き継ぎを追跡することを検討してください。

ポリシーの順序の問題 グループSLAは上から下の順に適用され、最初に一致するものが優先されることを忘れないでください。上部に一般的な「すべてのサポートグループ」ポリシーがある場合、その下のより具体的なポリシーがブロックされます。

eesel AI（イーゼルAI）でサポートワークフローを合理化する

グループSLAは社内パフォーマンスを追跡するための構造を提供しますが、構造はチームが実際にこれらのターゲットに一貫して到達できる場合にのみ機能します。そこで、AIアシスタンスが貴重になります。

当社は、チームを停滞させ、SLAの達成を困難にする反復作業を処理するZendesk（ゼンデスク）のようなツールと連携するようにeesel AI（イーゼルAI）を構築しました。グループSLAフレームワークを補完する方法を次に示します。

**自動チケットルーティング：**eesel AI（イーゼルAI）は、受信チケットをトリアージし、すぐに適切なグループにルーティングできます。チケットが手動割り当てを待つ一般的なキューに座っている代わりに、適切なチームのキューに即座に到着し、作業するための完全なグループSLAウィンドウを提供します。

**より迅速な最初の応答：**eesel AI（イーゼルAI）が最前線のサポートを処理する場合、数秒以内に顧客に応答します。これにより、顧客が無視されていると感じることなく、複雑な問題についてグループSLAウィンドウ内で作業する時間が人間のチームに与えられます。

**一貫した引き継ぎ品質：**eesel AI（イーゼルAI）は、エスカレーション時にチケットのコンテキストを要約するため、チケットがTier 1からTier 2に移動するとき（そのグループSLAクロックをトリガー）、受信担当者はすぐに作業を開始するために必要なすべてのものを備えています。

当社はZendesk（ゼンデスク）と直接統合し、過去のチケット、マクロ、およびヘルプセンターのコンテンツでトレーニングを行うため、AIはチームのように聞こえます。ライブに移行する前に、履歴チケットで応答をシミュレートして、ボリュームが増加しても品質が高いままであることを確認できます。

社内のアカウンタビリティを向上させるためにグループSLAを実装する場合は、AIがルーチンワークを処理するときに何が起こるかを検討してください。チームは、グループSLAが本当に重要な複雑な問題に集中するためのより多くの帯域幅を得ます。