Zendesk SaaS SLAに関する問い合わせへの対応方法：2026年完全ガイド

すべてのSaaS企業は、応答時間について約束をしています。「24時間以内にご連絡します」や「緊急の問題は2時間以内に解決します」など、これらの約束は顧客との関係の一部となります。しかし、数百、数千ものチケットでそれらの約束を追跡し続けるのは大変です。そこで、サービスレベル契約（SLA（Service Level Agreement））が登場します。

Zendeskには、コミットメントを達成しているかどうかを自動的に追跡するSLA機能が組み込まれています。請求に関する質問から重大な停止まで、あらゆる問題に対処するSaaS企業にとって、この機能は顧客満足度と解約率の差を意味する可能性があります。その仕組みと適切な設定方法について詳しく見ていきましょう。

チームを疲弊させることなく、一貫して積極的なSLA目標を達成したい場合は、eesel AIがZendeskと直接連携して、最前線での問い合わせに対応し、より迅速に応答を作成できます。ただし、その前に、基本事項について説明します。

Zendesk SaaS SLAに関する問い合わせとポリシーとは？

ZendeskのSLAポリシーは、基本的にサポートチームと顧客間の契約です。さまざまな種類の応答と解決に対する特定の時間目標を定義し、それらの目標を達成しているかどうかを自動的に追跡します。

仕組みは次のとおりです。チケットが特定の条件（「緊急」というタグが付いている、またはVIP顧客からのものであるなど）を満たすと、Zendeskはタイマーを開始します。そのタイマーは、最初の応答までの時間、その後の応答間の時間、または完全な解決までの時間などの指標を追跡します。期限が近づくと、チケットにフラグが立てられます。期限を過ぎると、SLA違反として記録されます。

ビジネス上の価値は明確です。SLAは説明責任を生み出します。顧客に問題がブラックホールに消えることはないという自信を与えます。また、チームに明確な優先順位（違反が近づいているチケットが最初に処理されます）を与えます。

理解しておくべき重要な区別があります。標準SLAは顧客向けです。顧客が経験することを追跡します。ただし、Zendesk Enterpriseは、チーム間の内部引き継ぎを追跡するグループSLAも提供しています。詳細については後述します。

プランの要件と機能の可用性

ここで注意が必要です。SLAポリシーは、すべてのZendeskプランで利用できるわけではありません。

出典：Zendeskの価格

Suite TeamからSuite Professionalへの移行は大幅（月額60ドル/エージェント）ですが、SLA機能の最小限の階層です。専任のサポートチームを持つほとんどのSaaS企業にとって、Suite Professionalが開始点となります。

Suite Enterpriseは、グループSLA（内部チームのパフォーマンスを追跡するため）、複数のビジネススケジュール（グローバルチームがある場合に便利）、および高度なルーティング機能を追加します。複数の部門にわたって複雑なワークフローを管理している場合は、アップグレードする価値があるかもしれません。

最初のSLAポリシーの設定

実際の設定について説明しましょう。開始する前に、重要な前提条件が1つあります。チケットに[優先度]フィールドが設定されている必要があります。SLAは優先度レベルに基づいて適用されるため、チケットに優先度が割り当てられていない場合、SLAはトリガーされません。

これを処理する最良の方法は、トリガーを使用することです。次のような基準に基づいて優先度を割り当てる自動ルールを設定します。

• 件名のキーワード（「緊急」、「ダウン」、「停止」）
• 顧客層（VIP顧客はより高い優先度を取得）
• チケットソース（チャットとメール）

それが完了したら、最初のポリシーを作成する方法は次のとおりです。

ステップ1：SLA設定に移動します

[管理センター] > [オブジェクトとルール] > [ビジネスルール] > [サービスレベル契約]に移動します。

ステップ2：ポリシーを作成します

明確でわかりやすい名前を付けます。「SLAポリシー1」よりも「標準サポートSLA」の方が適切です。このポリシーが適用されるチケットを決定する条件を定義します。一般的なアプローチは次のとおりです。

• すべてのチケット（包括的なデフォルト）
• 特定の組織からのチケット（VIP顧客）
• 特定のタグまたは優先度を持つチケット

ステップ3：指標を選択します

Zendeskは7つの異なるSLA指標を提供しています。すべてを有効にしないでください。まず、次の2つから始めます。

• 最初の応答時間： 問題を認識するまでの時間
• 1つの解決指標： 合計解決時間またはリクエスタの待機時間のいずれか

指標を追加すると、必ずしも価値が追加されるとは限らず、複雑さが増します。

ステップ4：優先度ごとにターゲットを設定します

優先度レベルごとに特定の時間ターゲットを定義します。一般的な開始点：

• 緊急：最初の応答1時間、解決4時間
• 高：最初の応答4時間、解決24時間
• 標準：最初の応答8時間、解決72時間
• 低：最初の応答24時間、解決1週間

これらは、願望ではなく、実際の能力に基づいている必要があります。2時間の目標を頻繁に違反するよりも、4時間の目標を一貫して達成する方が優れています。

ステップ5：営業時間と暦時間のどちらかを選択します

営業時間とは、定義された勤務時間中にのみ時計が進むことを意味します。暦時間とは、24時間365日進むことを意味します。グローバルな顧客を持つSaaS企業の場合、緊急の問題には暦時間の方が適切な場合がよくあります。

ステップ6：ポリシーを正しく順序付けます

Zendeskは、SLAポリシーを上から下に順番に適用します。最も制限の厳しいポリシー（VIP顧客SLAなど）を最初に配置し、次に広範なポリシーをその下に配置します。

主要なSLA指標の説明

各指標が実際に何を測定しているかを明確にしましょう。

応答時間指標：

• 最初の応答時間： チケットの作成から最初のエージェントによる公開応答までの時間。これは、認識指標です。顧客は誰かが自分の問題を見たことを知りたいと思っています。
• 次の応答時間： 顧客の最後のコメントから次の応答までの時間。これにより、会話が停滞するのを防ぎます。

更新時間指標：

• 定期的な更新： エージェントによる公開コメント間の最大時間。長期にわたる問題について顧客に情報を提供し続けるのに役立ちます。
• 一時停止可能な更新： 定期的な更新と同じですが、チケットが[保留]ステータス（顧客を待機中）の場合、時計が一時停止します。エージェントのワークロード追跡にとってより公平です。

解決時間指標：

• リクエスタの待機時間： チケットが[新規]、[オープン]、および[保留]ステータスで費やされる合計時間。顧客の実際の待機時間を測定します。
• エージェントの作業時間： [新規]および[オープン]のみの時間（[保留]は除外）。内部効率を測定します。
• 合計解決時間： 作成から解決までのライフサイクル全体。全体像の指標。

SaaSサポートチームの場合、通常、最初の応答時間と合計解決時間が最も重要です。最初から最後まで顧客の体験を捉えます。

内部説明責任のためのグループSLAの使用

グループSLAはEnterpriseのみの機能ですが、その階層にいる場合、またはアップグレードを検討している場合は理解する価値があります。

標準SLAが顧客体験を追跡するのに対し、グループSLAは内部チームの所有時間を追跡します。OLA（Operational Level Agreement（オペレーションレベル契約））と呼ばれることもあります。ユースケースは次のとおりです。チケットがサポートに入り、エンジニアリングにエスカレートされ、最終的な解決のためにサポートに戻ります。グループSLAを使用すると、チケットが各チームで費やされた時間を測定できます。

これは、内部のボトルネックを特定するのに役立ちます。全体の解決時間が48時間であるにもかかわらず、エンジニアリングがチケットを4時間しか保持していなかった場合、遅延が実際にどこで発生したかを知ることができます。

グループSLAは、部門間の引き継ぎも追跡できます。「サポートからエンジニアリングへの引き継ぎは2時間以内」または「エンジニアリングの応答は24時間以内」などの目標を設定できます。

1つの制限事項：グループSLAは、プライマリ所有権とエスカレーションを簡単に区別できません。チケットが複数回エスカレートされた場合、追跡はより複雑になります。

SLAパフォーマンスの最適化

SLAの設定は始まりにすぎません。これらの目標に対する実際のパフォーマンスを向上させるための実用的な方法を次に示します。

SLAベースのビューを作成します。 エージェントが常にすぐに注意を払う必要があるものを把握できるように、「次のSLA違反」でチケットを並べ替えます。この簡単な変更により、違反率を劇的に下げることができます。

積極的なエスカレーションにトリガーを使用します。 違反が近づいているときにチケットをエスカレートする（優先度を変更する、マネージャーに通知する、上級エージェントに割り当てる）自動ルールを設定します。

データに基づいて現実的な目標を設定します。 目標を設定する前に、過去のパフォーマンスを確認してください。過去四半期の平均最初の応答時間が6時間であった場合、2時間の目標を設定すると、常に違反が発生します。

速度と品質のバランスを取ります。 サポートにはドミノ・ピザの問題があります。30分での配達を約束した場合、ドライバーはスピードを上げ、ピザは冷たくなります。SLA目標が高すぎる場合、エージェントは急いで品質が低下します。徹底的で役立つ応答を可能にする目標を設定します。

四半期ごとに見直します。 ビジネスは変化します。SLAも同様です。数か月ごとに違反率、顧客からのフィードバック、およびチームの能力を見直し、必要に応じて目標を調整します。

AI自動化によるZendesk SaaS SLAに関する問い合わせ目標の達成

現実を言えば、SLAの構成が完璧であっても、人間の能力には限界があります。チケットの量が増加すると、何かを犠牲にする必要があります。SLA目標を達成できないか、チームを疲弊させるかのどちらかです。

ここで、AIが方程式を変えます。eesel AIはZendeskと直接連携し、人員を増やすことなく積極的なSLA目標を達成するのに役立ちます。

当社のAIエージェントは、最前線のサポートを自律的に処理します。過去のチケット、ヘルプセンターの記事、およびマクロから学習し、Zendeskで一般的な問い合わせに直接応答します。ルーチンな質問（パスワードのリセット、機能の説明、請求の明確化）については、AIが即座に最初の応答を提供し、量の急増時でも最初の応答時間を短縮できます。

より複雑な問題については、当社のAIコパイロットがエージェントが確認して送信するための応答を作成します。エージェントはゼロから始める代わりに、チームのトーンに一致し、適切なドキュメントを参照する、すぐに送信できる下書きを取得します。これにより、応答時間が大幅に短縮され、次の応答時間の目標を達成するのに役立ちます。

統合は、既存のZendeskワークフロー内で機能します。エージェントが学習するための個別のインターフェイスはありません。AIは、すでに作業している場所に表示されます。

公開する前に、過去のチケットでシミュレーションを実行して、AIが過去のSLAデータに対してどのように実行されるかを正確に確認できます。これにより、実際のお客様に触れる前に影響を測定できます。

価格設定は、Zendeskのエージェントごとのモデルとは異なります。eesel AIは、シートごとではなく、インタラクションごとに課金します。チームプランは、最大1,000回のインタラクションで月額239ドル（年間）から始まり、ビジネスプランは月額639ドルで、AIエージェント機能と過去のチケットに関するトレーニングが含まれています。

Zendesk SaaS SLAに関する問い合わせポリシーの開始

SLAを初めて設定する場合は、実用的なロードマップを次に示します。

まず、ベースラインを監査します。過去90日間の現在の最初の応答時間と解決時間を確認します。これにより、現実的な開始点が得られます。

次に、セグメントを特定します。VIP顧客は異なる目標が必要ですか？技術的な問題は、請求に関する質問とは異なる処理が必要ですか？異なる処理が本当に必要なセグメントに対して個別のポリシーを作成しますが、セグメント化しすぎないでください。3つのポリシーは管理可能です。10個は不可能です。

シンプルに始めます。最初の応答時間と1つの解決指標を有効にします。ベースラインデータに基づいて目標を設定します。後でいつでも複雑さを追加できます。

チームをトレーニングします。エージェントがSLAとは何か、なぜ重要なのか、違反が近づいているチケットを優先する方法を理解していることを確認します。

監視と調整を行います。最初の1か月間の違反率を監視します。目標を一貫して達成できない場合は、目標を調整するか、容量（人的またはAI）を追加します。

最後に、AI拡張がボリュームと目標に合っているかどうかを検討します。1時間以内の最初の応答が必要だが、24時間365日の人員配置を正当化できない場合は、AIエージェントが適切なソリューションである可能性があります。