この記事の内容
dropdown icon
キューイング
    dropdown icon
    概要
      キューの種類
    dropdown icon
    スキルに基づかないキュー
      チーム割り当てによる非スキルベースのキュー
      スキルベースではないキュー(エージェント割り当てあり)
    dropdown icon
    スキルベースのキュー
      キューに割り当てられたスキル基準
      フローで割り当てられたスキル要件
    dropdown icon
    キュー構成
      スキルベースのキューを設定する
      スキルベースではないキューを設定する
dropdown icon
ルーティング
    dropdown icon
    ルーティングの概念
      エージェント余剰シナリオ
      コンタクト余剰シナリオ
      混合マルチメディアプロファイル
    dropdown icon
    ルーティングパターン
      スキル ベース
      スキルベースではないルーティング
      エージェントベースルーティング
dropdown icon
Flowにおけるキューイングおよびルーティング機能
    Flowにおけるキューイングおよびルーティング機能
    dropdown icon
    キューイングアクティビティ
      キューコンタクト
      エージェントにキューイング
      エスカレーションコール配信グループ
    dropdown icon
    キュー情報アクティビティ
      キュー情報を取得する
      高度なキュー情報
    dropdown icon
    通話制御アクティビティ
      発信者番号表示を設定する
      録画コントロール
      ブラインド転送
      ブリッジ転送
      コンタクトを切断
      連絡の優先順位を設定する
    dropdown icon
    コールバックアクティビティ
      コールバック
      コールバックのスケジュール設定
      通話進捗状況分析
Webex Contact Center のルーティングとキューイングを理解する
list-menuこの記事の内容
list-menuフィードバックがある場合

この記事では、Webex Contact Center がどのように処理および指示を行うかの概要を説明します。 エージェントへの着信インタラクション。スキルベースや スキルベースではないルーティング方法、および最長利用可能、循環、最適利用可能などのルーティング方法。 また、管理者がインタラクションを管理し、エージェントを割り当て、制御するのに役立つフローアクティビティについても説明します。 通話フローを確認し、リアルタイムのキュー更新を取得して、業務と顧客満足度を向上させます。 しています。

キューイング

概要

Webex Contact Centerでは、キューは、電話、チャット、メール、ソーシャルチャンネルなどの受信インタラクションのためのホールディングエリアとして機能します。連絡先は自動的にエージェントに配布されるまで、またはエージェントが手動で処理するためにそれらをピックアップするまで、キューに駐車されます。さらに、スキルベースのルーティング、優先管理、公正なワークロード配布などの機能もサポートしています。

スーパーバイザーは、キューを使用してさまざまな作業ラインを観察し、コンタクトセンターでタスクの処理方法を改善することができます。

キューを効果的に使用することの重要な利点には、次のものがあります。

  • 顧客体験の向上:待ち時間を管理し、顧客に、彼らが助けられるために並んでいることを知らせます。
  • 効率の向上:呼び出しが秩序ある方法で処理されていることを確認し、混沌と誤った管理を軽減します。
  • コンタクトの公平な配布:単一のエージェントの過負荷を防ぐために、エージェント間で呼び出しを均等に分配します。
  • 優先度の取扱いについて:VIP顧客や緊急の問題など、特定の呼び出しの優先順位付けを許可します。

キューの種類

Webex Contact Centerは複数のタイプのキューをサポートしており、すべてのサイズと複雑さのコンタクトセンターで、均一な機能を備えたすべてのメディアタイプにわたって、さまざまな用途を可能にします。

連絡先をルーティングする際のエージェントスキルを考慮するキューと、そうでないキューがあります。これらのキューは、エージェントがそれらとどのように関連付けられているかによっても異なります。

キューには2つの広いカテゴリーがあります。

  • スキルのないキュー
  • スキルベースのキュー

スキルのないキュー

非スキルベースのキューは、エージェントに関連するスキルを考慮しません。スキルのないキューは、以下のオプションで設定できます。

  • チーム課題
  • エージェントの割り当て

チーム割り当てを伴うスキルベースの非キュー

チーム割り当てを伴う非スキルベースのキューでは、エージェントをチームに編成し、これらのチームを結合してCall Distribution Groups(CDG)を形成することができます。各グループ間の遅延時間を設定して、コールフローを管理できます。

Call Distribution Groupsは、設定された時間間隔で、このキューで連絡先を操作する資格を持つ複数のレベルのエージェントを定義するのに役立ちます。連絡先は、チームのレベルに基づいてエージェントに割り当てられます。エージェントが利用できない場合は、次のチームグループを含めるために拡張する前に、事前に設定された期間のために連絡先が駐車されます。このプロセスは、エージェントが利用可能であるか、すべてのグループをチェックするまで続きます。

これらのタイプのチームを設定できます。

  • 個々のチーム:エージェントは、特定の組織機能を表すことができるチームに編成することができ、その後、これらのチームのエージェントに連絡先をルーティングできるようにキューの一部になることができます。エージェントを複数のチームにタグ付けして、さまざまなキューからの連絡先を処理して効率的なルーティングを行うことができます。
  • キャパシティベースのチーム:Capacity-based Team (CBT) は、音声通話を Capacity-based Direct Number (DN) に指示する機能です。これにより、エージェントがシステムにサインインすることなく、電話番号へのルーティングが可能になり、従来のコールセンターエージェントではなく、ボイスメール、応答機、またはハントグループで通話が応答されるシナリオに適しています。このセットアップでは、チームに特定のエージェントが割り当てられていないため、Webex Contact Center Agent Desktop を使用しません。

Webexコンタクトセンターでスキルベースでないキューがどのように機能するかについてのワークフロー図

この例では、ターゲットの拡張を可能にする3つのCall Distribution Groupsがあり、設定された時間間隔でチーム全体でより多くのエージェントに拡張することを意味します。

最初のCall Distribution Groupにはチーム1が含まれており、3エージェントがA1、A2、A5を設定しています。

2番目のコール配布グループには、TEAM 2が含まれ、3エージェントがA2、A3、A4が設定されています。

3番目の(および最終的な)コール配布グループには、TEAM 3が含まれており、2エージェントがA6およびA7を構成しています。

連絡先がキューに入ると、システムは最初のコールディストリビューショングループで最初に一致するエージェントを検索します。エージェントが見つからない場合は、対象を次のグループに拡張する前に、設定された期間のために連絡先が駐車されます。これにより、既存のチームに新しいチームが追加されます。このプロセスは、マッチが見つかるか、すべてのグループが展開されるまで繰り返します。

'Check Agent Availability' と呼ばれる機能により、現在のグループに一致するエージェントが見つからない場合、連絡先は即座にその後のコール配布グループに拡張されます。これは、フローの「Queue Contact」アクティビティの<LINK TO section 3.1.1>で有効にできます。

この設定は、以下のシナリオになります。

  1. A2 はTEAM 1とTEAM2に属します。A2がAgent DesktopにログインするためにTEAM 1を選択した場合、システムはA2を1TEAMの一部とみなし、最初のコールディストリビューショングループのみとみなします。
  2. ただし、A5 はTEAM1に属しますが、現在ログインしている組織内の他のチームにも所属している可能性があります。したがって、A5はチーム1 の一部と見なされず、このキューに関連付けられていません。

チーム割り当て付きキューは、ログイン時にチームを選択するだけで、エージェントがキュー間を移動するための強力な機能を提供します。

利用可能なルーティングパターン:

エージェント割り当ての非スキルベースのキュー

非スキルベースのキューは、エージェントのプールがキューに直接割り当てられるキューの一種です。間接的に割り当てられたエージェントのプールを決定する他のキュータイプとは異なり、これらのキューは、管理者がエージェントを直接および手動で選択することを可能にします。例えば、チームベースの割り当てキューは、ログインしたチームに基づいてエージェントを割り当て、スキルベースの割り当てキューは、必要なスキルに基づいてエージェントと一致します。対照的に、管理者はこれらのキューにエージェントを直接追加してキューの一部になることができます。これは、システム駆動の割り当てに依存することなく、エージェント割り当てを管理する簡単な方法を提供します。

エージェント割り当て付きキューは、エージェントプール間の連絡先を配布するのに役立つ、シンプルで効果的なルーティングアルゴリズムを提供します。彼らは連絡先をルーティングするエージェントのスキルを考慮しません。しかし、エージェントは各キュー内で注文することができ、これは連絡先をルーティングするときに考慮されます。この文脈では、チームは主に、エージェント・キュー・アソシエーション、およびキュー・マネジメントを簡素化するコンタクトルーティング決定の要因ではなく、スーパーバイザーのための組織的な構成として機能します。

このタイプのキューは、エージェントの静的割り当てとエージェント・キュー連合の管理が運用制御のために実現可能で望ましい場合に適しており、ルーティング・アルゴリズムの選択がエージェント間の作業分布に適しています。これらのキューは、いくつかのタイプの顧客問い合わせが事前に作成された専門家エージェントによって提供できる専門的な専門知識を必要とするシナリオでも特に役立ちます。

しかし、複雑なコンタクトセンター組織は、これらのキューでエージェント割り当てを手動で管理するのが難しいかもしれません。それらは動的ルーティングとエージェントキューの関連付けを提供する他のキュータイプからより多くの恩恵を受けることができます。

Webex Contact Centerでエージェント割り当てを持つNon-Skill-Based Queueの例がどのように機能するかを説明するワークフロー図

この例では、キューには、A4、A9、A7などの特定の順序でマッピングされた一連のエージェントがあります。この順序は、エージェントに受信する連絡先と一致する特定のルーティングアルゴリズムで役割を果たします。システムは、それらの可用性と選択されたルーティングアルゴリズムに基づいて、これらのエージェントとの連絡先と一致します。

チーム割り当てのあるキューとは異なり、時間間隔でターゲットの拡張 の概念はありません。この連絡先をルートするために設定されたエージェントがどれにも使用できない場合、パークタイムアウト前にこれらのエージェントが連絡先を処理できるようになるまで、キューに駐車されます。これらのキューにはターゲットの拡張 は適用されません。

利用可能なルーティングパターン:

スキルベースのキュー

スキルベースのキューは、連絡先が適切なスキルを持つエージェントにルーティングされる機能を提供します。

以下の種類のスキルベースのオプションを設定できます。

キューに割り当てられたスキル基準

管理者は、キューにスキル基準を割り当てることができます。スキル基準を持つスキルベースのキューは、管理者がキュー内で必要なスキルを直接設定することを可能にします。直接スキル・プロファイルを介してキューのすべての必要なスキルを持っている組織内のすべてのエージェントは、暗黙的にこのキューの一部になります。

このセットアップは、管理者がスキルによってキューにマッピングするエージェントをライブビューにすることができます。高音量や低音などの状況では、管理者は、キューとエージェントスキルプロファイルの必要なスキルを調整し、必要に応じてエージェントプールを拡張または縮小することを検討することができます。

このタイプのキューは、チーム割り当てベースのキューとは異なります。 つまり、チームがキューの関連付けのエージェントに何の役割も果たさないという意味です。さらに、必要なスキルは、チームベースのスキルキューとは異なり、このキューで静的に構成されます (静的または変数) 必要なスキルを注入します。したがって、技術的にはスキルは接触自体ではなく、キューの一部である。

キューのスキル基準を完全に満たす(直接スキルプロファイルからのスキルを持つ)組織のエージェントは、このキューに暗黙的に関連付けられます。チームは、これらのキューとエージェント関連付けにおいて何の役割も果たしません。これらのエージェントは、管理および運用目的のために任意のチームの一員になることができます。

このキューにキューされたすべての連絡先は、キュー自体で定義されているスキル基準を自動的に仮定します。個々の連絡先は、チームの割り当てを伴うスキルベースのキューとは異なり、独自のスキル要件/基準を定義したり上書きしたりすることはできません。

Webexコンタクトセンターでスキル基準を持つスキルベースのキューがどのように機能するかを示すワークフロー図

この例では、

  • エージェントA1、A3、A7のみが、キューで設定されたスキル基準を満たしているため、これらのエージェントのみがキューに関連付けられます。
  • 条件を部分的に満たすA、A2、A4、6または5関連するスキルを欠くエージェントA、およびA6は、このキューに関連付けることはできません。

キューのスキル基準を満たすようにエージェントのスキルプロファイル(再スキル)を更新すると、そのエージェントは自動的に動的にキューの一部になります。交互に、キュースキルの基準自体を更新して、更新されたスキルの基準を満たすことによって、このキューからエージェントを自動的に動的に追加(または削除)します。

チーム割り当てのあるキューとは異なり、時間間隔でターゲットの拡張 の概念はありません。連絡先が関連するエージェントのいずれにもマッチできない場合、パークタイムアウト前にこれらのエージェントのいずれかが連絡先を処理できるようになるまで、キューに駐車されます。

スキルベースのキューは、エージェント協会へのスキルの静的割り当てとキューの管理が実現可能であり、運用管理のために望ましい場合に適しています。また、ルーティングアルゴリズムの選択がエージェント間の作業分布に適している場合にも適しています。これらのキューは、さまざまなタイプの顧客問い合わせが事前に派生した専門家エージェントによって提供される特定のスキルを必要とするシナリオでも特に有用です。

複雑なContact Center組織は、スキルベースのキューでエージェント割り当てへのキューを管理する方が簡単で、各エージェントが手動でリストに追加する必要があり、特に大きな組織では面倒です。

フローで割り当てられたスキル要件

スキルベースキュー フローに割り当てられたスキル要件を持つキューは、Webex Contact Centerのチーム割り当てベースキュー の一種で、Call Distribution Groupsと呼ばれる複数のレベルでチームセットを構成します。これらの構成チームにログインするエージェントは、コンタクトのスキル要件を完全に満たす場合、チームがキューで構成されているコール配布グループレベルに基づいて、このキューから連絡先を割り当てられます。

そのようなキュー内で、エージェントチームはコール配布グループにグループ化され、それらの間の設定可能な時間遅延が発生します。連絡先にエージェントが利用できない場合、リクエストは駐車され、遅延の後、ルーティングは次の Call Distribution Group に拡張されます。このプロセスは、エージェントが割り当てられるか、すべてのグループが疲れるまで続きます。一方、このプロセス中に以前にチェックされたグループのエージェントが利用可能になった場合、そのエージェントが選択されます。

エージェントは、エージェントに直接割り当てられたスキルプロファイルを介してスキルを習得します。エージェントスキルは、サインイン中のチームの選択に基づいて決定されます。

各連絡先はオプションで、フロー内のスキル要件を指定できます。 これは、利用可能なエージェントのスキルと一致し、最も適切なエージェントを選択します。

さらに、連絡先は、設定された時間間隔でスキルリラクゼーションを指定することもできます。これらは、設定された時間間隔で連絡先の元のスキル要件を上書きする変更されたスキル要件のセットです。これにより、複数のエージェントがこれらのリラックスしたスキル要件を満たすことができるように、連絡先がキューに駐車している間(通常「リラックス」するために使用される)そのスキル要件を変更することができます。

コールディストリビューショングループによるターゲット拡張は、スキルリラクゼーションサイクルと同時に発生する可能性があり、駐車した連絡先を適切なエージェントとより迅速に一致させることを目的とし、全体の待機時間を短縮し、キューのサービスレベルを向上させます。

Webexコンタクトセンターでスキルベースのキューがどのように機能するかを示すワークフロー図。

チーム割り当てを伴うスキルのないキューと同様に、3つのCall Distribution Groupsがあり、「ターゲットの展開」を可能にする、すなわち、設定された時間間隔でチーム全体でより多くのエージェントに拡大する。

  • 最初のコール配布グループには、TEAM 1が含まれ、3エージェントがA1、A2、A5で構成されています。
  • 2番目のコール配布グループには、TEAM 2が含まれ、3エージェントがA2、A3、A4が設定されています。
  • 3番目の(および最終的な)コール配布グループには、TEAM 3が含まれており、2エージェントがA6およびA7を構成しています。

しかし、注意すべきことが2つあります。

  • このキューにキューされるすべての連絡先は、そのスキル要件とフローを通じてスキルリラクゼーションを定義します。
  • エージェントは、スキルを構成することができます(スキル・プロファイル - 直接またはログインしたチームから継承されます)。

A2はTEAM 1とTEAM 2の両方に所属するように構成されていますが、ログイン中にこのエージェントが行ったチームの選択に応じて、現在のセッションではそのチームの一部とみなされ、そのチームからスキルプロファイル(スキル値)も継承されます(このエージェントが直接スキルプロファイルの設定で上書きされる場合を除く)。

これは、ログイン時にチームを選択するだけでエージェントがキュー間で移動できる強力な機能です。

選択したチームからスキルプロファイル設定を継承する能力と組み合わせて、エージェントはさまざまなスキルセットで動作することができます。

この例では、

  • 連絡先は、フローからのエスカレーション時に、最初のスキル要件 (sk_1 >= 6) がキューに入れられ、設定された時間間隔の後、スキルリラクゼーション (sk_1 >= 3) がキューされます。
  • A1、A3、A6、A7は、すべてのコール配布グループのすべてのエージェントに対して、キューイングされた連絡先の最初のスキル要件を満たすスキルを持っています。
  • 残りのエージェントは、スキル(sk_1)を持っているが、スキル要件を満たしていない(例:TEAMのA2、1TEAMのA42)か、このスキルを全く持っていない(例:A5、TEAMのA22)。
  • 時間が経つにつれて、スキルリラクゼーション時にA2とA4もコンタクトの「リラックスした」スキル要件を満たしています。

このキューにキューされたすべての連絡先について、システムは、最初のコール配布グループ内のマッチングエージェントを見つけようとします。マッチングエージェントが見つからない場合、ターゲットの拡張が 2 番目のコール配布グループに発生する前に設定された期間のために連絡先が駐車されます。2番目のコール配布グループで構成されているすべてのチームは、1番目のグループからの既存のチームにも追加されます。これで、システムは拡張されたグループ内で一致するエージェントを見つけようとします。これが起こっている間、スキルリラクゼーションは設定された時間間隔でコンタクトのスキル要件を更新し、システムは現在のコールディストリビューショングループで利用可能なエージェントと一致するために更新されたスキル要件を使用することに注意してください。

これは、設定されたすべてのコール配布グループが拡張され、マッチングエージェントが以前に見つかっていない限り、すべてのスキルリラクゼーションが適用されるまで続きます。

利用可能なルーティングパターン:

キューの設定

スキルベースのキューの設定

スキルの基準をキューに割り当てる
  • スキルと、必要に応じて、ダイナミックスキルを作成します。
  • 作成 スキルプロファイル.
  • エージェントにスキルのプロファイルを直接割り当てます。
  • エージェントに直接動的スキルを割り当てます。ダイナミックスキルは、スキルプロファイルによって割り当てられていません。
  • チャンネルタイプのTelephony、Chat、Email、Socialでキューを作成します。
  • Control Hubのキューにスキルと動的スキル要件を割り当てます。
  • キューで連絡先を処理できるエージェントの一覧を表示します。
  • ルーティングアルゴリズムを LAA または BAA のいずれかを選択します。BAAの場合、必要に応じて能力スキルと能力ダイナミックスキルの重みを設定します。
  • Queue Contact アクティビティをフローに追加し、このキューを選択します。
スキル要件をキューに割り当てる
  1. スキルと、必要に応じて、ダイナミックスキルを作成します。
  2. 作成 スキルプロファイル.
  3. スキルプロファイルをエージェントまたはチームに直接割り当てます。
  4. エージェントに直接動的スキルを割り当てます。ダイナミックスキルは、スキルプロファイルによって割り当てられていません。
  5. 作成する チーム.
  6. チームにエージェントを追加する。
  7. Telephony、Chat、Email、Socialのチャンネルタイプでキューを作成します。
  8. 1つのCDGまたは複数のCDGでチームをキューに追加します。
  9. ルーティングパターンをLAAまたはBAAのいずれかを選択します。
  10. Queue Contactアクティビティをフローに追加し、スキルベースのルーティングを構成するキューを選択します。詳細については、を参照してください。 キューコンタクト.
  11. キューコンタクトアクティビティでスキル、ダイナミックスキル、スキルリラクゼーションを割り当てます。BAAの場合、必要に応じて能力スキルと能力ダイナミックスキルの重みを設定します。
  12. フローポストキューイングでEscalate Call Distribution Activityを使用して、次のコール配布グループまたは最後のグループにすばやく移動できます。

スキルのないキューの設定

チームをキューに割り当て
  • 作成する チーム.
  • チームにエージェントを追加する。
  • Telephony、Chat、Email、Socialのチャンネルタイプでキューを作成します。
  • 1つのCDGまたは複数のCDGでチームをキューに追加します。
  • ルーティングパターンをLAAのいずれかを選択します。
  • Queue Contact アクティビティをフローに追加し、このキューを選択します。
  • フローポストキューイングでEscalate Call Distribution Activityを使用して、次のコール配布グループまたは最後のグループにすばやく移動できます。
キューフローにエージェントを割り当て
  • Telephony、Chat、Email、Socialのチャンネルタイプでキューを作成します。
  • エージェントをキューに直接追加する (注:このタイプのキューでは、スキルもチームも使用されません)。
  • Circular、Linear、Longest Availableエージェントなどのルーティングパターンを選択します。
ルーティング

ルーティングの概念

エージェントの余剰シナリオ

エージェント余剰のシナリオは、キューに連絡先があるよりも利用可能なエージェントが多い場合に発生します。この場合、顧客インタラクション(コンタクト)がキューに入ると、システムは、この特定のコンタクトのマッチングエージェントをすぐに見つけようとし、マッチングエージェントが見つかった場合は、その連絡先をキューに駐車し、マッチングエージェントが後で利用可能になるのを待つ必要はありません。

コンタクトがCall Distribution Groupまたはスキルリラクゼーションを通じて拡張されるたびに、システムは、この特定のコンタクトのマッチングエージェントをすぐに見つけようとします。

特定の連絡先にマッチするエージェントを見つけることは、キューで設定されたルーティングパターンを使用します。

Webex Contact Centerは、さまざまな種類のキューに複数のルーティングパターンを提供しており、待機時間を最小限に抑え、エージェントワークロードのバランスをとり、顧客が特定のニーズに対応するために必要なスキルを持つエージェントと接続できるようにすることで、組織は顧客サービスを最適化することができます。ルーティングパターンの詳細については、ルーティングパターンのセクションを参照してください。

コンタクト余剰シナリオ

連絡先余剰ルーティング (Contact Surplus Routing) は、受信する顧客インタラクション (または連絡先) の数が利用可能なエージェントを超える場合に発生します。この状況は、ピーク時や接触量の予期せぬ急増の間にしばしば起こります。コンタクト余剰ルーティングの主な目的は、このオーバーフローを効率的に管理し、過剰な需要にもかかわらず、カスタマーサービス基準を維持することです。特定のチャンネルで利用可能になったばかりのエージェントの場合、このエージェントが関連するすべてのキューに駐在しているすべての連絡先の中で、コンタクト余剰ルーティングは、適切な連絡先を見つけて割り当てるために動作します。

限られたエージェントの可用性で、コンタクトルーティングを効率的に実行するための主な戦略は次のとおりです。

  • キューランキング

    キューのランキングは、管理者がキューの相対的な重要性を指定することを可能にします。管理者は、キューからチームにログインしたエージェントへの呼び出しをチームごとにルーティングする順序を設定するために、キューのランキングを定義できます。

    たとえば、チームAにログインしたエージェントが、「課金」と「販売」の2つのキューに関連付けられていることを考えてみましょう。管理者は、キューランキングを使用して「課金」キューに高いランクを割り当てることができるので、連絡先がキューに入ると、「課金」の連絡先は「セールス」キューの連絡先に先立ってチームAのエージェントにルーティングされます。これは、「セールス」キューで待っている古い優先度の高い連絡先があるかもしれませんが、「請求」キューは「セールス」キューよりも高いキューランクを持っているためです。「課金」キューに連絡先が待機していない場合のみ、チームAのエージェントは、それらが関連する「セールス」(およびその他の)キューから連絡先をルーティングします。

    キューランキングの重要な特徴は次のとおりです。

      • 一部のキューにのみランクが割り当てられている場合、それらのキュー内の呼び出しは、ランクが指定されていないキュー内の呼び出しよりも優先されます。
      • キューのランキングは、1と501の間の値の範囲が最高ランクであるすべてのメディアタイプで、最大50キューに設定できます。
      • 複数のキューに同じランクを割り当てることができます。
      • キューランキングを有効にすると、明示的にランク付けされていないキューは、すべてのランク付けされたキューよりも低く扱われます。
      • キューランキング (Queue Ranking) は同じメディアタイプで動作します。

        たとえば、Queue Saleがランク2を持つ音声メディアタイプキューで、Queue Billing SupportがチームAのランク1 を持つチャットキューである場合、Team Aのボイスチャンネルで利用可能なエージェントは、ランクが2であるにもかかわらず、最初にボイスコールを取得します。

        ただし、チームBのチャットのキューを2つ考慮してください。キューランク2のクレジットカードとキューランク1のキューデビットカード。その後、チームBの利用可能なエージェントは、最初にキューデビットカードから連絡先が提供されます。

      • キューランキングは、キャパシティベースのチームには適用されません。

  • 連絡先の優先度

    連絡先がキューに入ると、1(最高)から10(最小、デフォルト)までの階層的な重要性を割り当てることで、優先順位を定義できます。この優先順位付けは、特定の連絡先が組織にとって重要性、緊急性、または戦略的価値に基づいてより迅速に処理されることを保証します。エージェントが関連付けられているすべてのキュー上のすべての駐車された連絡先のうち、次の連絡先を処理できるようにエージェントが利用可能である場合、すべてのキュー上の優先度の連絡先はエージェントにルーティングされます(スキルマッチングなどの他の基準が満たされます)。

    明示的な優先順位なしでキューに入れられている連絡先については、10 (最小) の既定の優先順位が考慮されます。同じ優先度を持つ複数の連絡先のうち、最長期間キューで待機している連絡先は、最初に利用可能で適格なエージェントにルーティングされます。

  • 最長待っているコンタクト

    これは、エージェントが関連付けられているすべてのキューで待機している最長の連絡先がエージェントにルーティングされるようにするための基本的な戦略です。

    これは、同じキューランクと同じ連絡先優先度を持つキューの複数の連絡先が処理されるのを待っている場合にルーティングされる連絡先を決定する究極の基準です。

基本的に、利用可能になったばかりのエージェントの連絡先剰余ルーティングは、以下の単一の連絡先を選択する手段です。

  • エージェントが利用可能なメディアタイプと同じである
  • このエージェントが関連付けられているキューのいずれかに駐車します
  • このエージェントが(もしあれば)スキル要件をすべて満たしている者
  • エージェントチームを構成する他のキューよりもランクが高いキューに駐車される
  • そのような連絡先のうち 最優先事項が
  • 同じ優先度を持つ連絡先の中で 最も古い待っている連絡先です

上記の例では、連絡先余剰シナリオを示している。エージェントA1はTEAM1 にログインし、複数のメディアタイプで連絡先を処理できるようになった。

A1関連する 3キュー – Q1Q2Q3.チーム 1キューランキング Q1一番高いランクで、 Q2Q3それぞれ。

これらのキューには、スキル要件と優先度が定義されているすべての連絡先がすでに駐在しています。

現在、接触余剰シナリオは次のように動作します。

  • これらのキューを横切るすべての駐車された連絡先の中で、 4連絡先をルーティングできます A1--- C2C7(QUEUE より) 2) および C3C8(QUEUE より) 3).

    この4 コンタクトのスキル要件のみがA1 のスキルによって完全に満たされています。

  • これらのうち 4contacts, 優先順位は次からの連絡先に与えられます キュー 2(例:C)2、C7Because) キュー 2キューのランクが上位です。

    なお、QUEUE1は最高ランクのQUEUEだが、そのスキル要件がAに満たされないため、駐在している連絡先は1A1にルーティングできません。

  • 間隔 C2C7最も優先度の高い接触は C7.最終選択はC7で、システムはA1にルーティングします。

    これはC2 がキューに入れられていても、連絡先優先順位がキューに入れられた時間よりも優先されるためです。

混合マルチメディアプロファイル

Webex Contact Centerは、マルチメディアプロファイル構成を通じて、エージェントがさまざまなメディアタイプ(声、チャット、メール、ソーシャル)の連絡先をサービスを提供することを可能にします。この構成に基づいて、エージェントはメディアタイプごとにプロビジョニングされたチャンネルを取得します。

エージェントにルーティングされるすべての連絡先は、エージェントがその連絡先に取り組んでいる限り、そのメディアタイプの 1 つのチャンネルを消費します。エージェントは音声チャンネルを1つしか持たないが、他のメディアタイプのチャンネルを5つまで持つことができる。

マルチメディアプロファイル のブレンドルーティング設定により、管理者は各エージェントに対して異なるチャンネルを同時に使用できるかを制御できます。これにより、組織は顧客に専念し、サービスの質の向上、顧客エクスペリエンスの向上、コンバージョン率を向上させることができます。また、いくつかのチャネルで不均一な負荷が発生した場合、組織はメディアチャネル間で負荷のバランスを取ることができ、エージェントの効率的な利用を可能にします。

3つの選択肢があります:

  • Exclusive

  • 混合型

  • リアルタイム

音声以外の連絡先を処理する場合、エージェントは、利用可能な音声チャンネルがある限り、エージェントデスクトップから手動音声通話を開始できます。これは、すべてのマルチメディアプロファイルタイプに適用されます。

マルチメディアプロファイルの設定の詳細については、を参照してください。 マルチメディアプロファイルを管理.

ルーティングパターン

スキル ベース

Webex Contact Centerのスキルベースのルーティングパターンは、問い合わせの解決に必要な特定のスキル(言語能力や技術的専門知識など)に基づいて、エージェントに顧客との直接的なやり取りを行います。これらのパターンは、各顧客が最も適格なエージェントに接続し、サービスの効率と顧客満足度を向上させます。利点には、処理時間の短縮、解像度の向上、専門知識と顧客のニーズに合わせて、エージェントリソースの最適利用が含まれます。

スキルベースのルーティングは、エージェントがスキルプロファイルから受け取るスキルと、エージェントに直接割り当てられるダイナミックスキルを使用できます。動的スキルは、エージェントのスキルプロファイルとは独立して変更できるエージェントの属性を表します。

スキルベースのルーティングパターンを使用する場合、まず、コンタクトのスキル要件(フローで割り当て)またはキューに割り当てられたスキル基準を使用して、スキルと動的スキルがこれらの要件/基準を完全に満たす利用可能なエージェントをフィルタリングします。次に、フィルタリングされたエージェントの中で、設定されたルーティングパターンに基づいて、連絡先に1つずつ選択されます。

Best Availableルーティングでは、熟練スキルと熟練度ダイナミック・スキルは、エージェントの選択に使用されるスコアに影響を与えるために重みを使用することもできます。ウェイトは、最長の利用可能なルーティングには影響しません。 このパターンは、エージェント適格性を判断するためにスキルと動的スキルを使用します。

最長利用可能

Longest Availableスキルベースのルーティングパターンは、そのスキルがコンタクトスキル要件/キュースキルの基準を完全に満たし、そのキュー内のすべての適格エージェント間で最後のコンタクトを処理してから最長で利用可能なエージェントにコンタクトをルーティングします。

このルーティングパターンは、利用可能な最長のインタラクションを割り当てることで、エージェント間で作業を均等に分散し、ワークロードの不均衡を防ぎます。それは仕事分配の公平性を維持し、他の人が自由である間、エージェントが過負荷にならないようにします。

上記の例では、能力と非能力スキルを持つ4 エージェントがあり、能力のスキル値が異なります。

「Longest Available」ルーティングパターンを持つスキルベースのキューにキューされている連絡先を考えてみましょう。

  • フローによって割り当てられた上記のスキル要件と、
  • 上記のスキル基準がスキルベースのキューで設定されている

このシナリオでは:

  • ルーティングでは、コンタクトスキル要件/キュースキル基準を完全に満たすエージェントのみが考慮されます。エージェントのみ A1A2A4コンタクトスキルの要件/キュースキルの基準を完全に満たします。

    エージェントA3 は適格ではありません。例えば、 キューに割り当てられたスキル基準A3キューとは関係ありません。

  • 中間 A1A2A4連絡先は、利用可能な最長のエージェントにルーティングされます – A1WHOは 10分、A より長い2または A4.

    連絡先を割り当てるA1 により、A1 はもはやすべてのメディアチャネルで利用可能な最長のエージェントにはなりません。

  • まったく同じスキル要件を持つ次の接触は、利用可能な次の最長のエージェント(A2)にルーティングされます。

このルーティングパターンは、以下の種類のスキルベースのキューでサポートされています。

ベストセラー

Best Availableスキルベースのルーティングパターンは、利用可能な最も資格のあるエージェントに顧客インタラクションが向けられます。このパターンは、エージェント間の必要なスキルの存在だけでなく、これらのスキルの能力レベルも評価し、スキルスコアを計算して、各コンタクトに最も適した(「ベスト」)エージェントを決定します。

このパターンフィルタは、コンタクトスキルの要件/キュースキルの基準を完全に満たす利用可能なエージェントです。次に、コンタクトスキル要件/キュースキル基準に記載されているすべてのスキルの能力値を使用して、各適格エージェントに対してスコアが計算されます。最高のスキルスコアを持つエージェントは、各コンタクトの「ベスト」エージェントとみなされます。

実際、コンタクトスキル要件/キュースキル基準に一致するエージェントのスキル値の合計は、スコアを決定します。

理解すべき重要なポイント:

  • 通常、実際のスキル値は、より高いスキルスコアが強いことを示すため、スコア計算に使用されます。ただし、スキル要件が (<=) 以下の条件を使用する場合、エージェントの特定のスキル値は、スコア計算で反転されます。つまり、effective_skill_value = (10) minus (actual_skill_value)。これは、スコアが低いことをより強い一致を示すために行われます。
  • 複数の適格エージェントが同じスコアを持つ場合、それらのうち最長のエージェントが選択されます。
  • 得点計算には熟練のスキルのみを考慮する。接触スキル要件/キュースキル基準におけるブール値、テキスト、または列挙スキルは、スコア計算には考慮されません。

上記の例では、能力のあるエージェントと能力のないエージェントが4つあり、能力のあるスキル値が異なる。

「Best Available」ルーティングパターンを持つスキルベースのキューにキューされている連絡先を考えてみましょう。

  • フローによって割り当てられた上記のスキル要件と、
  • 上記のスキル基準は、スキルベースのキューで設定されます。

このシナリオでは:

  • ルーティングでは、コンタクトスキル要件/キュースキル基準を完全に満たすエージェントのみが考慮されます。エージェントのみ A1A2A4コンタクトスキルの要件/キュースキルの基準を完全に満たします。

    エージェントA3 は適格ではありません。例えば、 キューに割り当てられたスキル基準A3キューとは関係ありません。

  • 中間 A1A2A4スコア計算は、能力スキルのみを考慮した接触スキル要件/キュースキル基準に基づいてシステムによって行われます。

    エージェントが追加/その他の能力スキルを持っている場合であっても、コンタクトスキル要件/キュースキル基準に記載されているスキルのみが、スコア計算のために考慮されます。

    また、(<=)以下の条件を使用した場合のスコア計算におけるスキル値の反転にも注意してください。

  • スコアに基づいて利用可能な最良のエージェントであるため、連絡先はA2 にルーティングされます。A2 が利用できない/ビジーの場合、連絡先は2番目に高いスコアを持つ次の利用可能なエージェントにルーティングされます。

    しかし、次の最高得点を持つ2 エージェント(A1A4 )があります。接触は、A1A4の間に利用可能な最長のエージェントにルーティングされます。

このルーティングパターンは、以下の種類のスキルベースのキューでサポートされています。

非スキルベースのルーティング

Webex Contact Centerは、エージェントの特定のスキルや専門知識を考慮せずに、入ってくる顧客インタラクションを配布することに焦点を当てたさまざまな非スキルベースのルーティングパターンもサポートしています。スキルベースのルーティングパターンとは異なり、エージェントスキルを考慮せず、ルーティングのスキル要件/基準を定義するために連絡先やキューを必要とします。代わりに、可用性、ワークロード分布、および定義済みのシーケンスなどの要因を優先し、個々のエージェントの能力ではなく、運用ロジックに基づいて連絡先を効率的に処理できるようにします。これらのパターンは、相互作用が比較的均一であるか、または特殊な処理を必要としない環境において特に有用である。

最長利用可能

Longest Available ルーティング パターンは、キュー内のエージェントにコンタクトをルーティングします。

このルーティングパターンは、アイドル状態で最も長いエージェントにインタラクションを割り当てることで、公正でバランスの取れたワークロード分布を保証します。ワークロードの不均衡を防ぐことで、エージェントが過負荷にならないようにし、他のエージェントはフリーのままです。このアプローチは、安定した接触フローの期間中に特に効果があり、エージェントプール全体で一貫したエンゲージメントを維持します。

エージェントは、任意のメディアタイプの連絡先が提供されると、すべてのチャネルで「利用可能な最長の」ポジションを失います。つまり、エージェントが連絡先を処理した後、メディアタイプのキューの次の連絡先はそのキューで利用可能な最長のエージェントに割り当てられます。

上記の例では、エージェントA1 は利用可能なエージェント(ポジション1)です。このエージェントが最初にログインしたか、他のエージェントよりも長い連絡先が割り当てられていません。

エージェント A2(ポジション) 2) および A3(ポジション) 3) も利用できますが、ログイン済みか、連絡先を処理したかのいずれかがあります。 A1.すべてのエージェントは、このルーティングパターンを持つ両方のキューに関連付けられています。

次のシナリオを考えてみましょう。

  • 時刻 T (航空機)0音声コンタクト C1キューに入れられ、利用可能な最長のエージェントにルーティングされます。 A1.

    「By Virtue of A1割り当てられる C1A1もはやすべてのメディアチャネルで利用可能な最も長いエージェントではありません。

  • 時刻 T (航空機)1チャットコンタクト C2現在利用可能な最も長いエージェントにキューされ、ルーティングされます。 A2.
  • 最後に、時折 T (航空機)2別の声の接触 C3キューとルーティングされます A3.

    A1A2最近、連絡先を取得しました - この時点で、それは A3一番長く待ち続けている。

Webex Contact Center の高分散アーキテクチャにより、これらの連絡先が同じキューに同時にキューされたときに、利用可能な最長のエージェントが 1 つの複数の連絡先をルーティングできる可能性は小さいです。

このルーティングパターンは、以下の種類の非スキルベースのキューでサポートされています。

ラウンドロビン

Circular ルーティング パターンは、利用可能なエージェントのグループ間でラウンドロビン順序で受信連絡先を配布します。連絡先がキューに入ると、システムがキュー内の次の利用可能なエージェントに事前定義されたシーケンスに基づいて割り当てます。

プロセスは、設定された順序でエージェントから始まります。最初の着信連絡先は、そのシーケンスの最初の利用可能なエージェントに割り当てられます。その後の連絡先の場合、システムは次に利用可能なエージェントを選択し、定義されたキュー順序で離れる場所から続行します。このパターンは繰り返し、エージェントをサイクリングしますが、常に最後に選択されたエージェントの位置の後に開始します。

このアプローチは、エージェント間で公正かつ均等に連絡先を配布するのに有効です。これは、単一のエージェントが接触に圧倒されないことを保証し、すべてのエージェントが一貫して相互作用を処理する均等な機会を持つことを保証するのに役立ちます。しかし、サーキュラールーティングパターンは、現在のワークロードや、特定の連絡先を処理するエージェントの能力に影響を与える可能性のある他の要因を考慮していません。

上記の例では、エージェントは以下の順序で円形のキューで構成されています。A34 A5 A6 A1 A2

開始位置は、設定された順序(A3)の最初のエージェントです。このキューで連絡先がエージェントにルーティングされるため、位置は円の周りを移動し、最後の連絡先がルーティングされたエージェントに構成された順序で次のエージェントに配置されます。

次のシナリオを考えてみましょう。

  • 最初の連絡先 (C1) がキューに入れられ、エージェント A3 にルーティングされます。

    ポインターは、設定された順序、つまりA4 で次のエージェントに更新されます。

  • 第2の接触(C2) がキューに入ると、システムは利用可能なエージェントを見つけ始めます。 A4I.E. A4→ A5→ A6→ A1→ A2→ A3.

    しかし、 A4A5利用できません(ログインしていないか、アイドルか、このメディアタイプの他の連絡先と完全にビジーであるかのいずれか)。 C2次の利用可能なエージェントにルーティングされます。 A6.ポインターは、設定された順序、つまりA1 で次のエージェントに更新されます。

  • 第3の接触(C3) がルーティングされる A1第4回コンタクト(C4) ルーティング A2.ポインターが再びA3 です。

    このロジックは継続し、連絡先は「円形」/「ラウンドロビン」パターンで利用可能なエージェント間で分散されます。

キューに固定された連絡先がある場合、エージェント余剰シナリオは、このメディアタイプで利用可能な次のエージェントとそれらの間の最も優先度の高い、最も古い連絡先と一致します。

これは、このキュー内の既存の位置値を考慮したり影響したりしません。

このルーティングパターンは、以下の種類の非スキルベースのキューでサポートされています。

トップダウン

トップダウンルーティングパターンは、利用可能なエージェントと注文されたエージェントグループ間で着信連絡先を順次に分配します。連絡先がキューに入ると、システムは常に最初から順序付けられたエージェントのリストを通過し、そのシーケンスの最初の利用可能なエージェント(コンタクトのメディアタイプの無料チャンネルを持つ)との連絡先と一致します。

これは、キューに入っているすべての連絡先に対して発生します。連絡先は、常に上部(最初に設定されたエージェント)から一致するように試みられ、一致するエージェントが見つかるまでリストを下に進みます。

循環ルーティングパターンとは異なり、最後に選択されたエージェントの位置に基づいて開始点を動的に変更する「ポインター」はありません。

このアプローチは、管理者が決定するバイアス/好みに基づいて注文されたエージェント間の連絡先を配布するのに有効です。これは、上部のエージェントが常にそれらの下部のエージェント上の連絡先を処理することを好ましくするのに役立ちます。しかし、トップダウンルーティングパターンは、現在のワークロードや、特定の連絡先を処理するエージェントの能力に影響を与える可能性のある他の要因を考慮していません。

上記の例では、エージェントは次の順序でトップダウンキューで構成されています。A34 A5 A6 A1 A2

つまり、管理者は、すべての連絡先を、利用可能な場合、最初のエージェント (A3) に、利用可能な場合は、次のエージェント (A4) に、設定された順序でルーティングすることを求めます。

次のシナリオを考えてみましょう。

  • ファーストコンタクト (C1) はキューに入れられ、エージェントにルーティングされます。 A3から A3順序の最上位にあります。
  • 2番目のコンタクト(C2)がキューに入ると、注文の上部からルーティングを再試行します(常にA3から始まります)。

    このメディアタイプのA3にチャンネル容量が増えた場合、C2A3 にルーティングされます。ただし、このメディアタイプでA3 が完全にビジーである場合、ルーティングはリストをA4に転送します。

  • しかし、 A4A5利用できません(ログインしていないか、アイドル、このメディアタイプの他の連絡先と完全にビジーです)。 C2トップダウン順に次の利用可能なエージェントにルーティングされます。 A6.
  • 同様に、第3の接触(C3)は、A3 から下に向かってルーティングしようとします。最初のマッチングエージェントはA1です。

    このロジックは、連絡先が利用可能なエージェントを見つけない限り、順序の下部まで続きます。

このルーティングパターンは、以下の種類の非スキルベースのキューでサポートされています。

エージェントベースのルーティング

エージェントベースルーティング (Agent-based Routing) は、特定の (「好意」) エージェントに直接連絡先をルートまたはキューする機能です。エージェントのEメールアドレスまたはエージェントのIDを持つエージェント検索は、優先エージェントへの連絡先をルートします。フロー内のQueue To Agentアクティビティは、エージェントベースのルーティングを実現するのに役立ちます。詳細については、を参照してください。 エージェントにキュー活動

コンタクトには、1つまたは複数の好ましいエージェントへのマッピングがあり、通常、Webexコンタクトセンター外の外部アプリケーションで管理できます。連絡先を優先するエージェント検索は、 HTTP リクエストアクティビティは、外部アプリケーションからマッピングを取得します。優先エージェントとの連絡先をルートまたは駐車するには、エージェントのWebexコンタクトセンターIDまたはEメールアドレスを使用してQueue To Agentアクティビティを設定します。連絡先は、その優先エージェントがすぐに利用可能でない場合は、優先エージェントに対して駐車することもできます。

エージェントベースのルーティングは、次のシナリオで役立ちます。

  • 優先するエージェントルーティング:顧客は、専用のエージェントや関係幹部に連絡先を割り当てることができます。このようなシナリオでは、エージェントベースのルーティングは、その優先エージェントに直接連絡先をルートします。
  • 最後のエージェントルーティング:連絡先がエージェントと対話するためにコンタクトセンターを複数回呼び戻すと、エージェントベースのルーティングは、その連絡先を処理した最後のエージェントにコンタクトをルーティングできます。

両方のユースケースでは、連絡先とエージェントマッピングの詳細は、Webexコンタクトセンターの外側に格納されます。

フローのキューイングとルーティング機能

フローのキューとルーティング機能

Webex Contact Centerでは、フローを介してルーティング、キューイング、コール制御の広い範囲を整列できます。

フローデザイナーで提供される様々なフローアクティビティとイベントハンドラーは、フロー内に配置して、インバウンドとアウトバウンドの連絡先のライフサイクルを効果的に管理することができます。

フローの設定と使用に関する詳細は、 を参照してください。 フローデザイナーによるフローの構築と管理.

キューのアクティビティ

Queue Contact

Queue Contactアクティビティは、連絡先を組織からアクティブなインバウンドキューにキューし、そのキュー内の適切なエージェントにルーティングできるようにします。

キューイングの次の側面は、このアクティビティを通じて管理できます。

  • Priority - 1(最高)から10(最低、デフォルト)までの階層的な重要性をキューイングする連絡先に割り当てる。
  • Skill Requirements - エージェントがスキルベースのキューで満たさなければならないスキル基準を設定し、連絡先をルーティングする資格があると見なします。
  • Skill Relaxations - エージェントを見つける可能性を高めるために、一定期間後に、以前に設定されたスキル要件を調整、修正、または削除する。
  • Check Agent Availability - システムが、利用可能なエージェントが見つからないすべてのコール配布グループを通じて瞬時に展開できるようにし、待機時間を回避します。

参照 ルーティングでは、優先度、スキル構成、エージェントの可用性が、連絡先をルーティングする上でどのように役割を果たすかを詳しく説明します。

Queue Contactアクティビティが正常に連絡先をキューに入れたら、

  • マッチングエージェントが既に利用可能である場合、システムは連絡先をエージェントにルーティングしようとします。

    これはtheを中断します Main flow 実行とさらなるイベントは、それぞれのイベントをトリガーすることができます。 Event Flows、設定されている場合。

  • マッチングエージェントが見つからない場合、連絡先はキューに駐車され、マッチングエージェントが利用可能になるのを待ちます。

    その後、フローの実行は、Queue Contactアクティビティの後に添付されたアクティビティを続けます。

    • キューで待機しているお客様に、事前に設定された音楽を再生します。 PlayMusic 活動
    • 顧客の要求に基づいてコールバックを登録する - 添付して Callback 活動
    • 再キューすなわち、現在のキューから連絡先を削除し、新しいキューに追加します。 Queue Contact または Queue to Agent 活動

マッチングエージェントが利用可能になると、システムは連絡先をエージェントにルーティングしようとします。

成功すると、それが中断される。 Main flow 実行とさらなるイベントは、それぞれのイベントをトリガーすることができます。 Event Flows、設定されている場合。

Queue Contactのアクティビティは、次のときに動作します。

  • 連絡先は割り当てられていないため、エージェントにルーティングされる準備ができています。
  • キューやスキル、その他のフロー構成が正しく設定されています。
  • 接触は25 エントリーポイントとキュー遷移の許容範囲内にとどまります。
  • 連絡先は、20成功したルーティング試行で許可された制限内に残ります。

代替ルーティングまたは追加の処理を必要とする連絡先を丁寧に管理するための「エラーハンドリング」パスを設定します。

そのような場合、アクティビティは失敗し、フローの実行は、 Error Handling パスだ

Skill Requirements、Skill Relaxations、Check Agent Availabilityなどの機能は、Queue Contactアクティビティでチーム割り当てのあるキューが選択されている場合にのみ利用できます。

アクティビティ設定、使用方法、出力変数に関する詳細は、こちらをご覧ください。 フローの構築と管理 > キューコンタクト.

エージェントにキュー

Queue to Agentアクティビティは、Webexコンタクトセンターで独自のエージェントIDまたはEメールアドレスを調べることで、連絡先を優先するエージェントに直接キューイングする機能を提供します。

キューイングの次の側面は、このアクティビティを通じて管理できます。

  • Priority - 同じエージェントに対してキューに入れられた連絡先に、より高い重要性を割り当てます。
  • Reporting Queue - 録音やデフォルトの音楽インキューなどの設定に使用するキューを特定し、連絡先を報告します。
  • Recovery Queue - 連絡先を指定された優先エージェントにルーティングできなかった場合、フォールバックとして使用するキューを特定します。

Queue To Agentアクティビティが正常に連絡先をキューに入れたら、

  • エージェントが既に利用可能である場合、連絡先はエージェントにルーティングされます。

    これはtheを中断します Main flow 実行とさらなるイベントは、それぞれのイベントをトリガーすることができます。 Event Flows、設定されている場合。

  • エージェントが利用可能なが、拒否する、応答しない、または連絡先を受信しない場合、それは提供されたリカバリキューに移動されます。

    リカバリキューでは、スキルのサポートなしに、連絡先は利用可能な最長のエージェントにルーティングされます。

  • エージェントが利用できない場合、Park Contact If Agent Unavailable「 オプション は selected連絡先が駐車され、エージェントが利用可能になるまで待ちます。

    その後、フローの実行は、Queue To Agentアクティビティの後に添付されたアクティビティを続けます。

    • キューで待機しているお客様に、事前に設定された音楽を再生します。 PlayMusic 活動
    • Callback 活動
    • 再キューすなわち、現在のキューから連絡先を削除し、新しいキューに追加します。 Queue to Agent または Queue Contact 活動

    エージェントが利用可能になると、システムはエージェントに連絡先をルートしようとします。

    これはtheを中断します Main flow 実行とさらなるイベントは、それぞれのイベントをトリガーすることができます。 Event Flows、設定されている場合。

  • エージェントが利用できない場合、Park Contact If Agent Unavailable「 オプション は not selectedキューが失敗します。

Queue To Agentのアクティビティは、次のときに動作します。

  • 連絡先は割り当てられていないため、エージェントにルーティングされる準備ができています。
  • 優先するエージェントIDまたはメールアドレスは有効です。
  • 報告キューとリカバリキューが正しく設定されています。
  • 優先エージェントがログインし、利用でき、連絡先を処理する準備ができています。

優先エージェントが利用できない場合、連絡先がスムーズにルーティングされるようにリカバリキューを構成します。

そのような場合、アクティビティは失敗し、フローの実行は、 Error Handling パスだ

アクティビティ設定、使用方法、出力変数に関する詳細は、こちらをご覧ください。 フローの構築と管理 > エージェントへのキュー.

Escalate Call Distribution グループ

Escalate Call Distribution Group の活動は以下でのみサポートされています。 queues with team assignmentそして、更新機能を提供します。 Call Distribution Group 自動拡張の更新を待つ代わりに、設定された待ち時間後に次のグループに自動拡張の更新を待つ代わりに、すぐに連絡します。これにより、連絡先をキュー内のすべての適格エージェントにすばやくルーティングできます。

Escalate Call Distribution Groupアクティビティを使用することで、連絡先を以下へエスカレートすることができます。

  • Next Group— 次のコール配布グループに追加されたチームを含めるためにチームセットを拡大する。
  • Last Group— チームセットを拡張して、キュー用に構成されたすべてのコール配布グループにマッピングされたすべてのチームを含みます。

Escalate Call Distribution Groupの活動は、以下の場合に動作します。

  • 連絡先は既にキューに入れられ、エスカレーションの準備が整いました。
  • 連絡先は、呼び出し分布グループを使用するキューでキューされます。

標準ルーティングを使用するキューについては、キューの設定されたルーティング動作を介して連絡先を配布し続けます。

そのような場合、アクティビティは失敗し、フローの実行は、 Error Handling パスだ

たとえば、連絡先が3つのコール分布グループを持つキューにキューに入ると、それぞれが30 秒の期間後に更新されます。

チームの一部にエージェントは利用できません CDG 1 および CDG 2と、エージェントは TEAM 3 これは最後の呼び出し分布グループに属しています

Escalate Call Distribution Groupのアクティビティがフローで使用されていない場合、以下に示すように長い待機時間になります。

Escalate Call Distribution Groupのアクティビティを使用して、待機時間を短縮できます。

Based on the Next Group または Last Group 選択したオプションでは、以下の図のように、連絡先を待つ時間が大幅に短縮されます。

アクティビティ設定、使用方法、出力変数に関する詳細は、こちらをご覧ください。 フローの構築と管理 > Escalate Call Distribution Group.

キュー情報アクティビティ

キュー情報を取得

Get Queue Infoアクティビティは、次のような特定の連絡先に対してリアルタイムキュー情報をフェッチする機能を提供します。

  • コンタクトの現在の位置 (PIQ)、またはまだキューされていない場合の潜在的な位置。
  • 予想される待ち時間 (EWT) または、タスクが応答する前にキューで待機すると推定される期間。
  • 連絡先の現在のコール配布グループにログインまたは利用可能なエージェント数。
  • 選択したキューのすべてのCall Distribution Groupsにログインまたは利用可能なエージェント数。
  • キューの古い連絡先が待ち受けている時間。

これらの詳細は、フロー実行時にアクティビティ出力変数として利用できるようになります。

各キューの詳細については、アクティビティの使用、詳細な定義、および計算方法を参照してください。 フローの構築と管理 > キュー情報の取得.

キュー情報の使用方法には以下のようなものがあります。

  • 連絡先がキュー内の位置と推定待ち時間を発表し、ルーティングを待っている間、顧客への待ち時間を予測します。
  • 推定待ち時間が長すぎる場合、コールバックを顧客に登録できるかどうかを決定します。
  • 現在の CDG にマッピングされたチームでエージェントが利用できない場合、連絡先を次のコール配布グループ (CDG) にエスカレートする。

Get Queue Infoアクティビティは、選択した変数が有効なキューに解決したときに動作します。

選択した変数が検証を必要とする場合や、利用可能なキューに解決しないケースを適切に管理するために、エラーハンドリングパスを設定します。

以下の場合、現在のCall Distribution Groupのリアルタイムキュー情報は適用されません。
  • Get Queue Infoアクティビティが実行されたとき、連絡先は(まだ)キューされません。
  • contactは、コール配布グループの概念をサポートしていないキューでキューされます。

この場合、これらの出力フィールドの -1 の値は、この情報が適用されないことを示します。

キューに費やされた15 秒ごとに、顧客がキューに長いEWTについて知らせるべきシナリオを考えてみましょう。

これは、フローのGet Queue Infoアクティビティを使用して達成できます。

高度なキュー情報

Advanced Queue Info アクティビティは、特定の連絡先に対してリアルタイムキュー情報を取得する機能を提供します。

  • コンタクトの現在の位置 (PIQ)、またはまだキューされていない場合の潜在的な位置。
  • 指定されたスキル基準に一致するコンタクトの現在のコール配布グループにログインまたは利用可能なエージェント数。
  • 選択したキューのすべてのコール配布グループにログインまたは利用可能なエージェントの数で、指定されたスキル基準に一致します。
  • 連絡先が指定されたキューに駐車されている現在のコール配布グループ。
  • 指定されたキュー内の呼び出し分散グループの総数。

これらの詳細は、フロー実行時にアクティビティ出力変数として利用できるようになります。

各キューの詳細については、アクティビティの使用、詳細な定義、および計算方法を参照してください。 フローの構築と管理 > 高度なキュー情報.

高度なキュー情報を使用する方法は次のようになります。

  • ルーティングを待っている間、連絡先の位置を顧客に知らせる。
  • 連絡先を次のコール配布グループにエスカレートするには、現在のコール配布グループにマッピングされたチームでスキル基準に一致するエージェントが利用できない場合。
  • すべてのコール配布グループで、スキル基準に一致するエージェントがログインしていない場合、コールバックを顧客に登録できるかどうかを決定します。

Advanced Queue Infoアクティビティは、次のときに動作します。

  • キュー情報は、キューレベルのスキル基準としてではなく、フローでスキル要件が設定されているキューに対して要求されます。
  • 連絡先が既にキューにある場合、連絡先が現在キューされている同じキューについて情報が要求されます。
  • 連絡先は、優先エージェントに直接ではなく、キューにキューされます。

これらの要件を満たさないリクエストを管理するために、エラーハンドリングパスを設定します。

そのような場合、アクティビティは失敗し、フローの実行は、 Error Handling パスだ

スキル基準を満たすエージェントが利用可能でないことを考慮して、顧客がコールバックを受信することについて知らされるべきシナリオを考えてみましょう。

これは、フローで高度なキューインフォメーションアクティビティを使用して、次のように達成できます。

コールコントロール活動

発信者IDを設定

Set Caller ID アクティビティは、通話中に表示されるべき発信者 ID を定義するために使用されます。Set Caller IDアクティビティは、PreDial Event Flowsでのみイベントフローの終了を示すターミナルアクティビティとして使用する必要があります。

Set Caller IDアクティビティでは、ダイヤル番号識別サービス(DNIS)、操作タイプ、または参加者の種類に基づいて、必要な自動番号識別(ANI)を設定できます。

アクティビティ設定、使用方法、出力変数に関する詳細は、こちらをご覧ください。 フローの構築と管理 > Set Caller ID.

録音コントロール

Recording Controlアクティビティは、発信者からの録音の同意をキャプチャするために、メニューアクティビティと一緒に使用するように設計されています。これにより、録音開始前に明示的な同意を必要とする規制またはポリシーの遵守が保証され、このステップをワークフローにシームレスに統合します。

メニュー IVR アクティビティは、Recording Control アクティビティの入力として割り当てられる論理変数にユーザーの同意をキャプチャする必要があります。お客様が同意報告書でユーザーの同意を報告する必要がある場合は、同意値は報告されたグローバル変数に保存する必要があります。また、報告が必要でない場合は、ローカル変数を使用することもできます。このアプローチは、テナントと顧客に、変数の管理と活用に関する柔軟性を高めます。

このアクティビティがフローに追加されると、ユーザーの同意は、テナントレベルまたはキューレベルまたは記録スケジュールのレベル設定設定よりも優先されます。

優先順位は以下の通りです。

  • ユーザの同意がフローでYesである場合、テナントまたはキューまたは記録スケジュールのレベルでの録音設定に関係なく、呼び出しが記録されます。
  • ユーザーがアクティビティへの応答として同意しない場合、テナントまたはキューまたは記録スケジュールのレベルで設定された記録設定に関係なく、呼び出しは記録されません。
  • Recording Controlアクティビティがフロー内に設定されていないが、テナントやキューやレコーディングスケジュールなどの他のレベルのいずれかでYesに設定されている場合は、呼び出しが記録されます。
  • Recording Controlアクティビティがフロー内に設定されていない場合、テナント、キュー、レコーディングスケジュールなど、すべてのレベルでNoに設定されている場合、呼び出しは記録されません。

この録音コントロールは、以下のように説明できます。

さらに、転送の続行、一時再開有効化、一時停止期間などの記録設定は、テナント、キュー、または記録スケジュールのレベルなど、既存の階層に従って適用できます。

アクティビティ設定、使用方法、出力変数に関する詳細は、こちらをご覧ください。 フローの構築と管理 > 記録制御.

ブラインド転送

ブラインド転送は、IVRシステムを通じてコンタクトが外部ダイヤル番号(DN)に効率的にルーティングされ、エージェント関与の必要性を排除するプロセスです。

ブラインド転送の活動は、呼び出しを外部またはサードパーティのDNに転送する必要がある場合に使用されます。これはターミナルアクティビティなので、転送が実行されるとフローは終了します。

Blind Transferアクティビティは、コンサルティングのためにフローが実行されたときにサポートされません。

アクティビティ設定、使用方法、出力変数に関する詳細は、こちらをご覧ください。 フローの構築と管理 > ブラインド転送.

橋渡し

ブリッジド転送アクティビティでは、フローが呼び出しの制御を保持している間、連絡先を一時的に外部宛先に転送することができます。外部宛先は、外部ブリッジまたはインタラクティブ音声応答(IVR)サービスです。

外部宛先が呼び出しを終了すると、呼び出しフローはエージェントにキューイングするなど、必要に応じてさらに進みます。

Bridge Transferアクティビティは、サードパーティのIVRまたは自動コール配信(ACD)システムへの転送中に連絡先をデキューします。連絡先がサードパーティのシステムによって処理されない場合は、元のキューに戻すことが可能で、適切な処理のために連絡先がワークフローに残ることを保証します。

たとえば、コンタクトセンターにWebex Contact Centerエージェントリソースと、外部コールセンターまたはプライベートブランチエクスチェンジ(PBX)のエージェントリソースがあるとします。顧客は、Webexコンタクトセンターエージェントのキューに対して、短い期間(60 秒など)のコールをキューにしたいと考えています。その期間中にエージェントが利用できない場合、呼び出しは外部コールセンターにブリッジ転送(暗黙のデキュー付き)して、コンタクトを処理することができます。

  1. Bridged Transfer アクティビティは、アウトバウンドコールフローとイベントフローではサポートされていません。
  2. エージェントに既に割り当てられている連絡先は、フローを介して Bridge Transfer ではサポートされていません。

アクティビティ設定、使用方法、出力変数に関する詳細は、こちらをご覧ください。 フローの構築・管理 > 橋渡し.

連絡先を切断する

Disconnect Contactアクティビティは、アクティブな連絡先をフローから直接切断または終了する機能を提供します。

これは、フローに添付された端末アクティビティであり、エージェント介入なしで終了する連絡先に有用であり、エラーパスのフローや顧客へのコールバックを登録した後に適しています。

設定に基づいて、このアクティビティを通じて連絡先が終了すると、コール後のアンケートまたはフィードバックがトリガーされます。

アクティビティ設定、使用方法、出力変数に関する詳細は、こちらをご覧ください。 フローの構築と管理 > 連絡先を切断する.

連絡先の優先順位を設定

[連絡先優先度の設定] アクティビティは、特定の優先度のレベルを連絡先に割り当てることにより、フロー内で効果的な連絡先優先度の管理を容易にします。これにより、特定の連絡先が重要度が高いか低いことを可能にし、エージェントが利用可能になったときに他の待ち受けの連絡先と比較して適切にルーティングされるようにします。この柔軟性により、フロー全体で接触の優先順位付けを正確に制御できます。

優先順位は、1(最高)から9(最低)に階層的な重要性レベルを割り当てることで決まります。優先度の高い連絡先は、優先度の低い連絡先よりも先にルーティングされます。複数の連絡先が同じ優先度レベルを共有する場合、最長待ちしている連絡先は、最初に次の利用可能で適格なエージェントにルーティングされます。このシステムにより、優先度の高い連絡先は、待ち時間に基づいて同等の優先度の高い連絡先間で公平性を維持しながら、迅速な注意を喚起します。

  1. [連絡先優先度の設定] アクティビティは、メインまたはイベントフロー内の任意の位置に配置できます。
  2. Set Contact Priorityアクティビティがキューイングアクティビティの前に設定されている場合(キュー連絡先やQueue To Agentなど)、その優先度設定は、その後のキューイングアクティビティで明示的に設定された優先度によって上書きされることがあります。ただし、以下のキューイングアクティビティが優先度を指定しない場合、以前の [Set Contact Priority] アクティビティで設定した連絡先優先度が適用されます。
  3. 逆に、Set Contact Priorityアクティビティがキューイングアクティビティの後に設定されている場合(キュー連絡先やキューからエージェントへ)は、以前のキューイングアクティビティによって設定された優先度設定を上書きします。
  4. Set Contact Priorityアクティビティは、アウトドアおよびキャンペーンの連絡先に対して現在サポートされていません。

アクティビティ設定、使用方法、出力変数に関する詳細は、こちらをご覧ください。 フローの構築と管理 > 連絡先の優先順位を設定する.

コールバックのアクティビティ

通知

コールバックのアクティビティは、コールバックを待つよりもコールバックを要求することを可能にし、待機時間を短縮し、放棄率を最小限に抑え、顧客満足度を大幅に向上させます。有効にすると、コールバックアクティビティがキューにタスクを作成し、利用可能なエージェントが顧客の呼び出しを返すことができるようにします。

フローデザイナーは、呼び出し元の元のキューに連絡先を保持するか、設定に基づいて別のキューに割り当てるようにアクティビティを設定できます。コールバックが元のキューに残っている場合、連絡先はその位置、スキル、優先度、およびコンテキストデータを維持し、次の利用可能なエージェントへのシームレスな割り当てを可能にします。ただし、別のキューが選択されている場合、連絡先はスキルがなく、既定の優先度で、選択したキューの最後にプッシュされます。

このアクティビティでは、お客様が希望するエージェントからコールバックをリクエストすることができ、体験に個人的なタッチを加え、顧客満足度を高めることができます。これは、コールバックアクティビティがフロー内の QueueToAgent アクティビティに従ったときに達成できます。さらに、コールバックアクティビティは、コールバックプロセスで使用されるAutomatic Number Identification (ANI) をカスタマイズするためのオプション設定を提供します。このカスタマイズは、ブランドの一貫性を高め、認識可能な発信者IDを確保することで、コール拒否の可能性を低減します。

フローデザイナーには、イベントフローに CallbackFailed イベントを含めるオプションがあります。このイベントは、コールバック試行が失敗したときに発生します。再試行間の遅延または間隔は、10秒の最小再試行間隔と最大72 時間で、Waitアクティビティを使用して設定できます。このシステムは、「待ち待ち」アクティビティを使用して、最大14 日間の10再試行をサポートします。

アクティビティ設定、使用方法、出力変数に関する詳細は、こちらをご覧ください。 フローの構築と管理 > コールバック.

コールバックのスケジュール

スケジュールされたコールバックアクティビティは、顧客に特定の将来の日付と時刻にコールバックを要求する利便性を提供することを可能にし、エージェントとの即時接続の必要性を排除します。この機能は、便利なコールバックウィンドウを選択できるようにすることで、カスタマーエクスペリエンスを向上させ、知覚される待ち時間を最小限に抑え、コール終了率を低下させます。

フローは、希望の日時などの発信者の入力をDTMFプロンプトを介してキャプチャし、必要な入力検証を実行した後にアクティビティに渡す必要があります。

開始する前に、必ず、 Callback Default Entry Point 以下に設定されています。 Channel Settings Control Hubにて。詳細については、を参照してください。 コールバックエントリーポイントの設定.

コールバックは、インバウンドまたはアウトバウンドのいずれかのテレフォニーキューを使用してスケジュールすることができます。最良の結果を得るには、コールバックが予定された後に現在の呼び出しが適切に終了することを確認するために、予定されたコールバックアクティビティの直後に切断アクティビティを追加することをお勧めします。IVR コールバックのスケジューリングに関する詳細は、を参照してください。 IVRコールバックのスケジュール.

要求された将来の日付と時刻でコールバックがトリガーされると、新しいコールまたはインタラクションが作成されます。この新しいインタラクションは、コールバックデフォルトエントリーポイントにリンクされている標準フローに従います。コールバックの試みが失敗した場合、そのフローで設定されている場合、フローは CallbackFailed イベントハンドラーを使用して自動的に呼び出しを再試行できます。

以下の入力検証は、入力がアクティビティに渡される前に考慮する必要があります。

  1. 日付の選択 — 今日から将来の31 日までの日付を選択できます。日付は以下の形式でなければなりません:YYYY-MM-DD(例:2025-07-18)
  2. Time Window Start and End Time - 選択する時間は少なくとも30 分から開始し、30 分から8 時間の間にどこでも持続できます。24-hourの書式を使用してください(例: 14:30:00) として共有する必要があります。
  3. タイムゾーン — 有効なタイムゾーンをIANA形式で入力する必要があります (例: America/New_York) だからこそ、適切なタイミングで電話をかけることができます。

リファレンス実装は、サブフローテンプレートの形式を提供し、アクティビティと一緒に使用されるDTMFプロンプトと基本的な検証を実証します。詳細については、を参照してください。 コールバックサブフローのテンプレート.

進捗分析を呼び出す

Call Progress Analysis (CPA) は、自動応答システムの検出とコールバックコールでのライブヒューマンボイスを可能にします。

コールバックの試みがAnswering Machine Detection (AMD) またはボイスメールに遭遇すると、システムは呼び出しを失敗として識別します。Answering Machine Detection (AMD) の結果は、CallbackFailed イベントハンドラーの reason 出力変数にキャプチャされます。この出力変数に基づいて、フローデザイナーはコールバックの再試行を設定できます。

  1. 礼儀正しいコールバックの場合、CallProgressAnalysis はメインフローのコールバック活動の後に位置することができます。予定されたコールバックまたは個人的な予定されたコールバックの場合、メインフローにNewPhoneContactの後に配置できます。
  2. イベントフローでは、CallbackFailed イベントハンドラーでのみサポートされます。
  3. Post Call Customer Survey(フィードバックアクティビティ)がフローで設定されている場合、AMDまたはボイスメールが回答した場合は開始されません。これにより、不必要な調査を誘発することを防ぎます。

アクティビティ設定、使用方法、出力変数に関する詳細は、こちらをご覧ください。 フローの構築と管理 > Call Progress Analysis.

キューイング

概要

Webex Contact Centerでは、キューは電話、チャット、メール、ソーシャルメディアなどの着信インタラクションを一時的に保留する場所として機能します。問い合わせは、自動的に担当者に分配されるか、担当者が手動で処理するまで、キューに待機されます。さらに、スキルベースのルーティング、優先順位管理、公平なワークロード配分といった機能もサポートしています。

管理者はキューを利用してさまざまな業務の流れを観察し、コンタクトセンターにおける業務処理方法を改善することができます。

キューを効果的に活用することによる主なメリットは以下のとおりです。

  • より良い顧客体験: 待ち時間を管理し、お客様に順番待ちであることを知らせてください。
  • 効率性の向上: 電話対応が秩序正しく行われるようにし、混乱や管理ミスを減らす。
  • 連絡先の公平な分配: 特定の担当者に過負荷がかからないよう、通話を担当者間で均等に分散してください。
  • 優先処理: VIP顧客や緊急案件など、特定の通話を優先的に処理できるようにする。

キューの種類

Webex Contact Centerは、さまざまなタイプのキューをサポートしており、規模や複雑さを問わず、あらゆるメディアタイプにおいて、均一な機能で幅広いユースケースに対応できます。

問い合わせのルーティングにおいて、エージェントのスキルを考慮するキューと、考慮しないキューが存在する。これらのキューは、エージェントがコンタクトに対応するためにどのように関連付けられるかという点でも異なっている。

行列には大きく分けて2つの種類があります。

  • スキルに基づかないキュー
  • スキルベースのキュー

スキルに基づかないキュー

スキルベースではないキューでは、エージェントに関連付けられたスキルは考慮されません。スキルベースではないキューは、以下のオプションで設定できます。

  • チーム編成
  • エージェントの割り当て

チーム割り当てによる非スキルベースのキュー

チーム割り当てのある非スキルベースのキューでは、エージェントをチームに編成し、これらのチームを組み合わせてコール分配グループ(CDG)を形成できます。通話の流れを管理するために、各グループ間に時間遅延を設定できます。

コール分配グループは、設定された時間間隔でこのキュー内のコンタクトに対応する資格を得るエージェントの複数のレベルを定義するのに役立ちます。担当者は、所属チームのレベルに基づいて連絡先を割り当てられます。担当者がいない場合、連絡先は事前に設定された期間保留され、その後次のチームグループに拡張されます。このプロセスは、担当者が利用可能になるか、すべてのグループの確認が完了するまで続きます。

次のような種類のチームを設定できます。

  • 各チーム: エージェントは特定の組織機能を表すチームに編成することができ、そのチームはキューの一部となり、問い合わせをこれらのチームのエージェントにルーティングすることができる。複数のチームにエージェントを割り当てることで、さまざまなキューからの問い合わせを効率的に処理できます。
  • 能力ベースのチーム: キャパシティベースチーム(CBT)は、音声通話をキャパシティベースの直通番号(DN)に振り分ける機能で、キャパシティとは同時に処理できる通話数を指します。この機能により、オペレーターがシステムにログインする必要なく、電話番号への通話ルーティングが可能になるため、従来のコールセンターオペレーターではなく、ボイスメール、留守番電話、またはハントグループによって通話が応答されるシナリオに適しています。この構成では、チームに特定の担当者は割り当てられておらず、Webex Contact Center Agent Desktopも使用していません。

Webex Contact Centerにおけるチーム割り当て付き非スキルベースキューの仕組みを示すワークフロー図

この例では、3つのコール分配グループがあり、これによりターゲットの拡張が可能になります。つまり、設定された時間間隔で、チームを超えてより多くのエージェントにターゲットを拡大できるということです。

最初のコール分配グループにはTEAM 1が含まれており、TEAM 1にはA1、A2、A5の3人のエージェントが設定されています。

2番目の通話分配グループにはTEAM 2が含まれており、A2、A3、A4の3人のエージェントが設定されています。

3番目(そして最後)の通話分配グループにはTEAM 3が含まれており、A6とA7という2人のエージェントが設定されています。

問い合わせがキューに追加されると、システムはまず最初のコール分配グループ内で一致するエージェントを検索します。エージェントが見つからない場合、次のグループへのターゲット拡張を行う前に、コンタクトは設定された期間保留されます。これにより、既存のチームに新たなチームが追加されることになります。このプロセスは、一致するものが見つかるか、すべてのグループが展開されるまで繰り返されます。

「エージェントの空き状況を確認」と呼ばれる機能により、現在のグループに一致するエージェントが見つからない場合、コンタクトは即座に次のコール分配グループに展開されます。これは、フロー内のキューコンタクトアクティビティ <LINK TO section 3.1.1> で有効にできます。

この設定により、以下のシナリオが発生します。

  1. A2 はチーム1とチーム2に属します。A2がエージェントデスクトップにログインする際にTEAM 1を選択した場合、システムはA2をTEAM 1の一員とみなし、したがって最初のコール分配グループのみに属するものとみなします。
  2. A5 はTEAM 1に属していますが、現在ログインしている組織内の他のチームに所属していた可能性もあります。したがって、A5はチーム1の一部とはみなされず、このキューとは関連付けられていません。

チーム割り当て機能付きのキューは、エージェントがログイン時にチームを選択するだけでキュー間を移動できるという強力な機能を提供します。

利用可能なルーティングパターン:

スキルベースではないキュー(エージェント割り当てあり)

スキルベースではないキューとは、エージェントのプールが直接キューに割り当てられるタイプのキューのことです。他のキュータイプは、割り当てられるエージェントのプールを間接的に決定するのに対し、これらのキューでは、管理者がエージェントを直接手動で選択できます。例えば、チームベースの割り当てキューは、エージェントがログインしているチームに基づいてエージェントを割り当て、スキルベースの割り当てキューは、必要なスキルに基づいてエージェントをマッチングします。一方、管理者はエージェントをこれらのキューに直接追加して、キューの一部にすることができます。これにより、システムによる割り当てに頼ることなく、エージェントの割り当てを簡単に管理できます。

エージェント割り当て機能を備えたキューは、シンプルでありながら効果的なルーティングアルゴリズムを提供し、エージェントのプール間でコンタクトを分散させるのに役立ちます。彼らは、担当者が連絡先を適切に振り分けるスキルを考慮していない。ただし、各キュー内でエージェントの順序付けを行うことができ、これは問い合わせをエージェントにルーティングする際に考慮されます。この文脈において、チームは主に管理者にとっての組織的な構成要素として機能し、エージェントとキューの関連付けやコンタクトのルーティングの決定における要素としてではなく、キュー管理を簡素化する役割を果たします。

このタイプのキューは、エージェントの静的割り当てとエージェントとキューの関連付けの管理が運用制御にとって実現可能かつ望ましい場合、およびルーティングアルゴリズムの選択がエージェント間の作業分散に適している場合に最適です。これらのキューは、複数の種類の顧客からの問い合わせに対して、事前に作成された専門エージェントのグループが対応できる専門知識を必要とするシナリオにおいて、特に役立ちます。

しかし、複雑なコンタクトセンター組織では、これらのキューにおけるエージェントの割り当てを手動で管理することが困難になる可能性がある。動的なルーティングやエージェントとキューの関連付けを提供する他のキュータイプの方が、より効果的である可能性がある。

Webex Contact Centerにおけるエージェント割り当て付き非スキルベースキューの例の動作を示すワークフロー図

この例では、キューにはA4、A9、A7など、特定の順序でマッピングされたエージェントのセットがあります。この順序は、着信した問い合わせをエージェントに割り当てる特定のルーティングアルゴリズムにおいて重要な役割を果たします。システムは、担当者の空き状況と選択されたルーティングアルゴリズムに基づいて、連絡先をこれらの担当者にマッチングします。

チーム割り当てのあるキューとは異なり、時間間隔を通じた ターゲット拡張の概念 はありません。設定されているエージェントのいずれもこのコンタクトをルーティングできない場合、いずれかのエージェントが待機タイムアウト前にコンタクトを処理できるようになるまで、コンタクトはキューに保留されます。ターゲット拡張 はこれらのキューには適用されません。

利用可能なルーティングパターン:

スキルベースのキュー

スキルベースのキューを使用すると、問い合わせを適切なスキルを持つエージェントに振り分け、ニーズを満たすことができます。

以下の種類のスキルベースのオプションを設定できます。

キューに割り当てられたスキル基準

管理者はキューにスキル基準を割り当てることができます。スキル基準を設定したスキルベースのキューを使用すると、管理者はキュー内で必要なスキルを直接設定できます。組織内のすべてのエージェントは、直接的なスキルプロファイルを通じてキューに必要なすべてのスキルを持っている場合、暗黙のうちにこのキューの一部となります。

この設定により、管理者はスキルに基づいてキューにマッピングされているエージェントをリアルタイムで把握できます。処理量が多い場合や少ない場合など、状況に応じて、管理者はキューの要求スキルやエージェントのスキルプロファイルを調整し、必要に応じてエージェントのプールを拡大または縮小することを検討する場合があります。

このタイプのキューは、チーム割り当てベースのキューとは異なり、通話分配グループの設定がないため、エージェントとキューの関連付けにおいてチームは役割を果たしません。さらに、このキューでは必要なスキルが静的に構成されています。これは、フローが(静的または可変の)必要なスキルを挿入するチームベースのスキルキューとは異なります。したがって、厳密に言えば、スキルはコンタクトそのものではなく、キューの一部である。

組織内のエージェントのうち、キューのスキル基準を完全に満たす者(直接スキルプロファイルに記載されているスキルを有する者)は、暗黙のうちにこのキューに関連付けられる。チームは、エージェントとこれらのキューとの関連付けにおいて一切役割を果たしません。これらのエージェントは、管理および運用上の目的で、あらゆるチームの一員となることができます。

このキューに登録されたすべての連絡先は、キュー自体で定義されたスキル基準を自動的に適用されます。個々の連絡先は、自身のスキルを定義したり、覆したりすることはできない requirements/criteria チーム割り当てのあるスキルベースのキューとは異なります。

Webex Contact Centerにおけるスキル基準に基づくスキルベースキューの仕組みを示すワークフロー図

この例では、

  • エージェントA1、A3、A7のみがキューに設定されたスキル基準を完全に満たしているため、これらのエージェントのみがこのキューに関連付けられます。
  • 基準を部分的に満たすエージェントA2、A4、A6、または関連スキルが不足しているエージェントA5は、このキューに関連付けることはできません。

エージェントのスキルプロファイルを更新(リスキリングと呼ばれる)して、キューのスキル基準を満たすようにすると、そのエージェントは自動的かつ動的にこのキューの一部になります。あるいは、キューのスキル基準自体を更新して、更新されたスキル基準を満たすエージェントの数を増やす(または減らす)ことで、このキューにエージェントが自動的かつ動的に追加(または削除)されることもあります。

チーム割り当てのあるキューとは異なり、時間間隔を通じた ターゲット拡張の概念 はありません。連絡先が関連付けられているエージェントのいずれにも一致しない場合、その連絡先はキューに保留され、保留タイムアウト前にいずれかのエージェントが連絡先を処理できるようになるまで待機します。

スキルベースのキューは、スキルの静的な割り当てと、キューとエージェントの関連付けの管理が運用制御上可能かつ望ましい場合に最適です。また、ルーティングアルゴリズムの選択がエージェント間の作業分配に適している場合にも適しています。これらのキューは、顧客からの問い合わせの種類によって特定のスキルが必要となり、事前に選定された専門エージェントのグループが対応できるようなシナリオにおいて特に役立ちます。

複雑なコンタクトセンター組織では、スキルベースのキューの方が、エージェント割り当て型のキューに比べて、キューとエージェントの割り当て管理が容易になる場合があります。エージェント割り当て型のキューでは、各エージェントを手動でリストに追加する必要があり、特に大規模な組織にとっては煩雑です。

フローで割り当てられたスキル要件

フロー内でスキル要件が割り当てられたスキルベースのキューは、Webex Contact Centerにおけるチーム割り当てベースのキューの一種であり、コール分配グループと呼ばれる複数のレベルでチームセットが構成されます。これらの設定済みチームにログインしているエージェントは、そのチームがキュー内で設定されているコール分配グループレベルに基づいて、かつコンタクトのスキル要件を完全に満たしている場合に、このキューからコンタクトが割り当てられます。

このようなキュー内では、エージェントチームはコール分配グループにグループ化され、グループ間には設定可能な時間遅延が設けられます。担当者が不在の場合、リクエストは保留され、一定時間経過後、次のコール分配グループにルーティングが展開されます。このプロセスは、担当者が割り当てられるか、すべてのグループが枯渇するまで続きます。一方、このプロセス中に、以前にチェックしたグループ内のエージェントが利用可能になった場合は、そのエージェントが選択されます。

エージェントは、エージェントに直接割り当てられたスキルプロファイルを通じてスキルを習得します。エージェントのスキルは、サインイン時のチーム選択に基づいて決定されます。

各担当者は、フロー内で任意にスキル要件を指定でき、その要件は利用可能なエージェントのスキルと照合され、最適なエージェントが選択されます。

さらに、契約者は設定された時間間隔で技能緩和を指定することもできます。これらは、設定された時間間隔で、連絡先の元のスキル要件を上書きする、修正されたスキル要件のセットです。これにより、担当者は待機中にスキル要件を変更(通常は「緩和」するために使用)することができ、緩和されたスキル要件に合うエージェントが増える。

コール分配グループによるターゲット拡大は、スキル緩和サイクルと同時に実施できます。どちらも、保留中のコンタクトを適切なエージェントにより迅速にマッチングさせることを目的としており、それによって全体の待ち時間を短縮し、キューのサービスレベルを向上させます。

Webex Contact Centerにおけるスキルベースのキューとチーム割り当ての仕組みを示すワークフロー図。

チーム割り当てのある非熟練者向けキューと同様に、3つのコール分配グループがあり、設定された時間間隔でチームを超えてより多くのエージェントにターゲットを拡大する「ターゲット拡張」が可能です。

  • 最初の通話分配グループにはTEAM 1が含まれており、TEAM 1にはA1、A2、A5の3人のエージェントが設定されています。
  • 2番目の通話分配グループにはTEAM 2が含まれており、A2、A3、A4の3人のエージェントが設定されています。
  • 3番目(そして最後)の通話分配グループにはTEAM 3が含まれており、A6とA7という2人のエージェントが設定されています。

しかし、注意すべき主な点が2つあります。

  • このキューに登録されるすべてのコンタクトは、フローを通じて必要なスキルとスキル緩和レベルを定義します。
  • エージェントは、スキルプロファイルを通じて(直接設定するか、ログインしているチームから継承する形で)スキルを設定できます。

A2はTEAM 1とTEAM 2の両方に属するように設定されていますが、ログイン時にエージェントが選択したチームに応じて、現在のセッションではそのチームの一員とみなされ、そのチームのスキルプロファイル(およびスキル値)も継承します(ただし、このエージェントに対して直接スキルプロファイル設定で上書きされている場合は除きます)。

これは、チーム割り当て機能を備えたキューが提供する強力な機能であり、エージェントはログイン時にチームを選択するだけでキュー間を移動できます。

選択したチームからスキルプロファイルの設定を継承できる機能と相まって、エージェントは異なるスキルセットを扱うことも可能です。

この例では、

  • 連絡先は初期スキル要件(sk_1)とともにキューに入れられます >= 6) フローからのエスカレーション中、スキルの緩和(sk_1 >= 3) 設定された時間間隔後。
  • すべての通話分配グループのすべてのエージェントの中で、キューに登録されたコンタクトの初期スキル要件を満たすスキルを持っているのは、A1、A3、A6、A7のみです。
  • 残りのエージェントは、スキル(sk_1)を持っているがスキル要件を満たしていない(例:TEAM 1のA2、TEAM 2のA4)、またはこのスキルを全く持っていない(例:TEAM 2のA5、A2)かのいずれかです。
  • 時間の経過とともに、技能要件が緩和されると、A2とA4も接触の「緩和された」技能要件を満たすようになる。

このキューにキューイングされたすべての問い合わせに対し、システムは、最初のコール配信グループ内で、その問い合わせの現在のスキル要件を完全に満たすエージェントを見つけようとします。一致するエージェントが見つからない場合、ターゲット拡張が2番目の通話分配グループに実行される前に、コンタクトは設定された期間保留されます。2番目の通話配信グループで設定されたすべてのチームは、最初のグループの既存のチームにも追加されます。次に、システムは拡張されたグループ内で一致するエージェントを見つけようとします。なお、この処理が行われている間、スキル緩和によって設定された時間間隔で担当者のスキル要件も更新され、システムは更新されたスキル要件を使用して、現在の通話分配グループで利用可能なエージェントとマッチングを行います。

これは、設定されているすべての通話分配グループが展開され、すべてのスキル緩和が適用されるまで続きます。ただし、それ以前に一致するエージェントが見つかった場合は除きます。

利用可能なルーティングパターン:

キュー構成

スキルベースのキューを設定する

スキル基準をキューに割り当てる
  • スキルを作成し、必要に応じて動的スキルを作成します。
  • スキルプロファイルを作成します
  • エージェントにスキルプロファイルを直接割り当てます。
  • エージェントに動的スキルを直接割り当てます。動的スキルはスキルプロファイルを通じて割り当てられません。
  • 電話、チャット、メール、ソーシャルのいずれかのチャネルタイプを指定してキューを作成します。
  • コントロールハブのキューに、スキルと動的スキルの要件を割り当てます。
  • キューに入っている問い合わせに対応できるエージェントの一覧を表示します。
  • ルーティングアルゴリズムとして、LAAまたはBAAのいずれかを選択してください。BAAの場合、必要に応じて熟練度スキルと熟練度ダイナミックスキルの重みを設定します。
  • フローにキュー連絡先アクティビティを追加し、このキューを選択します。
スキル要件をキューに割り当てる
  1. スキルを作成し、必要に応じて動的スキルを作成します。
  2. スキルプロファイルを作成します
  3. エージェントまたはチームにスキルプロファイルを直接割り当てます。
  4. エージェントに動的スキルを直接割り当てます。動的スキルはスキルプロファイルを通じて割り当てられません。
  5. チームを作成します。
  6. チームにエージェントを追加する。
  7. 電話、チャット、メール、ソーシャルのいずれかのチャネルタイプでキューを作成します。
  8. 単一のCDGまたは複数のCDGにチームをキューに追加します。
  9. ルーティングパターンとしてLAAまたはBAAを選択してください。
  10. フローにキュー連絡先アクティビティを追加し、スキルベースルーティングが設定されているキューを選択します。詳細については、 キューコンタクトを参照してください。
  11. キューコンタクトアクティビティで、スキル、動的スキル、およびスキル緩和を割り当てます。BAAの場合、必要に応じて熟練度スキルと熟練度ダイナミックスキルの重みを設定します。
  12. フローのキューイング後の「通話分配アクティビティのエスカレーション」を使用すると、次の通話分配グループまたは最後の通話分配グループにすばやく移動できます。

スキルベースではないキューを設定する

チームをキューに割り当てる
  • チームを作成します。
  • チームにエージェントを追加する。
  • 電話、チャット、メール、ソーシャルのいずれかのチャネルタイプでキューを作成します。
  • 単一のCDGまたは複数のCDGにチームをキューに追加します。
  • ルーティングパターンとしてLAAを選択してください。
  • フローにキュー連絡先アクティビティを追加し、このキューを選択します。
  • フローのキューイング後の「通話分配アクティビティのエスカレーション」を使用すると、次の通話分配グループまたは最後の通話分配グループにすばやく移動できます。
エージェントをキューフローに割り当てる
  • 電話、チャット、メール、ソーシャルのいずれかのチャネルタイプでキューを作成します。
  • エージェントをキューに直接追加します (注: このタイプのキューでは、スキルもチームも使用されません。
  • 循環型、直線型、最長利用可能エージェントなどのルーティングパターンを選択してください。
ルーティング

ルーティングの概念

エージェント余剰シナリオ

エージェント過剰シナリオとは、待機中の問い合わせ件数よりも利用可能なエージェント数が多い場合に発生する状況です。この場合、顧客とのやり取り(問い合わせ)がキューに登録されると、システムは直ちにその特定の問い合わせに対応するエージェントを探します。そして、対応するエージェントが見つかった場合は、その問い合わせをキューに待機させて、対応するエージェントが後で利用可能になるまで待つ必要はありません。

コール分配グループによる連絡先の拡張、またはスキル緩和が行われるたびに、システムは直ちにその特定の連絡先に一致するエージェントを再度検索しようとします。

特定の連絡先に対応するエージェントを見つけるには、キューに設定されているルーティングパターンを使用します。

Webex Contact Centerは、さまざまな種類のキューにわたる複数のルーティングパターンを提供しており、これにより組織は待ち時間を最小限に抑え、エージェントのワークロードのバランスを取り、顧客が特定のニーズに対応できる必要なスキルを持つエージェントに接続できるようにすることで、顧客サービスを最適化できます。ルーティングパターンに関する詳細については、「ルーティングパターン」のセクションを参照してください。

コンタクト余剰シナリオ

コンタクト過剰ルーティングは、顧客からの問い合わせ件数(またはコンタクト数)が利用可能なエージェント数を超えた場合に発生します。このような状況は、ピーク時や予期せぬ接触件数の急増時によく発生します。コンタクト過剰ルーティングの主な目的は、この過剰需要を効率的に管理し、需要過多にもかかわらず顧客サービス基準が維持されるようにすることです。特定のチャネルで利用可能になったばかりのエージェントに対しては、コンタクト余剰ルーティング機能が働き、そのエージェントに関連付けられているすべてのキューに存在する保留中のコンタクトの中から、適切なコンタクトを見つけて割り当てます。

限られたエージェント数で効率的にコンタクトルーティングを実行するための主要戦略は以下のとおりです。

  • キューランキング

    キューのランキング機能を使用すると、管理者はキューの相対的な重要度を指定できます。管理者は、キューのランキングを定義することで、チームごとに、キューからチームにログインしているエージェントに通話がルーティングされる順序を設定できます。

    例えば、チームAにログインしているエージェントは、「請求」と「販売」という2つのキューに関連付けられているとします。管理者はキューランキングを使用して「請求」キューに高いランクを割り当てることができます。これにより、問い合わせがキューに入った際に、「請求」キューからの問い合わせは「営業」キューからの問い合わせよりも先に、チームAに属するエージェントにルーティングされます。たとえ「営業」キューに、より古く優先度の高い問い合わせが待機している可能性があったとしても、これは「請求」キューのキュー順位が「営業」キューよりも高いという理由だけで起こります。「請求」キューに待機中の連絡先がなくなった場合にのみ、チームAのエージェントは、自身が関連付けられている「営業」(およびその他の)キューからの連絡先をルーティングします。

    キューランキングの重要な特徴をいくつか以下に示します。

      • ランクが一部のキューにのみ割り当てられている場合、ランクが割り当てられているキューでの呼び出しは、ランクが指定されていないキューでの呼び出しよりも優先されます。
      • キューのランキングは、すべてのメディアタイプにわたって最大50個のキューに設定でき、値は1から50までの範囲で、1が最高ランクとなります。
      • 複数のキューに同じランクを割り当てることができます。
      • キューのランキングを有効にすると、明示的なランクが割り当てられていないキューは、ランク付けされたすべてのキューよりも低いランクとして扱われます。
      • キューランキングは、同じメディアタイプ内で機能します。

        例えば、チームAにおいて、キュー「販売」がランク2の音声メディアタイプのキューであり、キュー「請求サポート」がランク1のチャットキューである場合、ランクが2であっても、チームAの音声チャネルで利用可能なエージェントが最初に音声通話を受け取ります。

        ただし、チームBの2つのチャットキュー、つまりキューランク2のクレジットカードキューとキューランク1のデビットカードキューを考えてみましょう。次に、チームBの利用可能なエージェントには、キューデビットカードからの連絡先が優先的に提供されます。

      • キューのランキングは、キャパシティベースのチームには適用されません。

  • 連絡の優先順位

    連絡先がキューに登録されると、その優先順位は、1(最高)から10(最低、デフォルト)までの階層的な重要度を割り当てることで定義できます。この優先順位付けにより、組織にとっての重要性、緊急性、または戦略的価値に基づいて、特定の問い合わせに迅速に対応することが可能になります。エージェントが、そのエージェントに関連付けられているすべてのキューの保留中のすべてのコンタクトの中から、次のコンタクトを処理できる状態にある場合、すべてのキューの中で最も優先度の高いコンタクトがそのエージェントにルーティングされます(スキルマッチングなどの他の基準が満たされている場合)。

    明示的な優先順位が指定されていないままキューに登録された連絡先については、デフォルトの優先順位として10(最低)が適用されます。優先順位が同じ複数の問い合わせがあった場合、待機時間が最も長い問い合わせが、対応可能で資格のあるエージェントに優先的に割り当てられます。

  • 最長待機時間

    これは、エージェントが関連付けられているすべてのキューの中で、最も待ち時間の長い問い合わせをエージェントにルーティングすることを保証する基本的な戦略です。

    これは、同じキュー順位と優先度を持つ複数のキュー間で処理待ちの問い合わせがある場合に、どの問い合わせをルーティングするかを決定する最終的な基準です。

基本的に、利用可能になったばかりのエージェントに対するコンタクト余剰ルーティングとは、次のような単一のコンタクトを選択することを意味します。

  • エージェントが利用可能なメディアと同じメディアタイプである
  • このエージェントが関連付けられているいずれかのキューに駐車されています
  • このエージェントは、必要なスキル要件(もしあれば)をすべて満たしています。
  • エージェントのチームで設定されている他のキューよりもランクの高いキューに配置されます
  • こうした連絡の中で最も優先順位が高いのは
  • 同じ優先順位の連絡先の中で最も古い待機中の連絡先です

上記の例は、連絡先が余剰になったシナリオを示しています。エージェントA1はTEAM 1にログインし、複数のメディアタイプで連絡先を処理できる状態になっています。

A1 は 3 つのキュー ( Q1Q2 、および Q3)に関連付けられています。TEAM 1 はキューランキングも定義しており、 Q1 が最も高くランクされ、次に Q2 、そして Q3 が続きます。

これらのキューにはすでに連絡先が登録されており、それぞれの連絡先には必要なスキルと優先順位が定義されています。

さて、接触過剰シナリオは次のように機能します。

  • これらのキュー全体に待機中のコンタクトのうち、 A1C2C7 (キュー 2 から) および C3C8 (キューから) にルーティングできるコンタクトは 4 つだけです。3).

    これら4つの連絡先のスキル要件のみが、 A1のスキルによって完全に満たされています。

  • これら 4 つの連絡先のうち、 QUEUE 2 の連絡先 (つまり C2、C7) が優先されます。これは 、 QUEUE 2 のキュー ランキングが高いためです。

    QUEUE 1 は最もランクの高いキューですが、A1 ではスキル要件が満たされないため、その待機中の連絡先は A1 にルーティングできません。

  • C2C7の間では、最も優先度の高いコンタクトは C7です。したがって、最終的な選択は C7であり、システムはそれを A1にルーティングします。

    これは、 C2 が先にキューに入れられていた場合でも発生します。なぜなら、コンタクトの優先順位がキューに入れられた時間よりも優先されるからです。

混合マルチメディアプロファイル

Webex Contact Centerでは、マルチメディアプロファイルの設定を通じて、エージェントがさまざまなメディアタイプ(音声、チャット、メール、ソーシャルメディア)を通じて顧客対応を行えるようにします。この構成に基づき、エージェントはメディアタイプごとにチャネルをプロビジョニングされます。

エージェントにルーティングされたすべての問い合わせは、エージェントがその問い合わせに対応している間、そのメディアタイプのチャネルを1つ消費します。エージェントは音声チャネルを1つしか持つことができませんが、その他のメディアタイプのチャネルは最大5つまで持つことができます。

マルチメディアプロファイル のブレンドルーティング設定を使用すると、管理者は各エージェントに対して異なるチャネルを同時に使用する方法を制御できます。これにより、組織は顧客一人ひとりにきめ細やかな対応を行うことが可能になり、サービスの質の向上、顧客体験の改善、コンバージョン率の向上につながります。また、組織は一部のチャネルで負荷の偏りが発生した場合に、メディアチャネル間で負荷を分散させることで、エージェントの効率的な利用を可能にすることができます。

選択肢は3つあります。

  • 限定

  • 混合

  • ブレンドリアルタイム

音声通話以外の問い合わせに対応する場合、エージェントは音声チャネルが利用可能であれば、エージェントデスクトップから手動で発信通話を開始できます。これは、すべてのマルチメディアプロファイルタイプに適用されます。

マルチメディア プロファイルの設定に関する詳細については、 マルチメディア プロファイルの管理を参照してください。

ルーティングパターン

スキル ベース

Webex Contact Centerのスキルベースのルーティングパターンは、言語能力や技術的な専門知識など、問い合わせを解決するために必要な特定のスキルに基づいて、顧客からの問い合わせをエージェントに振り分けます。これらのパターンにより、各顧客は最も適任の担当者につながることができ、サービス効率と顧客満足度が向上します。メリットとしては、処理時間の短縮、解決率の向上、そしてエージェントの専門知識を顧客ニーズに合わせることでエージェントのリソースを最適に活用できることなどが挙げられます。

スキルベースルーティングでは、エージェントがスキルプロファイルから取得するスキルと、エージェントに直接割り当てられる動的スキルを使用できます。動的スキルとは、エージェントのスキルプロファイルとは独立して変化しうるエージェントの属性を表します。

スキルベースのルーティングパターンを使用する場合、まず、コンタクトのスキル要件(フローで割り当てられる)またはキューに割り当てられたスキル基準を使用して、これらの要件を満たすスキルと動的スキルを持つ利用可能なエージェントをフィルタリングします。 / 基準を完全に満たす。次に、フィルタリングされたエージェントの中から、設定されたルーティングパターンに基づいて、その連絡先に対して1人のエージェントが選択されます。

最適なルーティングの場合、熟練度スキルと熟練度ダイナミックスキルは、エージェント選択に使用されるスコアに影響を与えるために重み付けを使用することもできます。重みは最長利用可能ルーティングには影響しません。このパターンは、エージェントの適格性を判断するためにスキルと動的スキルのみを使用します。

最も長く利用可能

最長利用可能スキルベースのルーティングパターンは、コンタクトのスキル要件を満たすスキルを持つエージェントにコンタクトをルーティングします。 / キューのスキル基準を完全に考慮し、そのキュー内のすべての対象エージェントの中で、前回の問い合わせ対応から最も長く待機しているエージェントを選択します。

このルーティングパターンは、最も長く対応可能なエージェントにインタラクションを割り当てることで、エージェント間で作業を均等に分散させ、ワークロードの偏りを防ぐのに役立ちます。これは業務配分の公平性を維持するのに役立ち、特定の担当者だけが過重な負担を強いられることなく、他の担当者が自由に業務を行えるようにします。

上記の例では、熟練度と非熟練度のスキルを持ち、熟練度スキルの値がそれぞれ異なる4人のエージェントが存在します。

「最長利用可能」ルーティングパターンを持つスキルベースのキューにキューイングされたコンタクトを考えてみましょう。

  • 上記のスキル要件がフローによって割り当てられる、または
  • 上記のスキル基準がスキルベースのキューに設定されている

このシナリオでは:

このルーティングパターンは、以下の種類のスキルベースキューでサポートされています。

最良の入手可能品

最適なスキルベースのルーティングパターンにより、顧客とのやり取りは、利用可能な中で最も適任なエージェントに確実に振り分けられます。このパターンでは、エージェントに必要なスキルが備わっているかどうかだけでなく、それらのスキルの習熟度も評価し、スキルスコアを計算して、各問い合わせに対して最も適任な(「最適な」)エージェントを決定します。

このパターンは、コンタクトスキル要件を満たすスキルを持つ利用可能なエージェントをフィルタリングします。 / キューのスキル基準を完全に満たす。次に、コンタクトスキル要件に記載されているすべてのスキルの熟練度値を使用して、対象となるエージェントごとにスコアが計算されます。 / キューのスキル基準。スキルスコアが最も高いエージェントが、各問い合わせに対する「最適な」エージェントとみなされます。

実質的に、接触スキル要件に合致するエージェントのスキル値の合計 / キューイングスキル基準によってスコアが決まります。

理解しておくべき重要なポイントをいくつかご紹介します。

  • 通常、スコア計算には実際のスキル値が使用されます。なぜなら、スキルスコアが高いほど、より強いマッチングを示すからです。ただし、スキル要件が以下( < =) 条件として、エージェントの特定のスキル値がスコア計算で反転される、つまりeffective_skill_value = (10)マイナス(actual_skill_value[] )[] 。これは、スコアが低いほど相性が良いことを示すために行われます。
  • 複数の適格エージェントのスコアが同じ場合、その中で最も長く利用可能なエージェントが選択されます。
  • スコア算出においては、習熟度のみが考慮されます。連絡先スキル要件に含まれるブール値、テキスト、または列挙型のスキル / キューイングスキル基準はスコア計算には考慮されません。

上記の例では、熟練度スキルと非熟練度スキルを持ち、熟練度スキルの値がそれぞれ異なる4人のエージェントが存在します。

「ベストアベイラブル」ルーティングパターンを持つスキルベースのキューにキューイングされたコンタクトを考えてみましょう。

  • 上記のスキル要件がフローによって割り当てられる、または
  • 上記のスキル基準は、スキルベースのキューで設定されます。

このシナリオでは:

このルーティングパターンは、以下の種類のスキルベースキューでサポートされています。

スキルベースではないルーティング

Webex Contact Centerは、エージェントの特定のスキルや専門知識を考慮せずに、着信した顧客とのやり取りを分配することに重点を置いた、スキルベースではないさまざまなルーティングパターンもサポートしています。スキルベースのルーティングパターンとは異なり、これらはエージェントのスキルを考慮せず、コンタクトやキューでスキル要件を定義する必要もありません。 / ルーティングの基準。むしろ、彼らは可用性、ワークロードの配分、事前定義されたシーケンスなどの要素を優先し、個々のエージェントの能力ではなく、運用ロジックに基づいて問い合わせを効率的に処理できるようにしている。これらのパターンは、相互作用が比較的均一であったり、特別な処理を必要としない環境において特に有用です。

最も長く利用可能

「最長利用可能時間」ルーティングパターンは、キューに関連付けられているすべてのエージェントの中で、前回の問い合わせを処理してから最も長い時間利用可能なエージェントに問い合わせをルーティングします。

このルーティングパターンは、最も長くアイドル状態にあるエージェントにインタラクションを割り当てることで、公平かつバランスの取れたワークロードの分散を保証します。ワークロードの不均衡を防ぐことで、特定のエージェントに過負荷がかかることなく、他のエージェントが自由に作業できる状態を維持します。このアプローチは、顧客との接触が安定している期間に特に効果的であり、エージェント全体にわたって一貫した関与を維持するのに役立ちます。

エージェントは、あらゆるメディアタイプのコンタクトを提示されると、すべてのチャネルにおいて「最も長く利用可能な」ポジションを失う。これは、エージェントが問い合わせを処理した後、キューに登録されているあらゆるメディアタイプの次の問い合わせは、そのキュー内で次に利用可能なエージェントに割り当てられることを意味します。

上記の例では、エージェント A1 が最も長く利用可能なエージェント(位置1)です。これは、このエージェントが最初にログインしたか、他のどのエージェントよりも長くコンタクトが割り当てられていないかのいずれかです。

エージェント A2 (ポジション2)と A3 (ポジション3)も利用可能ですが、ログイン済みであるか、 A1以降のコンタクトを処理しています。すべてのエージェントは、このルーティングパターンを持つ両方のキューに関連付けられています。

次のシナリオを考えてみましょう。

  • 時刻 T0において、音声コンタクト C1 がキューに入れられ、最も長く利用可能なエージェントにルーティングされます。A1.

    A1C1 [が割り当てられたことにより、 A1 はすべてのメディアチャネルにおいて最も長く利用可能なエージェントではなくなりました。

  • 時刻 T1に、チャットの問い合わせ C2 がキューに追加され、現在最も長く利用可能なエージェントである A2にルーティングされます。
  • 最後に、時刻 T2で、別の音声コンタクト C3 がキューに追加され、 A3にルーティングされます。

    A1A2 は最近連絡を取ったが、現時点では A3 が最も長く待っている。

Webex Contact Centerは高度に分散されたアーキテクチャを採用しているため、複数の問い合わせが同時に同じキューにキューイングされた場合、最も長く対応可能なエージェント1人が複数の問い合わせに対応する可能性がわずかにあります。

このルーティングパターンは、以下のタイプのスキルベースではないキューでサポートされています。

円形

循環ルーティングパターンは、着信コンタクトを利用可能なエージェントのグループにラウンドロビン方式で分配します。問い合わせがキューに追加されると、システムは事前に定められた順序に基づいて、キュー内で次に利用可能なエージェントに問い合わせを割り当てます。

プロセスは、設定された順序でエージェントを実行することから始まります。最初の着信は、その順番で最初に利用可能なエージェントに割り当てられます。以降の問い合わせについては、システムは次に利用可能なエージェントを選択し、定義されたキュー順序に従って前回の問い合わせから処理を再開します。このパターンは繰り返され、エージェントが順番に切り替わりますが、常に最後に選択されたエージェントの位置から開始されます。

この方法は、担当者間で顧客情報を公平かつ均等に分配するのに効果的です。これにより、特定の担当者が問い合わせ対応に追われることがなくなり、すべての担当者が公平に、かつ一貫して顧客対応を行う機会を得られるようになります。しかし、循環ルーティングパターンは、現在のワークロードや、エージェントが特定の問い合わせを処理する能力に影響を与える可能性のあるその他の要因を考慮していません。

上記の例では、エージェントは循環キュー内で次の順序で構成されます。A3 → A4 → A5 → A6 → A1 → A2.

まず、開始位置は設定された順序の最初のエージェントです(A3)。問い合わせがこのキュー内のエージェントにルーティングされると、位置は円周上を移動し、最後に問い合わせがルーティングされたエージェントの次に設定されている順序で次のエージェントに配置されます。

次のシナリオを考えてみましょう。

  • 最初のコンタクト(C1)はキューに入れられ、エージェント A3にルーティングされます。

    ポインタは、設定された順序で次のエージェントに更新されます。A4.

  • 2 番目のコンタクト (C2) がキューに入れられると、システムは A4 から利用可能なエージェントの検索を開始します。A4 → A5 → A6 → A1 → A2 → A3.

    しかし、 A4A5 は利用できません(ログインしていないか、アイドル状態か、このメディアタイプの他の連絡先で完全にビジー状態です)。そのため、 C2 は次に利用可能なエージェントである A6にルーティングされます。ポインタは、設定された順序で次のエージェントに更新されます。A1.

  • 同様に、3 番目の接点 (C3) は A1にルーティングされ、4 番目の接点 (C4) は A2にルーティングされます。ポインタは再び A3 の位置にあります。

    この論理は続き、連絡先は「循環」内の利用可能なエージェントに分配されます。 / 「ラウンドロビン」方式。

待機中の連絡先がキューにある場合、エージェント余剰シナリオでは、このメディアタイプで次に利用可能になったエージェントが、それらの連絡先の中で最も優先順位が高く、最も古い連絡先とマッチングされます。

これは、このキュー内の既存の位置値を考慮したり、影響を与えたりするものではありません。位置値は、コンタクト余剰ルーティングがエージェントと正常に一致した場合にのみ更新されます。

このルーティングパターンは、以下のタイプのスキルベースではないキューでサポートされています。

トップダウン

トップダウン型のルーティングパターンでは、着信した問い合わせを、利用可能なエージェントのグループに順番に分配します。問い合わせがキューに追加されると、システムは常にエージェントの順序付きリストを最初から順にたどり、その順序の中で最初に利用可能なエージェント(問い合わせのメディアタイプに対応する空きチャネルを持っているエージェント)と問い合わせをマッチングします。

これは、キューに登録されたすべての連絡先に対して発生します。連絡先の照合は、常にリストの最上位(最初に設定されたエージェント)から開始し、一致するエージェントが見つかるまでリストを下方向に進んで行われます。

円形ルーティングパターンとは異なり、最後に選択されたエージェントの位置に基づいて開始点を動的に変更する「ポインタ」は存在しません。

このアプローチは、何らかのバイアスに基づいて順序付けられたエージェント間でコンタクトを分配するのに効果的です。 / 管理者が決定する優先順位。これは、上位のエージェントが下位のエージェントよりも常に優先的に顧客対応を任されるようにするのに役立ちます。しかし、トップダウン型のルーティングパターンでは、現在のワークロードや、エージェントが特定の問い合わせを処理する能力に影響を与える可能性のあるその他の要因は考慮されていません。

上記の例では、エージェントはトップダウンキューで次の順序で構成されます。A3 → A4 → A5 → A6 → A1 → A2.

これは、管理者が、利用可能な場合は最初のエージェント(A3)にすべての連絡をルーティングし、利用できない場合は利用可能な場合は次のエージェント(A4)にルーティングし、その後、設定された順序で同様にルーティングすることを望んでいることを意味します。

次のシナリオを考えてみましょう。

  • 最初のコンタクト(C1)はキューに入れられ、 A3]が順番の最上位にあるため、エージェント A3 ]にルーティングされます。
  • 2 番目のコンタクト (C2) がキューに入れられると、ルーティングは再び順序の先頭 (常に A3から開始) から試行されます。

    A3 がこのメディアタイプに対してより多くのチャネル容量を持っている場合、 C2A3にルーティングされます。ただし、 A3 がこのメディアタイプで完全にビジー状態の場合、ルーティングはリストを下って A4に進みます。

  • しかし、 A4A5 は利用できません(ログインしていないか、アイドル状態か、このメディアタイプの他の連絡先で完全にビジー状態です)。そのため、 C2 はトップダウン順で次に利用可能なエージェントである A6にルーティングされます。
  • 同様に、3 番目の接点 (C3) は、 A3 から下に向かってルーティングされるよう試みられます。最初の一致するエージェントは A1です。

    このロジックは、注文の一番下まで問い合わせに利用可能なエージェントが見つからない場合まで続き、その場合はキューに待機状態になります。

このルーティングパターンは、以下のタイプのスキルベースではないキューでサポートされています。

エージェントベースルーティング

エージェントベースルーティングとは、問い合わせを特定の(「優先」の)エージェントに直接ルーティングまたはキューイングする機能です。エージェントのメールアドレスまたはIDを使用してエージェントを検索すると、問い合わせは希望するエージェントに転送されます。フロー内の「エージェントへのキュー」アクティビティは、エージェントベースのルーティングを実現するのに役立ちます。詳細については、 Queue To Agent アクティビティを参照してください。

連絡先は、1人または複数の優先エージェントにマッピングすることができ、これらは通常、Webex Contact Center以外の外部アプリケーションで管理されます。連絡先の優先エージェント検索は、 HTTP リクエスト アクティビティを介して行われ、外部アプリケーションからマッピングを取得します。コンタクトを希望のエージェントにルーティングまたは保留するには、エージェントの Webex Contact Center ID またはメールアドレスを使用して、[エージェントへのキュー] アクティビティを設定します。また、優先エージェントがすぐに対応できない場合は、そのエージェントに連絡を保留することもできます。

エージェントベースルーティングは、次のようなシナリオで役立ちます。

  • 優先エージェントルーティング: 顧客は、担当者を専任のエージェントまたはリレーションシップ・エグゼクティブに割り当てることができます。このような場合、エージェントベースルーティングは、問い合わせを優先エージェントに直接ルーティングします。
  • 最後のエージェントルーティング: 顧客がオペレーターとやり取りするためにコンタクトセンターに複数回電話をかけた場合、エージェントベースルーティング機能を使用すると、その顧客を最後に対応したオペレーターに振り分けることができます。

どちらの利用ケースにおいても、連絡先の詳細とエージェントのマッピング情報は、Webex Contact Centerの外部に保存されます。

Flowにおけるキューイングおよびルーティング機能

Flowにおけるキューイングおよびルーティング機能

Webex Contact Centerでは、フローを通じて、ルーティング、キューイング、通話制御など、幅広い機能を連携させることができます。

フローデザイナーで提供されるさまざまなフローアクティビティとイベントハンドラーをフロー内に配置することで、受信および送信コンタクトのライフサイクルを効果的に管理できます。

フローの設定と使用方法の詳細については、 フローデザイナーを使用してフローを構築および管理するを参照してください。

キューイングアクティビティ

キューコンタクト

キューコンタクトアクティビティを使用すると、組織からのアクティブな受信キューに連絡先をキューに追加して、そのキュー内の適切なエージェントにマッチングおよびルーティングすることができます。

このアクティビティを通じて、キューイングの以下の側面を管理できます。

  • 優先度 - キューに入れられる連絡先に、1 (最高) から 10 (最低、デフォルト) までの階層的な重要度を割り当てます。
  • スキル要件 - スキルベースのキューでエージェントがコンタクトのルーティング対象とみなされるために満たす必要のあるスキル基準を設定します。
  • スキル緩和 - エージェントを見つける可能性を高めるために、一定期間後に以前に設定されたスキル要件を調整、変更、または削除します。
  • エージェントの空き状況を確認する - 待機時間を回避するために、利用可能なエージェントが見つからないすべてのコール分配グループをシステムが即座に拡大できるようにします。

優先順位、スキル構成、エージェントの可用性がコンタクトのルーティングにどのように影響するかについての詳細は、 ルーティングを参照してください。

連絡先キューアクティビティが連絡先を正常にキューに追加すると、

  • 該当するエージェントが既に利用可能な場合、システムは問い合わせをそのエージェントに転送しようとします。

    これにより メイン フローの実行が中断され、設定されている場合、後続のイベントによって それぞれのイベントフローがトリガーされる可能性があります。

  • 一致するエージェントが見つからない場合、その連絡先はキューに登録され、一致するエージェントが利用可能になるまで待機します。

    その後、フローの実行はキューコンタクトアクティビティの後に添付されたアクティビティへと続き、以下の機能を提供します。

    • 列に並んで待っている顧客に、あらかじめ設定された音楽を再生します。 PlayMusic アクティビティを添付します。
    • 顧客のリクエストに基づいてコールバックを登録するには、 Callback アクティビティを添付します。
    • 再キューイング、つまり現在のキューから連絡先を削除し、新しいキューに追加します。別の Queue Contact または Queue to Agent アクティビティを添付します。

該当するエージェントが利用可能になると、システムはそのエージェントに問い合わせを転送しようとします。

成功すると、 メイン フローの実行が中断され、設定されていれば、後続のイベントによってそれぞれの イベントフローがトリガーされます。

キューコンタクトアクティビティは、以下の場合に機能します。

  • 担当者が割り当てられておらず、担当者へ転送される準備ができています。
  • キュー、スキル、その他のフロー設定は正しく設定されています。
  • 接触回数は、許容される25回の入場ポイントおよびキュー遷移の範囲内に収まっています。
  • 通信は、許可されているルーティング試行回数の上限である20回以内に収まっています。

エラー処理パスを設定して、代替ルーティングや追加処理が必要な連絡先を適切に管理できるようにします。

このような場合、アクティビティは失敗となり、フローの実行は エラー処理 パスに移動します。

スキル要件、スキル緩和、エージェントの空き状況確認などの機能は、チーム割り当てのあるキューが選択されている場合にのみ、キュー連絡アクティビティで利用できます。

アクティビティ設定、使用方法、出力変数に関する詳細については、 フローの構築と管理を参照してください。 > 連絡先をキューに追加します

エージェントにキューイング

「エージェントへのキュー」アクティビティを使用すると、Webex Contact Centerでエージェント固有のIDまたはメールアドレスを検索することで、問い合わせを希望のエージェントに直接キューイングできます。

このアクティビティを通じて、キューイングの以下の側面を管理できます。

  • 優先度 - アサイン higher/lower 同じエージェントに対してキューに入れられているコンタクトにとっての重要性。
  • レポートキュー - 録音やデフォルトのキュー内の音楽などの設定に使用するキュー、および連絡先のレポート目的を指定します。
  • リカバリーキュー - 連絡先が指定された優先エージェントにルーティングできなかった場合に、フォールバックとして使用するキューを指定します。

エージェントへのキューアクティビティがコンタクトを正常にキューに入れると、

  • 担当者が既に対応可能な場合は、問い合わせは担当者に転送されます。

    これにより メイン フローの実行が中断され、設定されている場合、後続のイベントによって それぞれのイベントフローがトリガーされる可能性があります。

  • 担当者が対応可能な場合でも、拒否、応答なし、または連絡を受け取れなかった場合は、指定された復旧キューに移動されます。

    復旧キューでは、問い合わせはスキルサポートなしで、最も長く対応可能なエージェントにルーティングされます。

  • エージェントが不在で Park Contact If Agent Unavailable」オプションが選択された場合は、連絡先は保留状態になり、エージェントが対応可能になるまで待機します。

    その後、フローの実行は「Queue To Agent」アクティビティの後に続くアクティビティへと進み、以下の機能を実現します。

    • 列に並んで待っている顧客に、あらかじめ設定された音楽を再生します。 PlayMusic アクティビティを添付します。
    • Callback 活動。
    • 再キューイング、つまり現在のキューから連絡先を削除し、新しいキューに追加します。別の Queue to Agent または Queue Contact アクティビティを添付します。

    エージェントが利用可能になると、システムは問い合わせをエージェントに転送しようとします。

    これにより メイン フローの実行が中断され、設定されている場合、後続のイベントによって それぞれのイベントフローがトリガーされる可能性があります。

  • エージェントが利用できない場合、かつ「Park Contact If Agent Unavailable」オプションが 選択されていない場合、キューイングは失敗します。

キューからエージェントへのアクティビティは、次の場合に機能します。

  • 担当者が割り当てられておらず、担当者へ転送される準備ができています。
  • ご希望のエージェントIDまたはメールアドレスは有効です。
  • レポートキューとリカバリーキューは正しく設定されています。
  • 担当エージェントがログインしており、対応可能で、連絡を受ける準備ができています。

優先エージェントが不在の場合でも、問い合わせがスムーズにルーティングされるように、リカバリーキューを設定してください。

このような場合、アクティビティは失敗となり、フローの実行は エラー処理 パスに移動します。

アクティビティ設定、使用方法、出力変数に関する詳細については、 フローの構築と管理を参照してください。 > エージェントにキューイングします

エスカレーションコール配信グループ

エスカレートコール分配グループアクティビティは、チーム割り当て[ を持つキューでのみサポートされており、設定された待機期間後に次のグループへの自動拡張更新が行われるのを待つのではなく、連絡先の コール分配グループ を即座に更新する機能を提供します。これにより、問い合わせ内容を待機中のすべての担当者へ迅速に振り分けることができます。

エスカレーションコール配信グループアクティビティを使用すると、連絡先を次のグループにエスカレーションできます。

  • 次のグループ— 次の通話配信グループに追加されたチームを含めるように、チームのセットを拡張します。
  • 最後のグループ—キュー用に構成されたすべてのコール分配グループにマッピングされたすべてのチームを含むようにチームのセットを拡張します。

エスカレーションコール配信グループアクティビティは、以下の場合に機能します。

  • 問い合わせは既にキューに登録されており、エスカレーションの準備ができています。
  • その問い合わせは、通話分配グループを使用するキューに登録されます。

標準ルーティングを使用するキューについては、キューに設定されているルーティング動作に従って、引き続き連絡先を配信してください。

このような場合、アクティビティは失敗となり、フローの実行は エラー処理 パスに移動します。

例えば、ある連絡先が3つの通話分配グループを持つキューにキューイングされ、各グループが30秒ごとに更新されるというシナリオを考えてみましょう。

CDG 1CDG 2のチームにはエージェントがいませんが、最後の通話配信グループに属する TEAM 3 にはエージェントが1人います。

フロー内でエスカレーションコール分配グループアクティビティを使用しない場合、以下に示すように、待ち時間が長くなります。

待機時間を短縮するには、エスカレーションコール分配グループアクティビティを以下のように使用します。

次のグループ または 最後のグループ オプションを選択すると、以下に示すように、連絡待ち時間が大幅に短縮されます。

アクティビティ設定、使用方法、出力変数に関する詳細については、 フローの構築と管理を参照してください。 > コール配信グループをエスカレーションします

キュー情報アクティビティ

キュー情報を取得する

「キュー情報取得」アクティビティは、次のような特定の連絡先のリアルタイムのキュー情報を取得する機能を提供します。

  • 連絡先の現在のキュー内位置(PIQ)、またはまだキューに登録されていない場合の潜在的な位置。
  • タスクが応答されるまでキューで待機すると推定される時間(EWT)または期間。
  • 連絡先の現在のコール配信グループ内で、ログインしている、または利用可能なエージェントの数。
  • 選択したキューのすべてのコール分配グループにおいて、ログインしている、または利用可能なエージェントの数。
  • キューの中で最も古い連絡先が待機している期間。

これらの詳細は、フロー実行時にアクティビティ出力変数として利用可能になります。

アクティビティの使用方法、各キューの詳細の詳細な定義と計算方法の詳細については、 フローの構築と管理を参照してください。 > キュー情報を取得します

キュー情報の利用方法としては、以下のようなものがあります。

  • 顧客が担当者への振り分けを待っている間、担当者の順番と推定待ち時間を顧客に知らせる。
  • 推定待ち時間が長すぎる場合に、顧客へのコールバックを登録できるかどうかを判断する。
  • 現在のコール分配グループ(CDG)に割り当てられたチームにエージェントがいない場合、その問い合わせを次のCDGにエスカレーションします。

「キュー情報取得」アクティビティは、選択された変数が有効なキューに解決された場合に機能します。

選択した変数の検証が必要な場合や、利用可能なキューに解決されない場合に適切に処理できるよう、エラー処理パスを設定します。

以下のケースでは、現在のコール分配グループのリアルタイムキュー情報は適用されません。
  • 「キュー情報取得」アクティビティが実行される時点では、連絡先は(まだ)キューに追加されていません。
  • 問い合わせは、通話分配グループの概念をサポートしていないキューに格納されます。

これらの場合、出力フィールドの値が-1であることは、この情報が適用できないことを示しています。

顧客が待ち行列で15秒経過するごとに、待ち時間が長いことを通知するシナリオを考えてみましょう。

これは、フロー内の「キュー情報取得」アクティビティを使用して、次のように実現できます。

高度なキュー情報

高度なキュー情報アクティビティでは、特定の連絡先のリアルタイムのキュー情報を取得する機能が提供され、さらに、次のような連絡先のスキル基準も考慮されます。

  • 連絡先の現在のキュー内位置(PIQ)、またはまだキューに登録されていない場合の潜在的な位置。
  • 指定されたスキル基準に一致する、連絡先の現在の通話配信グループ内でログインまたは利用可能なエージェントの数。
  • 指定されたスキル基準に一致する、選択されたキューのすべてのコール分配グループにおいて、ログインしている、または利用可能なエージェントの数。
  • 連絡先が指定されたキューに待機している現在の通話分配グループ。
  • 指定されたキュー内の通話分配グループの総数。

これらの詳細は、フロー実行時にアクティビティ出力変数として利用可能になります。

アクティビティの使用方法、各キューの詳細の詳細な定義と計算方法の詳細については、 フローの構築と管理を参照してください。 > 高度なキュー情報

高度なキュー情報を使用する方法には、次のようなものがあります。

  • 顧客がルーティングを待っている間に、担当者の順番を顧客に通知する。
  • 現在の通話分配グループに割り当てられたチームに、スキル基準に一致するエージェントがいない場合、その問い合わせを次の通話分配グループにエスカレーションします。
  • すべての通話分配グループにおいて、スキル基準に合致するエージェントがログインしていない場合、顧客へのコールバックを登録できるかどうかを判断する。

高度なキュー情報アクティビティは、以下の場合に機能します。

  • キュー情報は、スキル要件がキューレベルのスキル基準としてではなく、フロー内で設定されているキューに対して要求されます。
  • 連絡先が既にキューに登録されている場合、その連絡先が現在キューに登録されているのと同じキューに対して情報が要求されます。
  • 問い合わせはキューに登録され、優先エージェントに直接転送されるわけではありません。

これらの要件を満たさないリクエストを処理するには、エラー処理パスを設定してください。

このような場合、アクティビティは失敗となり、フローの実行は エラー処理 パスに移動します。

スキル基準を満たすエージェントがいないため、顧客に折り返しの電話があることを通知する必要があるシナリオを考えてみましょう。

これは、フロー内で「高度なキュー情報」アクティビティを以下のように使用することで実現できます。

通話制御アクティビティ

発信者番号表示を設定する

「発信者番号設定」アクティビティは、通話中に表示される発信者番号を定義するために使用されます。発信者番号設定アクティビティは、イベントフローの終了を示す終端アクティビティとして、プレダイヤルイベントフローでのみ使用する必要があります。

「発信者番号設定」アクティビティでは、ダイヤル番号識別サービス(DNIS)、操作タイプ、または参加者タイプに基づいて、必要な自動番号識別(ANI)を設定できます。

アクティビティ設定、使用方法、出力変数に関する詳細については、 フローの構築と管理を参照してください。 > 発信者番号を設定します

録画コントロール

録音制御アクティビティは、メニューアクティビティと併用して、発信者から録音の同意を取得するように設計されています。これにより、録画開始前に明示的な同意を必要とする規制や方針への準拠が保証され、この手順がワークフローにシームレスに統合されます。

メニューIVRアクティビティは、ユーザーの同意をブール変数に格納し、それを録音制御アクティビティへの入力として割り当てる必要があります。顧客が同意レポートでユーザーの同意を報告する必要がある場合、同意値は報告可能なグローバル変数に格納する必要があります。あるいは、報告が不要な場合は、ローカル変数を使用することもできます。このアプローチにより、テナントや顧客は、様々な要素を効果的に管理・活用する上で、より高い柔軟性を得ることができます。

このアクティビティがフローに追加されると、ユーザーの同意がテナントレベル、キューレベル、または録画スケジュールレベルの構成設定よりも優先されます。

優先順位は以下のとおりです。

  • フロー内でユーザーの同意が「はい」の場合、テナント、キュー、または録音スケジュールレベルで設定されている録音構成に関係なく、通話は録音されます。
  • ユーザーがアクティビティへの応答として同意しない場合、テナント、キュー、または録音スケジュールレベルで設定された録音構成に関係なく、通話は録音されません。
  • フロー内で録音制御アクティビティが設定されていない場合でも、テナント、キュー、録音スケジュールなどの他のレベルのいずれかで設定が「はい」に設定されている場合、通話は録音されます。
  • フロー内で録音制御アクティビティが設定されておらず、テナント、キュー、録音スケジュールなどのすべてのレベルで設定が「いいえ」に設定されている場合、通話は録音されません。

この録画制御は以下のように図示できます。

さらに、転送時に継続、一時停止再開の有効化、一時停止時間などの録画設定は、テナント、キュー、録画スケジュールレベルなど、既存の階層構造に従って引き続き適用されます。

アクティビティ設定、使用方法、出力変数に関する詳細については、 フローの構築と管理を参照してください。 > 録音コントロール

ブラインド転送

ブラインド転送とは、IVRシステムを通じて問い合わせを効率的に外部のダイヤル番号(DN)に転送するプロセスであり、オペレーターの介入を不要にします。

ブラインド転送機能は、通話を外部または第三者のDNに転送する必要がある場合に使用されます。これは終端処理なので、転送が実行されると処理フローは終了します。

相談のためにフローを実行する場合、ブラインド転送アクティビティはサポートされていません。

アクティビティ設定、使用方法、出力変数に関する詳細については、 フローの構築と管理を参照してください。 > ブラインド転送

ブリッジ転送

ブリッジ転送機能を使用すると、通話フローが通話の制御を維持したまま、連絡先を一時的に外部の宛先に転送できます。外部接続先としては、外部ブリッジまたはインタラクティブ音声応答(IVR)サービスが考えられます。

外部の通話先が通話を終了すると、通話の流れは必要に応じて継続され、例えばエージェントへのキューイングなどが行われる。

ブリッジ転送アクティビティは、連絡先をキューから削除し、サードパーティのIVRまたは自動着信分配(ACD)システムに転送します。サードパーティシステムで問い合わせが処理されなかった場合、元のキューに再キューイングすることで、適切な処理のために問い合わせがワークフロー内に残るようにすることができます。

例えば、コンタクトセンターにWebex Contact Centerのエージェントリソースと、外部のコールセンターまたは構内交換機(PBX)上のエージェントリソースがあるとします。顧客は、Webexコンタクトセンターのエージェントのキューに、短時間(例えば60秒)だけ通話をキューイングしたいと考えています。その期間中に担当者が対応できない場合は、通話は(暗黙的にキューから削除された状態で)外部のコールセンターに転送され、そこで問い合わせが処理されます。

  1. ブリッジ転送アクティビティは、発信コールフローおよびイベントフローではサポートされていません。
  2. 既にエージェントに割り当てられている連絡先は、フローを通じてブリッジ転送することはできません。

アクティビティ設定、使用方法、出力変数に関する詳細については、 フローの構築と管理を参照してください。 > ブリッジ転送

コンタクトを切断

「コンタクトの切断」アクティビティを使用すると、フローから直接アクティブなコンタクトを切断または終了できます。

これはフローに組み込まれた終端アクティビティであり、エージェントの介入なしにコンタクトを終了する際に役立ちます。エラーパスフローや、顧客へのコールバックを登録した後などに適しています。

設定に基づき、このアクティビティを通じて通話が終了した際に、通話後のアンケートまたはフィードバックがトリガーされます。

アクティビティ設定、使用方法、出力変数に関する詳細については、 フローの構築と管理を参照してください。 > コンタクトを切断します。

連絡の優先順位を設定する

「連絡先の優先順位を設定」アクティビティは、連絡先に特定の優先順位レベルを割り当てることができるようにすることで、フロー内での効果的な連絡先優先順位管理を促進します。これにより、特定の問い合わせに対して優先度を高くしたり低くしたりすることが可能になり、担当者が対応可能になった際に、他の待機中の問い合わせと比較して適切に振り分けられるようになります。この柔軟性により、ワークフロー全体を通して連絡先の優先順位付けを正確に制御できます。

優先順位は、1(最高)から9(最低)までの階層的な重要度レベルを割り当てることによって決定されます。優先順位が最も高い連絡は、優先順位の低い連絡よりも先に処理されます。複数の問い合わせが同じ優先順位を持つ場合、最も長く待機している問い合わせが、次に利用可能で対応可能な担当者へ優先的に振り分けられます。このシステムは、優先度の高い問い合わせには迅速な対応を保証すると同時に、優先度が同等の問い合わせについては待ち時間に基づいて公平性を維持する。

  1. 「連絡先の優先順位を設定」アクティビティは、メインフローまたはイベントフロー内の任意の場所に配置できます。
  2. 「連絡先の優先順位を設定」アクティビティがキューイングアクティビティ(「連絡先をキューに入れる」や「エージェントにキューに入れる」など)より前に構成されている場合、その優先順位設定は、後続のキューイングアクティビティで明示的に構成された優先順位によって上書きされる可能性があります。ただし、後続のキューイングアクティビティで優先度が指定されていない場合は、前の「連絡先優先度の設定」アクティビティで設定された連絡先優先度が適用されます。
  3. 逆に、キューイングアクティビティ(「連絡先をキューに入れる」や「エージェントにキューに入れる」など)の後に「連絡先の優先順位を設定」アクティビティが設定されている場合、先行するキューイングアクティビティによって設定された優先順位設定が上書きされます。
  4. 「連絡先の優先順位を設定」機能は、現在、発信連絡先およびキャンペーン連絡先ではサポートされていません。

アクティビティ設定、使用方法、出力変数に関する詳細については、 フローの構築と管理を参照してください。 > 連絡優先度を設定します

コールバックアクティビティ

コールバック

コールバック機能を使用すると、発信者は保留状態で待つ代わりにコールバックをリクエストできるため、待ち時間を短縮し、放棄率を最小限に抑えることで、顧客満足度を大幅に向上させることができます。コールバックアクティビティがアクティブになると、キューにタスクが作成され、利用可能なエージェントが顧客からの電話に折り返し対応できるようになります。

フロー設計者は、通話の発信元である元のキューに連絡先を保持するか、設定に基づいて別のキューに割り当てるかのいずれかをアクティビティに設定できます。コールバックが元のキューに残る場合、コンタクトは位置、スキル、優先度、およびコンテキストデータを維持し、次に利用可能なエージェントへのシームレスな割り当てが可能になります。ただし、別のキューが選択された場合、その連絡先は選択されたキューの末尾に、スキル情報なし、デフォルトの優先度で移動されます。

また、この機能により、顧客は希望する担当者からの折り返し電話をリクエストできるため、よりパーソナルな体験を提供し、顧客満足度を高めることができます。これは、コールバックアクティビティがフロー内でQueueToAgentアクティビティの後に続く場合に実現できます。さらに、コールバックアクティビティでは、コールバック処理中に使用される自動番号識別(ANI)をカスタマイズするためのオプション設定が提供されます。このカスタマイズはブランドの一貫性を保つのに役立ち、認識しやすい発信者番号を表示することで、通話拒否の可能性を低減します。

フローデザイナーは、イベントフローにCallbackFailedイベントを含めるオプションを選択できます。このイベントは、コールバックの試行が失敗したときに発生し、フロー設計者が特定の間隔で再試行を実装できるようにします。再試行間の遅延時間または間隔は、待機アクティビティを使用して設定できます。最小再試行間隔は10秒、最大再試行間隔は72時間です。このシステムは、待機アクティビティを使用して、最大14日間で最大10回の再試行をサポートします。

アクティビティ設定、使用方法、出力変数に関する詳細については、 フローの構築と管理を参照してください。 > 折り返し電話

コールバックのスケジュール設定

スケジュールされたコールバック機能により、顧客は特定の将来の日時を指定してコールバックをリクエストできるという利便性をフローに提供でき、エージェントにすぐに接続する必要がなくなります。この機能は、顧客が都合の良いコールバック時間帯を選択できるようにすることで、顧客体験を向上させ、体感待ち時間を最小限に抑え、通話放棄率を低下させます。

このフローは、DTMFプロンプトを介して、希望する日時などの呼び出し元の入力を取得し、必要な入力検証を実行した後、アクティビティに渡す必要があります。

開始する前に、コントロール ハブの チャネル設定コールバックのデフォルト エントリ ポイント が設定されていることを確認してください。詳細については、 コールバックエントリポイントの設定を参照してください。

コールバックは、着信キューでも発信キューでも、どの電話キューを使用してもスケジュールできます。最良の結果を得るには、スケジュールされたコールバックアクティビティの直後に切断アクティビティを追加して、コールバックがスケジュールされた後に現在の通話が適切に終了するようにすることをお勧めします。IVRコールバックのスケジュール設定の詳細については、 IVRコールバックのスケジュール設定を参照してください。

コールバックが指定された将来の日時になると、新しい呼び出しまたはインタラクションが作成されます。この新しいインタラクションは、コールバックのデフォルトエントリポイントにリンクされた標準的なフローに従います。コールバックの試行が失敗した場合、そのフローで設定されている場合は、 CallbackFailed イベント ハンドラーを使用して、フローが自動的に呼び出しを再試行できます。

アクティビティに入力値を渡す前に、以下の入力検証を考慮する必要があります。

  1. 日付選択—今日から31日後までの任意の日付を選択できます。日付は次の形式で入力してください。YYYY-MM-DD(例:2025-07-18)。
  2. 時間帯の開始時刻と終了時刻—選択する時刻は、現在時刻から少なくとも30分後から開始する必要があり、30分から8時間の間であればどの時間帯でも構いません。24時間形式( 14:30:00など)を使用してください。
  3. タイムゾーン—適切な時間にお電話できるよう、IANA形式( America/New_Yorkなど)で有効なタイムゾーンを入力してください。

参照実装として、アクティビティで使用されるDTMFプロンプトと基本的な検証を実証するためのサブフローテンプレートが提供されます。詳細については、 スケジュールされたコールバックサブフローテンプレートを参照してください。

通話進捗状況分析

通話進行状況分析(CPA)機能により、コールバック通話における自動応答システムと人間の音声を検出できます。

コールバック試行時に留守番電話検出(AMD)またはボイスメールが検出された場合、システムはその通話を失敗と認識します。留守番電話検出(AMD)の結果は、CallbackFailed イベントハンドラの reason 出力変数に格納されます。この出力変数に基づいて、フロー設計者はコールバックの再試行を設定できます。

  1. コールバックを円滑に行うため、CallProgressAnalysisはメインフロー内のCallbackアクティビティの後に配置できます。スケジュールされたコールバックまたは個人向けスケジュールされたコールバックの場合は、メインフローの NewPhoneContact の後に配置できます。
  2. イベントフローにおいては、CallbackFailed イベントハンドラでのみサポートされています。
  3. 通話後の顧客アンケート(フィードバック活動)がフロー内で設定されている場合、通話がAMDまたはボイスメールで応答された場合は、アンケートは開始されません。これにより、不要なアンケートの実施を防ぐことができます。

アクティビティ設定、使用方法、出力変数に関する詳細については、 フローの構築と管理を参照してください。 > 通話進捗分析

キューイング

概要

Webex Contact Center では、キューは電話、チャット、電子メール、ソーシャル チャネルなどの着信インタラクションの保留領域として機能します。 連絡先は、エージェントに自動的に配布されるか、エージェントが手動で処理のためにピックアップするまで、キュー内に保管されます。 さらに、スキルベースのルーティング、優先度管理、公平なワークロード分散などの機能もサポートしています。

スーパーバイザーはキューを使用してさまざまな作業ラインを観察し、コンタクト センターでのタスクの処理方法を改善できます。

キューを効果的に使用することによる主な利点は次のとおりです。

  • 顧客体験の向上: 待ち時間を管理し、顧客にサポートを受ける順番が来ていることを知らせます。
  • 効率性の向上: 混乱や不適切な管理を減らし、通話が秩序正しく処理されるようにします。
  • 連絡先の公平な分配: エージェント間で通話を均等に分散し、単一のエージェントに過度の負担がかからないようにします。
  • 優先処理: VIP 顧客や緊急の問題など、特定の通話を優先できるようにします。

キューの種類

Webex Contact Center は、均一な機能を持つすべてのメディア タイプにわたって、あらゆる規模と複雑さのコンタクト センターでさまざまなユース ケースを可能にする複数のタイプのキューをサポートしています。

連絡先をルーティングする際にエージェントのスキルを考慮するキューと考慮しないキューがあります。 これらのキューは、コンタクトを処理するためにエージェントがキューに関連付けられる方法の点でも異なります。

キューには、大きく分けて 2 つのカテゴリがあります。

  • スキルベースではないキュー
  • スキルベースのキュー

スキルベースではないキュー

非スキルベースのキューでは、エージェントに関連付けられたスキルは考慮されません。 非スキルベースのキューは、次のオプションを使用して設定できます。

  • チームの割り当て
  • エージェントの割り当て

チーム割り当てによるスキルベースではないキュー

チーム割り当てによる非スキルベースのキューでは、エージェントをチームに編成し、これらのチームを組み合わせてコール分配グループ (CDG) を形成できます。 通話フローを管理するために、各グループ間の時間遅延を設定できます。

コール分配グループは、設定された時間間隔でこのキュー内の連絡先を処理する資格を持つ複数レベルのエージェントを定義するのに役立ちます。 連絡先は、チームのレベルに基づいてエージェントに割り当てられます。 対応可能なエージェントがいない場合は、連絡先は事前設定された期間保留され、その後拡張されて次のチーム グループが含まれます。 このプロセスは、エージェントが利用可能になるか、すべてのグループがチェックされるまで続行されます。

次のタイプのチームを設定できます:

  • 個人チーム: エージェントは、特定の組織機能を表すチームに編成することができ、その後、キューの一部となり、問い合わせをこれらのチーム内のエージェントにルーティングできるようになります。 エージェントを複数のチームにタグ付けして、さまざまなキューからの問い合わせを処理し、効率的なルーティングを行うことができます。
  • 能力ベースのチーム: 容量ベース チーム (CBT) は、音声通話を容量ベースの直通番号 (DN) に転送する機能です。容量によって、同時に処理できる通話数が決まります。 エージェントがシステムにサインオンしなくても電話番号に通話をルーティングできるため、従来のコール センター エージェントではなく、ボイスメール、留守番電話、またはハント グループで通話に応答するシナリオに適しています。 この設定では、チームに特定のエージェントは割り当てられておらず、Webex Contact Center Agent Desktop.は使用されません。

Webex Contact Center における、チーム割り当てによる非スキルベース キューの仕組みを示すワークフロー図

この例では、ターゲットの拡張が可能な 3 つのコール配布グループがあり、設定された時間間隔でチーム全体のより多くのエージェントに拡張できます。

最初のコール分配グループには TEAM 1 が含まれており、これには A1、A2、A5 の 3 つのエージェントが構成されています。

2 番目のコール分配グループには TEAM 2 が含まれており、これには A2、A3、A4 の 3 つのエージェントが構成されています。

3 番目 (そして最後) のコール分配グループには、A6 と A7 の 2 つのエージェントが設定された TEAM 3 が含まれています。

連絡先がキューに入れられると、システムはまず最初のコール分配グループ内で一致するエージェントを検索します。 エージェントが見つからない場合、次のグループへのターゲット拡張が行われる前に、連絡先は設定された期間パークされます。 これにより、既存のチームに新しいチームが追加されます。 このプロセスは、一致するものが見つかるか、すべてのグループが展開されるまで繰り返されます。

「エージェントの可用性をチェック」という機能により、現在のグループ内に一致するエージェントが見つからない場合、連絡先はすぐに後続のコール分配グループに拡張されます。 これは、フロー内のキュー連絡先アクティビティ <LINK TO section 3.1.1> で有効にできます。

この設定により、次のシナリオが実現します。

  1. A2 TEAM 1 と TEAM 2 に属します。A2 が Agent Desktop にログインするために TEAM 1 を選択した場合、システムは A2 を TEAM 1 の一部と見なし、したがって最初のコール分配グループのみと見なします。
  2. A5 TEAM 1 に属していますが、現在ログインしている組織内の他のチームに属している可能性もあります。したがって、A5 は TEAM 1 の一部とはみなされず、このキューに関連付けられません。

チーム割り当てのあるキューは、ログイン時にチームを選択するだけでエージェントがキュー間を移動できる強力な機能を提供します。

利用可能なルーティングパターン:

エージェント割り当てによる非スキルベースのキュー

非スキルベースのキューは、エージェントのプールがキューに直接割り当てられるタイプのキューです。 割り当てられたエージェントのプールを間接的に決定する他のキュー タイプとは異なり、これらのキューでは管理者がエージェントを直接手動で選択できます。 たとえば、チームベースの割り当てキューは、ログインしているチームに基づいてエージェントを割り当て、スキルベースの割り当てキューは、必要なスキルに基づいてエージェントをマッチングします。 対照的に、管理者はエージェントをこれらのキューに直接追加してキューの一部にすることができます。 これにより、システム主導の割り当てに依存せずにエージェントの割り当てを管理する簡単な方法が提供されます。

エージェント割り当てを備えたキューは、エージェントのプール間での連絡先の分散に役立つ、シンプルでありながら効果的なルーティング アルゴリズムを提供します。 連絡先をルーティングする際にエージェントのスキルが考慮されません。 ただし、各キュー内でエージェントを順序付けすることができ、コンタクトをエージェントにルーティングするときにこれが考慮されます。 このコンテキストでは、チームは、キュー管理を簡素化するエージェントとキューの関連付けやコンタクト ルーティングの決定の要素としてではなく、主にスーパーバイザーの組織構成として機能します。

このタイプのキューは、エージェントの静的割り当てとエージェントとキューの関連付けの管理が実行可能かつ運用制御に望ましい場合、およびルーティング アルゴリズムの選択がエージェント間の作業分散に適している場合に最適です。 これらのキューは、いくつかの種類の顧客からの問い合わせに、事前に作成された専門エージェントのセグメントで対応できる専門知識が必要となるシナリオにも特に役立ちます。

ただし、複雑なコンタクト センター組織では、これらのキュー内のエージェントの割り当てを手動で管理することが難しい場合があります。 動的ルーティングとエージェントとキューの関連付けを提供する他のキュー タイプを使用すると、より多くのメリットが得られます。

Webex Contact Center のエージェント割り当てを伴う非スキルベース キューの例がどのように機能するかを示すワークフロー図

この例では、キューには A4、A9、A7 などの特定の順序でマップされたエージェントのセットがあります。 この順序は、着信コンタクトをエージェントに一致させる特定のルーティング アルゴリズムで役割を果たします。 システムは、空き状況と選択されたルーティング アルゴリズムに基づいて、連絡先とエージェントをマッチングします。

チーム割り当てのキューとは異なり、 ターゲット拡大 時間間隔にわたって。 このコンタクトをルーティングできる設定済みエージェントがいない場合は、パーク タイムアウト前にいずれかのエージェントがコンタクトを処理できるようになるまで、コンタクトはキュー内にパークされます。 ターゲット拡張 はこれらのキューには適用されません。

利用可能なルーティングパターン:

スキルベースのキュー

スキルベースのキューは、ニーズを満たす適切なスキルを持つエージェントに連絡先をルーティングする機能を提供します。

次の種類のスキルベースのオプションを設定できます。

キューに割り当てられたスキル基準

管理者はキューにスキル基準を割り当てることができます。 スキル基準を備えたスキルベースのキューにより、管理者は必要なスキルをキュー内で直接設定できます。 直接スキル プロファイルを介してキューの必要なスキルをすべて持つ組織内のすべてのエージェントは、暗黙的にこのキューの一部になります。

この設定により、管理者はスキルに基づいてキューにマッピングされているエージェントをリアルタイムで確認できるようになります。 ボリュームが多い、または少ないなどの状況では、管理者はキューの必須スキルとエージェントのスキル プロファイルを調整して、必要に応じてエージェント プールを拡大または縮小することを検討できます。

このタイプのキューは、コール分配グループ設定がないため、チームがエージェントとキューの関連付けにおいて役割を果たさないという点で、チーム割り当てベースのキューとは異なります。 さらに、フローによって (静的または可変の) 必要なスキルが注入されるチームベースのスキル キューとは異なり、このキューでは必要なスキルが静的に構成されます。 したがって、技術的には、スキルはコンタクト自体ではなくキューの一部です。

キューのスキル基準を完全に満たす組織内のエージェント(直接スキル プロファイルからのスキルを持つ)は、暗黙的にこのキューに関連付けられます。 チームは、これらのキューとエージェントの関連付けにおいて何ら役割を果たしません。 これらのエージェントは、管理および運用の目的で任意のチームに所属できます。

このキューに入れられたすべての連絡先は、キュー自体に定義されたスキル基準を自動的に想定します。 チーム割り当てによるスキルベースのキューとは異なり、個々の連絡先は独自のスキル要件/基準を定義したり上書きしたりすることはできません。

Webex Contact Center でスキル基準を使用したスキルベースキューの動作例を示すワークフロー図

この例では、

  • エージェント A1、A3、および A7 のみがキューに設定されたスキル基準を完全に満たしているため、これらのエージェントのみがこのキューに関連付けられます。
  • 基準を部分的に満たすエージェント A2、A4、A6、または関連するスキルが不足しているエージェント A5 は、このキューに関連付けることはできません。

エージェントのスキル プロファイルを更新してキューのスキル基準を満たすようにすると (再スキル化と呼ばれます)、そのエージェントは自動的かつ動的にこのキューの一部になります。 あるいは、キューのスキル基準自体を更新して、更新されたスキル基準を満たすエージェントの数を増やす (または減らす) と、このキューにエージェントが自動的かつ動的に追加 (または削除) されます。

チーム割り当てのキューとは異なり、時間間隔による ターゲット拡張 という概念はありません。 連絡先が関連付けられているエージェントのいずれにも一致しない場合は、パークタイムアウト前にこれらのエージェントのいずれかが連絡先を処理できるようになるまで、その連絡先はキュー内にパークされます。

スキルベースのキューは、スキルの静的割り当てとキューとエージェントの関連付けの管理が実行可能であり、運用制御に望ましい場合に最適です。 また、ルーティング アルゴリズムの選択がエージェント間の作業分散に適している場合にも適しています。 これらのキューは、さまざまな種類の顧客からの問い合わせに、事前に抽出された専門エージェントのセグメントで対応できる特定のスキルが必要となるシナリオにも特に役立ちます。

複雑なコンタクト センター組織では、各エージェントを手動でリストに追加する必要があり、特に大規模な組織では面倒な、エージェント割り当てのあるキューと比較して、スキルベースのキューでのキューとエージェントの割り当ての管理が簡単である場合があります。

フロー内で割り当てられたスキル要件

フロー内でスキル要件が割り当てられたスキル ベースのキューは、Webex Contact Center 内のチーム割り当てベースのキューの一種であり、一連のチームが複数のレベルで構成され、コール配布グループと呼ばれます。 これらの設定されたチームにログインしているエージェントには、連絡先のスキル要件も完全に満たしている場合、キュー内でチームが設定されているコール分配グループ レベルに基づいて、このキューから連絡先が割り当てられます。

このようなキュー内では、エージェント チームはコール分配グループにグループ化され、その間には設定可能な時間遅延が存在します。 連絡先に対応できるエージェントがいない場合は、リクエストは保留され、遅延後にルーティングが次のコール分配グループに拡張されます。 このプロセスは、エージェントが割り当てられるか、すべてのグループが使い果たされるまで継続されます。 一方、このプロセス中に、以前にチェックしたグループ内のエージェントが利用可能になった場合は、そのエージェントが選択されます。

エージェントは、エージェントに直接割り当てられたスキル プロファイルを通じてスキルを習得します。 エージェントのスキルは、サインイン時のチーム選択に基づいて決定されます。

各連絡先はフロー内でオプションでスキル要件を指定できます。このスキル要件は利用可能なエージェントのスキルと照合され、最適なエージェントが選択されます。

さらに、連絡先は設定された時間間隔でスキル緩和を指定することもできます。 これらは、設定された時間間隔で連絡先の元のスキル要件を上書きする、変更されたスキル要件のセットです。 これにより、連絡先はキューに待機している間にスキル要件を変更 (通常は「緩和」するために使用される) できるため、緩和されたスキル要件に一致するエージェントが増えます。

コール分配グループによるターゲットの拡張は、スキル緩和サイクルと同時に発生する可能性があります。どちらも保留中のコンタクトを適格なエージェントとより迅速にマッチングさせることを目的としており、全体的な待機時間を短縮し、キューのサービス レベルを向上させます。

Webex Contact Center でチーム割り当てによるスキルベースのキューがどのように機能するかの例を示すワークフロー図。

チーム割り当てによる非熟練キューと同様に、設定された時間間隔でチーム全体のエージェントへの拡張 (ターゲット拡張) を可能にする 3 つのコール配布グループがあります。

  • 最初のコール分配グループには TEAM 1 が含まれており、これには A1、A2、A5 の 3 つのエージェントが構成されています。
  • 2 番目のコール分配グループには TEAM 2 が含まれており、これには A2、A3、A4 の 3 つのエージェントが構成されています。
  • 3 番目 (そして最後) のコール配分グループには、A6 と A7 の 2 つのエージェントが設定された TEAM 3 が含まれています。

ただし、注意すべき点が 2 つあります。

  • このキューに入れられるすべての連絡先は、フローを通じてそのスキル要件とスキル緩和を定義します。
  • エージェントは、スキルを構成できます (スキル プロファイルを通じて、直接またはログインしているチームから継承)。

A2 は、TEAM 1 と TEAM 2 の両方に所属するように設定されていますが、このエージェントがログイン時に選択したチームに応じて、現在のセッションではそのチームに所属しているとみなされ、したがって、そのチームのスキル プロファイル (およびスキル値) も継承します (このエージェントの直接のスキル プロファイル設定で上書きされない限り)。

これは、チーム割り当てのあるキューによって提供される強力な機能であり、エージェントはログイン時にチームを選択するだけでキュー間を移動できます。

選択したチームからスキル プロファイル設定を継承する機能と組み合わせることで、エージェントはさまざまなスキル セットで作業することもできます。

この例では、

  • コンタクトは、フローからのエスカレーション中に初期スキル要件 (sk_1 >= 6) でキューに入れられ、設定された時間間隔後にスキル緩和 (sk_1 >= 3) されます。
  • すべてのコール分配グループのすべてのエージェントのうち、キューに入れられたコンタクトの初期スキル要件を満たすスキルを持つのは、A1、A3、A6、および A7 のみです。
  • 残りのエージェントは、スキル (sk_1) を持っていますが、スキル要件を満たしていません (例: チーム 1 では A2、チーム 2 では A4)、またはこのスキルをまったく持っていません (例: チーム 2 では A5、A2)。
  • 時間の経過とともに、スキルが緩和され、さらに A2 と A4 も連絡先の「緩和された」スキル要件を満たすようになりました。

このキューに入れられたすべての連絡先について、システムは最初のコール分配グループ内で、連絡先の現在のスキル要件を完全に満たす一致するエージェントを見つけようとします。 一致するエージェントが見つからない場合、ターゲット拡張が 2 番目のコール分配グループに発生するまで、連絡先は設定された期間パークされます。 2 番目の通話配分グループで構成されているすべてのチームも、最初のグループの既存のチームに追加されます。 ここで、システムは拡張されたグループ内で一致するエージェントを見つけようとします。 この処理が行われている間、スキル緩和により、設定された時間間隔で連絡先のスキル要件も更新され、システムは更新されたスキル要件を使用して、現在のコール分配グループ内の利用可能なエージェントと照合することに注意してください。

一致するエージェントが見つからない限り、構成されたすべてのコール配布グループが拡張され、すべてのスキル緩和が適用されるまで、この処理は続行されます。

利用可能なルーティングパターン:

キュー構成

スキルベースのキューを設定する

キューにスキル基準を割り当てる
  • スキルを作成します。
  • 作成する スキルプロファイル
  • スキル プロファイルをエージェントに直接割り当てます。
  • テレフォニー、チャット、電子メール、ソーシャルのチャネル タイプでキューを作成します。
  • Control Hub のキューにスキル要件を割り当てます。
  • キュー内の連絡先を処理できるエージェントのリストを表示します。
  • ルーティング アルゴリズムとして LAA または BAA を選択します。
  • フローにキュー コンタクト アクティビティを追加し、このキューを選択します。
キューにスキル要件を割り当てる
  1. スキルを作成します。
  2. スキル プロファイルを作成します
  3. スキル プロファイルをエージェントに直接またはチームに割り当てます。
  4. チームを作成します
  5. チームにエージェントを追加します。
  6. テレフォニー、チャット、電子メール、ソーシャルのチャネル タイプでキューを作成します。
  7. 単一の CDG または複数の CDG でチームをキューに追加します。
  8. LAA または BAA のいずれかのルーティング パターンを選択します。
  9. フローにキュー コンタクト アクティビティを追加し、スキル ベース ルーティングが設定されているキューを選択します。 詳細については、「 キュー連絡先」を参照してください。
  10. キュー コンタクト アクティビティでスキルとスキル緩和を割り当てます。
  11. フロー POST キュー内のエスカレート コール配布アクティビティを使用して、次のコール配布グループまたは最後のコール配布グループにすばやく移動します。

スキルベースではないキューを設定する

チームをキューに割り当てる
  • チームを作成します
  • チームにエージェントを追加します。
  • テレフォニー、チャット、電子メール、ソーシャルのチャネル タイプでキューを作成します。
  • 単一の CDG または複数の CDG でチームをキューに追加します。
  • LAA のいずれかのルーティング パターンを選択します。
  • フローにキュー コンタクト アクティビティを追加し、このキューを選択します。
  • フロー POST キュー内のエスカレート コール配布アクティビティを使用して、次のコール配布グループまたは最後のコール配布グループにすばやく移動します。
キューフローにエージェントを割り当てる
  • テレフォニー、チャット、電子メール、ソーシャルのチャネル タイプでキューを作成します。
  • エージェントをキューに直接追加します (注: このタイプのキューではスキルもチームも使用されません)。
  • 循環、線形、最長利用可能エージェントなどのルーティング パターンを選択します。

ルーティング

ルーティングの概念

エージェント余剰シナリオ

エージェント余剰シナリオは、キュー内の連絡先よりも利用可能なエージェントの数が多い場合に発生します。 この場合、顧客とのやり取り (連絡先) がキューに入れられると、システムはこの特定の連絡先に一致するエージェントを直ちに見つけようとします。一致するエージェントが見つかった場合、連絡先をキューに入れたままにして、後で一致するエージェントが対応可能になるまで待つ必要はありません。

コール分配グループを通じて、またはスキル緩和を通じて連絡先が拡張されるたびに、システムはこの特定の連絡先に一致するエージェントを直ちに再度見つけようとします。

特定の連絡先に一致するエージェントを検索するには、キューに設定されたルーティング パターンを使用します。

Webex Contact Center は、さまざまな種類のキューにわたって複数のルーティング パターンを提供します。これにより、組織は待機時間を最小限に抑え、エージェントの作業負荷のバランスを取り、顧客が特定のニーズに対応するために必要なスキルを持つエージェントに接続されるようにすることで、顧客サービスを最適化できます。 ルーティング パターンの詳細については、「ルーティング パターン」セクションを参照してください。

連絡先余剰シナリオ

コンタクト余剰ルーティングは、着信顧客インタラクション(またはコンタクト)の数が対応可能なエージェントの数を超えた場合に発生します。 この状況は、ピーク時や連絡量の予期せぬ急増時によく発生します。 コンタクト余剰ルーティングの主な目的は、このオーバーフローを効率的に管理し、過剰な需要があっても顧客サービスの基準が維持されるようにすることです。 特定のチャネルで対応可能になったばかりのエージェントの場合、コンタクト余剰ルーティングは、このエージェントが関連付けられているすべてのキューのすべての保留中のコンタクトの中から適切なコンタクトを見つけて割り当てるように機能します。

エージェントの可用性が限られている場合にコンタクト ルーティングを効率的に実行するための主な戦略は次のとおりです。

  • キューランキング

    キューのランキングにより、管理者はキューの相対的な重要度を指定できます。 管理者はキューのランキングを定義して、チームごとに、キューからチームにログインしているエージェントに通話がルーティングされる順序を設定できます。

    たとえば、チーム A にログインしているエージェントが、「請求」と「販売」の 2 つのキューに関連付けられているとします。 管理者はキューのランキングを使用して「請求」キューに高いランキングを割り当てることができるため、連絡先がキューに入ると、「請求」からの連絡先は「販売」キューからの連絡先よりも先に、チーム A に属するエージェントにルーティングされます。 これは、「販売」キューに待機している可能性のある、より古く優先度の高い連絡先がある場合でも発生します。これは、「請求」キューのキュー順位が「販売」キューよりも高いためです。 「請求」キューに待機中の連絡先がなくなった場合にのみ、チーム A のエージェントには、関連付けられている「営業」キュー (およびその他のキュー) からの連絡先がルーティングされます。

    キューランキングの重要な特性は次のとおりです。

      • 一部のキューにのみランクが割り当てられている場合は、それらのキュー内の呼び出しが、ランクが指定されていないキュー内の呼び出しよりも優先されます。
      • キューのランキングは、すべてのメディア タイプにわたって最大 50 個のキューに対して設定でき、値は 1 から 50 までの範囲で、最高ランクは 1 になります。
      • 複数のキューに同じランクを割り当てることができます。
      • キューのランク付けを有効にすると、明示的にランク付けされていないキューは、ランク付けされたすべてのキューよりも低い順位で扱われます。
      • キューランキングは同じメディア タイプ内で機能します。

        たとえば、キュー販売がランク 2 の音声メディア タイプのキューであり、キュー請求サポートがチーム A のランク 1 のチャット キューである場合、ランクが 2 であっても、チーム A の音声チャネルで対応可能なエージェントが最初に音声通話を取得します。

        ただし、チーム B に 2 つのチャット キュー (キュー ランク 2 のキュー クレジットカードとキュー ランク 1 のキュー デビット カード) があるとします。この場合、チーム B の対応可能なエージェントには、最初にキュー デビット カードからの問い合わせが提供されます。

      • キューのランキングは、容量ベースのチームには適用されません。

  • 連絡先の優先順位

    連絡先がキューに入れられると、1 (最高) から 10 (最低、デフォルト) の範囲の階層的な重要度を割り当てることによって、その優先度を定義できます。 この優先順位付けにより、組織にとっての重要性、緊急性、または戦略的価値に基づいて、特定の連絡先への対応がより迅速になります。 エージェントが、そのエージェントが関連付けられているすべてのキューのすべての保留中のコンタクトの中から次のコンタクトを処理できる場合、すべてのキューの中で最も優先度の高いコンタクトがそのエージェントにルーティングされます (スキルの一致などの他の基準が満たされている場合)。

    明示的な優先度なしでキューに入れられた連絡先の場合、デフォルトの優先度 10 (最低) が考慮されます。 同じ優先度を持つ複数の連絡先のうち、キュー内で待機している時間が最も長い連絡先が、最初に対応可能で適格なエージェントにルーティングされます。

  • 最長待機コンタクト

    これは、エージェントが関連付けられているすべてのキューの中で最も待機時間が長いコンタクトがエージェントにルーティングされるようにする基本的な戦略です。

    これは、同じキュー ランキングおよび同じ連絡先優先度を持つキュー間で複数の連絡先が処理を待機している場合に、ルーティングされる連絡先を決定する最終的な基準です。

基本的に、対応可能になったばかりのエージェントの連絡先余剰ルーティングは、次の単一の連絡先を選択することを意味します。

  • エージェントが利用可能なメディアタイプと同じメディアタイプである
  • このエージェントが関連付けられているキューのいずれかに待機している
  • このエージェントは、スキル要件(もしあれば)をすべて満たしている
  • エージェントのチームで設定されている他のキューよりもランクの高いキューに駐車されている
  • このようなすべての連絡先の中で最も優先度が高い
  • 同じ優先度のコンタクトの中で最も古い待機中のコンタクトです

連絡先過剰シナリオを示す上記の例では、エージェント A1 が TEAM 1 にログインし、複数のメディア タイプで連絡先を処理できるようになりました。

A1 は 3 つのキューに関連付けられています – 質問 1質問 2 そして 第 3 問チーム 1 キューの順位付けも定義されており、 質問 1 最も高いランクの場合、 質問 2 そして 第 3 問 それぞれ。

これらすべてのキューにはすでに連絡先が登録されており、連絡先ごとにスキル要件と優先度が定義されています。

さて、連絡先余剰シナリオは次のように機能します。

  • これらのキューに保管されているすべてのコンタクトのうち、ルーティングできるのは 4 つのコンタクトのみです。 A1 C2 C7 (QUEUE 2 より)そして C3 C8 (QUEUE 3 より)

    これらの 4 つの連絡先のスキル要件は、 A1

  • これらの 4 つの連絡先のうち、以下の連絡先が優先されます。 キュー 2 (つまり C2、C7) キュー 2 キューの順位が高くなります。

    ただし、 キュー 1 は最高ランクのキューであり、そのパークされたコンタクトのスキル要件が A1 によって満たされていないため、そのコンタクトはいずれも A1 にルーティングできません。

  • C2 そして C7最も優先度の高い連絡先は C7。 それで、最終的な選択は C7システムはそれを A1

    これは、 C2 コンタクトの優先度がキュー時間よりも優先されるため、先にキューに入れられました。

ブレンド マルチメディア プロファイル

マルチメディア プロファイル構成を通じて、Webex Contact Center はエージェントがさまざまなメディア タイプ (音声、チャット、電子メール、ソーシャル) にわたって連絡先に対応できるようにします。 この構成に基づいて、エージェントはメディア タイプごとにプロビジョニングされたチャネルを取得します。

エージェントにルーティングされるすべてのコンタクトは、エージェントがそのコンタクトを処理している間、そのメディア タイプのチャネルを 1 つ消費します。 エージェントが持つことができる音声チャネルは 1 つだけですが、他のメディア タイプのチャネルは最大 5 つ持つことができます。

マルチメディア プロファイル のブレンド ルーティング設定により、管理者は各エージェントで異なるチャネルを同時に使用できる方法を制御できます。 これにより、組織は顧客に細心の注意を払い、より良い Quality of Service、改善された顧客エクスペリエンス、およびより優れたコンバージョン率を促進できます。 また、組織は、一部のチャネルで負荷が不均一な場合にメディア チャネル間で負荷を分散し、エージェントを効率的に利用できるようになります。

選択肢は 3 つあります。

  • Exclusive

  • 混合型

  • ブレンドリアルタイム

音声以外の連絡先を処理する場合、エージェントは、音声チャネルが利用可能であれば、Agent Desktop から手動でアウトダイヤル音声通話を開始できます。 これはすべてのマルチメディア プロファイル タイプに適用されます。

マルチメディア プロファイルの構成の詳細については、「 マルチメディア プロファイルの管理」を参照してください

ルーティングパターン

スキルベース

Webex Contact Center のスキルベースのルーティング パターンは、言語能力や技術的専門知識など、問い合わせを解決するために必要な特定のスキルに基づいて、着信顧客インタラクションをエージェントに誘導します。 これらのパターンにより、各顧客が最も適格なエージェントに接続されるようになり、サービス効率と顧客満足度が向上します。 メリットとしては、処理時間の短縮、解決率の向上、エージェントの専門知識を顧客のニーズに合わせて調整することでエージェント リソースの使用が最適化されることなどが挙げられます。

スキルベースのルーティング パターンを使用する場合、最初に連絡先のスキル要件 (フローで割り当て) またはキューに割り当てられたスキル基準を使用して、これらの要件/基準を完全に満たすスキルを持つ利用可能なエージェントをフィルターします。 次に、フィルタリングされたエージェントの中から、設定されたルーティング パターンに基づいて 1 人のエージェントが連絡先として選択されます。

最長利用可能

最長対応可能スキルベースのルーティング パターンでは、コンタクト スキル要件 / キュー スキル基準を完全に満たし、そのキュー内のすべての対象エージェントの中で最後のコンタクトの処理以降最も長く対応可能なエージェントにコンタクトがルーティングされます。

このルーティング パターンは、最も長く対応可能なエージェントにインタラクションを割り当てることで、作業をエージェント間で均等に分散し、作業負荷の不均衡を防ぐのに役立ちます。 これにより、作業配分の公平性が維持され、エージェントの過負荷を防ぎながら他のエージェントが自由な状態を保つことができます。

上記の例では、熟練スキルと非熟練スキルを持ち、熟練スキル値が異なるエージェントが 4 人います。

「最長利用可能」ルーティング パターンを持つスキルベースのキューに入れられたコンタクトを考えてみます。

  • 上記のスキル要件がフローを通じて割り当てられた場合、または
  • 上記のスキル基準がスキルベースキューに設定されている

このシナリオでは、

  • コンタクト スキル要件 / キュー スキル基準を完全に満たすエージェントのみがルーティング対象となります。 エージェント A1A2A4 のみがコンタクト スキル要件 / キュー スキル基準を完全に満たしています。

    エージェント A3 は対象外です。 キューに割り当てられたスキル基準の場合、 A3 はキューに関連付けられていません。

  • A1A2A4 のうち、最も長く対応可能なエージェントである A1 に問い合わせがルーティングされます。A1 は、A2 や A4 よりも 10 分間対応可能です。

    A1 に連絡先が割り当てられたことにより、 A1 はすべてのメディア チャネルで最も長く対応可能なエージェントではなくなります。

  • まったく同じスキル要件を持つ次のコンタクトは、次に最も長く対応可能なエージェントである A2 にルーティングされ、以下同様に続きます。

このルーティング パターンは、次のタイプのスキルベース キューでサポートされます。

最良の入手可能な

最適なスキルベースのルーティング パターンにより、顧客とのやり取りが最も適格なエージェントに確実に転送されます。 このパターンは、エージェントに必要なスキルがあるかどうかだけでなく、それらのスキルの熟練度も評価し、スキル スコアを計算して、各コンタクトに最も適した (「最適な」) エージェントを決定します。

このパターンは、コンタクトスキル要件/キュースキル基準を完全に満たすスキルを持つ利用可能なエージェントをフィルタリングします。 次に、コンタクト スキル要件 / キュー スキル基準に記載されているすべてのスキルの熟練度値を使用して、対象となるエージェントごとにスコアが計算されます。 最も高いスキル スコアを持つエージェントが、各コンタクトに対して「最適な」エージェントとみなされます。

実際には、コンタクト スキル要件 / キュー スキル基準に一致するエージェントのスキル値の合計によってスコアが決まります。

理解すべき重要なポイント:

  • 通常、スキル スコアが高いほどマッチ度が高いことを示すため、スコアの計算には実際のスキル値が使用されます。 ただし、スキル要件が「以下(<=)」条件を使用する場合、エージェントの特定のスキル値はスコア計算で反転されます。つまり、 実効スキル値 = (10) マイナス (実スキル値)。 これは、スコアが低いほど一致度が高いことを示すようにするためです。
  • 複数の適格エージェントが同じスコアを持つ場合、その中で最も長く利用可能なエージェントが選択されます。
  • スコアの計算には熟練度スキルのみが考慮されます。 コンタクトスキル要件/キュースキル基準内のブール値、テキスト、または列挙型のスキルは、スコア計算では考慮されません。

上記の例では、熟練スキルと非熟練スキルを持ち、熟練スキル値が異なるエージェントが 4 人います。

「最適なルーティング」パターンを持つスキルベースのキューに入れられたコンタクトを考えてみます。

  • 上記のスキル要件がフローを通じて割り当てられた場合、または
  • 上記のスキル基準がスキルベース キューに設定されます。

このシナリオでは、

  • コンタクト スキル要件 / キュー スキル基準を完全に満たすエージェントのみがルーティング対象となります。 エージェントのみ A1 A2 そして A4 コンタクトスキル要件/キュースキル基準を完全に満たします。

    エージェント A3 資格がありません。 の場合 キューに割り当てられたスキル基準 A3 キューにも関連付けられていません。

  • の間で A1 A2 そして A4 スコアの計算は、コンタクト スキル要件 / キュー スキル基準に基づいてシステムによって実行され、熟練度スキルのみが考慮されます。

    エージェントが追加の熟練スキルを持っている場合でも、スコアの計算ではコンタクト スキル要件 / キュー スキル基準に記載されているスキルのみが考慮されます。

    また、<= (以下) 条件が使用される場合、スコア計算でスキル値が反転することにも注意してください。

  • 連絡先は次の宛先に送信されます A2 これはスコアに基づいて利用可能な最良のエージェントです。 もし A2 対応できない/話し中の場合、連絡先は、2 番目に高いスコアを持つ、次に最も対応可能なエージェントにルーティングされます。

    しかし、私たちには 2 人のエージェントがいます。 A1 そして A4 次に高いスコアを獲得しました。 コンタクトは、最も対応可能なエージェントにルーティングされます。 A1 そして A4

このルーティング パターンは、次のタイプのスキルベース キューでサポートされます。

非スキルベースルーティング

Webex Contact Center は、エージェントの特定のスキルや専門知識を考慮せずに、着信顧客とのやり取りを分散することに重点を置いた、さまざまな非スキルベースのルーティング パターンもサポートしています。 スキルベースのルーティング パターンとは異なり、これらではエージェントのスキルは考慮されず、連絡先またはキューでルーティングのスキル要件/基準を定義する必要もありません。 むしろ、可用性、作業負荷の分散、事前定義されたシーケンスなどの要素を優先し、個々のエージェントの能力ではなく運用ロジックに基づいて連絡先を効率的に処理できるようにします。 これらのパターンは、相互作用が比較的均一であるか、特別な処理を必要としない環境で特に役立ちます。

最長利用可能

最長対応可能ルーティング パターンは、そのキューに関連付けられている対応可能なすべてのエージェントの中で、最後のコンタクトの処理以降最も長く対応可能であったキュー内のエージェントにコンタクトをルーティングします。

このルーティング パターンでは、最も長い時間アイドル状態であったエージェントにインタラクションを割り当てることで、公平でバランスの取れた作業負荷の分散が保証されます。 作業負荷の不均衡を防ぐことで、どのエージェントにも過負荷がかからず、他のエージェントは自由な状態を保つことができます。 このアプローチは、コンタクトフローが安定している期間に特に効果的であり、エージェント プール全体で一貫したエンゲージメントを維持します。

エージェントは、いずれかのメディア タイプのコンタクトを提供されると、すべてのチャネルにわたって「最長利用可能」のポジションを失います。 つまり、エージェントがコンタクトを処理した後、キューに入れられたメディア タイプの次のコンタクトは、そのキュー内で次に最も長く利用可能なエージェントに割り当てられます。

上記の例では、エージェント A1 が最も長く利用可能なエージェント (位置 1) です。つまり、このエージェントは最初にログインしたか、他のどのエージェントよりも長い間コンタクトが割り当てられていないかのいずれかです。

エージェント A2 (ポジション 2) と A3 (ポジション 3) も対応可能ですが、ログインしているか、 A1 より後にコンタクトを処理しています。 すべてのエージェントは、このルーティング パターンを持つ両方のキューに関連付けられています。

次のシナリオを考えてみましょう。

  • 時刻 T0 に、音声コンタクト C1 がキューに入れられ、最も長く利用可能なエージェント、つまり A1 にルーティングされます。

    A1C1に割り当てられたことにより、 A1 はすべてのメディア チャネルで最も長く利用可能なエージェントではなくなりました。

  • 時刻 T1 に、チャット コンタクト C2 がキューに入れられ、最も長く対応可能なエージェント (現在は A2) にルーティングされます。
  • 最後に、時間 T2に、別の音声コンタクト C3 がキューに入れられ、 A3にルーティングされます。

    A1A2 は最近連絡を取りましたが、現時点で最も長く待っているのは A3 です。

Webex Contact Center の高度に分散されたアーキテクチャにより、複数のコンタクトが同時に同じキューに入れられた場合、最長時間対応可能な単一のエージェントに複数のコンタクトがルーティングされる可能性がわずかにあります。

このルーティング パターンは、次のタイプの非スキルベース キューでサポートされます。

ラウンドロビン

循環ルーティング パターンは、着信コンタクトをラウンドロビン方式で利用可能なエージェントのグループ間に分配します。 連絡先がキューに入れられると、システムは事前に決められた順序に基づいて、その連絡先をキュー内の次の対応可能なエージェントに割り当てます。

プロセスは、構成された順序でエージェントから始まります。 最初の着信コンタクトは、そのシーケンス内で最初に利用可能なエージェントに割り当てられます。 後続のコンタクトについては、システムは定義されたキュー順序で中断したところから続行して、次に利用可能なエージェントを選択します。 このパターンは繰り返され、エージェントを循環しますが、常に最後に選択されたエージェントの位置の後から開始されます。

このアプローチは、エージェント間で連絡先を公平かつ均等に分配するのに効果的です。 これにより、1 人のエージェントが問い合わせに圧倒されることがなくなり、すべてのエージェントが一貫してインタラクションを処理できる機会が平等に得られるようになります。 ただし、循環ルーティング パターンでは、現在の作業負荷や、エージェントが特定の連絡先を処理する能力に影響を与える可能性のあるその他の要因は考慮されません。

上記の例では、エージェントは次の順序で循環キューに設定されています: A3 → A4 → A5 → A6 → A1 → A2

まず、開始位置は設定された順序の最初のエージェント (A3) です。 問い合わせがこのキュー内のエージェントにルーティングされると、位置は円内を移動し、最後の問い合わせがルーティングされたエージェントの次に設定された順序にあるエージェントに配置されます。

次のシナリオを考えてみましょう。

  • 最初のコンタクト (C1) はキューに入れられ、エージェント A3 にルーティングされます。

    ポインターは設定された順序で次のエージェントに更新されます (例: A4)。

  • 2 回目の接触( C2)がキューに入れられると、システムは利用可能なエージェントの検索を開始します。 A4 すなわち A4 → A5 → A6 → A1 → A2 → A3

    しかし、 A4 そして A5 利用できません(ログインしていないか、アイドル状態か、このメディアタイプの他の連絡先で完全に忙しい状態です)。 C2 次の利用可能なエージェントにルーティングされます – A6。 ポインタは設定された順序で次のエージェントに更新されます。 A1

  • 同様に、3 番目のコンタクト( C3)は、 A1、4 番目の接触( C4)にルーティング A2。 ポインタは A3 また。

    このロジックは継続され、連絡先は「循環」/「ラウンドロビン」パターンで利用可能なエージェント間で分散されます。

キュー内に保留中のコンタクトがある場合、エージェント余剰シナリオでは、このメディア タイプで対応可能になる次のエージェントを、その中で最も優先度が高く、最も古いコンタクトに一致させます。

これは、このキュー内の既存の位置値を考慮したり、影響を与えたりしません。この位置値は、コンタクト余剰ルーティングがエージェントと正常に一致した場合にのみ更新されます。

このルーティング パターンは、次のタイプの非スキルベース キューでサポートされます。

トップダウン

トップダウン ルーティング パターンでは、着信コンタクトが、対応可能かつ順序付けられたエージェントのグループに順番に分配されます。 連絡先がキューに入れられると、システムは常にエージェントの順序付きリストを最初から走査し、その順序で最初に利用可能なエージェント(連絡先のメディア タイプの空きチャネルを持つエージェント)と連絡先を一致させます。

これは、キューに入れられたすべての連絡先に対して発生します。 連絡先のマッチングは、常に一番上 (最初に構成されたエージェント) から開始され、一致するエージェントが見つかるまでリストの下に向かって試行されます。

循環ルーティング パターンとは異なり、最後に選択されたエージェントの位置に基づいて開始点を動的に変更する「ポインター」はありません。

このアプローチは、管理者が決定した何らかの偏りや好みに基づいて順序付けられたエージェント間で連絡先を分配するのに効果的です。 これにより、上位のエージェントが下位のエージェントよりも優先的にコンタクトを処理できるようになります。 ただし、トップダウン ルーティング パターンでは、現在の作業負荷や、エージェントが特定の連絡先を処理する能力に影響を与える可能性のあるその他の要因は考慮されません。

上記の例では、エージェントはトップダウンキューに次の順序で構成されています: A3 → A4 → A5 → A6 → A1 → A2

これは、管理者が、すべての連絡先を、使用可能な場合は最初のエージェント (A3) にルーティングし、使用可能でない場合は次のエージェント (A4) にルーティングする、というように、構成された順序でルーティングすることを希望していることを意味します。

次のシナリオを考えてみましょう。

  • 最初の問い合わせ (C1) はキューに入れられ、エージェント A3 にルーティングされます。これは、 A3 が順序の先頭にあるためです。
  • 2 番目のコンタクト (C2) がキューに入れられると、ルーティングは再度、順序の先頭から試行されます (常に A3 から開始されます)。

    このメディア タイプに対して A3 にさらにチャネル容量がある場合、 C2A3にルーティングされます。 ただし、 A3 がこのメディア タイプで完全にビジー状態の場合、ルーティングはリストの A4に進みます。

  • ただし、 A4A5 は対応可能ではありません (ログインしていないか、アイドル状態であるか、このメディア タイプの他の連絡先で完全にビジー状態です)。そのため、 C2 は上から順に次に対応可能なエージェントである A6 にルーティングされます。
  • 同様に、3 番目のコンタクト (C3) は、 A3 から下に向かってルーティングされるよう試行されます。 最初に一致するエージェントは A1になります。

    このロジックは、注文の最後まで連絡先が対応可能なエージェントを見つけられなくなるまで継続され、その場合、連絡先はキューに保管されます。

このルーティング パターンは、次のタイプの非スキルベース キューでサポートされます。

エージェントベースルーティング

エージェント ベース ルーティングは、指定された (「優先」) エージェントにコンタクトを直接ルーティングまたはキューに入れる機能です。 エージェントの電子メール アドレスまたはエージェントの ID を使用したエージェント検索により、連絡先が優先エージェントにルーティングされます。 フロー内のエージェントへのキュー アクティビティは、エージェント ベースのルーティングの実現に役立ちます。 詳細については、「 エージェントへのキュー 」アクティビティを参照してください。

連絡先には 1 つ以上の優先エージェントへのマッピングを設定できます。優先エージェントは通常、Webex Contact Center 外部の外部アプリケーションで管理できます。 連絡先の優先エージェントの検索は、外部アプリケーションからマッピングを取得する HTTP リクエスト アクティビティを介して行われます。 優先エージェントにコンタクトをルーティングまたは保留するには、エージェントの Webex Contact Center ID または電子メール アドレスを使用して、エージェントにキューイング アクティビティを構成します。 優先エージェントがすぐに対応できない場合は、優先エージェントに対してコンタクトを保留することもできます。

エージェントベースのルーティングは、次のシナリオで役立ちます。

  • 優先エージェント ルーティング: 顧客は連絡先を専用エージェントまたはリレーションシップ エグゼクティブに割り当てることができます。 このようなシナリオでは、エージェント ベースのルーティングにより、連絡先が優先エージェントに直接ルーティングされます。
  • 最後のエージェント ルーティング: 連絡先がエージェントと対話するためにコンタクト センターに複数回コールバックする場合、エージェント ベース ルーティングにより、その連絡先を最後に処理したエージェントにルーティングできます。

どちらのユースケースでも、連絡先とエージェント マッピングの詳細は Webex Contact Center の外部に保存されます。

Flow のキューイングとルーティング機能

Flow のキューイングとルーティング機能

Webex Contact Center では、フローを通じて幅広いルーティング、キューイング、および通話制御機能を調整できます。

フロー デザイナーで提供されるさまざまなフロー アクティビティとイベント ハンドラーをフロー内に配置して、受信および送信コンタクトのライフサイクルを効果的に管理できます。

フローの設定と使用の詳細については、以下を参照してください。 Flow Designer でフローを構築および管理する

キューイングアクティビティ

Queue Contact

連絡先をキューに入れるアクティビティは、組織からのアクティブな受信キューに連絡先をキューイングして、そのキュー内の適切なエージェントに一致させてルーティングできるようにする機能を提供します。

このアクティビティを通じて、キューイングの次の側面を管理できます。

  • 優先度 - キューに入れられる連絡先に、1 (最高) から 10 (最低、デフォルト) の範囲の階層的重要度を割り当てます。
  • スキル要件 - 連絡先をルーティングする資格があるとみなされるために、スキルベース キュー内のエージェントが満たす必要のあるスキル基準を設定します。
  • スキル緩和 - エージェントを見つける可能性を高めるために、一定期間後に以前に設定したスキル要件を調整、変更、または削除します。
  • エージェントの空き状況を確認する - 待機時間を回避するために、利用可能なエージェントが見つからないすべてのコール配布グループにシステムが即座に拡張できるようにします。

見る ルーティング優先度、スキル構成、エージェントの可用性が連絡先のルーティングにどのように影響するかについては、こちらをご覧ください。

コンタクトキューアクティビティがコンタクトをキューに入れると、

  • 一致するエージェントがすでに利用可能な場合、システムは連絡先をエージェントにルーティングしようとします。

    これにより、 メインフロー 実行とさらなるイベントがそれぞれの イベントフロー(設定されている場合)。

  • 一致するエージェントが見つからない場合、連絡先はキューに保管され、一致するエージェントが対応可能になるまで待機します。

    フロー実行は、キュー連絡先アクティビティの後に接続されたアクティビティで続行され、次の機能を提供します。

    • 列に並んで待っている顧客に、あらかじめ設定された音楽を再生します。 プレイミュージック 活動。
    • 顧客のリクエストに基づいてコールバックを登録します。 折り返し電話 活動。
    • 再キューイング、つまり現在のキューから連絡先を削除し、別のキューに新しい連絡先を追加する キューコンタクト または エージェントへのキュー 活動。

一致するエージェントが利用可能になると、システムは連絡先をそのエージェントにルーティングしようとします。

成功すると、 メインフロー 実行とさらなるイベントがそれぞれの イベントフロー(設定されている場合)。

次の場合には、キュー コンタクト アクティビティの使用はサポートされません。

  • 連絡先にはすでにエージェントが割り当てられています。
  • フローに無効なキュー、スキル、またはその他の構成が提供されています。
  • コンタクトに許可されているエントリ ポイントとキュー遷移の最大数 (25) に達しました。
  • 連絡先を正常にルーティングするために許可されている最大試行回数 (20) に達しました。

このような場合、アクティビティは失敗し、フロー実行は エラー処理 パス。

スキル要件、スキル緩和、エージェントの可用性の確認などの機能は、チーム割り当てのあるキューが選択されている場合にのみ、キュー コンタクト アクティビティで使用できます。

アクティビティの設定、使用方法、出力変数の詳細については、以下を参照してください。 フローの構築と管理 > キューの連絡先

エージェントへのキュー

エージェントへのキュー アクティビティは、固有のエージェント ID または Webex Contact Center の電子メール アドレスを検索して、連絡先を優先エージェントに直接キューに入れる機能を提供します。

このアクティビティを通じて、キューイングの次の側面を管理できます。

  • 優先度 - 同じエージェントに対してキューに入れられたコンタクトに、高い/低い重要度を割り当てます。
  • レポートキュー - 録音やデフォルトのキュー内音楽などの構成、および連絡先のレポート目的に使用するキューを識別します。
  • 回復キュー - 指定された優先エージェントに連絡先をルーティングできなかった場合に、フォールバックとして使用するキューを識別します。

エージェントキューアクティビティがコンタクトをキューに入れると、

  • エージェントがすでに対応可能な場合は、連絡先はエージェントにルーティングされます。

    これにより、 メインフロー 実行とさらなるイベントがそれぞれの イベントフロー(設定されている場合)。

  • エージェントが対応可能であっても、拒否するか、応答しないか、または連絡を受信できなかった場合は、指定された回復キューに移動されます。

    回復キューでは、スキルのサポートなしで、最も長く対応可能なエージェントに連絡先がルーティングされます。

  • エージェントが利用できない場合は、「 エージェントが利用できない場合はパークに連絡してください 「オプションは 選択された連絡先は保留され、エージェントが対応可能になるまで待機します。

    フロー実行は、エージェントへのキューアクティビティの後に接続されたアクティビティで続行され、次のことが可能になります。

    • 列に並んで待っている顧客に、あらかじめ設定された音楽を再生します。 プレイミュージック 活動。
    • 折り返し電話 活動。
    • 再キューイング、つまり現在のキューから連絡先を削除し、別のキューに新しい連絡先を追加する エージェントへのキュー または キューコンタクト 活動。

    エージェントが対応可能になると、システムは連絡先をエージェントにルーティングしようとします。

    これにより、 メインフロー 実行とさらなるイベントがそれぞれの イベントフロー(設定されている場合)。

  • エージェントが利用できない場合は、「 エージェントが利用できない場合はパークに連絡してください 「オプションは 選択されていません、キューイングは失敗します。

次の場合には、エージェントへのキュー アクティビティの使用はサポートされません。
  • 連絡先にはすでにエージェントが割り当てられています。
  • 無効な優先エージェント ID または電子メール アドレスが指定されています。
  • 無効なレポートまたは回復キューが提供されています。
  • 優先エージェントは存在しますが、ログインしていないか、対応できないか、別の連絡先の処理中です。

このような場合、アクティビティは失敗し、フロー実行は エラー処理 パス。

アクティビティの設定、使用方法、出力変数の詳細については、「 フローの構築と管理 > エージェントへのキュー」を参照してください

エスカレーションコール分配グループ

通話配分グループのエスカレーション アクティビティは、 チーム割り当てのあるキューでのみサポートされており、構成された待機期間後に次のグループへの自動拡張更新が行われるまで待機するのではなく、連絡先の 通話配分グループ をすぐに更新する機能を提供します。 これにより、連絡先をキュー内のすべての適格なエージェントに迅速にルーティングできるようになります。

通話分配グループのエスカレーション アクティビティを使用すると、連絡先を次の宛先にエスカレートできます。

  • 次のグループ - チームのセットを拡張して、すぐ次の通話配分グループに追加されたチームを含めます。
  • 最後のグループ - チーム セットを拡張して、キューに設定されているすべての通話配布グループにマップされているすべてのチームを含めます。

次の場合には、エスカレート通話配布グループのアクティビティの使用はサポートされません。
  • 連絡先はまだキューに入っていません。
  • 連絡先は、通話配布グループの概念をサポートしていないキューに入れられています。

このような場合、アクティビティは失敗し、フロー実行は エラー処理 パスに移動します。

3 つの通話分配グループを持つキューに連絡先がキューイングされ、各グループが 30 秒ごとに更新されるというシナリオ例を考えてみましょう。

CDG 1CDG 2のチーム部分には対応可能なエージェントがいませんが、最後のコール分配グループに属する チーム 3 には対応可能なエージェントがいます。

フロー内でエスカレート コール配布グループのアクティビティが使用されていない場合、以下に示すように、待機時間が長くなります。

次のように、エスカレート コール配布グループ アクティビティを使用すると、待機時間を短縮できます。

選択した 次のグループ または 最後のグループ オプションに基づいて、以下に示すように、連絡先の待機時間が大幅に短縮されます。

アクティビティの設定、使用方法、および出力変数の詳細については、「 フローの構築と管理 > 通話配分グループのエスカレーション」を参照してください。

キュー情報アクティビティ

キュー情報を取得

キュー情報の取得アクティビティは、次のような特定の連絡先のリアルタイムのキュー情報を取得する機能を提供します。

  • キュー内の連絡先の現在の位置 (PIQ)、またはまだキューに入っていない場合は潜在的な位置。
  • 推定待機時間 (EWT)、またはタスクが応答されるまでにキュー内で待機すると推定される期間。
  • 連絡先の現在のコール分配グループ内でログインしているか利用可能なエージェントの数。
  • 選択したキューのすべてのコール分配グループでログインしている、または利用可能なエージェントの数。
  • キュー内の最も古い連絡先が待機していた期間。

これらの詳細は、フロー実行でアクティビティ出力変数として利用できるようになります。

アクティビティの使用状況、詳細な定義、および各キューの詳細の計算方法の詳細については、「 フローの構築と管理 > キュー情報の取得」を参照してください。

キュー情報の使用方法としては、次のようなものがあります。

  • 顧客がルーティングを待っている間に、連絡先のキュー内の位置と予想待ち時間を通知します。
  • 推定待ち時間が長すぎる場合に、顧客にコールバックを登録できるかどうかを決定します。
  • 現在の CDG (コール分配グループ) にマップされているチームにエージェントがいない場合は、連絡先を次の CDG にエスカレートします。

変数選択によって無効なキューが提供された場合、Get Queue Info アクティビティの使用はサポートされません。

この場合、アクティビティは失敗し、フロー実行は エラー処理 パスに移動します。

次の場合、現在のコール分配グループのリアルタイム キュー情報は適用されません。
  • Get Queue Info アクティビティが実行されたときに、連絡先は (まだ) キューに登録されていません。
  • 連絡先は、通話分配グループの概念をサポートしていないキューに入れられています。

このような場合、これらの出力フィールドの -1 の値は、この情報が該当しないことを示します。

キュー内で 15 秒が経過するごとに、キュー内の EWT が長いことを顧客に通知する必要があるというシナリオ例を考えてみましょう。

これは、次のようにフロー内の Get Queue Info アクティビティを使用して実現できます。

高度なキュー情報

高度なキュー情報アクティビティは、次のような連絡先のスキル基準を考慮して、特定の連絡先のリアルタイムのキュー情報を取得する機能を提供します。

  • キュー内の連絡先の現在の位置 (PIQ)、またはまだキューに入っていない場合は潜在的な位置。
  • 指定されたスキル基準に一致する、連絡先の現在のコール分配グループ内でログインしているか対応可能なエージェントの数。
  • 指定されたスキル基準に一致する、選択されたキューのすべてのコール分配グループでログインしているか利用可能なエージェントの数。
  • 指定されたキューに連絡先が保留されている現在の通話配布グループ。
  • 指定されたキュー内の通話分配グループの合計数。

これらの詳細は、フロー実行でアクティビティ出力変数として利用できるようになります。

アクティビティの使用状況、詳細な定義、各キューの詳細の計算方法の詳細については、以下を参照してください。 フローの構築と管理 > 高度なキュー情報

高度なキュー情報を使用する方法には次のようなものがあります。

  • ルーティングを待っている間に、顧客に連絡先のキュー内の位置を通知します。
  • 現在のコール分配グループにマップされているチーム内にスキル基準に一致するエージェントがいない場合は、連絡先を次のコール分配グループにエスカレートします。
  • すべてのコール分配グループにわたってスキル基準に一致するエージェントがログインしていない場合に、顧客にコールバックを登録できるかどうかを決定します。

次の場合には、高度なキュー情報アクティビティの使用はサポートされません。

  • キューにスキル基準が割り当てられたキューの情報が要求されます。
  • 連絡先はすでにキューに登録されていますが、情報が要求されているキューとは別のキューに登録されています。
  • 連絡先は優先エージェントに対して直接キューに入れられます。

このような場合、アクティビティは失敗し、フロー実行は エラー処理 パス。

スキル基準を満たすエージェントが利用できないことを考慮して、コールバックを受けることを顧客に通知する必要があるシナリオ例を考えてみましょう。

これは、次のようにフロー内の Advanced Queue Info アクティビティを使用することで実現できます。

通話制御アクティビティ

発信者 ID を設定する

発信者設定 ID アクティビティは、通話中に表示される発信者 ID を定義するために使用されます。 発信者設定 ID アクティビティは、イベント フローの終了を示すターミナル アクティビティとして、PreDial イベント フローでのみ使用する必要があります。

発信者設定 ID アクティビティを使用すると、ダイヤル番号識別サービス (DNIS)、操作タイプ、または参加者タイプに基づいて、必要な自動番号識別 (ANI) を構成できます。

アクティビティの設定、使用方法、出力変数の詳細については、以下を参照してください。 フローの構築と管理 > 呼び出し元の設定 ID

録音コントロール

録音コントロール アクティビティは、メニュー アクティビティと一緒に使用して、発信者からの録音の同意を取得するように設計されています。 これにより、録音を開始する前に明示的な同意を必要とする規制やポリシーへの準拠が保証され、このステップがワークフローにシームレスに統合されます。

メニュー IVR アクティビティは、ユーザの同意をブール変数にキャプチャし、それを記録制御アクティビティへの入力として割り当てる必要があります。 顧客が同意レポートでユーザの同意を報告する必要がある場合、同意値は報告可能なグローバル変数に保存する必要があります。 あるいは、レポートが不要な場合はローカル変数を使用することもできます。 このアプローチにより、テナントおよび顧客は、変数を効果的に管理および活用する柔軟性が向上します。

このアクティビティがフローに追加されると、テナント レベル、キュー レベル、または録画スケジュール レベルの構成設定よりもユーザの同意が優先されます。

優先順位は次のとおりです。

  • フロー内でユーザの同意が「はい」の場合、テナントまたはキューまたは記録スケジュール レベルで設定された記録構成に関係なく、通話は記録されます。
  • ユーザがアクティビティへの応答として同意しない場合は、テナントまたはキューまたは録音スケジュール レベルで設定された録音構成に関係なく、通話は録音されません。
  • フロー内で録音制御アクティビティが構成されていないが、テナント、キュー、録音スケジュールなどの他のレベルのいずれかで構成が「はい」に設定されている場合、通話は録音されます。
  • フロー内で録音制御アクティビティが構成されておらず、テナント、キュー、録音スケジュールなどのすべてのレベルで構成が「いいえ」に設定されている場合、通話は録音されません。

この記録制御は以下のように表すことができます。

さらに、転送時に続行、一時停止再開の有効化、一時停止期間などの録画構成は、テナント、キュー、録画スケジュール レベルなどの既存の階層に応じて引き続き適用されます。

アクティビティの設定、使用方法、出力変数の詳細については、「 フローの構築と管理 > 記録コントロール」を参照してください

ブラインド転送(Blind Transfer)

ブラインド転送は、エージェントの介入を必要とせずに、連絡先が IVR システムを通じて外部ダイヤル番号 (DN) に効率的にルーティングされるプロセスです。

ブラインド転送アクティビティは、通話を外部またはサードパーティの DN に転送する必要がある場合に使用されます。 これはターミナルアクティビティなので、転送が実行されるとフローは終了します。

フローがコンサルテーションのために実行される場合、ブラインド転送アクティビティはサポートされません。

アクティビティの設定、使用方法、出力変数の詳細については、「 フローの構築と管理 > ブラインド転送」を参照してください

ブリッジ転送

ブリッジ転送アクティビティを使用すると、フローが通話の制御を維持しながら、連絡先を一時的に外部の宛先に転送できます。 外部宛先は、外部ブリッジまたは Interactive Voice Response (IVR) サービスにすることができます。

外部の宛先が通話を終了すると、エージェントへのキューイングなど、必要に応じて通話フローがさらに続行されます。

ブリッジ転送アクティビティは、連絡先をサードパーティの IVR または自動通話分配 (ACD) システムに転送する際に、連絡先をキューから削除します。 連絡先がサードパーティ システムによって処理されない場合は、元のキューに再度戻して、適切な処理のためにワークフロー内に連絡先が残るようにすることができます。

たとえば、コンタクト センターに Webex Contact Center エージェント リソースと、外部コール センターまたは構内交換機 (PBX) 上のエージェント リソースがあるとします。 顧客は、短時間 (たとえば 60 秒)、Webex Contact Center エージェントのキューに対して通話をキューイングしたいと考えています。 その期間中にエージェントが対応できない場合は、コンタクトを処理するために、コールを外部のコール センターにブリッジ転送(暗黙的なデキューを使用)することができます。

  1. ブリッジ転送アクティビティは、発信コール フローおよびイベント フローではサポートされません。
  2. すでにエージェントに割り当てられている連絡先は、フローを介したブリッジ転送ではサポートされません。

アクティビティの設定、使用方法、出力変数の詳細については、「 フローの構築と管理 > ブリッジ転送」を参照してください

連絡先を切断する

連絡先の切断アクティビティは、フローから直接アクティブな連絡先を切断または終了する機能を提供します。

これはフローに添付されたターミナル アクティビティであり、エージェントの介入なしにコンタクトを終了する場合に役立ちます。エラー パス フローに適しており、顧客へのコールバックを登録した後でも使用できます。

設定に基づいて、このアクティビティを通じて連絡先が終了すると、POST コール アンケートまたはフィードバックがトリガーされます。

アクティビティの設定、使用方法、出力変数の詳細については、「 フローの構築と管理 > 連絡先の切断」を参照してください

連絡先の優先順位を設定

連絡先の優先度の設定アクティビティは、連絡先に特定の優先度レベルを割り当てることができるため、フロー内での連絡先の優先度管理を効果的に行うことができます。 これにより、特定の連絡先に高い重要度または低い重要度を与えることができ、エージェントが対応可能になったときに、他の待機中の連絡先と比較して適切にルーティングされることが保証されます。 この柔軟性により、フロー全体にわたって連絡先の優先順位を正確に制御できます。

優先度は、1 (最高) から 9 (最低) までの階層的な重要度レベルを割り当てることによって決定されます。 最も優先度の高い連絡先は、優先度の低い連絡先よりも先にルーティングされます。 複数の連絡先が同じ優先度レベルを共有している場合、最も長く待機していた連絡先が、最初に次に空いている適格なエージェントにルーティングされます。 このシステムにより、待機時間に基づいて同等の優先度の連絡先間の公平性を維持しながら、優先度の高い連絡先に迅速な対応が保証されます。

  1. 連絡先の優先順位の設定アクティビティは、メイン フローまたはイベント フロー内の任意のポイントに配置できます。
  2. コンタクト優先度の設定アクティビティがキューイング アクティビティ (コンタクトのキューイングやエージェントへのキューイングなど) の前に構成されている場合、その優先度設定は、後続のキューイング アクティビティで明示的に構成された優先度によって上書きされる可能性があります。 ただし、次のキューイング アクティビティで優先度が指定されていない場合は、前のコンタクト優先度の設定アクティビティで設定されたコンタクト優先度が適用されます。
  3. 逆に、コンタクト優先度の設定アクティビティがキューイング アクティビティ (コンタクトのキューイングやエージェントへのキューイングなど) の後に構成されている場合、先行するキューイング アクティビティによって構成された優先度設定が上書きされます。
  4. 連絡先の優先順位の設定アクティビティは、現在、アウトダイヤルおよびキャンペーンの連絡先ではサポートされていません。

アクティビティの設定、使用方法、出力変数の詳細については、「 フローの構築と管理 > 連絡先の優先度の設定」を参照してください。

コールバックアクティビティ

コールバック

コールバック アクティビティを使用すると、発信者は保留にされるのではなくコールバックをリクエストできるため、待ち時間が短縮され、放棄率が最小限に抑えられ、顧客満足度が大幅に向上します。 コールバック アクティビティをアクティブ化すると、キューにタスクが作成され、対応可能なエージェントが顧客の通話を折り返しできるようになります。

フロー デザイナーは、通話の発信元である元のキューに連絡先を保持するか、設定に基づいて別のキューに割り当てるか、アクティビティを構成できます。 コールバックが元のキューに留まる場合、連絡先の位置、スキル、優先度、コンテキスト データが維持され、次に利用可能なエージェントにシームレスに割り当てることができます。 ただし、別のキューを選択した場合、連絡先はスキルなしでデフォルトの優先度で、選択したキューの最後にプッシュされます。

このアクティビティにより、顧客は好みのエージェントにコールバックをリクエストすることもできるため、エクスペリエンスに個人的なタッチが加わり、顧客満足度が向上します。 これは、フロー内でコールバック アクティビティが QueueToAgent アクティビティに続く場合に実現できます。 さらに、コールバック アクティビティでは、コールバック プロセス中に使用される自動番号識別 (ANI) をカスタマイズするためのオプションの構成も提供されます。 このカスタマイズは、ブランドの一貫性を保つのに役立ち、発信者 ID を認識できるようにすることで、通話拒否の可能性を減らします。

フロー デザイナーには、イベント フローに CallbackFailed イベントを含めるオプションがあります。 このイベントはコールバックの試行が失敗したときにトリガーされ、フロー デザイナーが特定の間隔で再試行を実装できるようになります。 再試行間の遅延または間隔は、待機アクティビティを使用して構成できます。再試行間隔は最小 10 秒、最大 72 時間です。 システムは、待機アクティビティを使用して、最大 14 日間にわたって最大 10 回の再試行をサポートします。

アクティビティの設定、使用方法、出力変数の詳細については、「 フローの構築と管理 > コールバック」を参照してください。

コールバックのスケジュール

スケジュールされたコールバック アクティビティにより、フローは顧客に将来の特定の日時にコールバックをリクエストする利便性を提供できるようになり、エージェントにすぐに接続する必要がなくなります。 この機能により、顧客は都合の良いコールバック ウィンドウを選択できるようになり、待機時間の認識が最小限に抑えられ、通話放棄率が減少するため、顧客エクスペリエンスが向上します。

フローは、DTMF プロンプトを介して、希望日時などの発信者の入力を取得し、必要な入力検証を実行した後、それらをアクティビティに渡す必要があります。

開始する前に、コントロール ハブの [チャネル設定][コールバックのデフォルト エントリ ポイント] が設定されていることを確認してください。 詳細については、「 コールバック エントリ ポイントの設定」を参照してください。

コールバックは、着信または発信に関係なく、任意のテレフォニー キューを使用してスケジュールできます。 最良の結果を得るには、コールバックがスケジュールされたら現在の通話が適切に終了するように、スケジュールされたコールバック アクティビティの直後に切断アクティビティを追加することをお勧めします。 IVR コールバックのスケジュール設定の詳細については、「 IVR コールバックのスケジュール設定」を参照してください

要求された将来の日時にコールバックがトリガーされると、新しい通話またはインタラクションが作成されます。 この新しいインタラクションは、コールバックのデフォルト エントリ ポイントにリンクされた標準フローに従います。 コールバックの試行が失敗した場合、そのフローで構成されている場合には、 CallbackFailed イベント ハンドラーを使用して、フローは自動的に呼び出しを再試行できます。

アクティビティに入力を渡す前に、次の入力検証を考慮する必要があります。

  1. 日付の選択 - 今日から 31 日後までの任意の日付を選択できます。 日付は YYYY-MM-DD 形式にする必要があります (例: 2025-07-18)。
  2. 時間枠の開始時間と終了時間 - 選択する時間は少なくとも今から 30 分後に開始する必要があり、30 分から 8 時間までの範囲で継続できます。 24 時間形式の時刻を使用してください (例: 14:30:00)。
  3. タイムゾーン: 適切な時間に電話をかけられるように、有効なタイムゾーンを IANA 形式 ( America/New_York など) で入力する必要があります。

アクティビティとともに使用される DTMF プロンプトと基本的な検証を示すために、サブフロー テンプレートの形式でリファレンス実装が提供されます。 詳細については、 スケジュールされたコールバック サブフロー テンプレートを参照してください。

通話進捗分析

通話進行状況分析アクティビティ (CPA) を使用すると、コールバック通話における自動応答システムと人間の生の音声を検出できます。

コールバックの試行中に留守番電話検出 (AMD) またはボイスメールが検出されると、システムはその通話を失敗したものとして認識します。 留守番電話検出 (AMD) の結果は、CallbackFailed イベント ハンドラーの理由出力変数にキャプチャされます。 この出力変数に基づいて、フロー デザイナーはコールバックの再試行を構成できます。

  1. 礼儀正しいコールバックの場合、CallProgressAnalysis はメイン フローの Callback アクティビティの後の位置に配置できます。 スケジュールされたコールバックまたは個人のスケジュールされたコールバックの場合は、メイン フローの NewPhoneContact の後に配置できます。
  2. イベント フローでは、CallbackFailed イベント ハンドラーでのみサポートされます。
  3. フロー内に POST コール顧客アンケート (フィードバック アクティビティ) が設定されている場合、コールが AMD またはボイスメールで応答されると、アンケートは開始されません。 これにより、不要な調査がトリガーされることがなくなります。

アクティビティの設定、使用方法、出力変数の詳細については、「 フローの構築と管理 > 通話進行状況分析」を参照してください。

この投稿記事は役に立ちましたか?
この投稿記事は役に立ちましたか?