ZendeskのSLAとグループSLA：より良いサポートワークフローのために、それぞれの使い分け

もしあなたがZendeskのインスタンスを管理しているなら、SLAポリシーには2つの種類があることに気づいているかもしれません。標準SLAはずっと以前から存在しています。グループSLAは2023年後半に登場しました。そして、どちらをいつ使うべきか疑問に思っているなら、それはあなただけではありません。

この混乱はもっともです。どちらも時間を追跡します。どちらもビューに表示されます。どちらも違反する可能性がありますが、測定するものは全く異なり、目的も異なります。間違った方を使用したり（または両方が必要なときに片方だけを使用したり）すると、サポート業務に盲点が生じることになります。

各ポリシータイプが正確に何をするのか、どちらが必要なのか、そしてそれらを一緒に使用する方法を詳しく見ていきましょう。

Zendesk SLAポリシーとは？

標準のZendesk SLAポリシーは、顧客向けの合意です。これは、あなたのチームがチケットに対応し、解決することを約束する速さを定義します。これらは、契約で明示的に、または内部目標として暗黙的に、顧客に対して行う約束です。

標準SLAは、いくつかの指標を追跡できます。

これらのポリシーは、ZendeskのSuite Professionalプラン以上で利用可能で、年間請求の場合、エージェント1人あたり月額115ドルからとなります。

設定は、管理センターの「オブジェクトとルール」>「ビジネスルール」>「サービスレベルアグリーメント」で行います。特定の条件（「グループはサポート」や「チャネルはメール」など）を持つポリシーを作成し、各優先度レベルの時間目標を設定します。

Zendeskの管理センターは、これらの顧客向けのコミットメントを設定するためのインターフェースを提供します。設定が完了すると、標準SLAはチケットビューに表示され、目標が危険にさらされている場合に通知をトリガーします。

要するに、顧客へのコミットメントに影響を与える場合は、標準SLAポリシーに含めるべきです。

ZendeskグループSLAポリシーとは？

グループSLAポリシーは、内部合意です。運用レベル合意 (OLA) とも呼ばれ、チケットが特定の内部チームに割り当てられたままになる時間を測定します。これらは顧客へのコミットメントに関するものではありません。内部の説明責任に関するものです。

グループSLAは、担当時間 (Ownership Time) という1つの指標のみを追跡します。これは、チケットがグループに割り当てられてから、他の場所に再割り当てされるか、解決されるまでの期間を測定します。チケットが別のグループに再割り当てされた場合、そのグループの担当タイマーが新たに開始されます。

これらのポリシーは、Suite Enterprise以上でのみ利用可能で、エージェント1人あたり月額169ドルからとなります。これはエージェントあたり54ドルの増加なので、実際に必要かどうかを確認する必要があります。

主なユースケースは、複数チームのワークフローです。Tier 1サポートチームから始まり、払い戻しの承認のために財務部門にエスカレーションされ、解決のためにサポートに戻ってくるチケットについて考えてみてください。グループSLAを使用すると、顧客の全体的な解決コミットメントに影響を与えることなく、「財務部門は4時間以内にエスカレーションを処理する必要がある」のような目標を設定できます。

Zendesk SLA vs グループSLA：主な違い

これらを並べて比較して、何が違うのかを正確に見てみましょう。

対象者と目的 (Audience and purpose)

標準SLAは外向きです。顧客があなたに期待できることを定義します。グループSLAは内向きです。チームが互いに期待できることを定義します。

測定される指標 (Metrics measured)

標準SLAでは、5つの指標を使用できます。グループSLAでは、1つの指標を使用できます。その単一の指標（担当時間）は、内部追跡には強力ですが、顧客向けのコミットメントには役に立ちません。

プランの要件 (Plan requirements)

出典：Zendeskの価格ページ

設定の柔軟性 (Configuration flexibility)

標準SLAを使用すると、条件を自由に設定できます。チャネル、フォーム、組織、タグなどでフィルタリングできます。グループSLAは制限されています。フィルタリングできるのは...グループのみです。それだけです。VIP顧客からの緊急チケットにのみ適用されるグループSLAを作成することはできません。その優先度ロジックは別途処理する必要があります。

標準Zendesk SLAポリシーを使用する場合

標準SLAは、ほとんどのシナリオに適した選択肢です。次の場合に使用します。

シングルチームのワークフローがある場合。 Tier 1が最初から最後までほとんどのチケットを処理する場合、標準SLAで必要なものがすべて揃います。

顧客へのコミットメントを行っている場合。 契約に記載されている、または顧客に宣伝しているSLAは、標準SLAである必要があります。

チャネルベースの差別化が必要な場合。 メールとチャットでは期待値が異なります。標準SLAを使用すると、チャネルベースの条件を使用して、メールに4時間の目標、チャットに2分の目標を設定できます。

顧客層によって差別化する場合。 VIP顧客はより迅速な応答時間を取得します。標準SLAは、組織またはタグの条件を使用して、異なる顧客セグメントに異なる目標を適用できます。

条件に柔軟性が必要な場合。 チャネル、フォーム、優先度、カスタムフィールドの条件を組み合わせる機能により、標準SLAは複雑なルーティングシナリオに適応できます。

実際の例：eコマース企業は、メールチケット（8時間の最初の返信）用の標準SLAと、メッセージング（5分の最初の返信）用の別の標準SLAを持っている場合があります。どちらのポリシーもチャネルでフィルタリングし、次にグループでフィルタリングして、各コミュニケーション方法に対する明確な期待を作成します。

グループSLAポリシーを使用する場合

ワークフローが複雑になると、グループSLAが必要になります。次の場合に検討してください。

チケットが複数のチームを通過する場合。 解決にサポート、財務、法務、または製品チーム間の引き継ぎが必要な場合、グループSLAは各チームの貢献を個別に追跡します。

内部のボトルネックを特定する必要がある場合。 チケットが顧客向けのSLAに違反した場合、Tier 1が遅かったからですか？それとも、財務部門が払い戻しを承認するのに3日かかったからですか？グループSLAを使用すると、その可視性が得られます。

チーム固有の説明責任が必要な場合。 各グループは、独自の担当目標を持つことができます。財務部門は払い戻しの承認に4時間、製品部門はバグの検証に24時間かかる場合があります。

外部のコミットメントが内部の効率に依存する場合。 顧客に24時間以内の解決を約束しているが、内部の引き継ぎでその時間の半分が費やされることがわかっている場合、グループSLAは内部の部分を管理するのに役立ちます。

払い戻しの例を実際に見てみましょう。顧客が払い戻しをリクエストします。サポートはチケットを作成し、資格を確認し、4時間のグループSLAで財務部門に割り当てます。財務部門は承認し、チケットをサポートに戻します。サポートは払い戻しを処理し、チケットを閉じます。顧客には全体の解決時間のみが表示されます。しかし、内部的には、財務部門がチケットを保持していた時間を正確に確認できます。

知っておくべき重要な制限事項： グループSLAは、チームが主要な所有者であるか、エスカレーションを受けているかを区別できません。また、JiraやSlackのサイドカンバセーションのような外部システムで費やされた時間を追跡することもできません。それらがワークフローにとって重要な場合は、回避策または代替の追跡方法が必要になります。

Zendesk SLAとグループSLAポリシーを一緒に使用する

最も洗練された設定では、両方のポリシータイプをレイヤーで使用します。その仕組みは次のとおりです。

レイヤー1：標準SLAは顧客への約束を追跡します。 これはあなたの公約です。「緊急チケットには1時間以内に返信し、8時間以内に解決します。」

レイヤー2：グループSLAは内部効率を追跡します。 「財務部門はエスカレーションを処理するのに2時間かかります。製品部門はバグレポートを検証するのに4時間かかります。」

これらを組み合わせることで、完全な可視性が得られます。チケットが顧客SLAに違反した場合、ドリルダウンして、どの内部グループが遅延の原因となったかを確認できます。

補完的なポリシーの設定 (Setting up complementary policies)

まず、標準SLAを基盤として使用します。コミットメントに基づいて顧客向けの目標を設定します。次に、チケットがエスカレーションされるチームにグループSLAを追加します。

例：

• 標準SLA：「緊急チケットは1時間以内に最初の返信、8時間以内に解決」
• 財務部門のグループSLA：「緊急チケットの財務部門の担当目標：2時間」
• 製品部門のグループSLA：「緊急バグの製品部門の担当目標：4時間」

ビューの設定 (View configuration)

SLAとグループSLAの両方の列をビューに追加します。エージェントは、顧客向けのカウントダウンと内部の担当タイマーを並べて確認できます。SLAで昇順にソートして、違反に最も近いチケットを表示します。

知っておくべき1つの癖：両方のSLAタイプで同時にソートすることはできません。ビューは一度に1つの列でのみソートできます。ほとんどのチームは、顧客へのコミットメントに影響するため、標準SLA列でソートします。

Zendesk Exploreでのレポート (Reporting with Zendesk Explore)

真の力はレポートにあります。標準SLAは、顧客向けの指標にフィードされます。グループSLAを使用すると、内部効率ダッシュボードを構築できます。次のレポートを作成できます。

• 全体的なSLA達成率（顧客ビュー）
• グループ固有の担当達成率（内部ビュー）
• ボトルネック分析（どのグループが最も違反の原因となっているか）

この階層化されたアプローチにより、SLA追跡は単純な監視ツールからサポート業務の診断システムに変わります。

AIがZendesk SLAの目標達成にどのように役立つか

SLAを追跡することは重要です。しかし、一貫して目標を達成することが実際に重要です。そこでAIが役立ちます。

私たちは、Zendeskと連携して、チームがより確実に目標を達成できるようにeesel AIを構築しました。SLA戦略における適合方法を次に示します。

AIエージェントによる即時の最初の返信。 パスワードのリセットや注文状況の確認のような一般的な質問については、AIエージェントが即座に応答できます。これにより、最初の返信時間が数時間または数分から数秒に短縮されます。Zendeskと直接統合され、過去のチケットから学習して、あなたの声に合わせます。

AIコパイロットによる迅速な解決。 人間のタッチが必要な複雑なチケットについては、AIコパイロットが知識ソースから取得して返信を下書きします。ヘルプセンター、Confluence、Googleドキュメント、または過去に解決されたチケットのいずれであっても、エージェントは回答を探す代わりに数秒で正確な下書きを取得できます。

展開前にテスト。 シミュレーションモードを使用すると、AIの応答を過去のチケットに対して実行できます。実際のお客様に対してオンにする前に、SLA指標にどのように影響したかを正確に確認できます。

その結果、人員を増やすことなくSLAパフォーマンスが向上します。SLA追跡戦略の詳細については、Zendesk SLA追跡に関する完全なガイドをご覧ください。

Zendesk SLAポリシーを設定する際の一般的な間違い

経験豊富な管理者でもこれらのエラーを犯します。最初から避けてください。

チケットの優先度を設定しない。 優先度が設定されていないチケットにはSLAは適用されません。トリガーを使用して、チケットの属性に基づいて優先度を自動的に割り当て、何も見落とさないようにします。

ビジネス時間がより理にかなっている場合に、カレンダー時間を使用する。 あなたのチームが午前9時から午後5時まで働く場合、SLAをカレンダー時間で測定しないでください。金曜日の午後6時に作成されたチケットは、土曜日の朝までに違反するべきではありません。

ポリシーを多すぎること。 各ポリシーはメンテナンスのオーバーヘッドを追加します。いくつかの広範なポリシーから始め、異なるセグメントに異なる目標が必要であるという明確な証拠がある場合にのみ分割します。

外部のエスカレーションを無視する。 グループSLAは、Jira、Slack、またはサイドカンバセーションでの時間を追跡できません。これらの引き継ぎが重要な場合は、プレースホルダーワークフローまたは手動追跡を構築してギャップを埋めます。

過去のデータなしで目標を設定する。 SLA目標を推測しないでください。過去90日間の実際のパフォーマンスを見て、達成可能な目標を設定します。いつでも後で厳しくすることができます。

レビューまたは調整しない。 SLAは設定して忘れるものではありません。違反率を毎月確認してください。100％の達成率を達成している場合は、目標が緩すぎる可能性があります。常に違反している場合は、非現実的であるか、より多くのスタッフが必要になる可能性があります。

正しいZendesk SLA戦略を開始する

意思決定の流れは次のとおりです。まず、標準SLAから始めます。これらは下位層のプランで利用でき、構成がより柔軟で、ほとんどのユースケースをカバーします。複雑な複数チームのワークフローがあり、内部の引き継ぎを個別に追跡する必要がある場合は、グループSLAを追加します。

SLAが多いほど可視性が向上するわけではないことを忘れないでください。チームが実際に理解し、一貫して達成できる適切に設計されたいくつかのポリシーは、混乱を生み出す重複するルールの複雑なWebよりも優れています。

SLAパフォーマンスの向上を目指している場合は、自動化が役立つ場所を検討してください。最初の返信時間の目標を達成する最も速い方法は、待機を完全に取り除くことです。eesel AIのようなツールは、一般的なチケットを即座に処理でき、人間のエージェントは本当に専門知識を必要とする複雑な問題に集中できます。

AIがSLA指標にどのように影響するかを確認する準備はできましたか？数分でeesel AIをZendeskに接続し、ライブになる前に過去のチケットに対してテストできます。