Skip Navigation
Expand
インシデントのルールの設定のベスト・プラクティス
Answer ID 7581   |   Last Review Date 08/14/2019

インシデントのルールを設定する場合のベスト・プラクティスは何ですか。

環境:

インシデント ビジネス (ワークフロー/エスカレーション)ルール

解決策:

インシデント・ルールセットは著しく複雑になることがあります。ただし、下に示すベスト・プラクティスは、ルールを編成し、ルールを使用して実現可能な有益なアクションを利用できるようにするルールセットの堅実な基盤を設定するのに役立ちます。

 

一般的なルールの設定と構造

一部のベストプラクティスは、ルールベースの全体の設定とその構造に焦点を合わせています。

  1. ルールを構築する前に、紙にワークフロー・プロセスを計画し、描写します。これにより、ルーティングおよび処理プロセスを理解するだけでなく、現在のプロセスの非効率性も識別できます。
  2. ルールを構築する前に、キュー、スタッフ・アカウント、カスタム・フィールド、およびプロファイルを準備し、機能させます。インシデントのルールは一般に、インシデントをルーティングしたり、フィールドを設定したりするために使用します。ルールを作成しようとする前に、必要な項目がアプリケーションに存在することを確認してください。
  3. 少なくとも2つのルールの状態を作成します。1つのルールの状態を初期状態として設定する必要があります。初期ルールの状態には、アプリケーションで作成された新規インシデントの初期のルーティングのルールを含みます。既存のインシデントに作用し、その更新を処理するために使われる、少なくとも1つの非初期状態を用意しておくべきです。
  4. すべてのインシデントを初期状態から移行させます。初期アクションが実行された後に、インシデントを特定のユーザーやキューに割り当てるなど、インシデントを別の状態に移行させる適切なアクションを初期ルール状態のルールに含めるようにします。

    各インシデントは、初期状態のルールに1回だけヒットし、その後別の状態に移行されるようにする必要があります。インシデントが初期状態のままである場合、それが次回に更新されたときに、同じルールをヒットし、新しいインシデントであるかのように、再度ルーティングされます。これはループ効果を引き起こし、エージェントがインシデントを別のユーザーやグループに再割当てできなくなることがあります。
  5. 最も重要で特別なルールをリストの一番上に含めます。インシデントが設定された複数のルールに一致することはよくあります。最も制限が厳しく、最も重要なルールとアクションがルール・リストの一番上に表示されるように、ルールを順序付けします。これにより、それらのルールが正しくインシデントに作用するようになります。

    次に、ルールでインシデントを別の状態に移行していることを確認するか、または後続のルールが予期せずにインシデントに作用し、初期アクションを「上書き」していないことを確認してください。たとえば、特定の会社からのインシデントが、特定のエージェントにルーティングされることになっている場合、そのルールをリストの一番上に含めて、リストの下方のルールに基づいて、そのインシデントに作用したり、再割当てされたりしないことを確認してください。
  6. キャッチオール・ルールを含めます。新規インシデントが割り当てられず、未解決の状態で、システムで失われることのないように、初期状態で表示されるルールの一番下に、キャッチオール(あらゆる状況に対処できる)ルールを作成します。一般に、このルールは次のようなものになります。

    IFインシデントのステータスのタイプ=未解決
    THENインシデントを割り当て(キューまたはスタッフへ) AND
    状態を(既存の状態へ)移行する。
  7. キャッチオール・エスカレーション・アクションを含めます。ルールが非初期状態に移行したら、インシデントを汎用的なエスカレーションチェーン・ルールに一致させて、エスカレーションがトリガーされ、未解決のインシデントが長期間更新されない場合に、組織内の誰かに通知されるようにします。これにより、処理されて解決される必要のある古いインシデントに注意を引き付けます。
  8. 関数を使用すべきかどうかを判断します。ルールベース内で関数を使用する必要はありません。関数は、インシデントの有効期間を通して複数回適用する必要のあるルールのセットをグループ化するために設計されています。それにより、ルールベースで同じルールのセットを何回も再作成する必要がありません。同じルールのセットを複数回実行する必要があることがわかっている(エスカレーション・ルールなど)場合は、それらのルールを関数に入れて、特定のルールからその関数を呼び出します。
  9. 各ルールについて記述するために「メモ」フィールドを使用します。ルールを追加または編集する場合、「メモ」フィールドにルールの簡単な説明を入力します。後で他の管理者が全体の設定の中でそのルールの目的を理解しやすいように、それが追加された日付と追加したユーザーを記載します。左側のフレームのルールの上にマウスのポインタを置くと、「メモ」フィールドがポップアップとして表示されるので、ルールの目的を簡単に確認できます。
 

エスカレーション・アクションの設定と順序付け

  1. 各エスカレーションに2つのルールを含めます。エスカレーションを構成する場合、各エスカレーション・アクションに2つのルールを使用します。チェーン・ルール(インシデントをエスカレーションするタイムフレームと条件を設定する)とアクション・ルール(マネージャにEメールを送信するなど、エスカレーションが発生したときに実行するアクションを指定する)を使用する必要があります。エスカレーション・ルールの詳細については、アンサーID7332:エスカレーション・ルールの設定を参照してください。
  2. チェーン・ルールの前にアクション・ルールをリストに表示します。エスカレーション・ルールのペアでは、チェーン・ルールの上にアクション・ルールを置きます。複数のエスカレーション・ルールのペアがある場合、アクション・ルールのグループを最初にリストに表示し、その後にチェーン・ルールのグループを続けます。そのようにすることで、前の更新のチェーン・ルールにすでに一致しているインシデントが、アクション・ルールに一致し、さらに別のエスカレーション条件に一致する機会があります。
  3. エスカレーション関数を作成します。2、3組のエスカレーション・ルールのペアしかない場合でも、それらを関数に入れて、すべてのエスカレーション・ルールをグループ化することを考慮してください。ルールからエスカレーション関数を呼び出します。これにより、エスカレーション・プロセス全体を簡単に確認し、構成されるルールのペアを検証することができます。
 

特定のアクションの使用

ルールのTHENセクションの「アクションを追加」メニューには、送信されるインシデントの数を減らしたり、特定のタイプのインシデントの情報を自動的に提供したりできるいくつかのオプションが含まれます。これらのオプションを理解することは、プロセスをさらに自動化するのに役立つ可能性があります。

  1. ユーザーがインシデントを送信する際に、ユーザーにアンサーを提案します。SmartAssistant提案ソリューション機能は、エンドユーザーが質問を送信する際に自動的にナレッジベースからのアンサーを提案します。インシデントが作成される前に、ユーザーはアンサーのリストを確認してから、質問の送信を続行するオプションがあります。この構成方法に関する詳細については、アンサーID7387:「質問をする」リクエストに対するソリューションの自動提案を参照してください。
  2. プロダクトまたはカテゴリの値によってSmartAssistantソリューションを制限します。SA_SUGGEST_LIMIT_PROD_LVLおよびSA_SUGGEST_CAT_LVL環境設定を使用して、送信されるインシデントのプロダクトまたはカテゴリの値によって、提案ソリューションを制限するようにアプリケーションを構成できます。プロダクト・レベルを1の値に設定すると、SmartAssistantソリューションが同じプロダクト値に制限されます。プロダクトがエンドユーザー・ページで使用されない場合、カテゴリ・レベルを1に設定して、カテゴリ値によってソリューションを制限できます。

    注意:一般に、公開されたアンサーが著しく大量(1000個を超えるアンサーなど)で、「かつ」エンドユーザーがインシデントの送信時に、サブプロダクトまたはサブカテゴリの選択にきわめて優れていると断定できないかぎり、これらのどちらの値も1より大きい値に設定することはお薦めしません。

    さらに、プロダクトとカテゴリの両方を有効にしている場合、エンドユーザーがリクエストの送信時に、正しいプロダクト「かつ」カテゴリを選択することにきわめて優れていないかぎり、プロダクトによってのみ提案ソリューションを制限することをお薦めします。多くの場合、エンドユーザーは、1つの値を適切に選択できても、他のフィールドを適切に選択できないことがあります。
  3. 特定のリクエストに既存のアンサーIDを付加します。ユーザーに特定のアンサーIDを推奨すべき場合、インシデントのタイプを判断します。アクション「スレッドの追加」>「既存のソリューションを「回答」フィールドに付加(アンサーIDで指定)」を使用して、これらの受信インシデントへの特定のアンサーを表示するルールを作成します。これは、インシデントが作成される「前」に問題を解決するのに役立ちます。
  4. リクエストに特定の回答を付加します。必要に応じて、受信リクエストとともに標準テキストの回答を自動的に表示できるインシデントのタイプを決定します。さらに、アクション「スレッドの追加」>「定型応答を「回答」フィールドに付加」を含むルールを作成します。これにより、インシデントを作成する「前」に、エンドユーザーの問題の解決に役立つ標準テキスト回答をエンドユーザーに表示できます。

    この場合、インシデントが到着したら、エージェントはとにかく標準テキストを使用して、ただちにエンド・ユーザーに返送します。テキスト回答を自動的に表示するインシデント・ルールの設定では、人の介入を必要としなくても、エンドユーザーにエージェントから受け取る場合と同じ情報を与えます。これにより、エージェントの作業時間を削減し、重複する質問を自動的に処理します。
  5. IF条件として「次の正規表現と一致する」を使用します。特定のタイプの重複したインシデントを識別するには、IF条件「Incident.Customerスレッドが次の正規表現と一致する」を使用します。次に、パイプ(|)を使用して、ルールをトリガーすべき受信インシデント内の語句を指定します。正規表現の詳細については、アンサーID7429:正規表現およびそれらをルールに適用する方法を参照するか、またはRightNowナレッジベースで「正規表現」を検索してください。ルールのTHEN部分では、特定のアンサーIDまたは標準回答を付加できます。

最後に:ルールの作成が終了したら、それらを見直して、抜け穴が残されていないことを確認します。すべてのシナリオがカバーされることを確認してください。いくつかのテスト・レコードを作成し、ルール・ログを使用して、すべてのルールが正しく実行したことを確認します。

詳細情報は、現在ご利用のバージョンのオンライン・ドキュメンテーションにある ベスト・プラクティス: ビジネス・ルールの計画 セクションをご覧ください。 Oracle B2C Service オンライン・ドキュメンテーション又はマニュアルにアクセスするには、Oracle B2C Serviceプロダクトのドキュメントをご覧ください。

Available Languages for this Answer:

Notify Me
The page will refresh upon submission. Any pending input will be lost.