Dynamics 365 とサポート案件 -3

前回の記事では、サポート案件を起票するところを取り上げました。
電話、メール、Webサイトなど顧客からリクエストが入る可能性のあるそれぞれのソースに対してDynamics 365が対応できるよう設計することが大切です。
顧客からの要請に応じてサポート案件を起票後、次に問題解決のためのアクションを起こします。代表的な2つのアクションを取り上げてみましょう。

アクション1:すぐに解決できるよう、既定のサポート情報を提供する
顧客はできるだけ早く問題を解決したいと願っているはずです。そのために、顧客自身で試すことができる ”修正手順” などを記した電子メールを送信することはよくあります。このシナリオで便利な機能がDynamics 365の「サポート情報記事」です。

ちょっとややこしいのですが、Dynamics 365 Customer Engagement 9.0の環境では、2種類の「記事」機能が存在します。
一つは昔から用意されている「記事」(エンティティ名:KbArticle)。
もう一つが「サポート情報記事」(エンティティ名:KnowledgeArticle)です。
2018-05-07_11-23-27

「記事」は既存の ”サービスアプリケーション” で新しい「サポート情報記事」は「統合インターフェース(Unified Interface)」の顧客サービスハブで利用することができます。利用するUIによって利用する機能の選択肢が変わるので注意が必要です。

「記事」はテンプレートをもとに作成します。あらかじめ用意されている標準の記事テンプレートのほかに、企業が自身でテンプレートを作成し活用することもできます。
2018-05-07_11-56-16
情報を記録するという目的は今でも十分に果たすことができる「記事」ですが、機能設計が古く自由度が低いところが問題です。顧客に対してビジュアルや映像を参照したわかりやすい記事(リッチなコンテンツ)を作成するのに難があります。また、モバイル端末などに最適化させることもできません。

新しい「サポート情報記事」はテンプレートから作成するのではなく、用意されたエディター内で自由にコンテンツ作成が行えます。プレビュー機能も準備されており、PC以外のディバイス、例えばスマートフォンやタブレットに向けたコンテンツを作成することができるため、よりリッチなコンテンツを作成できます。そのほかにも「翻訳」など多言語に対応した機能も準備されています。
2018-05-07_12-03-05

どちらの記事機能も目的の情報が見つけやすくなるよう、「タグ」(検索キーワード)を設定します。サポート情報記事は、フルテキスト検索、あいまい検索など多くの検索オプションが用意されているのですぐに情報を検索し結果を表示することが可能です。
2018-05-07_14-28-45
必要な記事を見つけたら、あとは活用するだけです。
例えばOutlookでメールを作成する際、サポート情報記事の内容を挿入するなど便利な使い方ができるようになります。この機能は本当に便利ですので、利用されたことのない方は是非お試しください。数クリックで、正確で、組織が公式に認めた記事コンテンツをメール内に挿入し、あとは前後の文章を書いてすぐにメールを送信できます。それも、同一ウィンドウ内で作業が完結します。
Dynamics 365とOutlookが連携すると、これほどまでに作業時間が短くなるのかと多くのDynamics 365ユーザーが感動するところです!
2018-05-07_14-42-58

 

アクション2:サポート案件を解決するよう、担当者をアサインする
担当者をアサインするのに便利な機能が「キュー」です。
キューとはなんでしょうか?
キューは「」のようなものだと考えるとわかりやすいかもしれません。オペレータや一次窓口の担当者は「サポート案件を起票」し、案件を直接誰かに割り振るのではなく、「キュー」の箱の中に入れます。
図1
あとはキューの箱の中から、準備ができた担当者が順次案件を受けていきます。(キューからアイテムをピックする)
2018-05-07_14-56-02
なぜキューを使うのでしょうか?
直接担当者に割り振った場合、もしその担当者の処理能力が遅かったらどうでしょうか? もしその担当者が抱えきれないくらい案件を持っており、すぐに取り掛かれないとき顧客に対して迷惑が掛かりませんか?
担当者が休暇を取得しなければならないときどうでしょうか? AさんとBさんにスキル差や経験の差がある場合はどうでしょうか?
Dynamics 365では直接担当者に案件を割り振ることもできますが、キューに入れることにより、もっとも適切な人材が、最も適切なタイミングで案件処理を開始することを期待できます。

キューは目的ごとに複数作成できるため、例えば職能別、契約別に作成することもできます。プレミア サポート契約を結んでいる顧客はキューAへ。 通常サポート契約の場合はキューBへなど柔軟な使い方が実現します。そして、キューAには経験豊かな高レベル エンジニアを割り当てておくことができるかもしれません。
担当者も、キューの箱の中を見渡し、自分が取得するキューを選択できます。これにより、各担当者が最も得意とする案件を ”自分で選択” ができるため作業効率も上がります。

良いことばかりのように見える「キュー」ですが、もちろん問題点もあります。それは、キュー内で「受け取られないまま放置される」サポート案件が発生することです。インフォシェアでDynamics 365のご相談をいただくときも、この問題を心配されているお客様が多いように見受けられます。
この問題を防ぐために、管理者は定期的にキューの中身を確認し、長期間放置されている案件が存在しないか確認する必要があります。放置されているキューを確認後、あとは組織のルールに従って、最も適切な担当者に「直接」割り当てることを検討できます。
「確認」というと難しいことのように聞こえますが、Dynamics 365の標準レポートで「放置されているキューの状態」を表示することができますし、ワークフローなどを併用することも考慮できるでしょう。

次の記事では、サポート案件のクローズについて取り上げます。
Dynamics 365 Customer Engagementの「サービス」機能については、インフォシェアの「Dynamics 365基礎」トレーニングで演習とともに学習可能です。ぜひ参加をご検討ください!