リピーターを同じエージェントに振り分ける方法（連絡先、ケース、およびモバイルでの方法）
概要
このチュートリアルでは、リピーターのお客様が次回以降のコールやチャットをご利用の際、最も関連性の高いエージェントに接続されるようルーティングを設定する方法について説明します。このルーティング戦略は、お客様とエージェント間の継続性を維持するのに役立ち、お客様の問題を熟知している担当者に再接続することで、顧客満足度の向上につながります。
|
Bright Pattern には、リピーターを直近の対応を担当したエージェントにルーティングするための組み込み機能が用意されています。これは、シナリオ変数 $(item.continuationUserId) を使用して行われます。この方法では不十分な場合、以下の3つのカスタムルーティング方法をご利用いただけます
| |
ダウンロード可能なシナリオ
このチュートリアルで使用した完成済みのシナリオをダウンロードできます。方法3に関連するシナリオについては、下記の 方法3 を参照してください。これらはサンプルシナリオであり、本番環境での使用を意図したものではない点にご注意ください。
ダウンロード後：
- [コンタクトセンター管理者] > [シナリオ] に移動します。
- [シナリオのインポート] をクリックします。
- ファイルをアップロードし、シナリオを開いて設定内容を確認してください。
カスタムルーティングの3つの方法
1. コンタクトレコードを使用する（最後に担当したエージェントを保存します）。
2. ケースの担当者を基準とする（未解決または最近のケースに割り当てられたエージェントに基づいてルーティングします）。
3. 顧客が会社の電話番号に電話をかけた際、以前に対応したエージェントに再度接続するようにルーティングします。
3つの方法すべてで使用されるルーティングパターン
対象となるエージェントIDを決定した後、シナリオでは次のようなロジックに従う必要があります。
1. 対象のエージェントがログインしており、利用可能かどうかを確認します。
2. 利用可能な場合：そのエージェントにインタラクションをルーティングします。
3. 利用不可能な場合：チームまたはスキルベースのルーティングを行います（エージェントのチームを表すスキルを使用してルーティングします）。
4. そのスキルを持つエージェントが誰も利用可能でない場合：通常のオーバーフローまたはフォールバックルーティングを適用します。
Bright Patternのルーティングはスキルベースであるため、「チーム」へのフォールバックを行うには、チームを直接指定するルーティングではなく、スキルやスキルグループを通じてチームを表現する必要があります。
方法1：コンタクトレベルのエージェントリンクを使用するルーティング
状況によっては、組織が「前のエージェント」の決定方法について、より詳細なコントロールを必要とする場合があります。例えば、独自の時間枠を適用したり、複数のインタラクションタイプにわたるルーティング履歴を維持したりしたい場合などが挙げられます。
このような状況では、シナリオ内でエージェント情報をカスタム連絡先フィールドに保存し、それらのフィールドをルーティングの判断に使用することができます。
以下のコンタクトベースの方法では、アクティビティ履歴を利用して、リピーターのお客様を直近対応したエージェントにルーティングします。この方法は、既定の「サービス継続」の動作では不十分な場合に使用してください。
ビジネスケース
以前に組織に連絡した顧客から再度連絡があった場合、そのインタラクションが定義された時間枠内で発生していたことを条件として、その顧客を直近で対応した、または対応を試みたエージェントにそのインタラクションを割り当てることができます。 このアプローチにより、継続性が向上し、説明の繰り返しを減らし、よりパーソナライズされた顧客体験を実現できます。
この方法の仕組み
1. システムは、利用可能な識別子（電話番号やチャットIDなど）を使用して顧客を特定します。顧客は、Bright Patternの識別設定を使用して自動的に特定できます。この設定では、着信したインタラクションを社内の連絡先データベースや設定済みの外部データベースと照合することが可能です。
2. 連絡先のアクティビティ履歴を確認し、最後に担当したエージェントと、条件を満たすインタラクションの発生時刻を特定します。
3. 最後のインタラクションが設定された時間枠内に収まる場合、システムはそのエージェントへのルーティングを試行します。
4. 担当エージェントが不在の場合は、スキルベースのフォールバックルーティングが適用されます。
ステップ1：カスタム連絡先フィールドの作成
「コンタクトセンター管理者 > ケースおよびコンタクト管理 > カスタムフィールド」で、次のようなフィールドを作成します。
- 最終担当エージェントID（テキスト）
- 最終エージェント対応日時（日付/時刻）
これらのフィールドには、その連絡先に関する最新の適格なエージェントの関連付け情報が保存されます。この情報は通常、連絡先にリンクされたアクティビティレコードから取得され、シナリオまたは統合ロジックによって書き込まれます。
ステップ2：どのアクティビティが「最後のエージェント」を更新するかを定義する
ルーティングに使用される「最後のエージェント」は、連絡先に関連付けられた最新の適格なアクティビティに基づいて決定する必要があります。ビジネス要件に応じて、適格なアクティビティには以下が含まれる場合があります。
- エージェントが対応したインバウンドインタラクション
- エージェントが行った手動のアウトバウンドコール試行（応答の有無を問わず）
- プレビューキャンペーンによる発信試行（応答の有無を問わず）
適格なアクティビティが発生した際には、連絡先フィールドに以下の情報を更新してください。
- 対応したエージェントのID
- インタラクションの日時
これにより、その後のルーティング判断において、最新の適格なエージェントの関連付けを利用できるようになります。
コンタクトベースのエージェントルーティングのシナリオロジック
以下のシナリオは、実装の一例を示しています。本番環境では、追加の分岐やエラー処理が必要になる場合があります。インバウンドシナリオにおいて、ルーティングは以下の決定プロセスに従う必要があります。
1. 電話番号やその他の利用可能な識別子を使用して、顧客の特定を試行します。
ほとんどのシナリオにおいて、Bright Patternは、音声通話の場合はANI、チャットチャネルの場合はメッセンジャー識別子など、組み込みの認証方法を使用して連絡先を自動的に識別します。
追加またはカスタムの識別ロジックが必要な場合は、「連絡先の識別子」シナリオブロックを使用することで、電話番号、メッセンジャーID、またはカスタム連絡先フィールドなどの特定の識別子を用いて連絡先を検索できます。
なお、シナリオ内のどこかで「連絡先の識別子」ブロックが使用されている場合、そのシナリオでは自動連絡先識別が無効になります。その場合、このブロックを使用してすべてのシナリオパスにおいて連絡先を明示的に識別する必要があります。
2. 連絡先が見つからない場合（この分岐は「連絡先の識別子」ブロックの「見つかりません」出口にあります）：
- 標準のルーティングを使用して、顧客を任意のエージェントに振り分けます。インタラクション終了後、そのインタラクションを対応したエージェントの識別子（
$(user.id)）と、インタラクションの時刻（$(system.dateTime)）を取得します - 「Bright Pattern Create Object」ブロックを使用して、データベースに新規の連絡先を作成してください。以下の情報を設定してください。
- オブジェクトタイプ：連絡先
- 連絡先フィールド：名、姓、電話番号、メールアドレスなど、利用可能な顧客の詳細情報をすべて入力してください
- 最終エージェントID：（
$(user.id)） - 最終エージェント対応時刻：（
$(system.dateTime)）
3. 連絡先が見つかったものの、最後のエージェント情報が保存されていない場合：
- 以下のIfシナリオブロックを使用して、その連絡先に前回のエージェント情報が関連付けられているかを確認してください
- 最後のエージェント情報が保存されていない場合は、通常のルーティングを使用して対応を行います
- 対応終了後、対応を担当したエージェントの識別子（
$(user.id)）と対応時刻（$(system.dateTime)）を取得します。 - 「Bright Pattern Update Object」ブロックを使用して、これらの値をデータベース内の連絡先レコードに書き込みます。以下のプロパティを設定してください。
- オブジェクトタイプ：連絡先
- レコードID：既存の連絡先レコードのID。通常、直前の「連絡先の識別子」ブロックによって返されます
- 最終エージェントID：（
$(user.id)） - 最終エージェント対応時刻：（
$(system.dateTime)）
4. 連絡先が見つかり、かつ最後のエージェント情報が存在する場合：
- そのインタラクションが許可された時間枠内にあるかどうかを確認します（下記のステップ3を参照してください）
- そうでない場合は、通常のルーティングを続行します
- 時間枠内である場合は、保存されているエージェントへのルーティングを試行します
「エージェント検索」および「コールの接続」ブロックを使用して、保存されているエージェントへルーティングしてください。「エージェント検索」ブロックの「必須のエージェントのスキル」を設定して特定のエージェントの待機条件を選択し、$(contact.LastAgentID)を検索します。詳しくは特定のエージェントへのルーティングをご覧ください。
ステップ3：エージェント再接続の時間枠を適用する
エージェント固有のルーティングは、前回のインタラクションが十分に最近のものであり、関連性が保たれている場合にのみ実行されるべきです。
インバウンドシナリオでは：
1. 変数$(contact.LastInteractionTime)を使用して、連絡先から「最終エージェント対応時刻」を取得します
2. 変数$(system.dateTime)を使用して、それを現在の日時と比較します。
3. インタラクションが定義されたしきい値（例：24時間）より古い場合は、エージェント固有のルーティングをスキップし、通常のルーティングロジックに進みます。これは、2つの分岐を持つ「If」ブロックを使用して行うことができます。
- 前回のインタラクションが許容時間枠内にある場合：
- 顧客を登録済みのエージェントにルーティングします
- 前回のインタラクションが許容時間枠外にある場合：
- 通常のルーティングを継続し、利用可能な任意のエージェントに顧客を接続します
以下のスクリーンショットでは、変数$(system.dateTime)および$(contact.LastInteractionTime)を使用して、現在の時刻と顧客の最後のインタラクション時刻を比較するように「If」ブロックが設定されています。経過時間が定義されたしきい値（例：24時間）未満の場合、シナリオは最後のエージェントへのルーティング処理へと続きます。それ以外の場合は、標準のルーティングパスに従って処理が行われます。
ステップ4：最後のエージェントにルーティングする
最後のエージェントIDが存在し、インタラクションが許容インターバル内にある場合は、「エージェント検索」ブロックの「特定のエージェント」待機条件を使用して、保存されているエージェントにルーティングします。
ステップ5：フォールバックルーティングの設定
「エージェント検索」ブロックでは、ルーティング条件としてチームメンバーシップを使用することはできません。その代わり、優先エージェントが利用できない場合、シナリオはいくつかのフォールバックオプションのいずれかに進む必要があります。
まず、「エージェント検索」ブロックを設定し、ユーザーIDに基づいて保存済みのエージェントを検索するようにします。また、「インターバル」プロパティを設定して、その特定のエージェントが利用可能になるまでシナリオが待機する時間を定義します。そのインターバル内にエージェントが利用可能にならない場合は、対応する条件付き終了を使用して、選択済みのフォールバックルーティング方法に進みます。その後、以下のフォールバックオプションのいずれかを選択できます。
エージェントの所属チームを表すスキルを使用してルーティングする
チームごとに1つのスキルを作成し、各エージェントに適切なチームスキルを割り当て、シナリオ内でそのスキルへインタラクションをルーティングします。詳しくは「エージェントへのスキルの割り当て」をご参照ください。これにより、真のチームベースのルーティングではなくスキルを通じて実装されますが、同じ運用グループ内のエージェントにインタラクションを割り当てることが可能になります。
一般的なキューにルーティングするか、標準的なルーティングロジックを適用する
優先エージェントが利用できなくなった後にエージェント固有のルーティングが不要な場合は、シナリオを通常のサービス、キュー、またはオーバーフローパスへと継続させることができます。
識別に関する要件と制限
エージェント再接続ルーティングは、システムがインタラクションを単一の連絡先レコードと確実に紐付けられる場合にのみ機能します。
複数の連絡先が同じ電話番号やその他の識別子を共有している場合、システムは最後に担当したエージェントを特定できない可能性があり、その場合はインタラクションは標準のルーティングに従うことになります。
重複を排除した正確な連絡先データを維持することで、このルーティング方法の有効性が向上します。
適合する連絡先が見つからない場合は、新規の連絡先を作成できますが、エージェント再接続ルーティングが可能になるのは、顧客に関連付けられた連絡先にエージェント情報が保存されている場合のみです。
方法2：ケースの担当者に基づくルーティング
この方法では、その連絡先に関連付けられた未解決または最近のケースに割り当てられたエージェントに基づいて、顧客をルーティングします。顧客に進行中のサポートケースがあり、再度センターに連絡した場合、そのインタラクションは当該ケースを担当するエージェントに直接ルーティングされます。
ステップ1：連絡先の識別
方法1と同様に、電話番号やその他の識別子を使用して、着信したインタラクションを既存の連絡先と照合します。
ステップ2：関連するケースを検索する
CRMまたはケース管理システムとの連携機能を使用して：
1. その連絡先に関連する、未解決または最近のケースを検索します。例えば、連絡先が識別された後、「Bright Pattern Search Object」ブロックを使用して、内部データベースから「報告者ID」が当該連絡先のIDと適合し、「ステータス」が「Open」であるケースレコードを検索できます。その後、このブロックは、割り当てられたエージェントなどの関連するケースフィールドをレコードセットとして返却し、その後のルーティングロジックで使用できます。
例えば、特定された連絡先に関連する未解決のケースを検索するには：
- 「Bright Pattern Search Object」ブロックを追加します。
- オブジェクトタイプを「ケース」に設定します。
- 次のような検索条件を追加します：
- 報告者ID =
$(contact.id) - ステータス =
Open
- 報告者ID =
- 後で使用したい値について、返却フィールドを追加します。例：
- ケースID
- 割り当てられたエージェントIDまたは所有者フィールド
- ステータス
- レコードセット名を設定します。例：
openCases
2. 最も関連性の高いケース（例えば、最も最近更新された未解決のケース）を選択します。検索オブジェクトブロックの「返却フィールド」で「割り当てられたエージェントID」フィールドを指定し、返された値をターゲットエージェントIDとして使用します。
このエージェントが、初期ルーティングのターゲットとなります。
ステップ3：標準的なルーティングロジックの適用
「If」ブロックを使用して、ケースにすでに割り当てられたエージェントがいるかどうかを確認します。
1. 割り当てられたエージェントが見つかった場合：
- そのエージェントにインタラクションを直接ルーティングしようと試行します
2. 割り当てられたエージェントが利用できない場合：
- エージェントのチームまたは一般キューにルーティングするフォールバックルーティングを設定します。詳しくは方法1のステップ5をご参照ください。
3. 該当するケースや割り当てられたエージェントが見つからない場合：
- 既定のルーティングロジックを続行します
方法3：顧客が会社の電話番号に電話をかけた際、以前に連絡を取ったエージェントへ転送する
この方法は、現場の技術者が携帯電話から会社の電話システムを経由してアウトバウンドコールを行い、発信元として会社の代表番号が表示される場合によく使用されます。顧客が電話に出られず、後で代表番号に折り返し電話をかけた場合、このシナリオでは前回のエージェントを識別し、その折り返し電話を一般的なキューに送るのではなく、その技術者に直接ルーティングすることができます。この方法では2つの異なるシナリオを使用します。1つは連絡先レコードに技術者のIDを保存するためのシナリオ、もう1つは保存されたIDを使用して折り返しのコールを同じ技術者にルーティングするためのシナリオです。
ダウンロード可能なシナリオ
ステップ1：アウトバウンドコール発信時にフィールド技術者の情報を保存する
折り返し電話のルーティングを機能させるには、システムが発信を行った技術者の身元情報を保存しておく必要があります。
1. 発信先の顧客が、内部データベースの連絡先レコードに関連付けられていることを確認してください。
2. 会社の電話システムを通じて発信を行う際、技術者のユーザーIDを取得してください。
3. そのユーザーIDを、連絡先レコードの「最終エージェントID」などのカスタム連絡先フィールドに保存します。
5. 連絡先レコードがまだ存在しない場合は「Bright Pattern Create Object」ブロックを、すでに存在する場合は「Bright Pattern Update Object」ブロックを使用します。以下のプロパティを設定してください。
- オブジェクトタイプ：連絡先
- レコードID：既存の連絡先を更新する場合、特定された連絡先レコードのID
- 最終エージェントID：
$(user.id) - 最終エージェント対応時刻：
$(system.dateTime)
ステップ2：折り返しコールでの顧客の識別
後日、顧客が会社の代表番号に電話をかけてきた場合：
1. 発信元の電話番号を使用して、連絡先レコードを識別します。
2. その連絡先から、保存されている「最終エージェントID」の値を取得します。
3. オプション：直近の対応期間を適用したい場合は、保存されている「最終エージェント対応時刻」の値を取得します。
4. 連絡先が見つからない場合、または保存されている技術者IDが存在しない場合は、通常のルーティングを続行します。
ステップ3：技術者へのルーティングの試行
1. 「エージェント検索」ブロックを使用して、ユーザーIDに基づいて保存されている技術者を検索します。
2. その特定の技術者が指定したインターバルの間利用可能になるのを待つよう、ブロックを設定します。
3. 技術者が利用可能になった場合、その技術者に折り返しコールをルーティングします。
ステップ4：フォールバックルーティングの設定
1. 技術者が利用できない場合は、フォールバック経路に進みます。適切なフィールドサポートグループを表すスキルを使用してルーティングするか、通常のキュー／オーバーフロー経路に進みます。
2. 適合するフォールバックエージェントがいない場合は、標準のルーティングに進みます。
要約
これら3つの方法はいずれも、同じ中核となるルーティング手法を使用しています。違いは、システムが「適切な」エージェントをどこから取得するかという点にあります。
| 方法 | エージェントのソース |
|---|---|
| 連絡先レベルのリンク | 連絡先のカスタムフィールドに保存 |
| ケースのルーティング | 未解決または最近のケースに割り当てられたエージェント |
| フィールド／モバイル対応シナリオ | アウトバウンドのフィールドコール後に連絡先に関連付けられたエージェント |
ワークフローに合った方法を選択することで、特定のエージェントが不在の場合でも信頼性の高いフォールバックルーティングを維持しつつ、よりパーソナライズされた効率的な顧客体験を作成することができます。