Skip to main content
From 16:00 UTC on January 17, 2026, to 20:00 UTC on January 17, 2026, we will perform planned maintenance on the Trailhead, myTrailhead, and Trailblazer Community sites. During the maintenance, these sites will be unavailable, and users won't be able to access them. Please plan your activities around this required maintenance.

カスタマーサービスインシデント管理をはじめる

学習の目的

この単元を完了すると、次のことができるようになります。

  • カスタマーサービスインシデント管理の利点を挙げる。
  • インシデントを定義する。
  • インシデントの重要度を説明する。
  • インシデントのフェーズを挙げる。

インシデントは起こるもの

Ursa Major Solar, Inc. は、米国南西部を中心に太陽光発電関連の商品やシステムを提供している企業です。Ursa Major Solar のビジネスは好調ですが、最近、重大なサービスインシデントが発生し、それに対する備えは万全ではありませんでした。ある日、ニューメキシコ州のアルバカーキで大規模な停電が発生しました。困ったことに、停電地域には Ursa Major Solar の多くのお客様がいました。お客様のソーラーシステムは電力網に接続されていて、停電中には電力網に電気を供給できないため、ソーラーシステムも停止しました。停電が発生したことで、サポートエージェントは多くの電話を受けました。

まずチームはインシデントが発生しているということを認識する必要がありました。この場合、多くのお客様で同じ問題が発生していました。次に、問題の根本原因と修正方法を調べることができるエキスパートを見つける必要がありました。最後に、それをお客様やチーム全体に伝える方法を見つける必要がありました。

残念なことに、Ursa Major はその各ステップで問題に直面しました。各エージェントは、大きな問題があることに気付かずに個々に問題を解決しようとしていました。このやり方では、エージェントの時間が無駄になるだけでなく、お客様の不満も募ります。また、多くのお客様に同じ問題が発生していることにチームが気付いてから、原因がわかるまでにも時間がかかりました。 

状況を更に悪化させたのは、シフト中のエージェントの多くが新人で、助けを得るために開発チームの誰に連絡すればよいかを知らなかったことでした。電話の件数に圧倒されていたため、立ち止まって考える暇がありませんでした。問題が診断された後に、回答を作成するのにも時間がかかりました。Ursa Major とそのお客様にとって散々な日になってしまいました。

最終的には、チームはなんとかすべてのケースを解決できましたが、もっとうまくやれたはずです。 

次のインシデントに備えて計画する

Ursa Major の CEO である Sita Nagappan-Alvarez は、もっと複雑または広範囲な停電が発生したらどのようなことになるかと心配しています。再びインシデントが発生する前に解決策を見つけなければなりません。

彼女は次のインシデントに備えた目標のリストを作成します。

  • インシデントをすばやく認識する。
  • インシデントを一元管理する場所を作る。
  • 問題を適切なエキスパートに転送し、エキスパートが根本原因を見つけて解決策を特定する。
  • 問題を認め、できるだけ早く状況と解決策の最新情報をお客様に提供する。
  • 解決を追跡し、適切に実施されていることを確認する。
  • すべてのお客様に通知し、すべてのケースをクローズする。
  • お客様とエージェントのために、解決策を合理化してスピードアップする。
  • 悪い状況をお客様の信頼を勝ち取るチャンスに変える。

Sita はリストを優秀なテクニカルサポートエージェントの Ada Balewa に渡し、Ursa Major が次のインシデントに備える方法を調べるように指示します。

カスタマーサービスインシデント管理による解決

Ada は Sita の目標をすべて満たすツールを探しているときに、Salesforce のカスタマーサービスインシデント管理を見つけました。Service Cloud に組み込まれたこの機能を使用すれば、チームは大規模な中断を追跡し、適切なエキスパートに作業を委任できます。また、お客様とのコミュニケーションや解決策のロールアウトにも役立ちます。更に良いことに、すでに Service Cloud を使用している Ursa Major はこの機能を無料で使用できます。

関心を持った彼女はもう少し詳しく調べます。カスタマーサービスインシデント管理では問題を 3 つのフェーズに分けます。 

  • 最初に、インシデントが発生します。関連するケースが入ってくるようになり、チームはどれだけのお客様が影響を受けているかを認識します。
  • 次に、問題フェーズでは、エキスパートチームが集まり、問題の根本原因を調べます。
  • 最後に、チームは問題を解決するために必要なステップを説明する変更要求レコードを作成します。

Ada は例も見たいと考え、動画を視聴して会社がインシデントを受け、対応し、修正する方法を確認します。

Ada は Ursa Major でカスタマーサービスインシデント管理を試したいと考えます。まずは計画を作成して、インシデントの定義と優先順位付けを行い、適切な人を関与させる必要があります。計画が完了したら、次に発見事項をまとめたナレッジ記事を作成します。レビュー後、チームはそれを使用してインシデントが発生したときに何をすればよいかを知ることができます。彼女はすでに Slack でスウォーミングを設定済みで、これも役立つはずだと知っています。

インシデントを定義する

Ada は IT Infrastructure Library (ITIL®) によって定義されたベストプラクティスと自社のビジネス目標を使用してカスタマーサービスインシデントを定義します。Ursa Major の他の従業員と相談した後、彼女は重大インシデントを定義します。重大インシデントとは、いくつかのチームの協力が必要であり、緊急性が高い、または影響が大きい、またはその両方である複数の関連するケースのことです。

Ursa Major では、問題が次のいずれかの条件を満たす場合に緊急インシデントとみなします。

  • それによって生じる損害が急速に増大する可能性がある。
  • 早急に修正しなければ、より大きなインシデントになる可能性がある。
  • 主要なお客様に影響を及ぼしているか、そうなる可能性がある。

たとえば、複数のお客様拠点で特定の種類の太陽熱温水器の漏水が発生し、屋根コンポーネントに損害が発生したとします。早急に修正しなければより大きな損害が発生する可能性があり、複数のお客様に影響を及ぼしているため、Ursa Major ではこれを緊急インシデントとみなします。

 次のいずれかの条件を満たす場合、インシデントは影響が大きいとみなされます。

  • 誰かが怪我をする。
  • 多くのお客様に影響を及ぼす。
  • 多額の金銭的影響がある。
  • Ursa Major の評判を損なう可能性がある。

たとえば、大きな病院の太陽熱温水器で漏水が発生したとします。床に水がたまることで、患者やスタッフが怪我をする可能性があります。怪我の可能性と評判への悪影響の可能性があるため、このインシデントは影響が大きいとみなされます。

重要度を定義する

このフレームワークに基づいて、Ada は ITIL のベストプラクティス基準を使用して、Ursa Major のインシデントの 3 つの重要度のリストを重要度 1 (高)、重要度 2 (中)、重要度 3 (低) と定義します。

緊急度

影響

1

2

3

2

3

4

3

4

5

Ada は各インシデント重要度にいくつかの例を挙げます。

  • 重要度 1: システム全体の停止など、この問題はすべてのお客様に影響を及ぼします。複数の屋根に損害が及ぶ壊滅的な太陽熱温水器の障害など、お客様の金銭的損失が発生します。
  • 重要度 2: 地域的な停止など、この問題は複数のお客様に影響を及ぼし、お客様の商品の使用可能状況にも影響を及ぼします。
  • 重要度 3: 複数のお客様拠点でソーラーパネルの効率が早く低下するなど、この問題は複数のお客様に影響を及ぼしますが、重大ではなく回避策があります。
  • 重要度 4 および重要度 5: 優先度が非常に低く、多くの場合は標準のケース解決手法で修正できます。

サービスレベル契約を導入する

重要度を設定した Ada は次に、Ursa Major の既存のサービスレベル契約 (SLA) を会社のサービスレベルマネージャーと一緒に調べます。SLA では、お客様が購入したサービス活動の種類をリストし、応答時間と解決時間に関する要件を含めます。Ursa Major がその要件を満たすことが重要です。

彼らは一緒に、インシデントの重要度とお客様の SLA に基づいて、さまざまな種類のインシデントの応答時間と解決時間を決定します。 

重要度

目標応答時間

目標解決時間

1 (高)

30 分以内

4 時間

2 (中)

1 時間以内

8 時間

3 (低)

2 時間以内

1 週間

これでインシデント中にお客様に適切に対応できるようになります。

インシデント中に誰に連絡するかを決める

インシデントが発生する前に、Ada は連絡先となる人のリストを作成します。 

  • インシデント所有者: 最初は Ada がすべてのインシデントのインシデントマネージャーです。チームがプロセスに慣れてきたら、インシデント所有者のリストを拡大する予定です。
  • テクニカルエキスパート: 現在問題が発生しているソーラー機器や設置の種類に関する 1 人以上のエキスパートでトラブルシューティングチームを編成します。Ursa Major ではシニアソーラー設置担当者または修理技術者が起用されます。
  • サービスレベルマネージャー: 影響を受けたお客様のサービスレベルマネージャーが SLA のコンプライアンスを監視します。
  • 当番のカスタマーサービスマネージャー: カスタマーサービスマネージャーはチームとのコミュニケーションを行います。

Ada は予備的な計画を完了しました。彼女は発見事項をまとめたナレッジ記事を作成します。チームがインシデント中にこれを使用することで、誰もが何をすべきかを把握できます。

Ada はカスタマーサービスインシデント管理が Ursa Major にとって最適なツールだと知りました。Ursa Major で何をインシデントとみなすかを定義し、インシデントの重要度を設定し、連絡先となる人のリストを作成しました。更に情報をナレッジ記事にまとめました。これで、Salesforce にカスタマーサービスインシデント管理の設定を依頼する準備ができました。

リソース

Salesforce ヘルプで Trailhead のフィードバックを共有してください。

Trailhead についての感想をお聞かせください。[Salesforce ヘルプ] サイトから新しいフィードバックフォームにいつでもアクセスできるようになりました。

詳細はこちら フィードバックの共有に進む