このブラッシュアップセッションはすべてSLA（サービスレベルアグリーメント）に関するものです。
セッションの内容：
Zendeskでカスタマーサクセスコンサルタントの職に就く前、Sam Chandlerは、一介のZendesk管理者としてZendeskプラットフォームを利用し、カスタマーサービス部門の構築から発注処理までのすべてを行なっていました。以前はアトランタ地域のZendeskユーザーグループのリーダー的存在として活躍し、さまざまなウェビナーやイベント会場でカスタマーサービスのトピックについて講演していました。
また、他のブラッシュアップシリーズもぜひご覧ください。
パート1：SLAとは
サービスレベルアグリーメント... 1980年代の電気通信事業者がかつて漠然と抱いていたこの考えは、サービスを通じて差別化を図ろうとするあらゆる組織に採用されています。しかし、サービスレベルアグリーメント（SLA）とは正確には何であり、それは広大なカスタマーサポートの領域でどのような目的に役立つのでしょうか。これは絶えず変化し進化しているという考えですが、より幅広いカスタマーエクスペリエンスの他の多くの側面に取り組んでいるのは、ビルディングブロックです。
気にかけたほうがよい理由は何ですか？
SLAをワークフローに組み込むと、最終的な#custservの目標を効率良く達成できるからです。尋ねる理由は何ですか？調査結果が示しているからです。応答時間SLAについてITユーザーに最近行なった調査によると、SLAを導入していない企業に比べて、平均応答時間が200倍速いことが報告されています。さらに、SLAを確立するだけで、意識が改善される可能性があります。また、この調査では、SLAを採用しているほとんどのお客様において、サービスプロバイダーがこれらの契約条項を満たしているものと確信していることがわかりました。
この「ブラッシュアップシリーズ」のパート1では、SLAの種類のいくつかと、それらをどのように現行のサポートエコシステムに適合させることができるかについて説明します。
用語を定義する
サービスレベルアグリーメント（SLA）は、表向きは、サービス内容が正式に規定され、サービスの特定の側面がサービスプロバイダーとサービス利用者との間で合意されるサービス契約の一部として定義されます。しかし非公式には、実際にはエンドユーザーに標準化されたサービス品質を確保するにとどまっています。
Zendeskでは、サービス目標を定義することでSLAを確立し、サービス目標に関連する数値を監視し、最終的にそれらの目標を達成することができます。サポートポータルにSLAポリシーを作成すると、サービスレベルの目標を達成できないチケットの可視性が強化され、すばやく対処することができます。
ZendeskのSLAポリシーには所定の構成があります。各SLAポリシーには以下のものが含まれます。
- SLAポリシーを適用するために、チケットが満たさなくてはならない条件セット。
- 必要な個々の測定基準と優先する値を達成するための目標時間。
- 測定項目に選択したひとつ以上の測定基準。
- 目標を営業時間とカレンダー時間のどちらで測定するかを指定する優先する値
カスタマーサービスへのSLAポリシーの最適な組み込み方法を決定するために、SLA構成の主なタイプをいくつかを調べてみましょう。
-
顧客ベース：個々の顧客またはグループとの合意
例：稼働時間の保証を顧客の契約に条項として記載している電気通信会社 -
サービスベース：特定のサービスまたは製品のすべての利用客に対する合意
例：注文のピザが30分以内に配達されなかった顧客にピザの無料提供を約束するピザ店
これらの種類を個別に使用したり、組み合わせたりして、いくらでもサービスモデルを作れます。もちろん、組織としての判断や顧客へのサービス保証の方法次第でその数も決まります。
組織でZendesk SLAポリシーを使用する方法
Zendesk SLA機能の最大の強みの1つは、その適応性です。サポートポータルが会社のより大きなSLAパズルの一部である場合も、あるいは全体を構成している場合も、組織のより多くのKPI、あるいは2つの組み合わせさえも満たせるよう、上記のタイプに基づく目標を作成するのは簡単です。
使用するSLA測定基準を決定する
Zendesk SLAポリシーは4つの測定基準に基づいています。最初の応答時間、次の応答時間、リクエスタの待ち時間、およびエージェントの作業時間。
最初の2つのメトリックは応答時間に基づいていますが、後者の2つは解決時間に基づいています。解決策ベースの測定基準は一度に1つしか使用できませんが、応答時間関連の測定基準は同時に複数使用できます。それでは、どうやってこれらの点をつないで、自分に合ったポリシーを作成するのでしょうか。以下は、ZendeskのSLA機能で利用可能な測定基準を利用するサービスベースおよび顧客ベースのSLA構成の例です。
可能なSLA構成の例
サービスベースの構成
サービスレベルアグリーメントに始めて手を着けてみるには、これは最善の方法です。特定の顧客にサービスを保証する体系的な契約保証サービスを本格的に開始する前に、すべてのチケットのサービス基準を設定してチームのスキルを磨くことができます。また、これにより、サポートエージェントのサービス基準遵守のプレッシャーを緩和できるだけでなく、すべての顧客に対してサポートの効率性が全体的に向上します。
- 例1：最初の応答時間または全体解決時間に会社の目標を設定し、すべてのチケットにSLAを適用する（使用する測定基準：初回応答時間、リクエスタ待機時間）
- 例2：各エージェントのチケット処理時間の目安を設定して、新人エージェントをトレーニングします（使用する測定基準：エージェント作業時間
全体的な解決時間を監視するためのSLA
顧客ベースの構成
Zendeskを使用して顧客ベースのSLAを構築する方法はいくつかあります。顧客ごとに1つのSLAを設定し、それぞれに異なる標準を含めることができます。特定の特性に基づいて顧客をグループ化することもできます。個々の顧客との間で設定したSLA契約を尊重することができ、また、SLA機能によって特定の優先する値に集中することもできます。
- 例1：組織のオープンチケットに少々の愛が必要な場合に知らせるポリシーを設定することで、顧客とのSLA契約に積極的に対応します（使用する測定基準：次の応答時間、リクエスタ待機時間）
- 例2：TwitterまたはFacebookのチャンネルを通じてチケットを送信する人の応答時間を監視するためのSLAを確立することで、ソーシャルメディアサポートのプレゼンスを最適化します（使用する測定基準：初回応答時間、リクエスタ待機時間）
ソーシャルメディアチャネルのSLAポリシー*
ご注意: スペースがないため、ここではZendeskが提供するソーシャルメディアチャンネルを2つしか挙げませんでしたが、最適な結果を得るためには、FacebookやTwitterのある限りのオプションをすべて「あらゆる」条件に含めることをお勧めします。
やる気満々で自身のSLAポリシーを始めようというのに、まだもう少しインスピレーションが必要ですか？Zendeskユーザーの仲間がSLA機能を使用した素晴らしい方法の事例をいくつか見てみましょう。
- Mat Cropperによる拡張SLAの使用
- Mat CropperによるチケットSLAに基づく、トリガ、自動化、およびレポートの実行
- Tloによる営業時間が異なる複数のSLAを設定する方法
会話の切り出し
- SLAポリシーを確立する際に、組織はどんなSLA測定基準を使用しますか？
- ZendeskのSLA機能を使用した革新的な方法の例をいくつか共有してください
パート2：ビジネスルールパズル
SLAはワークフロー作成ではありません
SLAとはどのようなものか理解が深まったら、次はSLAを実践させます。ただし、SLAがすべての問題を解決するわけではないことを忘れないでください。サービスレベルアグリーメントは単なる契約です。顧客との関係は信頼の上に成り立つものですが、それでも予防的な注意が必要です。
この「ブラッシュアップシリーズ」のパート2では、SLAをより大きなワークフローに組み込む方法について説明します。
SLAの優先順位への道を見つける
SLAは、設定した後は忘れることができるスタンドアロン機能ではありません。ワークフローをパズルと考えると、SLAはトリガー、マクロ、自動化、およびその他すべてのZendesk機能と共に1つの要素に過ぎません幸い、Zendeskポータルはさまざまなワークフロー設計に適応できます。それはあなたにとって最適な方法を見つけることです。
どんなワークフローでも、いつもお勧めすのるは、簡単に始めて必要に応じて構築を進めていくことです。まず初めに優先する値を1つ選び、それを中心に設計していくべきです。パート1で述べたように、優先する価値は、組織が何を最重要視するかによって異なります。それを知る前に、複数のワークフローが有機的に浮かび上がくるでしょう。そのうちのいくつかはおそらく絡み合い、他のものは完全に独立したままでいます。
優先する値の例
- 「私たちは、顧客に一定の応答時間を保証する有料サービスレベルを設定しました。」
- 「Zendeskポータルに新しい部門を追加しました。これで解決時間を監視することができます」
- 「Twitterから送信されたチケットが特定の期間内に確実に送信されるようにします。」
Samがおすすめするワークフローの設計
以下のチャートに、Zendeskのワークフローを一般的に作成するときの順序を示しました。人生のたいていのものと同様に、この順序はあなたのプロジェクトや意図によって常に変わることに注意してください！
特にSLAワークフローを設計しているときに注意することの1つは、Zendesk SLAポリシーが「優先」チケットフィールドと連携することです。これは、ワークフローの推進に使用している「優先する値」とは異なります。ZendeskでSLAポリシーを作成するには、この機能を正しく機能させるために、チケットフォームの「優先」チケットフィールドを利用する必要があります。
Zendesk SLAポリシーの使い方については、こちらをご覧ください。
Zendeskでワークフローを作成する際の推奨事項
注意事項：
- カスタムフィールドは、ワークフローを成長させるための種として考える傾向があります。ワークフロー用に作成した他のビジネスルールで使用するために、チケットフォーム、ユーザー、または組織にカスタムフィールドを1つも追加する必要がないというようなことは滅多にありません。
- 各ビューの列のフォーマットを制御できることを知っていましたか？SLAターゲット用のカスタムビューを作成するときは、必ず「Next SLA Breach」列を含めてください。ビューをCSVファイルとしてエクスポートすることもできます。そのため、このビューに関連する列を（適切な順序で）表示するようにしてください。
- マクロは私のお気に入りのZendesk機能の1つです。これは素晴らしいワークフローのサンデーの桜のようなものです。私はマクロを使用して、特に新しいワークフローを導入するときに、全員が同じページにアクセスできるようにします。一度に複数の機能を実行するマクロを作成することができれば、エージェントがこれらのステップをすべて覚えておく必要がなくなるため、エラーを減らすことができます。追加のボーナス：顧客からの問題の相談でエージェントが使用する回答集ライブラリをマクロを使用して作成すれば、企業として一貫したメッセージングや、そして最終的にはブランドの統一にも役立ちます。
SLAポリシーを組み込んだワークフローの例
シナリオ：企業は、サイトの停止が1時間以内に解決されることを保証する条項を顧客の契約に追加したいと考えています。
どうしたら良いでしょうか？
- 停止チケットを自動的に優先する
- 解決するまでの時間をエージェントに知らせる
- 問題が解決したら顧客に通知する
- SLAを満たせなかった場合は監督者に警告する
1) カスタムフィールド
- [Enterprise] 「障害」というチケットフォームを作成し、関連するすべての情報のフィールドを含めるまたは作成する
- [Professional] Webフォームに「問い合わせ理由」というドロップダウンのチケットフィールドを作成し、「障害」という項目を含める
2) SLA
条件：
- [Enterprise] チケットフォームは「障害」で、組織は[顧客名]とする
- [Professional] 「問い合わせ理由」は「障害」で、組織は[顧客名]とする
以下のアクションを実行：
リクエスタの待機時間
- 緊急 = 1時間
- 高、普通、低 = 24時間（または任意の目標解決時間）
3) トリガ
デフォルトの「リクエストの受信をリクエスタに通知」を複製し、「障害レポートを[顧客名]に通知」という名前を付けます。
デフォルトの条件はそのままにして、以下を追加します。
- [Enterprise] チケットフォームは「障害」で、組織は[顧客名]とする*
- [Professional] 「問い合わせ理由」は「障害」で、組織は[顧客名]とする*
*デフォルトの通知を改変して上記の条件を除外し、2つの通知が発生しないようにする必要があります
以下のアクションを実行：
- チケットの優先度 - 緊急
- 通知：メールユーザー = リクエスタ（顧客へのメッセージを改変し、保証された解決時間について言及する）
- 通知：メールグループは[障害対処チーム]
4) 自動化
条件：
- チケットステータス より小さい 解決済み
- [Enterprise] チケットフォームは「障害」または[Professional] 「問い合わせ理由」は「障害」
- 組織は[顧客名]
以下のアクションを実行:
- 「SLAbreach」タグを追加
- 通知：メールユーザーは[グループの責任者]
5) ビュー
SLA違反ビュー（下記の「Bは違反を意味する」を参照）
- チケットステータスは「より小さい 解決済み」
- チケットタグには「SLAbreach」が含まれる
障害ビュー
- チケットのステータスは「より小さい 解決済み」です。
- [Enterprise] チケットフォームは「障害」または[Professional] 「問い合わせ理由」は「障害」
6) マクロ
- チケットステータスは「解決済み」
- チケットタイプは「問題」
- チケットコメント障害が解決したことと、問題が解決しない場合の連絡方法を顧客に伝える
Bは違反を意味する
あなたのチームは優秀なので、おそらく新しいSLAをチームのワークフローにシームレスに取り入れることでしょう。それでも、やむを得ずSLA違反を経験する時のためにプロセスを作成しておくことは重要です。このプロセスには、少なくとも違反の発生をエージェントまたはスーパーバイザーに警告するためのZendeskのワークフローを含める必要がありますが、SLA目標をいつも守れていないエージェントを特定して指導するためのプロセスの導入も検討する必要があります。
例：
- SLA違反についてスーパーバイザーやエージェントに通知するための自動化を作成する
- SLA違反用のカスタムビューを作成する
- SLA違反をタグ付けする自動化を作成する。各エージェントの違反数に基づいてレポートやビューを作成すれば、後で指導することができます。
ワークフローを監査する
ワークフローとビジネスルールを定期的に監査して、それらがまだ有効であることを確認することも実践的です。特に、契約したSLAを扱う場合は特にそうです。Enterpriseプランのユーザーは、監査プロセスを支援するために、ルールのプロパティ分析機能を利用することができます。ただし、すべてのプランのユーザーは、定期的にビジネスルールを監査し、そのたびに関連性が失われていないことを確認できます。
会話の切り出し
- SLAにどのようなビジネスルールやその他のZendesk機能を使用しますか？
- SLAを中心にワークフローを作成する際には、どのような考えを念頭に置いていますか？
パート3：これでSLAを構築できました。すばらしい。次に行きましょう。
SLAと洞察
世界で最も美しく構築されたSLAワークフローを設定できますが、データを分析して目標を確実に達成するために必要な手順を踏まない限り、これらは意味がありません。
この「ブラッシュアップシリーズ」のパート3では、SLAポリシーを確立した後に必要になる実践について説明します。
SLAのパズルを完成させるための最後のステップは、インサイトレポートを実装することです。インサイトのSLAレポートは月末までに利用可能になる予定ですが、SLA目標のデータで、今すぐインサイト内で分析できるものがまだたくさんあります。SLA契約によっては、サービスプロバイダーとの間でフォローアップを行い、契約の終了を遅らせるために顧客のチェックポイントが含まれているものがあります。
インサイトは、さまざまな方法でこれを支援します。
- 常に最新の統計情報を収集が得られれば、どのような問題でも手遅れにならないうちに積極的に解決することで、顧客のチェックポイントミーティングの近くになったときに、ちょっとした障害があっても対処することができます。さらに、顧客が苦情を訴えてきた場合にも、あなたの立場を支えるために独自のデータを持つことは助けになります。
- 顧客があなたに助けを求めるのを待つ必要もありません。さらに一歩進め、インサイト内でスケジュールできるダッシュボードレポートを積極的に送信します。それは、結果を出すあなたの能力ついて揺るぎない自信を示すと同時に、あなたの能力に対する顧客の確信と信頼を築くのにも役立ちます。 インサイトレポートの共有について詳しくは、このKB記事をご覧ください。
意味のある測定基準
インサイトは、考え得るあらゆる測定基準でほとんど満たされた非常に強力なレポート作成ツールです。では、どのようにして意味のあるKPIを決定しますか？あらゆる人のためにすべての質問に答えることができる「すべてを終わらせてすべてになる」という測定基準はありません。ワークフローやSLA自体と同じように、組織の価値観に基づいています。SLAに関連していることから、監視に役立つ以下のような測定基準があります。同じ測定基準を説明するためにさまざまなサポート環境で使用されている用語も含めました。
- 解決時間：ターンアラウンドタイム（TAT）とも呼ばれる
- ワンタッチ解決：ファーストコール解決（FCR）とも呼ばれる
- 初回応答時間：平均応答時間（ASA）とも呼ばれる
- サポートを待つ時間
- セルフサービスによって解決された要求（ナレッジベース）
- CSAT / NPS *→顧客がまだ満足していないのであれば、他の数値は関係ありません。
*満足度評価は、公式の顧客レビューの前にチェックポイントとしても機能します。
エージェントのトレーニング
チーム全体が期待に応えられるようにすることも重要です。優先する測定基準を決定したら、エージェントに知らせて、それに従って処理させるようにします。測定基準やレポートを社内のナレッジベースに投稿するか、あるいはインサイトか、チームがアクセスできる場所にSLAダッシュボードを維持します。組織のシニアリーダーが報告書のコピーを確実に受け取るようにすることに重点を何度も置いていますが、組織としてあなたの立ち位置をチーム全体に知らせておくようにすることは健全です。
最も重要なことは、あなたのエージェントのKPIがあなたのSLAやその他の目標とも一致させるようにすることです。たとえば、会社のKPIに解決時間またはCSATの目標が含まれている場合は、定義された時間枠（タイムサービスファクタ）にエージェントが受け取るリクエストの数についてエージェントを測定することを考え直してみる必要があります。できるだけ多くのリクエストを処理してタイムサービスファクタの目標を維持しようとしているエージェントは、顧客の問題を完全に解決することなく、多くのチケットに対応したり、チケットを急いで片付けるなどで顧客の満足度を下げることがあります。また、他の測定基準を犠牲にして1つの測定基準だけに集中はさせたくはないものです。初回応答時間は確かに重要ですが、担当者が最初の問い合わせにすばやく返信することに集中していることは望ましくありません。
会話の切り出し
- SLAに関して最も重要な測定基準は何ですか？
- どのようにして契約上の義務を離れてSLAの関係を育てますか？