Zendesk SLAポリシーのエンタープライズ要件：2026年完全ガイド

サービスレベル契約（SLA: Service Level Agreement）は、予測可能なカスタマーサポートのバックボーンです。SLAは期待値を設定し、チームに責任を持たせ、顧客に問題がタイムリーに解決されるという自信を与えます。エンタープライズ組織にとって、SLAポリシーを適切に設定することは、単に顧客満足度だけではありません。複数のチーム、地域、そして時には数千のエージェントにわたって大規模に運用することなのです。

エンタープライズレベルでZendeskを実行している場合、基本的なSLA追跡以上のものが必要です。内部アカウンタビリティのためのグループSLA、グローバルチームのための複数のビジネススケジュール、そしてメトリクスの測定方法を微調整できる高度な構成オプションが必要です。このガイドでは、プランの選択から実装のベストプラクティスまで、Zendesk SLAポリシーのエンタープライズ要件について知っておくべきことをすべて説明します。

ZendeskのSLAポリシーとは？

ZendeskのSLAポリシーは、基本的にサポートチームと顧客との間の契約です。問題への対応と解決にどれくらいの速さでコミットするかを定義し、それらのコミットメントに対する実際のパフォーマンスを測定します。

仕組みは次のとおりです。「VIP顧客からのチケット」や「テクニカルサポートリクエスト」など、特定の条件を持つポリシーを作成します。チケットがこれらの条件を満たすと、Zendeskは設定した時間ターゲットに対してチケットの追跡を開始します。緊急のチケットには15分の初回返信ターゲットが設定され、優先度の低いリクエストには24時間が設定される場合があります。プラットフォームはこれらのメトリクスを自動的に追跡し、エージェントにカウントダウンタイマーを表示し、ターゲットが危険にさらされている場合にマネージャーに警告します。

エンタープライズにとっての真の価値は、単純な追跡にとどまりません。SLAは大規模なアカウンタビリティを生み出します。複数の部門に数百人のエージェントがいる場合、SLAは誰もが自分の優先順位を理解し、同じ基準に向けて取り組むことを保証します。また、ボトルネックを特定し、リソースを効果的に割り当て、リーダーシップにパフォーマンスを実証するために必要なデータも提供します。

SLAターゲットを一貫して上回ることを目指すチームのために、最前線のチケットを即座に処理し、エージェントがより迅速な応答を下書きするのに役立つeesel AIを構築しました。しかし、AI拡張を検討する前に、強固なSLA基盤が必要です。

Zendesk Enterprise SLAの要件と機能

すべてのZendeskプランにSLA機能が含まれているわけではなく、エンタープライズ要件は基本的なもの以上のものを必要とします。プランの要件と、各ティアで利用できるものについて知っておくべきことは次のとおりです。

SLAポリシーのプラン要件

SLAポリシーは、Suite Professionalプランから利用可能になります。内訳は次のとおりです。

出典： Zendeskの価格ページ

エンタープライズSLA管理に真剣に取り組む場合、Suite Enterpriseは実際の機能がアンロックされる場所です。月額1エージェントあたり追加の54ドルで、内部ハンドオフを追跡するためのグループSLA、グローバル運用のための複数の営業時間スケジュール、および高度なカスタマイズオプションを利用できます。

標準SLAポリシーとグループSLA

標準SLAは、顧客向けのコミットメントに対するチームのパフォーマンスを測定します。初回返信時間、解決時間、および定期的な更新はすべてこのカテゴリに分類されます。これらは、ほとんどの人が「SLA」と聞いて思い浮かべるものです。

Enterpriseプランでのみ利用可能なグループSLAは、異なる目的を果たします。特定の内部チームにチケットが割り当てられたままになっている時間を追跡します。これは、運用レベル契約（OLA: Operational Level Agreement）とも呼ばれます。チケットがTier 1サポートからエンジニアリングにエスカレートされた場合、グループSLAは、エンジニアリングが解決または返送するまでにチケットを保持する時間を測定します。

これは、顧客向けのSLAがエンタープライズレベルでは誤解を招く可能性があるため重要です。チケットはSLAターゲット内に収まっている可能性がありますが、実際には内部チームを待つために数日を費やしています。グループSLAは、これらの内部ボトルネックを明らかにし、修正できるようにします。

エンタープライズ固有の機能

Suite Enterpriseは、大規模な運用に不可欠ないくつかの機能をアンロックします。

複数のビジネススケジュール。 ニューヨーク、ロンドン、シンガポールにサポートチームがある場合は、各地域に異なる営業時間を設定できます。次に、SLAはチケットの割り当てまたはその他の基準に基づいて適切なスケジュールを尊重します。

初回返信時間の詳細設定。 Enterprise管理者は、初回返信タイマーの開始時期と、それを満たすアクションをカスタマイズできます。これは、顧客への連絡前のライトエージェントまたは内部メモを含む複雑なワークフローにとって重要です。

APIアクセス。 すべてのプランにいくつかのAPI機能がありますが、エンタープライズセットアップでは、カスタムレポート、自動化されたSLA調整、または外部システムとの同期のために、より深い統合が必要になることがよくあります。

すべてのエンタープライズが追跡すべき主要なSLAメトリクス

Zendeskは7つの異なるSLAメトリクスを提供していますが、すべてがエンタープライズ運用に等しく役立つわけではありません。ここでは、各メトリクスが何を測定し、いつ使用するかを示します。

返信時間メトリクス

初回返信時間（FRT: First Reply Time） は、顧客が最初の応答を待つ時間を追跡します。これは通常、顧客満足度にとって最も重要なメトリクスです。問題をすぐに解決できなくても、受領を確認し、期待値を設定することは非常に重要です。

次の返信時間（NRT: Next Reply Time） は、会話全体を通して、顧客のフォローアップと応答の間のギャップを測定します。FRTは注目を集めますが、NRTは複数のやり取りが必要な複雑なチケットにとってより重要になることがよくあります。

更新時間メトリクス

定期的な更新 は、問題が解決されない場合でも、顧客が定期的に連絡を受けることを保証します。各公開エージェントのコメント間の時間を測定します。これにより、チケットが沈黙することを防ぎます。これは、ほとんどの場合、他の何よりも顧客をイライラさせます。

一時停止可能な更新 は似ていますが、チケットが保留ステータスの場合に一時停止します。チケットが新規、オープン、または保留中の場合にのみ実行されます。これにより、エージェントが顧客を正当に待っている場合にペナルティが科せられるのを防ぎます。

解決時間メトリクス

リクエスター待機時間 は、顧客が新規、オープン、および保留ステータスで待機するすべての時間を組み合わせます。保留中は一時停止します。このメトリクスは、顧客の視点からの全体的な顧客体験を反映しています。

エージェント作業時間 は、保留を除く、新規およびオープンステータスで費やされた時間のみを測定します。エージェントがチケットに費やした実際の労力を示し、キャパシティプランニングやプロセスの非効率性の特定に役立ちます。

合計解決時間 は、チケットの作成から解決までのすべてをカウントします。これには、保留時間が含まれます。これは、エンドツーエンドの解決プロセスの最も包括的な尺度です。

グループ所有時間 は、Enterpriseプランでのみ利用可能なグループSLAメトリクスです。チケットが特定の内部グループに割り当てられたままになっている時間を測定します。割り当てられたときに開始し、他の場所に再割り当てされたときに終了します。

営業時間と暦時間

各メトリクスの重要な決定は、営業時間または暦時間で測定するかどうかです。営業時間は、定義された営業時間スケジュール中の時間のみをカウントします。暦時間は24時間年中無休で実行されます。

エンタープライズチームの場合、一般的なルールは、公平性のために営業時間を使用し、コミットメントがリアルタイムの場合は暦時間を使用することです。「4時間以内に応答する」と約束する場合は、おそらく暦時間にする必要があります。「2営業日以内に解決する」と約束する場合は、週末がチームにカウントされないように営業時間を使用します。

エンタープライズ規模でZendesk SLAポリシーを構成する方法

最初からSLAを正しく設定すると、後で頭痛の種になるのを防ぐことができます。エンタープライズ実装の実際的なアプローチを次に示します。

最初のSLAポリシーの設定

まず、Admin Center > Objects and rules > Business rules > Service level agreementsに移動します。「ポリシーの作成」をクリックし、構成を進めます。

1. ポリシーに明確な名前を付けます。 「SLAポリシー1」のような一般的なラベルではなく、「エンタープライズ顧客 - 技術的な問題」のような説明的な名前を使用します。

2. 条件を慎重に設定します。 条件は、ポリシーが適用されるチケットを決定します。チケットフィールド、ユーザーフィールド、および組織フィールドを使用できます。ポリシーは上から下に評価され、最初に一致するポリシーが優先されることに注意してください。

3. メトリクスを選択します。 すべてのメトリクスを有効にしないでください。初回返信時間と1つの解決メトリクスから始めます。チームが基本を習得した後にのみ、他のメトリクスを追加します。

4. 現実的なターゲットを設定します。 最小ターゲットは15秒ですが、それを使用する必要があるという意味ではありません。過去のパフォーマンスデータと改善目標に基づいてターゲットを設定します。現在の平均FRTが4時間の場合、15分のターゲットを設定すると、常に違反が発生するだけです。

5. 営業時間の設定。 各優先度レベルの営業時間または暦時間を選択します。ほとんどのエンタープライズチームは、標準メトリクスには営業時間を使用し、緊急の優先度のみに暦時間を使用します。

内部アカウンタビリティのためのグループSLAの構成

グループSLAには、Enterpriseプランと内部ワークフローの明確な理解が必要です。設定するには：

1. Service level agreementsセクションで、「グループSLA」タブを選択します
2. 新しいポリシーを作成し、適用するグループを選択します
3. 各優先度レベルの所有時間ターゲットを設定します
4. 営業時間または暦時間を選択します

一般的なユースケースには、エンジニアリングでチケットが保持される時間の追跡、払い戻しリクエストに対する財務チームの応答時間の測定、または専門のサポートチームへのエスカレーションの監視が含まれます。

スケールに応じたポリシーの整理

ポリシーの順序は非常に重要です。Zendeskはポリシーを上から下に評価し、最初の一致を適用します。エンタープライズ規模では、これには慎重な整理が必要です。

最も制限の厳しいポリシーを最初に配置します。 プラチナ顧客向けの特別なSLAがある場合は、一般的な顧客ポリシーの前に表示する必要があります。そうしないと、一般的なポリシーが最初に一致し、プラチナSLAは適用されません。

トリガーを使用して優先度を自動的に設定します。 SLAを適用するにはチケットに優先度を設定する必要があるため、組織、件名行のキーワード、またはフォームの選択などの基準に基づいて優先度を設定するトリガーを作成します。これにより、エージェントが手動で優先度を設定することに依存せずに、SLAが一貫して適用されるようになります。

会話チャネルとチケットチャネルを分離します。 チャットおよびメッセージングの会話には、メールチケットとは異なるターゲットが必要です。チャネルタイプごとに個別のポリシーを作成し、リアルタイムチャネルのターゲットを厳しくすることを検討してください。

顧客固有のティアを作成します。 エンタープライズ組織は、主要な顧客と契約上のSLAを結んでいることがよくあります。組織ベースの条件を使用してこれらの顧客専用のポリシーを作成し、ポリシーリストの一番上に配置します。

エンタープライズSLAのベストプラクティスとガバナンス

SLAを構成することは始まりにすぎません。長期的な成功には、ガバナンス、定期的なレビュー、および速度と品質のバランスが必要です。

シンプルに始めて、反復処理します

エンタープライズチームが犯す最大の過ちは、初日からSLAを過剰に設計することです。初回返信時間と1つの解決メトリクスから始めます。チームが定期的な更新や一時停止可能な更新などの複雑さを追加する前に、SLAを使用した作業に適応させます。

チームが成熟するにつれて、メトリクスを追加し、ターゲットを絞り込むことができます。しかし、5つの異なるメトリクスから始めると、混乱が生じ、エージェントが間違ったことに集中するだけです。

データに基づいて現実的なターゲットを設定します

希望的観測ではなく、実際の過去のパフォーマンスに基づいてターゲットを設定します。90パーセンタイルのFRTが現在6時間の場合、1時間のターゲットを設定すると、常に違反が発生し、エージェントが不満を抱きます。

より良いアプローチは、最初に80パーセンタイルまたは90パーセンタイルでターゲットを設定し、プロセスを改善するにつれて徐々に厳しくすることです。これにより、改善を推進しながら、早期に勝利を収めることができます。

四半期ごとにレビューと調整を行います

ビジネスニーズは変化し、SLAも変化する必要があります。次のことを確認するために、四半期ごとのカレンダーリマインダーを設定します。

• ポリシーおよびメトリクスごとの違反率
• 時間の経過に伴う傾向
• ターゲットがビジネスの優先順位と一致しているかどうか
• 何がうまくいっていて、何がうまくいっていないかについてのエージェントからのフィードバック

一貫して見逃されている、または余裕を持って一貫して満たされているターゲットを調整します。SLAは達成可能でありながら、やりがいのあるものでなければなりません。

速度と品質のバランスを取ります

SLAは迅速な対応へのプレッシャーを生み出し、急いで質の低い対応につながる可能性があります。速度と品質の両方を評価する堅牢なQAプログラムでこれに対抗します。エージェントは、悪い応答でSLAターゲットを達成することが成功ではないことを知っておく必要があります。

古典的な注意喚起の物語は、ドミノピザの「30分以内にお届け、無料」保証です。これにより、ドライバーが締め切りに間に合うように急いで危険な行動をとりました。サポートチームは赤信号を無視しませんが、不完全な応答を送信したり、複雑な質問を無視したりする可能性があります。QAはこれを防ぎます。

優先順位付けにSLAベースのビューを使用します

SLA違反時間でソートされたビューを作成して、エージェントが優先順位を付けるのに役立ちます。Admin Center > Objects and rules > Viewsで、「次のSLA違反」列を追加し、昇順でソートします。これにより、作成時期に関係なく、違反に最も近いチケットが最初に表示されるようになります。

エージェントに、デフォルトのIDソートされたキューではなく、これらのビューから作業するようにトレーニングします。これにより、「最新優先」バイアスを防ぎます。このバイアスでは、緊急のチケットが新しくても重要度の低いリクエストの下に埋もれてしまいます。

AI自動化によるSLAターゲットの達成

SLA構成が完璧であっても、大規模な積極的なターゲットを達成するには、人間の努力だけでは不十分です。ここで、AI自動化が不可欠になります。

課題は簡単です。チケットのボリュームが急増すると、エージェントはそれほど速く作業できません。初回返信時間のターゲットは、ピーク時に低下します。エージェントが情報を探している間、複雑なチケットはキューに座っています。ルーチンリクエストは、複雑な問題に費やすべき時間を消費します。

当社のAIエージェントは、一般的な最前線のチケットを即座に処理します。パスワードのリセット、注文状況の検索、および基本的なトラブルシューティングは、数時間ではなく数秒で解決されます。これにより、ルーチンチケットの初回返信時間と合計解決時間のメトリクスが劇的に低下します。

人間の専門知識を必要とするチケットの場合、当社のAIコパイロットは、ナレッジベース、過去のチケット、および接続されたドキュメントからプルして、正確な応答を下書きします。エージェントは最初から作成するのではなく、レビューして送信するため、エージェントの作業時間が大幅に短縮されます。

エンタープライズチームにとっての主な利点は、eesel AIがZendeskと直接統合されることです。別のインターフェイスやワークフローの中断はありません。エージェントはすでに知っているのと同じZendeskワークスペースで作業し、AIアシスタンスを利用してSLAターゲットを一貫して上回ることができます。

また、ライブになる前に、過去のチケットでAI構成をテストできるシミュレーションモードも提供しています。過去四半期のSLAパフォーマンスにどのように影響したかを正確に確認し、実際の顧客との会話に触れる前に微調整します。

SLA追跡の最適化について詳しく知りたい場合は、Zendesk SLA追跡に関する完全なガイドをご覧ください。セットアップの詳細については、Zendesk統合ドキュメントをご覧ください。

ZendeskでエンタープライズSLAポリシーを開始する

エンタープライズレベルでSLAを実装することは、圧倒される必要はありません。実際的なロードマップを次に示します。

1. 現在のパフォーマンスを監査します。 ターゲットを設定する前に、ベースラインを理解します。チケットデータをエクスポートし、優先度別に現在のFRT、解決時間、および違反率を計算します。

2. 顧客セグメントを特定します。 契約上のSLA要件がある顧客はどれですか？最も収益を上げている顧客はどれですか？さまざまなセグメントの階層化されたポリシーを作成します。

3. 内部ワークフローをマッピングします。 チケットがチーム間でどのように流れるかをドキュメント化します。グループSLAがアカウンタビリティを提供するハンドオフポイントを特定します。

4. 2つのメトリクスから始めます。 初回返信時間とリクエスター待機時間は、ほとんどのチームにとって十分です。これらが安定した後にのみ、複雑さを追加します。

5. 営業時間を構成します。 各チームまたは地域のスケジュールを設定します。SLAがタイムゾーンの境界を越えて正しく計算されることをテストします。

6. 優先度設定トリガーを作成します。 顧客層、問題の種類、またはチャネルに基づいて、優先度の割り当てを自動化します。これにより、SLAが一貫して適用されるようになります。

7. SLAビューに関するエージェントのトレーニング。 「次のSLA違反」ソートを使用して、作業に効果的に優先順位を付ける方法を説明します。

8. AI拡張の計画。 自動化がターゲットを一貫して達成するのにどのように役立つかを検討します。AIによって即座に処理されるチケットの割合が小さくても、人間のエージェントに余裕が生まれます。

目標は、初日に完璧なSLAコンプライアンスを実現することではありません。時間の経過とともに改善され、アカウンタビリティを生み出し、顧客にエンタープライズサポート運用に期待される予測可能なエクスペリエンスを提供するシステムを構築することです。

AIがSLAターゲットを超えるのにどのように役立つかを知りたい場合は、eesel AIを探索して、即時応答とAI支援による下書きがメトリクスに何をもたらすかを発見してください。