ウィザードを使用した Service Analytics の作成

あなたは DTC のシステム管理者と共に、大量のデータ分析、計算、レポート、クエリなど拷問のような経験をする覚悟を決めていました。ただし、意外にもあなたがすべきことは、アプリケーションの設定ウィザードでビジネスに関するいくつかの質問に答えることだけでした。システム管理者は「私はアプリケーションをいろいろと試し、もっと詳しく知るために Salesforce 担当者の 1 人と一緒に作業しました。これは使いやすいウィザードで、時間もそれ程かかりません。」と言います。

ウィザードの質問の多くは、サービスビジネスの管理に使用する Salesforce オブジェクトや項目について「はい/いいえ」で答えるだけの質問です。わからない場合は「いいえ」と答えて構いません。オブジェクトや項目を使用していない場合に「はい」と答えると、アプリケーションのダッシュボードやデータセットでエラーが発生します。そのため、わからない場合は「いいえ」を選択してください。

1. 1 つ前の単元「Service Analytics の使用開始」で設定したばかりである組織にログインします。
2. アプリケーションランチャー () で、[Analytics Studio] を見つけて選択します。

Analytics Studio を初めて開くと、ようこそ画面が表示され、使用を開始するのに参考となるリソースが紹介されます。この画面は閉じてもかまいません。いつでもヘルプメニューから再び開くことができます。右上にある疑問符をクリックしてヘルプメニューを開き、[Analytics へようこそ] を選択します。

では、Service Analytics アプリケーションを作成します。

1. Analytics Studio で、右上の [Create (作成)] ボタンをクリックし、[アプリケーション] を選択します。
2. テンプレートをスクロールし、[Service Analytics for Trailhead] を見つけて選択します。
   重要: 注意して Service Analytics for Trailhead というアプリケーションのみを選択してください。正しく選択しないと、作成するアプリケーションが Trailhead の説明と一致しなくなります。
3. [続行] をクリックして、次のページの [続行] をクリックします。
4. 互換チェックが実行され、アプリケーションの作成に必要なすべてのデータが組織に含まれていることが確認されます。この特別な Developer Edition 組織は適切なデータをすべて含むように設定されています。(独自の組織で Service Analytics を作成した場合、エラーメッセージが表示され、問題の解決方法が示される場合があります)。互換性チェックを実行して数秒間待機します。続いて、[Next (次へ)] をクリックします。
5. [カスタム] を選択して、[Next (次へ)] をクリックします。
6. ウィザードの最初のページには、サポートケースに使用するメトリクスに関する詳細が表示されています。
   メモ: 組織によって、Service Analytics でウィザードに表示される質問はこの画面とは異なる場合があります。ウィザードの機能は、お客様のニーズにお応えして定期的に更新されています。
   
7. 最初の質問「What primary field do you use to track case duration?」 (ケースの所要時間を追跡するために、どのプライマリ項目を使用すればいいですか?)あなたが探している KPI の 1 つはケースの所要時間 (チームでケースをクローズするのに要する時間) であるため、これは重要に見えます。所要期間のカスタム数式項目がない場合は、項目を空白にするよう記載されています。
   システム管理者によると Service Cloud データのカスタム数式は作成されたことがないため、この質問と次の質問は空白にします。
   参考までに、独自のカスタム数式がない場合、Service Analytics でケースの所要時間が算出されます。ケースがクローズしていない場合、ケースの作成日と今日の間の期間が算出されます。クローズしている場合、作成日とクローズ日が使用されます。
8. 次に「What field do you use to track whether cases are within the bounds of an SLA?」 (ケースが SLA の範囲内にあるかどうか追跡するには、どの項目を使用すればいいですか?) という質問を見てみましょう。回答の選択肢を見ていきます。担当者のメール、顧客の絵文字、古い説明など、多くの値はこのコンテキストでは意味をなしません。適切な回答を見つけるまで探します。ページの下部付近に、[SLA Type (SLA 種別)] があります。この値は SLA を指しているため、いくらか意味をなします。ただし、必要な項目は、対象として含む SLA の種別ではなく、ケースが SLA の範囲内にあるかどうかを示す項目です。
   管理者は、ケースが SLA の条件を満たさない場合に知らせるために使用する、[SLA 違反] を選択するよう指示します。
9. 「Which field do you use to track first contact resolution?」 (初回連絡での解決を追跡するには、どの項目を使用すればいいですか?) までページを下にスクロールします。
   回答に目を通していくと、そのほとんどが明らかに当てはまらないことがわかります。明らかに正しい回答、[First Contact Resolution (初回連絡での解決)] を選択します。
10. 最後の質問では、会計年度の開始日が尋ねられます。横に赤のアスタリスク (*) が表示されています。これは質問への回答が必要であることを意味します。デフォルトでは 1 月で、これは DTC で使用される月です。デフォルト値をそのままにして、[Next (次へ)] をクリックします。

わかりやすい質問です。ウィザードではデフォルトの回答に対して多くの作業が行われていることにお気づきでしょう。値を選択する必要があるとき、ほとんどの場合は選ぶべき値が明らかです。システム管理者が言ったとおり、それ程大変ではありません。次のステップに進みましょう。

1. 最初の質問「What field do you use to track the status of a case?」 (ケースの状況を追跡するには、どの項目を使用すればいいですか?) の横にはアスタリスクが付いるので、回答が必要です。回答項目には [状況] が事前入力されています (DTC では、ちょうどこのデフォルト値を使用します)。
   このため、この質問への作業は不要です。
2. 質問 2 に移動します。この質問は、サポートレベルの記録に使用する項目についての質問です。回答項目に [項目を選択] が表示されています。デフォルト値はありません。[SLA Type (SLA 種別)] を選択します。
3. 次に「What field do you use to identify the product associated with the case?」 (ケースに関連付けられている商品を特定するには、どの項目を使用すればいいですか?) という質問に移動します。[商品] と [商品ファミリー] の両方が表示されています。システム管理者は、DTC に多くの商品があることを知っています。商品ごとにケースを見ていくと、必要以上の詳細が表示されます。
   わかりやすいカテゴリのみに基づいてケースを調べるために、[商品ファミリー] を選択します。
4. 「What field do you use to view data by geography?」 (場所別にデータを表示するには、どの項目を使用すればいいですか?) までスクロールします。場所データに使用する取引先オブジェクトから項目を指定 (すぐ前の質問に対する回答) するように求められます。質問に関連する回答として、取引先住所、市区郡 (請求先)、国 (請求先) などがあります。
   システム管理者は、あなたが [国(請求先)] を使用することを知っているため、これを選択します。
5. 回答が必要なアスタリスクの付いた質問はもう他にはありません。システム管理者は質問 10 「Do you use the record type field to distinguish your cases?」 (ケースを区別するのに [レコードタイプ] 項目を使用しますか?) で立ち止まりました。システム管理者は、[レコードタイプ] 項目がユーザーの組織に対して有効化されていないことを伝えます。
   DTC ではレコードタイプを使用していないため、答えを [いいえ] に変更します。組織にその種類のデータがないのに [はい] を選択した場合、ダッシュボードでエラーが発生します。
6. システム管理者は質問 11 「Do you assign ownership of cases to queues?」 (ケースの所有権をキューに割り当てますか?) についても同様であることを伝えます。(キューが何か不明の場合は、質問 11 の説明をお読みください。)
   DTC ではキューを使用していないため、ここでも [いいえ] を選択します。
7. [Next (次へ)] をクリックしてページ 3 に進みます。

ページ 3 に目を通すと、他にアスタリスクは見当たりません。ほっとしましたね。回答が必要ないということは、これで終了かもしれません。いいえ、ちょっと待ってください。

システム管理者はこう言います。「多くの作業を済ませた後ではありますが、次の 2 ページを詳しく見てみましょう。注意しなければならない質問がいくつかあります。そうでないと、ダッシュボードでエラーが発生し、顧客満足度に関するデータが適切に表示されません。」

1. 質問を下にスクロールする際、システム管理者はいくつかの点を指摘します。「ケースの所有者および状況の変更の追跡に関する最初の質問をご覧ください。追跡しないため、デフォルトの [はい] をそのまま使用すると、ダッシュボードは適切に動作しません。」このため、回答を [いいえ] に変更します。
2. 次に、システム管理者は CSAT スコアに関する質問 2 に注目するよう促します。「デフォルトは [はい] で、これは非常に重要です。前に [いいえ] に設定しようとしましたが、これは大きな間違いで、ダッシュボードには顧客満足度に関するデータが表示されませんでした。」システム管理者はこのことを覚えておくように伝えます。回答を [はい] のままにし、次に進みます。
3. サポートプロセスでナレッジを使用するかどうかを尋ねる質問 3 も、詳しく見る必要があります。システム管理者は次のように説明します。「現時点ではサポートプロセスでのナレッジの使用を追跡していませんが、追跡していた場合は、ここで [はい] を選択すれば、Service Analytics で詳細を取得するための新しいウィザードページが表示されます。」システム管理者の指示に従って、回答を [いいえ] のままにします。
4. 次に、テレフォニーについての質問 4 に進みます。システム管理者によると、この質問も重要で、[はい] のままにする必要があります。[いいえ] に変更すると、Service Analytics でチームが電話でサポートケースに対応する方法に関する主要なメトリクスが表示されないためです。
5. 残りの質問に目を通すと、質問 6 「商談を識別するのにレコードタイプ項目を使用しますか?」が目にとまるでしょう。システム管理者に「先程、最後のページでレコードタイプに関する別の質問を [いいえ] に設定しませんでしたか? ここでも同じようにすべきですか?」と伝えます。システム管理者は少し間をおいてから、次のように述べます。「あなたは、もうこのしくみを理解しましたね。もちろん、レコードタイプは使用しません。問題の発生を回避できましたね。」回答を [いいえ] に設定します。システム管理者は残りのデフォルト値が適切であることを確認しました。ただし、Service Analytics を詳しく見ていった後で、再検討することもできます、と語りました。それはまたの機会にして、[Next (次へ)] をクリックしてページ 4 に進みます。

1. 「最後のページで CSAT スコアに関する質問に [はい] と答えましたね。」とシステム管理者は尋ねます。「そのデータをアプリケーションに正しく取得するには、注意を払う必要があります。」質問 1 「顧客満足度を追加するために、どのオブジェクトを使用しますか?」」に対するデフォルトの回答は [ケース] です。多くの会社は CSAT データ用のカスタムオブジェクトを作成しています。外部ツールを使用して CSAT データを収集して保存し、カスタム Salesforce オブジェクトにインポートするのが一般的です。
   DTC ではたまたま、ケースオブジェクトでカスタム項目を使用して、調査ツールから収集した CSAT データを保存しているため、デフォルト値のままにします。
2. 質問 2 「CSAT を追跡するために、選択したオブジェクトのどの項目を使用しますか?」に移動します。CSAT データを保存するケースオブジェクトからカスタム項目を選択します。システム管理者は、ここで正しい項目を選択することが、CSAT データが正しく表示されるための鍵となることを説明します。
   システム管理者は、これは CSAT 項目であるため、CSAT 項目を探して選択するよう伝えます。
3. 質問 3 と 4 に答える必要があるのは、質問 1 でケース以外のオブジェクトを選択した場合のみであるため、これらの質問に答える必要はありません。システム管理者は [Next (次へ)] をクリックして、ウィザードの最後のページに進むよう伝えます。

Service Analytics の作成の終了

まず、ページ 6 を見ていることに気付いてください。「これはページ 5 のはずですよね、間違えましたか?」とシステム管理者に尋ねます。システム管理者はすべて問題ないと答えます。「ナレッジに関する質問に [いいえ] と答えたことを思い出してください。ページ 5 は [はい] と答えた場合に表示されます。ただし、[いいえ] と答えたため、これで問題ありません。」ページには、エージェントが通話中に顧客を待たせる最大サービス時間についての質問が 1 つあるだけです。DTC の基準は 30 秒であることを知っているので、回答項目にそう入力し、[Next (次へ)] をクリックします。

次のページでは、組織のデータがアプリケーションを作成するための要件を満たしていることを確認するかどうか尋ねられます。システム管理者は「正しいデータを取得したことをすでに確認したので、[いいえ] を選択しましょう。」と言います。選択したので、最後に [Next (次へ)] をクリックします。

メモ
組織では、あなたはこの質問に [はい] と答えたいでしょう。スキャンを実行するとデータ修正が必要な箇所が示されるため、大幅に手間が省け、エラーのないアプリケーションを確実に作成することができます。

[アプリケーションに名前を付ける] ウィンドウに「My First Service App」 (私の最初のサービスアプリケーション) と入力して [Create (作成)] をクリックします。Service Analytics でしばらく待機するよう表示されます。システム管理者はあなたが「DTC では CSAT データにケースオブジェクトを使用するため、最後のいくつかの質問があって助かりました。他のオブジェクトを使用していたら、どうなっていたでしょうか?」と質問することを想定して作業をしようとしているところです。

他の多くのサポート組織のように別のオブジェクトで CSAT を追跡した場合、Service Analytics はそのデータをページ 4 の質問 3 および 4 に基づいてケースデータと統合する、ということをシステム管理者は説明します。

Service Analytics でアプリケーションを作成している間、Salesforce ヘルプで CSAT メトリクスの設定およびウィザードの残りに関する説明を読むことにしました。(この単元の下部にあるリンクを参照してください。)システム管理者はアプリケーションを表示する準備ができ次第、メールすることを約束します。あなたはコーヒーでも飲みに席を立ちます。

この単元を一時中断して、アプリケーションの特別な Developer Edition が適切に動作するために実行すべき一度限りの手順を行います。

Service Analytics アプリケーションを作成できました。いずれかの Service Analytics ダッシュボードでデータが欠落している場合は、「CRM Analytics アプリケーションの基本」モジュールで紹介した Trailhead Data Manager を実行します。Trailhead のみで使用できるものですが、この省略可能な手順によってアプリケーションのデータが更新され、ダッシュボードに有意なデータを表示できるようになります。

重要
Trailhead Data Manager を実行する前に、アプリケーションのダッシュボードが表示されることを確認します。また、Trailhead Data Manager は、Trailhead 内でのみ実行します。独自の組織で Service Analytics を設定する場合、Trailhead Data Manager は使用しません。

1. Analytics Studio で、右上のアプリケーションピッカーをクリックし、[Trailhead Data Manager] を選択します。見つからない場合は、下にスクロールしてください。
2. 次のページで、上部付近にある [Trailhead Data Manager] タブをクリックします。
3. Trailhead Data Manager ホームページで、データを更新する必要があるかどうかを確認します。データが最新であることがページで確認できれば、更新の必要はありません。ページにデータが更新されていないと表示されていたら、[Refresh DTC Data (DTC データを更新)] をクリックします。データの更新には数分かかる場合があります。
4. [Analytics Studio] に戻ります。
5. 左側のパネルの [データマネージャー] をクリックします。(CRM Analytics データマネージャーが開きます。Trailhead Data Manager と混同しないでください)。
6. [Manage Dataflows (データフローを管理)] をクリックします。
7. データマネージャーで、左側のパネルの [接続] をクリックします。
8. [SFDC_LOCAL] 行で、[未スケジュール] の横にあるドロップダウンを開き、[今すぐ実行] をクリックします。
9. 左側のパネルの [監視] をクリックし、データ同期が完了するのを待ちます。すべてのジョブの状況が「実行中」から「成功」に変わるまで、更新ボタンを数回クリックします。
10. すべてのデータ同期が完了したら、左側のパネルの [データフローとレシピ] をクリックします。
11. [Default Salesforce Dataflow (デフォルトの Salesforce データフロー)] を見つけてそのドロップダウンを開き、[今すぐ実行] を選択します。
12. [My First Service App eltDataflow (私の最初のサービスアプリケーション eltDataflow)] を見つけてそのドロップダウンを開き、[今すぐ実行] を選択します。

休憩時間は終わりました。最初の Service Analytics アプリケーションを作成し、実際のアプリケーションのように機能させるために Trailhead 用の手順を実施しました。お見事でした! 次に、達成した内容を確認しましょう。

1. Trailhead Data Manager が完了したら、Salesforce アプリケーションランチャーで [Analytics Studio] を見つけて選択します。
2. 左側の列の [すべての項目] をクリックします。
3. ページの [アプリケーション] セクションで [My First Service App (私の最初のサービスアプリケーション)] を見つけ、右側の [アプリケーションを実行] タブをクリックします。すると、Service Analytics Overview ダッシュボードが表示されます。サービスビジネスを完全に把握する準備ができました。

メモ
ダッシュボードが今回の例や Service Analytics アプリケーションモジュールの他の例と多少異なっていても、問題ありません。データが異なっていてもダッシュボードの基本要素は同じです。

このモジュールの最初に営業担当副社長に声を掛けられたことを思い出してください。その営業担当副社長は、新しい DTC Electronics タブレットに関する顧客の問題を理解するためのサポートが必要でした。あなたとシステム管理者は、正しい CSAT データの取得に的を絞り、タブレットのサポートおよび CSAT の数値をただちに確認したいと思っています。

概要ダッシュボードには、この数値をはじめとする情報が示されます。バックログのサイズ、エージェントがケースをクローズする平均時間、初回連絡での解決データへの変更を確認できます。また、ダッシュボード上部にある検索条件で選択した日付範囲の平均値と比較した、これらのメトリクスのトレンドも確認できます。ここで表示されたデータでどのようなことができるのでしょうか? 確認してみましょう。

1. ダッシュボードタイトルのすぐ下で [Last 180 Days (過去 180 日間)] をクリックし、[期間] 検索条件を開いて別の期間を選択します。すべてのメトリクスがどのように変わるかを見てください。多くのことを意のままに制御できます。
2. それでは、下部を見てみましょう。オープンケース、エージェント、バックログ、チャネルなどを確認できる、アプリケーションの残りのダッシュボードに移動するリンクがあります。これらのリンクは後で役に立つので、覚えておいてください。概要ダッシュボードは、残りのダッシュボードへの適切なエントリポイントとなります。どこに行けばよいかわからない場合、いつでもここに戻ってくることができます。
3. [Prioritize Open Cases (オープンケースの優先順位付け)] をクリックして、オープンケースを確認してみましょう。
4. Open Cases ダッシュボードで、[Case Segmentation (ケースのセグメント化)] の下にある [By Product Family (商品ファミリー別)] ウィジェットを見つけます。(アプリケーションの作成時に [商品ファミリー] を選択したことを覚えていますか?)タブレットバーを選択すると、ダッシュボードが再作成され、タブレットのオープンケースが示されます。ちょうど探していたオープンタブレットケースです。これについては、モジュールの後半で説明します。ここでは、右上にある [Overview] をクリックして Service Overview ダッシュボードに戻ります。
5. CSAT データを表示できるかどうかの確認も必要です。[Account Profile (取引先プロファイル)] の下で、チームの平均 CSAT スコアを確認できます。ただ、さらに詳しく知りたい場合もあります。右下にある [Review CSAT Drivers (CSAT ドライバーの確認)] をクリックします。
6. 開いたばかりの Customer Satisfaction ダッシュボードを確認します。取引先別、発生源別などの CSAT の平均の詳細が表示されています。時の経過に伴って CSAT がどのように変化しているか、CSAT がケースの所要時間にどのように関連しているかなどを確認できます。

クイックレビューで十分に内容を把握できます。設定ウィザードでの作業は (システム管理者からのサポートはさておき) やるだけの価値がありました。タブレットの市場投入をサポートするのに必要なものが得られました。さらに、サービスビジネス全体を完全に把握するための優れたツールも備えています。今すぐチームへのロールアウトを開始できます!

分析の仕方を覚えていますか? 作成するのが難しく、作業するのはさらに難しい、図がほとんどない、さえないスプレッドシート。ただし、Service Analytics では、すべてのサービス KPI が一か所に表示されます。それらは、迅速に把握すべき情報を示すダッシュボードに表示されます。かつては、商品、地域、顧客グループ、サポートチームなどごとに、非常に多くのレポートやダッシュボードがありました。現在あるのは、把握すべき分野別に絞り込むことのできる少数のダッシュボードです。必要なことは、ウィザードでいくつかの質問に正しく回答することだけです。

アプリケーションにはほとんど触れませんでしたが、すでに短い時間で素晴らしいダッシュボードを数多く見てきました。ここまでずいぶん早く進んできました。次は、アプリケーションを実際に使用してみましょう。

• 「CRM Analytics アプリケーションの基本」 Trailhead モジュール
• 設定ウィザードを使用した Service Analytics のカスタマイズ
• CSAT メトリクスの設定例