WEBVTT

00:00:00.000 --> 00:00:08.840
顧客が注文の破損についてメールし翌日に電話をかけその後チャットを開く 誰も状況を把握しておらず顧客は毎回同じ説明を繰り返しサポートチームは受信トレイ

00:00:08.840 --> 00:00:14.780
メモ別々のツールを探し回る羽目になります それこそがダイナミクス365のケース管理で解決できる問題です

00:00:14.780 --> 00:00:18.460
ケースとは忙しいオフィスビル内にある一つのラベル付きホルダーのようなものだと考えて ください

00:00:18.460 --> 00:00:22.700
顧客の問題に関するあらゆる情報が最初の質問から最終的な回答まで全てそのホルダーに まとめられます

00:00:22.700 --> 00:00:31.380
m 365 fm のミルコピーターズがお届けするこのナレッジナゲットではケースルーティング 応答期限サポート記事そしてクローズに至るまでがどのように連携するかを見ていきましょう

00:00:31.380 --> 00:00:39.860
ケースとは何か25で説明しますではケースとは一体何でしょうか ケースとは回答や解決が必要な一つの顧客の問題を記録したものです

00:00:39.860 --> 00:00:45.260
問題の内容は製品の破損請求に関する質問 ログインの不具合サービス利用のサポート依頼など様々です

00:00:45.260 --> 00:00:52.860
重要なのは一人の顧客が同時に複数のケースを持つ場合があるという点です 例えば一人の顧客が月曜日に請求書について問い合わせ火曜日にデバイスの故障を報告し

00:00:52.860 --> 00:00:59.660
金曜日に住所変更のサポートを必要とするかもしれません これらは個別の問題であるためダイナミクス365では全ての会話を混乱した一つのスレッドに

00:00:59.660 --> 00:01:05.100
まとめず個別のケース記録として管理します 担当者がケースを作成する際それを顧客と直接紐付けます

00:01:05.100 --> 00:01:13.080
その顧客とは個人を指す取引先担当者である場合もあればその人が勤務する会社を指す 取引先企業である場合もありますつまりノースウィンドトレーダーズのジェイミーが問題を

00:01:13.080 --> 00:01:20.300
報告した場合ケースはジェイミーと会社の双方に紐付けられ 記録を開いた誰でも誰が助けを必要としておりどの組織の問題であるかを確認できます

00:01:20.300 --> 00:01:29.280
ケースには問題の簡潔な説明も必要です ソフトウェア更新後にプリンターが停止したや年間プランで二重請求されたといったタイトルを

00:01:29.280 --> 00:01:38.340
つけることですべての記録を開かなくてもオープンなケースの一覧を確認しやすく なりますそのタイトルの下に担当者が詳細を追記します何が起きたのか

00:01:38.340 --> 00:01:46.420
いつ始まったのか顧客はすでに何を試したのかどの製品に関するものか そしてそれは質問なのか依頼なのかあるいは障害なのかこれらの詳細によって曖昧な

00:01:46.420 --> 00:01:54.180
メッセージが誰かが責任を持って解決できるタスクへと変わります さらに詳しく見ていきましょうケースには件名製品優先度ケースの種類を設定できます

00:01:54.180 --> 00:02:02.460
件名は請求や技術サポートなどの領域に問題を分類し 製品は顧客が何を使っているかを特定し優先順位はチームがどれほど迅速に対応すべきかを

00:02:02.460 --> 00:02:11.840
示しケースタイプはサポートプロセスに基づいて作業を整理する別の方法をチームに提供します これらの項目自体が顧客や問題を解決するわけではありませんが何百ものケースが異なる

00:02:11.840 --> 00:02:20.420
顧客から届く場合サポートチームが業務を明確に把握する助けとなります 深刻なサービス障害に対応しているチームが一般的な質問の中からそれを見つけ出すために時間を

00:02:20.420 --> 00:02:29.420
費やすべきではありませんさてケースとは単に誰かが記入して忘れるようなフォームではありません それはやり取り全体を記録する作業記録となります電子メールをケースに関連付けたり

00:02:29.420 --> 00:02:35.700
電話の内容をそこに反映させたりできるほかエージェントはチャット後にメモを追加したり フォローアップのタスクを設定したり予定を記録したりできます

00:02:35.700 --> 00:02:43.720
すべての活動が同じ顧客の問題に関連付けられるため次に担当する人は状況を一から組み立て直す必要がありません エージェントが午前中に作業を開始し

00:02:43.720 --> 00:02:52.520
昼食後にケースを製品スペシャリストに引き継ぐ状況を想像してみてください ケースの記録がなければスペシャリストはああこれを見ておいてくれるといった短いメッセージしか受け取れないかもしれません

00:02:52.520 --> 00:03:00.080
これでは不十分ですケースの記録があれば元の問題顧客の詳細通話中に何が起こったか 最初の担当者が何をすでに確認したかを把握できます

00:03:00.080 --> 00:03:07.220
それによりはるかに優れた引き継ぎが可能になります ダイナミクス365はサポートプロセスが進む中でケースの状態を明確に保ちます

00:03:07.220 --> 00:03:13.300
チームが調査している間はアクティブ状態を維持でき チームが問題を解決するか最終的な回答を提供すると解決済みにします

00:03:13.300 --> 00:03:19.620
リクエストの作業が不要になった場合 例えば誤って送信されたまたは顧客が取り下げたといった場合にはチームはそれをキャンセルできます

00:03:19.620 --> 00:03:27.520
アクティブ解決済みそしてキャンセル この3つの状態によりチームは各問題が現在どのような状況かという共通認識を持てるため

00:03:27.520 --> 00:03:35.500
ケースにまだ対応が必要かどうかを推測する必要がなくなり 管理者が古い完了済みの作業を新たな顧客の問題として扱う必要もなくなります

00:03:35.500 --> 00:03:42.680
一つの記録が管理を可能にし顧客の全履歴がエージェントにコンテキストを提供します ケースの背後にある顧客のストーリーです

00:03:42.680 --> 00:03:48.100
ケースは何を修正すべきかを教えてくれます 顧客記録は何がこの瞬間に至ったのかを教えてくれます

00:03:48.100 --> 00:03:53.260
エージェントがダイナミクス365カスタマーサービスでケースを開くと最新のメッセージを超えて 確認することができます

00:03:53.260 --> 00:03:59.280
彼らは全体像つまり過去のケース以前のメール顧客に関連付けられた製品 そしてそのサポート履歴を把握します

00:03:59.280 --> 00:04:02.940
コンテキストは会話を変えます なぜコンテキストが重要なのでしょうか

00:04:02.940 --> 00:04:09.020
顧客がデバイスの故障を報告してくる場面を想像してください エージェントが今日のメッセージしか見られない場合基本的な質問から始めてしまうかもしれません

00:04:09.020 --> 00:04:15.660
モデルは何ですかいつから発生しましたか再起動は試しましたか しかしその顧客は今週すでに2回サポートに連絡しています

00:04:15.660 --> 00:04:22.820
最初の担当者はトラブルシューティングの手順を送り2番目の担当者は交換部品を手配しました その履歴を知っている3番目の担当者は顧客に最初からやり直すよう求めません

00:04:22.820 --> 00:04:30.640
代わりにその手順はすでに試されており交換部品でも解決しなかったことがわかります では次の手順を試しましょうと言いますこれはもう一度問題を説明していただけますか

00:04:30.640 --> 00:04:34.900
という言葉とは大きく異なります これは360度カスタマービューと呼ばれることがよくあります

00:04:34.900 --> 00:04:41.520
名前は立派に聞こえますが意味はシンプルです これはエージェントが単なる孤立したメッセージではなく多角的な視点から顧客を把握することを意味します

00:04:41.520 --> 00:04:50.880
エージェントは顧客本人その所属企業過去のサポート以来これまでの会話そして関連する製品を把握します サポートチームにとってこれは推測による対応を排除し明確な出発点を提供します

00:04:50.880 --> 00:04:59.880
さてすべての顧客が同じ種類のサポートを受けるわけではありません 保証を購入している顧客もいれば一定のサポート時間数を契約している企業や問い合わせ件数に上限がある契約

00:04:59.880 --> 00:05:06.940
あるいは迅速な対応が受けられるプレミアムサポートの顧客もいます ダイナミクス365はこれらすべてを権利エンタイトルメントで追跡します

00:05:06.940 --> 00:05:13.300
権利とはシステム内における顧客のサポート契約のことです アカウントに付随するサービス利用契約だと考えてください

00:05:13.300 --> 00:05:18.640
エージェントはエンジニアの派遣を約束したり有償作業を開始したりする前にどのようなサポートが適用されるかを確認します

00:05:18.640 --> 00:05:23.780
これにより気まずい事態を避けられます 例えば製品の故障に対してまだ保証が適用される顧客がいるとします

00:05:23.780 --> 00:05:28.420
そのケースはその手順に沿って処理されます 別の顧客はサポート時間をすべて使い切っているかもしれません

00:05:28.420 --> 00:05:33.860
エージェントは契約外の作業を約束する前にそれを把握できます またサポートチームが顧客を公平に扱うためにも役立ちます

00:05:33.860 --> 00:05:40.560
エージェントは古い契約書を探したりタブ書に問い合わせたりする必要はありません サポート条件は顧客情報と共に表示されるためエージェントはすぐに見つけることができます

00:05:40.560 --> 00:05:44.740
次にナレッジベースがあります サポートチームは同じ問題を何度も解決します

00:05:44.740 --> 00:05:49.880
パスワードのリセットセットアップ手順アップデート後の基地のエラー 提携回答がある請求に関する質問などです

00:05:49.880 --> 00:05:56.340
ナレッジ記事はそうした回答を一箇所に保存します サービスワークスペース内でエージェントはケースに対応しながら記事を検索できます

00:05:56.340 --> 00:06:01.940
記事にはわかりやすい説明手順スクリーンショットまたはチームが行うべき正確なチェック項目が含まれている場合があります

00:06:01.940 --> 00:06:06.720
エージェントがそれぞれ記憶を頼りに独自の回答を作成するのではなくチームがレビューした共有回答を使用します

00:06:06.720 --> 00:06:11.040
これによりサポートの質が一定にもたれます また経験の浅いエージェントの助けにもなります

00:06:11.040 --> 00:06:16.120
チーム内で周知された解決策を利用できるため一般的な問題をうまく処理するのに長年の経験は必要ありません

00:06:16.120 --> 00:06:19.680
コパイロットのケース要約はもう一つの一般的な問題である長いケース履歴の管理に役立ちます

00:06:19.680 --> 00:06:23.240
ケースには時間の経過とともに膨大なメールメモ更新情報が蓄積されることがあります

00:06:23.240 --> 00:06:26.560
すべてに目を通すには時間がかかります 特に引き継ぎ後はなおさらです

00:06:26.560 --> 00:06:33.240
コパイロットはケースのタイトル顧客件名製品優先度ケースタイプ説明最近のアクティビティをまとめた短い要約を作成します

00:06:33.240 --> 00:06:40.400
これはエージェントが作業を開始する前の簡単なブリーフィングとなります エージェントは記録を確認し自身の判断を下す必要がありますが状況をより早く把握できます

00:06:40.400 --> 00:06:49.600
これは顧客が待機しておりケースが複数の担当者を経由してきた場合に役立ちます エージェントが顧客と問題を理解したらケースを適切な担当者に届ける必要があります

00:06:49.600 --> 00:06:57.880
受付から適切なQA 顧客はメール電話チャットソーシャルメディアセルフサービスポータルなど様々な方法で助けを求めることができます

00:06:57.880 --> 00:07:07.840
チャンネルは変わりますがサポートチームにはリクエストを管理するための明確な場所が一つ必要です レコード作成ルールを設定しておけばダイナミクス365はそれらの会話からケースを作成できます

00:07:07.840 --> 00:07:15.500
共有サポートアドレスに届くメールを考えてみましょう 誰かが気づくまでメールボックスに放置するのではなくルールによってそのメールがケースに変換されます

00:07:15.500 --> 00:07:20.500
そのメッセージがカスタマーサービス内での作業の起点となります これにより手動でのコピー作業が削減されます

00:07:20.500 --> 00:07:26.640
同じ考え方が他の接続済チャネルにも適用されます チームはどのメッセージで新しいケースを作成しどれを既存のケースに紐付けるかを選択します

00:07:26.640 --> 00:07:31.440
進行中の問題への返信はその問題に紐付けられたままになります 新しい質問には独自のケースが作成されます

00:07:31.440 --> 00:07:35.980
次に担当者が引き継ぐまでの間ケースを保持する場所が必要です その場所となるのが多くの場合9です

00:07:35.980 --> 00:07:41.460
9はチームにとっての共有作業トレイです それは特定の一人のエージェントの受信トレイではなくリクエストを見た本人だけのものでもありません

00:07:41.460 --> 00:07:48.640
その代わりチーム全体が対応待ちの作業を確認できる場所となります 請求チーム技術サポートチーム返品チームを持つ会社を想像してみてください

00:07:48.640 --> 00:07:56.380
各チームには独自の給があります 請求に関する質問は請求チームへ製品の不具合は技術サポートへ返品依頼は返品プロセスを熟知した担当者へ送られます

00:07:56.380 --> 00:08:01.600
単純に聞こえますが実際にそうなのです 明確に分類することで作業をむやみにたらい回しにする必要がなくなります

00:08:01.600 --> 00:08:07.480
ルーティングルールはその分類を助けてくれます ルーティングルールはケースの詳細を確認し適切な給や担当者へ送信します

00:08:07.480 --> 00:08:13.120
特定の製品に関するケースはその製品担当チームへ送られます 特定の地域からのケースは現地のサポートへ送られます

00:08:13.120 --> 00:08:17.560
深刻な問題は緊急要求へ送られます 一般的な質問は標準チームの給で待機します

00:08:17.560 --> 00:08:23.020
スキルに基づいて業務を振り分ける組織もあります 例えばフランス語で問い合わせてきた顧客にはフランス語が話せる担当者が必要です

00:08:23.020 --> 00:08:30.640
技術的な問題には特定の製品について訓練を受けた担当者が必要です ルーティングを行うことですべてのリクエストを一様に扱うのではなく解決できる担当者に直接案件を割り当てることができます

00:08:30.640 --> 00:08:36.460
自動化は役立ちますが最終的な判断を下すのはやはり人間です チームリーダーが困難な案件を見てシニア担当者に直接割り当てることもあるでしょう

00:08:36.460 --> 00:08:42.260
あるいは顧客をすでによく知っている担当者がいるかもしれません 問題が複数の製品にまたがりルールでは判断できない経験が必要な場合もあります

00:08:42.260 --> 00:08:50.780
手動での割り当てによりチームはそうした人間的な判断を下す余地が生まれます 案件の進行中に担当者が変更されることもあります担当者がより多くの情報を必要とし案件を急に戻す場合があるからです

00:08:50.780 --> 00:08:56.880
チームがその問題を多部門の管轄だと判断したり通常のチームでは解決できない緊急リクエストを エスカレーションする必要が生じたりすることもあります

00:08:56.880 --> 00:09:04.360
ダイナミクス365は担当者が行き詰まったまま放置するのではなく業務が停滞しないようにします さて一つの問題から多数の案件が発生することもあります

00:09:04.360 --> 00:09:11.020
何十人もの顧客に影響を与えるソフトウェアの障害を想像してみてください 顧客はそれぞれ個別にサポートへ連絡するため各報告に対して個別の案件が必要です

00:09:11.020 --> 00:09:18.400
しかしすべての報告は一つの大きな問題につながっています 親案件はその後半な問題を追跡し子案件はその下の個々の顧客からの報告を追跡します

00:09:18.400 --> 00:09:25.940
これによりサポートチームは2つの視点を同時に持つことができます 親案件を通じて根本的な障害の解決に取り組みつつ子案件で各顧客に状況を伝えることができます

00:09:25.940 --> 00:09:32.940
修正方法が見つかればすべての電話対応ごとに1から障害を調査する必要はありません 重複案件はより小規模で同様の問題を引き起こします

00:09:32.940 --> 00:09:38.180
顧客がメールと電話の両方で同じ問題を問い合わせたり2人の担当者が気づかずにそれぞれ 案件を作成したりすることがあります

00:09:38.180 --> 00:09:44.880
チームは労力を分散させる代わりに類似の案件を統合することができます 一つの案件がメインの記録となり作業を一元化できます

00:09:44.880 --> 00:09:53.540
同じ問題を2度も解決する必要はありません 適切な給と担当者に案件を割り当てることで作業が始まりますが顧客は約束された時間内での対応を期待しています

00:09:53.540 --> 00:09:59.320
sla とガイド付き作業で約束を守る 案件を適切な担当者に割り当てるのは仕事の半分にすぎません

00:09:59.320 --> 00:10:06.040
なぜなら顧客は約束した時間内での支援も期待しているからです そこで登場するのがサービスレベルアグリーメントいわゆるsla です

00:10:06.040 --> 00:10:13.680
sla は案件に期限を設定するためチームは最初の返信であれ完全な解決であれ 顧客との約束を果たすまでにあとどれくらいの時間があるかを正確に把握できます

00:10:13.680 --> 00:10:23.980
しかしここで重要な点がありますそれらの期限が常に同じとは限らないということです 例えば技術チームが修正の発見とテストに2営業日かかる場合でも顧客は1時間以内の確認連絡を期待している

00:10:23.980 --> 00:10:30.960
ことがあります ダイナミクス365では初回応答目標と解決目標を個別に追跡できるためすべての問題を即座に解決できるかのように

00:10:30.960 --> 00:10:38.660
予想うことなくチームが迅速に行動できますここでサービスが停止してしまった顧客を 想像してみてください顧客は10分での完全な修理を期待しているわけではありませんが

00:10:38.660 --> 00:10:47.640
問題が認識されているという確認と今後の見通しそして状況の報告を求めています 初回応答目標は最初の接触を追跡し解決目標は回答や修正に至るまでの全

00:10:47.640 --> 00:10:54.520
工程を追跡します また顧客によって約束される内容は異なりますプレミアムサポート契約を結んでいる企業は標準プランの顧客よりも早い

00:10:54.520 --> 00:11:04.020
応答目標が設定されます優先度の高い障害には日常的な操作方法の質問よりも短い期限が設定されます サポート契約優先度ケースの種類が適用される時間ルールを形成します

00:11:04.020 --> 00:11:11.860
これにより約束が公平かつ明確にもたれます slaがないと担当者はリストの古い順から対応してしまい 期限が迫った重要な案件が見過ごされる可能性があります

00:11:11.860 --> 00:11:19.340
slaがあればケース画面に時間インジケーターが表示されどの約束を優先すべきかが担当者に示されます そのためプレッシャーが高まる様子を視覚的に把握できます

00:11:19.340 --> 00:11:29.200
時間に余裕のあるケースも対応が必要ですが応答期限が迫っているケースは今すぐ対応し なければなりませんチームは目標が近づいたあるいは期限を過ぎた際にアラートやエスカレーションを設定できるため

00:11:29.200 --> 00:11:36.260
顧客から催促される前に上司が介入できます 時間目標は緊急性を管理しビジネスプロセスフローは業務そのものを誘導します

00:11:36.260 --> 00:11:44.300
ビジネスプロセスフローはケース内に表示される一連のステージです これは組織が望むケース対応手順に基づいて担当者に明確な道筋を示します

00:11:44.300 --> 00:11:52.360
各ステージは受付から調査解決へと進みそれぞれの段階で適切な質問と確認が行われ ますこれをプロセス内の適切な箇所に配置されたチェックリストと考えてください

00:11:52.360 --> 00:12:01.340
新しい担当者は専門家にケースを引き継ぐ際にどの詳細情報が必要かを推測する必要がありません フローは製品問題の種類影響範囲など次のチームが必要とする情報を求めることができます

00:12:01.340 --> 00:12:07.480
経験豊富な担当者はより早く進められますが共通の道筋があることでチーム全体が同じ方向を向いて作業できます 具体例を見てみましょう

00:12:07.480 --> 00:12:15.540
優先度の高いサービス障害が発生したとします ケースは緊急急に入りslaのカウントダウンが始まります担当者は顧客の詳細を確認し

00:12:15.540 --> 00:12:24.260
影響を記録し応答期限が切れる前に最初の応答を送信します 次にプロセスフローによりケースは診断ステージへ進みチームはエラーの詳細を収集し

00:12:24.260 --> 00:12:30.600
関連するレポートを確認します その後原因が特定され顧客への更新情報が準備されるとケースは解決ステージへと進みます

00:12:30.600 --> 00:12:38.440
この一連の流れはマネージャーにとっても全体像をより明確に把握する助けとなります 担当者は問い合わせの受付診断最終的な回答のどの段階でケースが滞っているかを確認できます

00:12:38.440 --> 00:12:43.440
このワークフローはチームの課題をすべて解決するわけではありませんが 多忙な中で基本的な手順が省略されるのを防ぎます

00:12:43.440 --> 00:12:52.760
ダイナミクス365では各段階でエージェントが選択できるステータス変更を制御することも可能です これはステータス理由の遷移と呼ばれ技術的な名称に聞こえますが考え方はシンプルです

00:12:52.760 --> 00:13:00.540
ケースは論理的な手順に沿って進める必要があります 必須の社内チェックを待っているケースを誰かが完了とマークしたり理由を記録せずに新規ケースを即座に

00:13:00.540 --> 00:13:05.360
キャンセルしたりすることは避けなければなりません ケースの状態が変われば選択可能なアクションも変わります

00:13:05.360 --> 00:13:10.400
例えば調査中のケースであれば顧客からの詳細情報を待つ間にエージェントが一時保留にする 選択肢が用意されます

00:13:10.400 --> 00:13:16.040
顧客から返信があればエージェントは作業を再開できます 問題が解決すればケースを解決済みに移行できます

00:13:16.040 --> 00:13:23.600
これによりケース履歴が整理されます 返信するだけでは業務は完了しませんチームは問題がどのように収束したかを記録し適切にケースをクローズする必要があります

00:13:23.600 --> 00:13:31.060
解決学習そしてより良いサービスへ返信を送っただけで自動的にケースがクローズされるわけではありません チームは解決策を記録する必要があります

00:13:31.060 --> 00:13:40.560
つまり何が問題を解決したかあるいは顧客にどのような最終回答をしたかを書き留めます それは交換機の送付重複支払いの返金アクセスを遮断していた設定の更新などが考えられます

00:13:40.560 --> 00:13:48.060
その記録は顧客データの一部となり数ヶ月後に同じ顧客から関連する問題で問い合わせがあった際 次の担当者に有益な出発点を提供します

00:13:48.060 --> 00:13:53.280
最初の修正でうまくいかないこともあります 顧客が指示通りに言ってもエラーが再発するかもしれません

00:13:53.280 --> 00:14:00.840
交換部品が届いても故障が直らない場合もあります そのような状況では履歴のない新規レコードを作成するのではなくケースを再オープンするか

00:14:00.840 --> 00:14:05.040
急に戻して継続的に対応できます ケースはチームが中断したところから再開されます

00:14:05.040 --> 00:14:11.960
これは担当者が変わる際に重要です 新しい担当者は前任者が何を試み顧客が何を確認し何がまだ未確認なのかを把握できます

00:14:11.960 --> 00:14:21.600
担当者が変わったという理由だけで顧客が最初からすべてを説明し直す必要はありません 時間の経過とともに蓄積されたケースデータは個別の顧客の問題を超えてチームに現状を伝えてくれます

00:14:21.600 --> 00:14:30.220
マネージャーは解決までの時間を確認することでケースの発生から完了までにかかる時間を追跡できます ステージ滞留時間を確認すればケースがどの段階に多くの時間を費やしているかがわかります

00:14:30.220 --> 00:14:38.000
また初回コンタクト解決率も監視できこれは最初の担当者が引き継ぎなしでどれだけ問題を解決できたかを示します ワークロードの管理も重要です

00:14:38.000 --> 00:14:46.040
毎週月曜の朝に特定の給がいっぱいになればチームはそれを把握できます 技術的なケースが内部確認待ちで数日停滞すればその遅延はケースデータに現れます

00:14:46.040 --> 00:14:52.140
あるチームがケースを素早くクローズしても顧客が再オープンし続けるなら最初の解決策の品質を見直す必要があります

00:14:52.140 --> 00:14:57.360
数字そのものが全てを説明するわけではありません 数字はチームが何を問いかけるべきかを指し示します

00:14:57.360 --> 00:15:02.640
特定の製品に関するケースがなぜ増加しているのか なぜ特定の種類のケースに予想以上の時間がかかるのか

00:15:02.640 --> 00:15:09.840
なぜエージェントは同じ答えを繰り返し検索し役立つナレッジ記事を見つけられないのか パターンを読み解くことで日々のサポート業務から学びを得ることができます

00:15:09.840 --> 00:15:15.240
類似ケースの増加は製品の不具合を示唆している可能性があります 最近のアップデートが顧客を混乱させた可能性もあります

00:15:15.240 --> 00:15:22.080
マニュアルの手順をより明確にする必要があるという指摘かもしれません 各リクエストを個別の事象と捉えるのではなく共通の原因を見つけて対処できます

00:15:22.080 --> 00:15:26.940
それにより将来的なケースの発生数を減らせます 顧客からのフィードバックも全体像には不可欠です

00:15:26.940 --> 00:15:33.000
ケースがクローズされ目標が達成されていても3回も問い合わせをしなければならなかった 顧客は不満を感じるかもしれません

00:15:33.000 --> 00:15:40.040
ケース履歴とフィードバックの両方を見ることでマネージャーは顧客体験をより深く理解できます そもそもケースを作成したくないと考える顧客もいます

00:15:40.040 --> 00:15:46.280
そこで役立つのがセルフサービスポータルです ポータルを通じて顧客はサポートチームに電話することなくリクエスト作成

00:15:46.280 --> 00:15:52.840
ステータス確認情報の追加ナレッジ記事の閲覧が可能です 簡単な質問であれば全員の時間を節約できます

00:15:52.840 --> 00:16:02.720
顧客は都合の良い時に配送状況を確認したりセットアップガイドを参照したりできます 一方エージェントは調査説明判断が必要な問題により多くの時間を避けるようになります

00:16:02.720 --> 00:16:07.900
ダイナミクス365カスタマーサービスはなじみのあるマイクロソフトツールと連携してケース処理を サポートします

00:16:07.900 --> 00:16:12.820
エージェントはアウトルックでメールを処理できます チームはチームで難解な問題について議論できます

00:16:12.820 --> 00:16:19.000
ドキュメントや共有情報はシェアポイントに集約可能です パワービーアイでケースデータをレポートやダッシュボード化し

00:16:19.000 --> 00:16:25.420
パワープラットフォームで独自のホームアラート自動化処理を追加できます 各ツールにはそれぞれの役割があります

00:16:25.420 --> 00:16:32.220
どのようなツールで通信や共有を行ってもケースはサポートの問題と履歴をつなぎ合わせる 中心的な場所であり続けます

00:16:32.220 --> 00:16:40.740
ケース管理の本質はチケット画面を埋めることではありません あらゆる顧客の問題に明確な道筋と記録された回答を提供しそこからチームが学びを得ることです

00:16:40.740 --> 00:16:46.200
まとめ顧客体験の全体像を統合しましょう 最後に最も重要なポイントをお伝えします

00:16:46.200 --> 00:16:51.400
ダイナミクス365のケース管理なら課題や作業約束 結果を一つのレコードに集約できます

00:16:51.400 --> 00:16:56.020
文脈を見失ったり何度も同じ修正を繰り返したりすることもありません 皆さんのサポートプロセスを見直してみてください

00:16:56.020 --> 00:17:01.280
顧客の情報は一体どこへ消えてしまっているのでしょうか そこで情報を一つにまとめることがすべてを変える鍵となります

00:17:01.280 --> 00:17:05.220
お気に入りのポッドキャストプラットフォームで登録して私ミルコピータースがお届けするメートル365

00:17:05.220 --> 00:17:10.600
fmのマイクロソフト活用術をぜひお聞きください 日常業務を支えるツールをわかりやすく解説しています