ZendeskのチケットあたりのマルチSLAポリシー：設定と最適化の方法

多忙なサポートチームを管理しているなら、状況に応じて同じチケットに異なるSLAを適用できるかどうか、一度は考えたことがあるでしょう。例えば、VIP顧客にはより迅速なSLAを適用したい一方で、使用されたチャネルに基づいて異なるターゲットを設定する必要があるかもしれません。結論から言うと、Zendeskでは、各チケットに適用できるアクティブな標準SLAポリシーとグループSLAポリシーは、特定の時点でそれぞれ1つずつに制限されています。しかし、だからといって方法がないわけではありません。システムの仕組みを理解すればよいのです。

このガイドでは、ZendeskのSLAポリシーアーキテクチャがどのように機能するのか、なぜ1ポリシー制限が存在するのか、そして複雑なサポートシナリオを処理するためにポリシーを整理するための実証済みの戦略について詳しく説明します。初めてSLAを設定する場合でも、なぜチケットに間違ったポリシーが適用され続けるのかをトラブルシューティングする場合でも、ここで実用的な答えが見つかるはずです。

ZendeskのSLAトラッキングとは？

マルチポリシーの話に入る前に、まず基本を確認しましょう。ZendeskにおけるSLA（Service Level Agreement：サービスレベルアグリーメント）は、本質的には「約束に付随するタイマー」です。これは、チームが顧客の問題への対応や解決にどれくらいの速さで取り組むかを規定するものです。

ZendeskのSLAトラッキングを使用すると、これらのコミットメントを構造化して定義し、それらが守られているかどうかを測定できます。プラットフォームでは、以下のようないくつかの指標を追跡できます。

指標	測定内容	主な用途
初回返信時間 (First Reply Time)	チケット作成からエージェントの最初の返信までの時間	初期対応に関する顧客の期待値設定
次回返信時間 (Next Reply Time)	顧客の追記からエージェントの返信までの時間	会話全体を通じた応答性の維持
リクエスタ待機時間 (Requester Wait Time)	顧客が待機している合計時間	実際の顧客体験の測定
エージェント作業時間 (Agent Work Time)	チケットが「新規」または「オープン」ステータスにある時間	必要な内部工数の把握
合計解決時間 (Total Resolution Time)	作成から解決までの全ライフサイクル	エンドツーエンドの効率性の追跡

各指標は異なる目的を持っており、多くのチームは複雑な設定を追加する前に、まず「初回返信時間」と「合計解決時間」から開始します。

Zendeskのチケットに複数のSLAポリシーを設定できますか？

単刀直入に答えれば、**「いいえ」**です。1つのチケットに複数の標準SLAポリシーを同時にアクティブにすることはできません。特定の時点において、チケットが持てるのは正確に1つの標準SLAポリシーと、（Enterpriseプランの場合は）1つのグループSLAポリシーのみです。

これはバグや見落としではありません。ターゲットの競合を防ぐための意図的な設計です。例えば、あるポリシーが「1時間以内に返信」と言い、別のポリシーが「4時間以内に返信」と言っている場合、Zendeskはどちらを追跡すべきでしょうか？競合する要件を調整しようとするのではなく、Zendeskは最初に一致したポリシーを適用し、そこで停止します。

重要なフレーズは「特定の時点において」です。チケットのライフサイクル中に条件が変更されれば、SLAポリシーも変更される可能性があります。例えば、チケットの優先度が「標準」から「緊急」にエスカレーションされ、それぞれの優先度に対して異なるターゲットが設定されている場合、チケットはそれ以降「緊急」のターゲットを採用します。それでも、一度にアクティブになるポリシーは1つだけです。

ここで、Zendeskのポリシー順序システムの理解が非常に重要になります。

ZendeskはどのSLAポリシーを適用するかをどのように決定するか

チケットが作成または更新されると、Zendeskは以下の特定の順序で処理を実行します。

1. 最初にトリガが実行される - フィールドの設定、チケットの割り当て、タグの追加などを行う自動化ルールは、SLAの評価前に実行されます。
2. SLAポリシーがチェックされる - ポリシーリストの上から順に、チケットの条件に一致する最初のポリシーを探します。
3. 最初に一致したものが優先される - 一致するポリシーが見つかるとすぐにそれが適用され、検索は終了します。
4. グループSLAは個別に評価される - Enterpriseプランの場合、グループSLAについても同じプロセスが実行されます。

この上から下への評価プロセスこそが、ポリシーの順序が極めて重要である理由です。チケットが技術的に3つの異なるポリシーに一致する可能性があっても、最上位にランクされているものだけが適用されます。

具体的な例を見てみましょう。次のような順序でポリシーがあるとします。

1. VIP顧客 - 1時間以内に初回返信
2. エンタープライズクライアント - 4時間以内に初回返信
3. 標準サポート - 8時間以内に初回返信

「VIP」タグが付いており、かつ「エンタープライズ」組織に属している顧客からチケットが届いた場合、両方のポリシー条件に一致しますが、リストの最上位にある「VIP顧客」ポリシーが優先されます。顧客には4時間ではなく1時間のターゲットが適用されます。

この挙動は制限ではなく、むしろ機能です。これにより、複数のポリシーに該当する可能性がある場合でも、最も重要な顧客が常に最速の応答時間を得られるようなサービスレベルの階層を作成できます。

ZendeskのマルチSLAポリシー設定を整理するためのベストプラクティス

1つのチケットに複数のポリシーを適用することはできないため、適切なポリシーが自動的に適用されるようにポリシー構造を設計する必要があります。経験豊富なZendesk管理者は、次のようなアプローチをとっています。

最も具体的なものから順にポリシーを並べる

SLA整理の黄金律は、最も制限が厳しく具体的なポリシーを一番上に、広範で包括的なポリシーを一番下に配置することです。これを漏斗（ファンネル）のように考えてください。最も緊急で重要なケースが上位のポリシーでキャッチされ、それ以外のすべてがデフォルト設定へと流れていきます。

推奨される順序戦略は以下の通りです。

優先順位	ポリシータイプ	条件の例
1	VIP/緊急	組織がVIP、またはタグに「escalated」を含む
2	チャネル固有	チャネルがメッセージングまたはチャット
3	顧客ティア	組織タイプがエンタープライズ
4	部門/グループ	グループがテクニカルサポート
5	問題タイプ	フォームが「バグレポート」、またはタグに「outage」を含む
6	包括的（キャッチオール）	すべてのチケット（条件なし）

SLA評価の前にトリガを使用して優先度を設定する

複雑なSLAシナリオを管理するための最も効果的なテクニックの1つは、SLAシステムが評価を行う前に、トリガを使用してチケットフィールドを標準化することです。SLAポリシーではすべてのチケットフィールドを条件として使用できるわけではないため（特にステータスや特定のカスタムフィールドは使用不可）、ビジネスロジックを「優先度（Priority）」フィールドに変換することで、より細かな制御が可能になります。

実用的なワークフローは以下の通りです。

1. 受信チケットを評価するトリガを作成する - VIP組織、特定のキーワード、緊急性の指標などをチェックします。
2. それに応じて優先度を設定する - トリガを使用して「緊急」「高」「標準」「低」の優先度を割り当てます。
3. 優先度を中心にSLAポリシーを構築する - これにより、ポリシーで優先度を主要な条件として使用し、各レベルに異なるターゲットを設定できます。

このアプローチは、標準SLAよりも条件の選択肢が限られているグループSLAを扱う場合に特に有効です。

チャネル固有のポリシーを設定する

サポートチャネルによって、顧客の期待値は異なります。チャットで連絡してくる人は即時の返答を期待しますが、メールの顧客は数時間待っても満足するかもしれません。チャネルごとに個別のポリシーを作成することで、チームに過度な負担をかけることなく、これらの多様な期待に応えることができます。

一般的な設定例は以下の通りです。

チャネル	初回返信ターゲット	理由
メッセージング/チャット	2〜5分	リアルタイムの会話が期待されるため
電話	即時	返信時間の指標は不要
メール	1〜4時間	非同期のコミュニケーション
Webフォーム	4〜8時間	緊急性が低く、非技術的な内容が多いため

ポイントは、「チャネル」の条件（「次である」「次ではない」）を使用してポリシーをセグメント化することです。多くの管理者は、メッセージングチケットが最も時間に敏感であるため、リストの最上位にメッセージングポリシーを配置します。

標準ポリシーと並行してグループSLAを活用する

Zendesk Enterpriseプランを利用している場合、グループSLA（運用レベルアグリーメント、またはOLAと呼ばれることもあります）にアクセスできます。これらは内部向けのタイマーで、顧客向けの応答時間を追跡するのではなく、チケットが特定のグループに割り当てられている時間を測定します。

理解しておくべき重要な点は、グループSLAは標準SLAとは独立して動作するということです。1つのチケットにこれらを1つずつ同時に設定できます。つまり、以下のような運用が可能です。

• 顧客に4時間以内に返信する標準SLAを追跡する
• エンジニアリングチームがチケットを所有する時間を8時間以内にするグループSLAを追跡する

この二重追跡は、複数の部門間を移動するチケットに特に役立ちます。顧客へのコミットメントに対するパフォーマンスと、内部チーム内での業務の進捗効率の両方を確認できます。

ただし、グループSLAには制限もあります。必須条件としてグループの割り当てを使用する必要があり、追加の条件はオプションです。標準SLAで利用可能なすべての条件フィールドが使えるわけではありません。また、決定的な点として、グループSLAは、チケットが「最初の割り当て」として届いたのか、「エスカレーション」を通じて届いたのかを区別できません。

ZendeskマルチSLAポリシー構成の一般的なシナリオ

いくつかの現実的なシナリオと、それぞれのポリシー構造の作り方を見ていきましょう。

シナリオ1：VIP顧客に迅速な対応が必要な場合

標準顧客とVIP顧客が混在しており、チャネルや問題の種類に関係なく、VIPにはより迅速なサービスを提供したい場合。

解決策： リストの最上部に、組織タグやユーザーフィールドを使用してVIPを識別するVIPポリシーを作成します。厳しいターゲットを設定します。その下に、他のすべての顧客向けの標準ポリシーを配置します。

シナリオ2：チャネルごとに異なる応答時間が必要な場合

チームがチャット（即時）とメール（緊急度低）の両方を担当しており、それぞれに適切なターゲットを設定したい場合。

解決策： リストの上部にチャネルごとの個別ポリシーを作成します。「チャネルがメッセージングである」および「チャネルがメッセージングではない」という条件を使用します。メッセージングチケットは最も時間に敏感であるため、メッセージングポリシーを順序の上位に配置してください。

シナリオ3：エスカレーションされたチケットの内部追跡が必要な場合

サポートからエンジニアリングに回されたチケットについて、顧客向けのSLAとは別に内部の所有時間ターゲットを設定したい場合。

解決策： 顧客へのコミットメントには標準SLAを使用します。各内部チーム向けに、所有時間ターゲットを設定したグループSLAを作成します。ただし、グループSLAはエンジニアリングに直接割り当てられたチケットとサポートからエスカレーションされたチケットを区別できないため、どちらも同じ所有時間タイマーが作動することを覚えておいてください。

シナリオ4：外部へのエスカレーションを処理する場合

Zendesk以外のツール（JiraやSlackなど）を使用しているベンダーやパートナーにチケットをエスカレーションする必要がある場合。

制限事項： グループSLAは、Zendeskのグループではない外部チームとのやり取りにかかった時間を測定することはできません。

回避策： 一部の管理者は、外部エスカレーション用の「プレースホルダー」グループを作成しています。待機中はチケットをその外部グループに割り当てることで、内部のグループSLAを一時停止させます。外部チームから返信があったら、チケットを内部チームに再度割り当て、グループSLAを再開させます。

AIによるSLAパフォーマンスの最適化

チケット量が増える中で、厳しいSLAターゲットを一貫して達成するのは困難です。ここでAIツールが役立ちます。

初回返信時間のターゲット達成は、多くの場合最大の課題です。パスワードのリセット、注文ステータスの確認、基本的なトラブルシューティングなどの一般的な質問に対して、理想的な初回返信時間は実質的に「即時」です。AIエージェントは、これらの定型的な問い合わせに対して即座に正確な回答を提供し、人間のエージェントがチケットを見る前にSLAを満たすことができます。

人間の専門知識を必要とするより複雑な問題については、AIコパイロットがエージェントの返信作成時間を短縮できます。ナレッジベースから情報を引き出し、過去の解決事例に基づいて返信を提案することで、エージェントは品質を落とさずに迅速に対応できます。これにより、次回返信時間と全体的な解決時間の両方の指標が向上します。

eesel AIでは、Zendeskと直接連携し、まさにこれらの課題を解決するプラットフォームを構築しました。当社のAIエージェントは定型的なチケットを自律的に処理し、日常的な問い合わせに対して初回返信時間のターゲットを即座に達成します。人間の判断が必要な複雑な問題については、AIコパイロットが過去のチケット、マクロ、ヘルプセンターのコンテンツから学習し、正確でパーソナライズされた返信の下書きを作成します。これにより、エージェントが情報を探す時間を削減し、SLAの期限内に返信できるよう支援します。

SLA管理において特に価値があるのは、シミュレーション機能です。AI自動化を導入する前に、過去のチケットに対してテストを行い、既存のSLAに対してどのようなパフォーマンスを発揮したかを正確に確認できます。これにより、自信を持って設定を調整できます。

今日からZendeskのSLAポリシーの最適化を始めましょう

Zendeskの「1チケット1ポリシー」という制限は、回避すべき制約ではなく、明確で階層的なサービスレベルを作成するためのフレームワークです。ポリシーを具体的なものから順に並べ、SLA評価の前にトリガを使用してチケットフィールドを標準化することで、事実上あらゆるサポートシナリオに対応できます。

現在の設定を見直すためのクイックチェックリストを以下に示します。

• 最も重要な顧客ポリシーがリストの最上位にありますか？
• すべてのチケットにSLAが適用されるよう、一番下に包括的な（キャッチオール）ポリシーがありますか？
• SLA評価の前に、トリガを使用して優先度を一貫して設定していますか？
• チームがオフラインの時間をSLAがカウントしないよう、営業時間を設定していますか？
• エージェントはSLAバッジの意味と、業務の優先順位付けの方法を理解していますか？

単なる指標の追跡を超えてSLAパフォーマンスを向上させたい場合は、AIがどのように役立つかを検討してみてください。一般的な質問への回答の自動化、エージェントの返信下書きの支援、関連ナレッジへの即時アクセスなどは、すべてターゲットの一貫した達成に寄与します。Zendeskアカウントをeesel AIに接続し、過去のチケットでセットアップをテストして、SLAパフォーマンスへの潜在的な影響を確認してみてください。