顧客が注文の破損についてメールし翌日に電話をかけその後チャットを開く 誰も状況を把握しておらず顧客は毎回同じ説明を繰り返しサポートチームは受信トレイメモ別々のツールを探し回る羽目になります それこそがダイナミクス365のケース管理で解決できる問題ですケースとは忙しいオフィスビル内にある一つのラベル付きホルダーのようなものだと考えて ください顧客の問題に関するあらゆる情報が最初の質問から最終的な回答まで全てそのホルダーに まとめられますm 365 fm のミルコピーターズがお届けするこのナレッジナゲットではケースルーティング 応答期限サポート記事そしてクローズに至るまでがどのように連携するかを見ていきましょうケースとは何か25で説明しますではケースとは一体何でしょうか ケースとは回答や解決が必要な一つの顧客の問題を記録したものです問題の内容は製品の破損請求に関する質問 ログインの不具合サービス利用のサポート依頼など様々です重要なのは一人の顧客が同時に複数のケースを持つ場合があるという点です 例えば一人の顧客が月曜日に請求書について問い合わせ火曜日にデバイスの故障を報告し金曜日に住所変更のサポートを必要とするかもしれません これらは個別の問題であるためダイナミクス365では全ての会話を混乱した一つのスレッドにまとめず個別のケース記録として管理します 担当者がケースを作成する際それを顧客と直接紐付けますその顧客とは個人を指す取引先担当者である場合もあればその人が勤務する会社を指す 取引先企業である場合もありますつまりノースウィンドトレーダーズのジェイミーが問題を報告した場合ケースはジェイミーと会社の双方に紐付けられ 記録を開いた誰でも誰が助けを必要としておりどの組織の問題であるかを確認できますケースには問題の簡潔な説明も必要です ソフトウェア更新後にプリンターが停止したや年間プランで二重請求されたといったタイトルをつけることですべての記録を開かなくてもオープンなケースの一覧を確認しやすく なりますそのタイトルの下に担当者が詳細を追記します何が起きたのかいつ始まったのか顧客はすでに何を試したのかどの製品に関するものか そしてそれは質問なのか依頼なのかあるいは障害なのかこれらの詳細によって曖昧なメッセージが誰かが責任を持って解決できるタスクへと変わります さらに詳しく見ていきましょうケースには件名製品優先度ケースの種類を設定できます件名は請求や技術サポートなどの領域に問題を分類し 製品は顧客が何を使っているかを特定し優先順位はチームがどれほど迅速に対応すべきかを示しケースタイプはサポートプロセスに基づいて作業を整理する別の方法をチームに提供します これらの項目自体が顧客や問題を解決するわけではありませんが何百ものケースが異なる顧客から届く場合サポートチームが業務を明確に把握する助けとなります 深刻なサービス障害に対応しているチームが一般的な質問の中からそれを見つけ出すために時間を費やすべきではありませんさてケースとは単に誰かが記入して忘れるようなフォームではありません それはやり取り全体を記録する作業記録となります電子メールをケースに関連付けたり電話の内容をそこに反映させたりできるほかエージェントはチャット後にメモを追加したり フォローアップのタスクを設定したり予定を記録したりできますすべての活動が同じ顧客の問題に関連付けられるため次に担当する人は状況を一から組み立て直す必要がありません エージェントが午前中に作業を開始し昼食後にケースを製品スペシャリストに引き継ぐ状況を想像してみてください ケースの記録がなければスペシャリストはああこれを見ておいてくれるといった短いメッセージしか受け取れないかもしれませんこれでは不十分ですケースの記録があれば元の問題顧客の詳細通話中に何が起こったか 最初の担当者が何をすでに確認したかを把握できますそれによりはるかに優れた引き継ぎが可能になります ダイナミクス365はサポートプロセスが進む中でケースの状態を明確に保ちますチームが調査している間はアクティブ状態を維持でき チームが問題を解決するか最終的な回答を提供すると解決済みにしますリクエストの作業が不要になった場合 例えば誤って送信されたまたは顧客が取り下げたといった場合にはチームはそれをキャンセルできますアクティブ解決済みそしてキャンセル この3つの状態によりチームは各問題が現在どのような状況かという共通認識を持てるためケースにまだ対応が必要かどうかを推測する必要がなくなり 管理者が古い完了済みの作業を新たな顧客の問題として扱う必要もなくなります一つの記録が管理を可能にし顧客の全履歴がエージェントにコンテキストを提供します ケースの背後にある顧客のストーリーですケースは何を修正すべきかを教えてくれます 顧客記録は何がこの瞬間に至ったのかを教えてくれますエージェントがダイナミクス365カスタマーサービスでケースを開くと最新のメッセージを超えて 確認することができます彼らは全体像つまり過去のケース以前のメール顧客に関連付けられた製品 そしてそのサポート履歴を把握しますコンテキストは会話を変えます なぜコンテキストが重要なのでしょうか顧客がデバイスの故障を報告してくる場面を想像してください エージェントが今日のメッセージしか見られない場合基本的な質問から始めてしまうかもしれませんモデルは何ですかいつから発生しましたか再起動は試しましたか しかしその顧客は今週すでに2回サポートに連絡しています最初の担当者はトラブルシューティングの手順を送り2番目の担当者は交換部品を手配しました その履歴を知っている3番目の担当者は顧客に最初からやり直すよう求めません代わりにその手順はすでに試されており交換部品でも解決しなかったことがわかります では次の手順を試しましょうと言いますこれはもう一度問題を説明していただけますかという言葉とは大きく異なります これは360度カスタマービューと呼ばれることがよくあります名前は立派に聞こえますが意味はシンプルです これはエージェントが単なる孤立したメッセージではなく多角的な視点から顧客を把握することを意味しますエージェントは顧客本人その所属企業過去のサポート以来これまでの会話そして関連する製品を把握します サポートチームにとってこれは推測による対応を排除し明確な出発点を提供しますさてすべての顧客が同じ種類のサポートを受けるわけではありません 保証を購入している顧客もいれば一定のサポート時間数を契約している企業や問い合わせ件数に上限がある契約あるいは迅速な対応が受けられるプレミアムサポートの顧客もいます ダイナミクス365はこれらすべてを権利エンタイトルメントで追跡します権利とはシステム内における顧客のサポート契約のことです アカウントに付随するサービス利用契約だと考えてくださいエージェントはエンジニアの派遣を約束したり有償作業を開始したりする前にどのようなサポートが適用されるかを確認しますこれにより気まずい事態を避けられます 例えば製品の故障に対してまだ保証が適用される顧客がいるとしますそのケースはその手順に沿って処理されます 別の顧客はサポート時間をすべて使い切っているかもしれませんエージェントは契約外の作業を約束する前にそれを把握できます またサポートチームが顧客を公平に扱うためにも役立ちますエージェントは古い契約書を探したりタブ書に問い合わせたりする必要はありません サポート条件は顧客情報と共に表示されるためエージェントはすぐに見つけることができます次にナレッジベースがあります サポートチームは同じ問題を何度も解決しますパスワードのリセットセットアップ手順アップデート後の基地のエラー 提携回答がある請求に関する質問などですナレッジ記事はそうした回答を一箇所に保存します サービスワークスペース内でエージェントはケースに対応しながら記事を検索できます記事にはわかりやすい説明手順スクリーンショットまたはチームが行うべき正確なチェック項目が含まれている場合がありますエージェントがそれぞれ記憶を頼りに独自の回答を作成するのではなくチームがレビューした共有回答を使用しますこれによりサポートの質が一定にもたれます また経験の浅いエージェントの助けにもなりますチーム内で周知された解決策を利用できるため一般的な問題をうまく処理するのに長年の経験は必要ありませんコパイロットのケース要約はもう一つの一般的な問題である長いケース履歴の管理に役立ちますケースには時間の経過とともに膨大なメールメモ更新情報が蓄積されることがありますすべてに目を通すには時間がかかります 特に引き継ぎ後はなおさらですコパイロットはケースのタイトル顧客件名製品優先度ケースタイプ説明最近のアクティビティをまとめた短い要約を作成しますこれはエージェントが作業を開始する前の簡単なブリーフィングとなります エージェントは記録を確認し自身の判断を下す必要がありますが状況をより早く把握できますこれは顧客が待機しておりケースが複数の担当者を経由してきた場合に役立ちます エージェントが顧客と問題を理解したらケースを適切な担当者に届ける必要があります受付から適切なQA 顧客はメール電話チャットソーシャルメディアセルフサービスポータルなど様々な方法で助けを求めることができますチャンネルは変わりますがサポートチームにはリクエストを管理するための明確な場所が一つ必要です レコード作成ルールを設定しておけばダイナミクス365はそれらの会話からケースを作成できます共有サポートアドレスに届くメールを考えてみましょう 誰かが気づくまでメールボックスに放置するのではなくルールによってそのメールがケースに変換されますそのメッセージがカスタマーサービス内での作業の起点となります これにより手動でのコピー作業が削減されます同じ考え方が他の接続済チャネルにも適用されます チームはどのメッセージで新しいケースを作成しどれを既存のケースに紐付けるかを選択します進行中の問題への返信はその問題に紐付けられたままになります 新しい質問には独自のケースが作成されます次に担当者が引き継ぐまでの間ケースを保持する場所が必要です その場所となるのが多くの場合9です9はチームにとっての共有作業トレイです それは特定の一人のエージェントの受信トレイではなくリクエストを見た本人だけのものでもありませんその代わりチーム全体が対応待ちの作業を確認できる場所となります 請求チーム技術サポートチーム返品チームを持つ会社を想像してみてください各チームには独自の給があります 請求に関する質問は請求チームへ製品の不具合は技術サポートへ返品依頼は返品プロセスを熟知した担当者へ送られます単純に聞こえますが実際にそうなのです 明確に分類することで作業をむやみにたらい回しにする必要がなくなりますルーティングルールはその分類を助けてくれます ルーティングルールはケースの詳細を確認し適切な給や担当者へ送信します特定の製品に関するケースはその製品担当チームへ送られます 特定の地域からのケースは現地のサポートへ送られます深刻な問題は緊急要求へ送られます 一般的な質問は標準チームの給で待機しますスキルに基づいて業務を振り分ける組織もあります 例えばフランス語で問い合わせてきた顧客にはフランス語が話せる担当者が必要です技術的な問題には特定の製品について訓練を受けた担当者が必要です ルーティングを行うことですべてのリクエストを一様に扱うのではなく解決できる担当者に直接案件を割り当てることができます自動化は役立ちますが最終的な判断を下すのはやはり人間です チームリーダーが困難な案件を見てシニア担当者に直接割り当てることもあるでしょうあるいは顧客をすでによく知っている担当者がいるかもしれません 問題が複数の製品にまたがりルールでは判断できない経験が必要な場合もあります手動での割り当てによりチームはそうした人間的な判断を下す余地が生まれます 案件の進行中に担当者が変更されることもあります担当者がより多くの情報を必要とし案件を急に戻す場合があるからですチームがその問題を多部門の管轄だと判断したり通常のチームでは解決できない緊急リクエストを エスカレーションする必要が生じたりすることもありますダイナミクス365は担当者が行き詰まったまま放置するのではなく業務が停滞しないようにします さて一つの問題から多数の案件が発生することもあります何十人もの顧客に影響を与えるソフトウェアの障害を想像してみてください 顧客はそれぞれ個別にサポートへ連絡するため各報告に対して個別の案件が必要ですしかしすべての報告は一つの大きな問題につながっています 親案件はその後半な問題を追跡し子案件はその下の個々の顧客からの報告を追跡しますこれによりサポートチームは2つの視点を同時に持つことができます 親案件を通じて根本的な障害の解決に取り組みつつ子案件で各顧客に状況を伝えることができます修正方法が見つかればすべての電話対応ごとに1から障害を調査する必要はありません 重複案件はより小規模で同様の問題を引き起こします顧客がメールと電話の両方で同じ問題を問い合わせたり2人の担当者が気づかずにそれぞれ 案件を作成したりすることがありますチームは労力を分散させる代わりに類似の案件を統合することができます 一つの案件がメインの記録となり作業を一元化できます同じ問題を2度も解決する必要はありません 適切な給と担当者に案件を割り当てることで作業が始まりますが顧客は約束された時間内での対応を期待していますsla とガイド付き作業で約束を守る 案件を適切な担当者に割り当てるのは仕事の半分にすぎませんなぜなら顧客は約束した時間内での支援も期待しているからです そこで登場するのがサービスレベルアグリーメントいわゆるsla ですsla は案件に期限を設定するためチームは最初の返信であれ完全な解決であれ 顧客との約束を果たすまでにあとどれくらいの時間があるかを正確に把握できますしかしここで重要な点がありますそれらの期限が常に同じとは限らないということです 例えば技術チームが修正の発見とテストに2営業日かかる場合でも顧客は1時間以内の確認連絡を期待していることがあります ダイナミクス365では初回応答目標と解決目標を個別に追跡できるためすべての問題を即座に解決できるかのように予想うことなくチームが迅速に行動できますここでサービスが停止してしまった顧客を 想像してみてください顧客は10分での完全な修理を期待しているわけではありませんが問題が認識されているという確認と今後の見通しそして状況の報告を求めています 初回応答目標は最初の接触を追跡し解決目標は回答や修正に至るまでの全工程を追跡します また顧客によって約束される内容は異なりますプレミアムサポート契約を結んでいる企業は標準プランの顧客よりも早い応答目標が設定されます優先度の高い障害には日常的な操作方法の質問よりも短い期限が設定されます サポート契約優先度ケースの種類が適用される時間ルールを形成しますこれにより約束が公平かつ明確にもたれます slaがないと担当者はリストの古い順から対応してしまい 期限が迫った重要な案件が見過ごされる可能性がありますslaがあればケース画面に時間インジケーターが表示されどの約束を優先すべきかが担当者に示されます そのためプレッシャーが高まる様子を視覚的に把握できます時間に余裕のあるケースも対応が必要ですが応答期限が迫っているケースは今すぐ対応し なければなりませんチームは目標が近づいたあるいは期限を過ぎた際にアラートやエスカレーションを設定できるため顧客から催促される前に上司が介入できます 時間目標は緊急性を管理しビジネスプロセスフローは業務そのものを誘導しますビジネスプロセスフローはケース内に表示される一連のステージです これは組織が望むケース対応手順に基づいて担当者に明確な道筋を示します各ステージは受付から調査解決へと進みそれぞれの段階で適切な質問と確認が行われ ますこれをプロセス内の適切な箇所に配置されたチェックリストと考えてください新しい担当者は専門家にケースを引き継ぐ際にどの詳細情報が必要かを推測する必要がありません フローは製品問題の種類影響範囲など次のチームが必要とする情報を求めることができます経験豊富な担当者はより早く進められますが共通の道筋があることでチーム全体が同じ方向を向いて作業できます 具体例を見てみましょう優先度の高いサービス障害が発生したとします ケースは緊急急に入りslaのカウントダウンが始まります担当者は顧客の詳細を確認し影響を記録し応答期限が切れる前に最初の応答を送信します 次にプロセスフローによりケースは診断ステージへ進みチームはエラーの詳細を収集し関連するレポートを確認します その後原因が特定され顧客への更新情報が準備されるとケースは解決ステージへと進みますこの一連の流れはマネージャーにとっても全体像をより明確に把握する助けとなります 担当者は問い合わせの受付診断最終的な回答のどの段階でケースが滞っているかを確認できますこのワークフローはチームの課題をすべて解決するわけではありませんが 多忙な中で基本的な手順が省略されるのを防ぎますダイナミクス365では各段階でエージェントが選択できるステータス変更を制御することも可能です これはステータス理由の遷移と呼ばれ技術的な名称に聞こえますが考え方はシンプルですケースは論理的な手順に沿って進める必要があります 必須の社内チェックを待っているケースを誰かが完了とマークしたり理由を記録せずに新規ケースを即座にキャンセルしたりすることは避けなければなりません ケースの状態が変われば選択可能なアクションも変わります例えば調査中のケースであれば顧客からの詳細情報を待つ間にエージェントが一時保留にする 選択肢が用意されます顧客から返信があればエージェントは作業を再開できます 問題が解決すればケースを解決済みに移行できますこれによりケース履歴が整理されます 返信するだけでは業務は完了しませんチームは問題がどのように収束したかを記録し適切にケースをクローズする必要があります解決学習そしてより良いサービスへ返信を送っただけで自動的にケースがクローズされるわけではありません チームは解決策を記録する必要がありますつまり何が問題を解決したかあるいは顧客にどのような最終回答をしたかを書き留めます それは交換機の送付重複支払いの返金アクセスを遮断していた設定の更新などが考えられますその記録は顧客データの一部となり数ヶ月後に同じ顧客から関連する問題で問い合わせがあった際 次の担当者に有益な出発点を提供します最初の修正でうまくいかないこともあります 顧客が指示通りに言ってもエラーが再発するかもしれません交換部品が届いても故障が直らない場合もあります そのような状況では履歴のない新規レコードを作成するのではなくケースを再オープンするか急に戻して継続的に対応できます ケースはチームが中断したところから再開されますこれは担当者が変わる際に重要です 新しい担当者は前任者が何を試み顧客が何を確認し何がまだ未確認なのかを把握できます担当者が変わったという理由だけで顧客が最初からすべてを説明し直す必要はありません 時間の経過とともに蓄積されたケースデータは個別の顧客の問題を超えてチームに現状を伝えてくれますマネージャーは解決までの時間を確認することでケースの発生から完了までにかかる時間を追跡できます ステージ滞留時間を確認すればケースがどの段階に多くの時間を費やしているかがわかりますまた初回コンタクト解決率も監視できこれは最初の担当者が引き継ぎなしでどれだけ問題を解決できたかを示します ワークロードの管理も重要です毎週月曜の朝に特定の給がいっぱいになればチームはそれを把握できます 技術的なケースが内部確認待ちで数日停滞すればその遅延はケースデータに現れますあるチームがケースを素早くクローズしても顧客が再オープンし続けるなら最初の解決策の品質を見直す必要があります数字そのものが全てを説明するわけではありません 数字はチームが何を問いかけるべきかを指し示します特定の製品に関するケースがなぜ増加しているのか なぜ特定の種類のケースに予想以上の時間がかかるのかなぜエージェントは同じ答えを繰り返し検索し役立つナレッジ記事を見つけられないのか パターンを読み解くことで日々のサポート業務から学びを得ることができます類似ケースの増加は製品の不具合を示唆している可能性があります 最近のアップデートが顧客を混乱させた可能性もありますマニュアルの手順をより明確にする必要があるという指摘かもしれません 各リクエストを個別の事象と捉えるのではなく共通の原因を見つけて対処できますそれにより将来的なケースの発生数を減らせます 顧客からのフィードバックも全体像には不可欠ですケースがクローズされ目標が達成されていても3回も問い合わせをしなければならなかった 顧客は不満を感じるかもしれませんケース履歴とフィードバックの両方を見ることでマネージャーは顧客体験をより深く理解できます そもそもケースを作成したくないと考える顧客もいますそこで役立つのがセルフサービスポータルです ポータルを通じて顧客はサポートチームに電話することなくリクエスト作成ステータス確認情報の追加ナレッジ記事の閲覧が可能です 簡単な質問であれば全員の時間を節約できます顧客は都合の良い時に配送状況を確認したりセットアップガイドを参照したりできます 一方エージェントは調査説明判断が必要な問題により多くの時間を避けるようになりますダイナミクス365カスタマーサービスはなじみのあるマイクロソフトツールと連携してケース処理を サポートしますエージェントはアウトルックでメールを処理できます チームはチームで難解な問題について議論できますドキュメントや共有情報はシェアポイントに集約可能です パワービーアイでケースデータをレポートやダッシュボード化しパワープラットフォームで独自のホームアラート自動化処理を追加できます 各ツールにはそれぞれの役割がありますどのようなツールで通信や共有を行ってもケースはサポートの問題と履歴をつなぎ合わせる 中心的な場所であり続けますケース管理の本質はチケット画面を埋めることではありません あらゆる顧客の問題に明確な道筋と記録された回答を提供しそこからチームが学びを得ることですまとめ顧客体験の全体像を統合しましょう 最後に最も重要なポイントをお伝えしますダイナミクス365のケース管理なら課題や作業約束 結果を一つのレコードに集約できます文脈を見失ったり何度も同じ修正を繰り返したりすることもありません 皆さんのサポートプロセスを見直してみてください顧客の情報は一体どこへ消えてしまっているのでしょうか そこで情報を一つにまとめることがすべてを変える鍵となりますお気に入りのポッドキャストプラットフォームで登録して私ミルコピータースがお届けするメートル365 fmのマイクロソフト活用術をぜひお聞きください 日常業務を支えるツールをわかりやすく解説しています