Service Cloud Specialist

  • Trailhead のスーパーバッジ、Service Cloud Specialist の日本語訳(非公式)です。

  • 各カスタマイズ要素のラベル部分には補足として日本語を括弧内に記載している場合がありますが、正解チェックは英語のラベルを元に行われるため、実際のチャレンジには日本語表記を含めず、英語表記のみを使用して行って下さい。また、チャレンジ前にユーザと組織の言語・ロケールを英語に切り替えておくことを推奨します。

このスーパーバッジを取得するためにすること

  1. エージェントのコンソールを設計し更新する

  2. ケース管理機能を実装する

  3. サービスレベルのアクションを表示する

  4. メールからエージェントへのケースのルーティングを設定する

  5. ナレッジ共有プラットフォームを作成する

  6. ケースとエージェントの自動化システムを確立する

  7. ケース分析を構築する

このスーパーバッジでテストする概念

  • Lightning コンソール

  • ケース管理

  • エンタイトルメント管理

  • メールに関連するケースの機能

  • ケースのルーティング

  • Lightning ナレッジ

  • 自動化ツール

  • レポート・ダッシュボード

事前準備とメモ

  • ペンと紙を準備して、要件を読み進める際にメモを取ってください。

  • このスーパーバッジ用に、新しい Trailhead Playground を作成してください。この組織をほかの目的で使用すると、課題について検証する際に問題を引き起こす可能性があります。

  • このスーパーバッジにおいて、ユーザは Lightning Experience を利用するため、この点を考慮してすべての設計上の決定を行ってください。

  • このスーパーバッジで利用される用語のいくつかは、UI に表示される設定上の名称名と完全に一致しない場合があります。これは、Salesforce の機能に関する知識と、ビジネス上のニーズを満たす正しい機能を選択する能力をテストするためです。

ユースケース

Ursa Major Solar, Inc., は米国を拠点とする、太陽光エネルギー機器のサプライヤで、最近事業を太平洋岸北西部にも拡大しています。新しい顧客はこれまで、日照時間が長い夏の間に発電される電力については満足しており、送配電網へ送り返すだけの余剰電力を発電できています。しかし冬になると曇や雨の日が増え発電量が下がってしまうため、顧客は発電量よりも使用量が上回ってしまうことを懸念しています。

Usra Major では、顧客の痛みは会社の痛みです。経営陣は、太平洋岸北西部の顧客の声に耳を傾け、顧客がより多く発電できるようにするため、新しいコンタクトセンターを立ち上げることを決定しました。あなたはシステム管理者として、新しく立ち上がった Cloudy Support Team (クラウディサポートチーム) のミッションの成功を確実にするため、Service Cloud の機能の実装を一任されました。あなたはケース管理のロジック、ケースのルーティングやコンタクトチャネルの設計、ナレッジベースの実装、またオペレーションを効率化できるコンソールの設定を行います。また、ケースの傾向を追跡するための分析結果をマネージャへ提供します。最も重要なことは、Usra Major の顧客に対して、その顧客が享受する素晴らしいサポートを受けられるよう道案内をすることです。

主要なステークホルダ

顧客の声に耳を傾ける前に、コンタクトセンターがどのように機能すべきかを理解するため、チームメンバーに話を聞いています。主要なステークホルダは次の通りです。

  • Ada Balewa (製品サポートスペシャリスト)

  • Maria Jimenez (システム管理者)

標準オブジェクト

Ursa Major では以下の標準オブジェクトを利用しています。

  • Account (取引先) - Usra Major から機器を購入する法人顧客

  • Contact (取引先責任者) - Usra Major の顧客の既存の担当者、または見込み顧客としての担当者

  • Case (ケース) - 顧客から報告されるサポートに関する問題

ビジネス要件

エージェントのサポートユーザインタフェース

Usra Major には、顧客に喜んでいただくにはまず従業員を幸せにする、という戦略があります。クラウディサポートチームのメンバーが、オフィスにある無料の果物と、改善された Lightning のおかげで元気になればなるほど、チームメンバーはより良い顧客体験を提供できるでしょう。そのため、あなたはユーザフレンドリーな Lightning のエージェント向けのサポートユーザインターフェイスを構築し、効率化のための設定を行います、そしてこのプロジェクトが継続し新しい機能を組み込むことができるように微調整を続けていくことになるでしょう。

まず、チームメンバーに割り当てるための 2つのプロファイルを作成しましょう。

  • Cloud Team Billing Support (クラウドチーム請求サポート) - Salesforce ライセンスユーザで、取引先・取引先責任者・ケース・契約へのアクセス権限があります。

  • Cloud Team Technical Support (クラウドチームテクニカルサポート) - Salesforce ライセンスユーザで、取引先・取引先責任者・ケースへのアクセス権限がありますが、契約へのアクセス権はありません。

続いて、既存のサービスコンソール Lightning アプリケーションを改善しましょう。以下は、改善に着手するために、システム管理者の Maria Jimenez と製品サポートスペシャリストの Ada Balewa からのヒアリング結果をまとめたメモです。

  • コンソールの名称を Cloudy Support Service Console にリネームする。

  • カラースキームに #106935 を割り当てる。

  • ユーティリティバーに「ソフトフォン」、「手作業でのタスクの完了を自動化する方法」、「最近のケース 5 件を迅速に確認するための方法」をそれぞれ追加する。

  • Cloud Team Billing Support プロファイルと Cloud Team Technical Support プロファイルのユーザがこのコンソールアプリケーションにアクセスできるようする。

生産性を保つために、エージェントがケースのレコード詳細を見ている間にメールを作成するための手段も提供しましょう。また、テストとユーザの受け入れを促進するために、Ada のログイン情報を追加し、彼女に Cloud Team Technical Support プロファイルを割り当てましょう。

ケース管理

コンタクトセンターが人間の体であるとするなら、その目と耳はコンタクトチャネルで、エージェントは筋肉、ケースは血液です。ケースは、顧客を助けるためにエージェントへ重要な情報を運びます。ケース管理により、ビジネス要求に基づいてケースを正しい人に割り当てたり、整理したり、エスカレーションすることができます。Ursa Major の Salesforce システム管理者である Maria Jimenez が、クラウディサポートチームの要件を集めて整理することを手伝ってくれました。

サポートのライフサイクル

冬の日とは大きく異なるシアトルの夏の日にドレスを着るとします。あなたはきっとスノーブーツではなくサンダルを履き、レインコートの代わりに T シャツを着るでしょう。同じように、サポートエージェントは請求に関するケースと機器の設置に関するケースは異なる方法で処理するでしょう。クラウディサポートチームは、最も効果の大きい、テクニカルサポートの問題から改善に着手することにしました。ケースのページレイアウトやケースオブジェクトのサポートライフサイクルを設定し、エージェントがテクニカルサポートのケースを処理していることを識別できるように実装を進めていきましょう。

ケースのライフサイクル名Cloud Technical Team (クラウドテクニカルチーム)

ケースライフサイクルのステージ

※新規追加が必要な選択リスト値があります New (新規) Investigating Cause (原因の調査中) Investigating Solution (解決策の調査中) Resolving with Customer (顧客による解決) Escalated (エスカレーション済) Closed (クローズ)

ケース情報のページ名

Cloud Technical Team Page (クラウドテクニカルチームのページ)

表示したいケース情報

既存のケースレイアウトと同様ですが、次の項目を取り除きます。 Potential Library Product そして次の項目を含めます。 Type (種別) Reason (原因) Escalated (エスカレーション済フラグ) Asset (納入商品)を含めます。

ケース情報のページに割り当てるプロファイル

Cloud Team Technical Support (クラウドチームテクニカルサポート) System Administrator (システム管理者)

ケースの整理

ケースは、個々のサポートエージェントによって引き取られる(または割り当てられる)前に、整理されて蓄積していきます。ケースが血流である場合、この仕組みは動脈のようであり、筋肉にたどり着く前に血液を保持し、優先順位付けを行います。このようなケースを整理する仕組み(ケースオーガナイザ)を設定する前に、サポートエージェントがメンバーとなる 3 つの公開グループを作成します。公開グループの名前は次のとおりです。

  1. Basic Support Agents

  2. Intermediate Support Agents

  3. Advanced Support Agents

あなた自身のユーザと Ada を Advanced Support Agents の公開グループに追加しましょう。

続いて Basic Case Organizer と Advanced Case Organizer という名称で 2 つのケースオーガナイザを作成します。 Basic Support Agents 公開グループまたは Intermediate Support Agents 公開グループに所属するエージェントが、Basic Case Organizer から担当するケースを受け取れるように設定します。また、Intermediate Support Agents グループまたは Advanced Support Agents グループに所属するエージェントは、Advanced Case Organizer から担当するケースを受け取れるように設定します。

エージェントは、必要に応じて手動でケースオーガナイザにケースを移動することができますが、新規作成されたケースを適切なケースオーガナイザに自動的に渡すカスタムルールも作成しましょう。新しいケースは、優先度が High (高) の場合を除いて、常に Basic Case Organizer に割り当てられる必要があります。優先度が High (高) のケースは、Advanced Case Organizer に割り当てられる必要があります。

システムはまた、Basic Case Organizer から Advanced Case Organizer へ、特別な注意を必要とするケースを通知して、より経験豊富なエージェントがサポートできることができるようにする必要があります。ケースの優先度が Low (低)で、状況が Escalated (エスカレーション済み)、Closed (クローズ済)、Resolving with Customer (顧客による解決) のいずれでもない場合、ケースは 3 時間更新がないと通知される必要があります。ケースの優先度が Medium (中) で状況が Escalated、Closed、Resolving with Customer のいずれでもない場合、ケースは作成から 3 時間後に通知されます。

サポートはチームスポーツ

ケースを解決するため定期的に一緒に働いているチームメンバーのおかげで、Ada は上手くやっています。クラウディサポートチームが、定期的に協力してくれるスタッフをケースに割り当てられるような設定を行いましょう。ケースへの参照権限をもつ Customer Contact という役割と、ケースへの参照・編集権限をもつ Support Lead という 2 つの役割を設定します。

そして、エージェントが各ケースでそれぞれチームメンバーの役割を割り当てられるような設定を追加しましょう。

サポートレベルの管理

Ursa Major Solar の CEO である Sita Nagappan-Alvarez は、一人一人の顧客の価値をよく強調しています。大規模な複合商業施設から一戸建て住宅まで、販売されたすべての太陽光システムは、企業の収益と環境を支えています。サポートチームは業界をリードするケース処理時間と顧客満足度を達成していますが、一部の顧客はより厳格な SLA を望んでおり、そのサービスのために特別料金を支払う意思があります。この要望に応えて、サポートチームの経営陣は 2 つのサービスレベルを提供する計画を思い浮かべました。有料の Cirrus Support (巻雲サポートプラン)と、デフォルトのサポートプランとなる Stratus Support (層雲サポートプラン)です。ここでは Cirrus Support プランを実装し、エージェントが利用できるようにしましょう。以下が Cirrus Support プランの概要です。

サポートレベル名Cirrus Support Process

1 番目のステップ

目標名: Resolution Time (解決時間) 優先度がHigh (高) のケースは 360 分以内にクローズする必要があります。ケースの所有者は 45 分前に警告メールが送信されます。

2 番目のステップ

目標名: Resolution Time (解決時間) 優先度が Low (低) またはMedium(中)のケースは 840 分以内にクローズする必要があります。

3 番目のステップ

目標名: Initial Response (初回応答) 優先度に関わらず、20 分以内に完了する必要があります。もし完了されなかった場合、10 分後に優先度が High (高) の ToDo がケースの所有者に対して作成されます。

もし顧客が追加のサポートに対して支払いを行っても、サポートエージェントがそれを判断出来ない場合、顧客はサポートに対して本当に支払いを行ったと言えるのでしょうか。エージェントが顧客のサポートプランを把握できるように、取引先の詳細ビューを更新し Cirrus Support を追加できるように設定しましょう。また、アプリケーションにタブを追加してサポートレベルの割り当て全体を確認できるようにしましょう。加えて、エージェントがサポートレベルのステップの進捗状況をトラッキングできるように、ケースの詳細ビューを更新しましょう。

注：このスーパーバッジでは、メールから作成されたケースに対してケースプランのステップを適用する必要はありません。自動的にこれを行う Apex トリガを作成することができます。実際の組織でこの機能を使用するには、開発者に相談してください！*1

ケースのルーティング

ケース管理とサポートレベルの実装が完了したので、次に、可能な限りシームレスなサポートを顧客に提供するエンドツーエンドのサポートを構築しましょう。

メールによるケースの処理

新しいソーシャルメディアプラットフォーム、モバイル、メッセンジャーアプリ、さらには電話まで、顧客がサポートエージェントに連絡する方法は、シアトルの冬の空に浮かぶ雲と同じくらいの数だけあります。クラウディサポートチームはメールのチャネルから実装を始めたいと考えています。Ursa Major における既存のサポートケースの発生源を分析した結果、メールは引き続き、顧客がサポートの問題を送信しフォローアップするための主要サポートチャネルとなるでしょう。デスクトップアプリケーションをインストールすることなく、顧客から受信したメールを以下の設定でケースとして処理する方法を設定しましょう。

チャネルの名称Cloudy Email Routing

メールアドレス

ユーザのログインメールアドレスとは異なる任意のメールドレス

作成されたケースの所有者

Basic Case Organizer

作成されたケースの優先度

Medium (中)

作成されたケースの発生源

Email (メール)

Ada によると、顧客はよく 1 つのサポートの問題に対して 2 通のメールを送っています。1 つ目はその顧客の質問や問題で、2 つ目は「これは対応されていますか？」という顧客からのリマインドメッセージです。そこで、メール経由で作成されたすべての新規ケースに対して、顧客に自動返信する仕組みを設定することを Maria から勧められました。この仕組みの名前を Cloudy Email Response Rule (クラウディサポートチームのメール返信ルール)としてください。この自動送信メールの送信者は Ursa Major Cloudy Support Team としてください。また、Support：Cloudy New Email From Case という名前のメールテンプレートを作成しこの設定で利用します。

ケースの交通整理

コンタクトセンターを人間の体に例える話に戻ると、血液 (ケース) を筋肉 (エージェント) に運ぶための最後のステップである毛細血管を構築する必要があります。すべてのエージェントに対応可能なすべてのケースを渡す必要があるでしょうか？エージェントは同時にいくつのケースを引き受けるべきでしょうか？エージェントが休憩のため外に出て雲を見ることにした場合、システムでどのようにその休憩を記録すればよいでしょうか？Ursa Major の経営陣はこれらの課題に対して意思決定し、ケースのルーティングシステムを導入することになりました。Stormy Cases という名前でルーティングのためのチャネルを設定し、以下の 2つのシチュエーションに基づいてケースをルーティングしましょう。

  • 最優先のシチュエーションである Advances Cases は、Advanced Case Organizer からケースが引き出され、各ケースに 2 の作業単位を割り当てます。ケースは対応可能な状態が最も長いエージェントから優先的に割り当てられます。

  • 優先度の低いシチュエーションである Basic Cases は、Basic Case Organizer からケースが引き出され、各ケースに 1 の作業単位を割り当てます。同じく、ケースは対応可能な状態が最も長いエージェントから優先的に割り当てられます。

Stormy Cases でケースを受け取るエージェントは、Available (対応可能) のステータスを選択できるようにする必要があります。忙しい場合や対応不可の場合に備えて、ステータスには以下の選択肢も必要です。

  • Unavailable - Break (対応不可 - 休憩中)

  • Unavailable - Off (対応不可 - 離席)

  • Unavailable - Working Cases (対応不可 - 他のケース対応中)

エージェントがケースを受け入れる際、誤ったケースが到来していることに気づいた場合は、Wrong Queue (間違ったキュー) を選択してそのケースを送り返すことができるように設定しましょう。ここで、エージェントには Cloud Team Technical Support のプロファイルが割り当てられていることに注意してください。

ケースの専門性をシェアする

Ada はケース対応中でないときに、他のサポートエージェントがソーラーパネルに関する専門知識を他のエージェントにシェアしています。メンターとして振る舞うことは、彼女が直接話しかける人たちにとって役に立つことですが、数多くの新しいエージェントと一緒に新しいコンタクトセンターを強化していくには、よりスケーラブルなアプローチが必要です。Lightning Knowledge を設定して、Ada や他のエージェントが専門知識をカタログ化できるようにしましょう。

Lightning Knowledge を設定する

あなたと Ada はナレッジへのアクセス権が必要です。また、ナレッジ記事の整理に用いる 2 つの大分類と、いくつかのサブグループを設定しましょう。

  • Billing Topics (請求に関するトピック)

    • Reimbursements (買取について)

    • Payments (支払について)

  • Technical Topics (技術的なトピック)

    • Panel Access (日照について)

    • Connections (接続について)

    • Broken Equipment (機器の故障について)

ナレッジオブジェクトに、Question (質問) と Answer (回答) という 2 つのロングテキスト項目を作成した上で、以下の記事を作成し公開しましょう。

Title (件名)Linking SP-100 to SP-200

Question (質問)

How does the SP-100 connect to the SP-200?

Answer (回答)

You should use the UM-B linker to connect the SP-100 and SP-200 panels.

Category (カテゴリ)

Connections

Status (ステータス)

Published (公開済み)

また、エージェントのケース詳細ビューで、ケースに割り当たっている公開記事を見られるように設定しましょう。

エージェントの活動の自動化

以前 Ada とコーヒーを飲んでいたとき、彼女は Ursa Major での最初の 1 か月について話してくれました。ある地域の停電により、大部分の顧客が送配電網から外れ、入電件数は通常の 5 倍に増え、顧客は皆システムの再起動方法について尋ねてきました。エージェント達は未処理のケースに対応するために数日間残業し、今日でもその 2013 年の大停電のことが話題になります。今後、重たい曇りの天気や暴風によって発電量が減少してしまう場合に、Ada はその大停電のときと同じくらいの問い合わせが発生すると予測してます。それらのケースが作成されたときに Cloudy Support チームのエージェントが圧倒されてしまわないように、プロセスを自動化することを Mariaから勧められました。

自動化された ToDo 作成

最終的な自動化のゴールは、エージェントがボタンをクリックするだけで、天候の影響によるパネルの性能低下に関するケースを処理できるようにすることです。その前に、そのケースが確実に天候に原因があると保証したいと考えています。ケースの Type (種別) が Electrical で Reason (原因) が Performance、Status (状況) が Working の場合に、新しい ToDo をエージェントに割り当てる自動化プロセスを設定しましょう。ToDo には以下の内容を設定します。

Subject (件名)Research the weather

Description (説明)

Recent poor performance has been attributed to cloudy weather. Research the customer's weather at the time of poor performance.

Status (状況)

Not started

Priority (優先度)

Normal

Related to (関連先)

元のケース

再利用可能なメール

エージェントがそれぞれの顧客に、天候の影響によるパネルの性能低下に関するメールを都度作成しなくても済むよう、再利用可能なメールを作成しましょう。以下の[括弧で囲まれたテキスト]は、ケースの情報を自動的に埋め込む仕組みに置き換えてください。

再利用可能なメール名Cloudy weather

Subject (件名)

Low power generation in cloudy weather

Body (本文)

Hey [顧客のファーストネーム], Sorry to hear that your panels aren't generating the power you hoped for. Based on our research, it appears the low power produced is related to the cloudy weather in your area recently. In the worst conditions, Ursa Major panels produce ~25% of maximum power. If you have additional questions, please give us a call and reference case [ケース番号]. Thanks! [エージェントのファーストネーム], Ursa Major Solar

再利用可能なテキスト

再利用できる電子メールを作成することは素晴らしいことですが、さらに多くの場所で適用できるテキストを作成するのはどうでしょうか。クラウディサポートチームのエージェントは、再利用可能なメールを使用した後に、そのテキストを使用してケースを更新します。ここでも、[括弧で囲まれたテキスト]を、情報を自動的に埋め込む機能に置き換えてください。

再利用可能なテキストの名前Cloudy weather response sent

Text (テキスト)

Agent [エージェントの名前] sent the Cloudy Weather email to the customer and closed the case.

Category (カテゴリ)

FAQ

Channel (本文)

Internal

自動化されたアクション

エージェントが再利用可能なメールと再利用可能なテキストを活用するよりも時間を節約できるものは何でしょうか。エージェントがリラックスしている間に、エージェントがボタンを 1つクリックするだけで、再使用可能なメール・テキスト、およびその他のアクションを自動的に適用できる設定を行いましょう。実現すべきハイレベルのアクションを次に示します。この自動化されたアクションの名前は Cloudy Weather Resolution としてください。

  • 現在作業中のケースを選択する。

  • Cloudy weather (作成した再利用可能なメール) を使用して、顧客にメールを送信する。

  • ケースをクローズし、Cloudy weather response sent (作成した再利用可能なテキスト) を使用して Description (説明) 項目を追記する。

コンタクトセンターの分析

これまでに構築してきたケースのルーティング・管理・および自動化により、クラウディサポートチームは素晴らしいスタートを切るはずです。チームがケース管理の効果を評価できるよう、レポートを作成してダッシュボードを更新しましょう。

サポートマネジメントチームが、顧客が助けを求めている理由を理解できるようレポートを作成します。Case Reason and Type Analysis (ケース原因とタイプ分析) レポートを作成し、Cloud Support Reports フォルダに保存します。最初に Type (種別) ごとに、次に Reason (原因) でレコードを整理します。最も頻繁に使用される種別が最初に表示され、使用頻度が最も低い種別を最後に表示しましょう。レポートにはケースの所有者、取引先名、件名を含み、クローズしたケースのみを表示します。レポートには、ケース種別が縦棒グラフの各棒を表し、ケースの原因が縦棒内に並んでいるようなレポートグラフを含めます。

次に、新しいレポートを使用して Case Performance Dashboard (ケースパフォーマンスダッシュボード) を作成します。種別が縦棒グラフの各棒となるように、種別でグルーピングした分析結果を表示しましょう。このダッシュボードコンポーネントには、Case Reason and Types (ケース原因と種別) というタイトルを設定し、サブタイトルに Case Distribution Analysis (ケースディストリビューション分析) を設定します。コンポーネントをダッシュボードの中央に配置し、幅を最大になるように広げてスペースを利用します。

Challenge

Challenge 1: エージェントのダッシュボードを構築する

サービスコンソールアプリケーションの外観と機能を設定してください。

Challenge 2: ケース管理を確立する

ケースのライフサイクル、ケースを管理する組織、ケースへのチームレベルのアクセスをサポートする機能を追加し設定してください。

Challenge 3: サービスレベルとアクションを作成する

有料の Cirrus Support プランを実施するためのサービスレベルとステップを構築してください。

Challenge 4: ケースのルーティングを設定する

メールを自動的にケースに変換する仕組みと、ケースのトラフィックがどのようにルーティングされるかを決定するルールを設計してください。

Challenge 5: Lightning Knowledge を実装する

Lightning Knowledge を実装し、エージェントが使用するための機能を表示し、ナレッジ記事を作成してください。

Challenge 6: ケースとエージェントの自動化を構築する

自動化によって、数少ないエージェントがたくさんいるようにしましょう。タスクを自動的に作成する仕組みと、ボタンをクリックするだけで再利用可能なメールとテキストを適用する仕組みを構築してください。

Challenge 7: レポートを作成しダッシュボードを更新する

要求されたレポートを設計し、Case Performance Dashboard に適用してください。Challenge を検証する直前に必ずダッシュボードを更新してください。

訳注

ヒント

Challenge 4

  • メールテンプレート本文の内容は適当で構いません。

前へSecurity Specialist

最終更新