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

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

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

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

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

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

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

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 の一部とはみなされず、このキューに関連付けられません。

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

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

• 最長利用可能

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

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

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

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

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

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

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

• 最長利用可能
• ラウンドロビン
• 線形/トップダウン

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

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

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

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

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

この例では、

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

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

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

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

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

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

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

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

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

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

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

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

• 最初のコール分配グループには TEAM 1 が含まれており、これには A1、A2、A5 の 3 つのエージェントが構成されています。
• 2 番目のコール分配グループには、A2、A3、A4 の 3 つのエージェントが設定された TEAM 2 が含まれています。
• 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 番目の通話配分グループで構成されているすべてのチームは、最初のグループの既存のチームにも追加されます。 ここで、システムは拡張されたグループ内で一致するエージェントを見つけようとします。 この処理が行われている間、スキル緩和により、設定された時間間隔で連絡先のスキル要件も更新され、システムは更新されたスキル要件を使用して、現在のコール分配グループ内の利用可能なエージェントと照合することに注意してください。

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

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

• 最長利用可能
• 最良のもの

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

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

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

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

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

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

• キューランキング

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

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

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

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

    • キュー ランキングは同じメディア タイプ内で機能します。

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

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

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

• 連絡先の優先順位

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

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

• 最長待機コンタクト

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

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

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

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

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

A1 は、 Q1、 Q2 、 Q3 の 3 つのキューに関連付けられています。 チーム 1 はキューのランキングも定義しており、 Q1 が最も高く、次に Q2 と Q3 が続きます。

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

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

• これらのキューのすべての保留中のコンタクトのうち、 A1 ～ C2、 C7 (キュー 2 から)、 C3、 C8 (キュー 3 から) にルーティングできるのは 4 件のコンタクトのみです。

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

• これら 4 つのコンタクトのうち、 キュー 2 のキュー順位の方が高いため、 キュー 2 (つまり C2、C7) からのコンタクトが優先されます。

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

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

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

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

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

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

選択肢は 3 つあります。

• 排他的 – エージェントは、一度に 1 つのメディア タイプのコンタクトのみを処理できます。

  これは、組織がエージェントが一度に 1 つのタスクに完全に集中することを期待している場合に役立ちます。

• ブレンド – 構成されたチャネルの容量まで、各メディア タイプの任意の数のコンタクトを同時に処理できます。

  これは、組織がエージェントにマルチタスクを要求し、異なるメディア タイプにわたる複数の連絡先に対応することを期待している場合に役立ちます。

• ブレンド型リアルタイム – ブレンド型と同じですが、音声とチャットは相互に排他的です。 音声が処理されている場合、チャット連絡先は表示されません。逆の場合も同様です。

  これは、組織がエージェントにマルチタスクを期待しているが、エージェントが単一の「リアルタイム」コンタクト（音声またはチャット）に集中できるようにして、相手側のエンド カスタマーに十分な注意を払うことができる場合に役立ちます。

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

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

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

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

エージェント ベースのルーティングは、指定された (「優先」) エージェントにコンタクトを直接ルーティングまたはキューに入れる機能です。 エージェントの電子メール アドレスまたはエージェント ID を使用したエージェント検索により、連絡先が優先エージェントにルーティングされます。 フロー内のエージェントへのキュー アクティビティは、エージェント ベースのルーティングの実現に役立ちます。 詳細については、 エージェントへのキュー 活動。

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

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

• 優先エージェント ルーティング: 顧客は連絡先を専属エージェントまたはリレーションシップ エグゼクティブに割り当てることができます。 このようなシナリオでは、エージェント ベースのルーティングにより、連絡先が優先エージェントに直接ルーティングされます。
• 最後のエージェント ルーティング: 連絡先がエージェントと対話するためにコンタクト センターに複数回コールバックする場合、エージェント ベースのルーティングにより、その連絡先を最後に処理したエージェントにルーティングできます。

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

連絡先をキューに入れるアクティビティは、組織からのアクティブな受信キューに連絡先をキューイングして、そのキュー内の適切なエージェントに一致させてルーティングできるようにする機能を提供します。

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

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

優先度、スキル構成、エージェントの可用性が連絡先のルーティングにどのように影響するかについては、「 ルーティング」を参照してください。

コンタクトキューアクティビティがコンタクトをキューに入れると、

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

  これにより、 メイン フロー の実行が中断され、構成されている場合、さらにイベントがそれぞれの イベント フローをトリガーできます。

• 一致するエージェントが見つからない場合、連絡先はキューに保管され、一致するエージェントが対応可能になるまで待機します。

  フロー実行は、キュー連絡先アクティビティの後に接続されたアクティビティで続行され、次の機能を提供します。

  • PlayMusic アクティビティを添付して、キューで待機している顧客に対して事前に構成された音楽を再生します。
  • コールバック アクティビティを添付して、顧客のリクエストに基づいてコールバックを登録します。
  • 再キューイング、つまり現在のキューから連絡先を削除して新しいキューに追加するには、別の キュー連絡先 または キューエージェント アクティビティを添付します。

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

成功すると、 メイン フロー の実行が中断され、構成されている場合は、さらにイベントがそれぞれの イベント フローをトリガーできるようになります。

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

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

エージェントにキューイングするアクティビティは、Webex Contact Center で一意のエージェント ID または電子メール アドレスを検索して、優先エージェントにコンタクトを直接キューイングする機能を提供します。

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

• 優先度 - 同じエージェントに対してキューに入れられたコンタクトに、高い/低い重要度を割り当てます。
• レポートキュー - 録音やデフォルトのキュー内音楽などの構成、および連絡先のレポート目的に使用するキューを識別します。
• 回復キュー - 指定された優先エージェントに連絡先をルーティングできなかった場合に、フォールバックとして使用するキューを識別します。

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

• エージェントがすでに対応可能な場合は、連絡先はエージェントにルーティングされます。

  これにより、 メインフロー 実行とさらなるイベントがそれぞれの イベントフロー（設定されている場合）。

• エージェントが対応可能であっても、拒否するか、応答しないか、または連絡を受信できなかった場合は、指定された回復キューに移動されます。

  回復キューでは、スキルのサポートなしで、最も長く対応可能なエージェントに連絡先がルーティングされます。

• エージェントが利用できない場合は、「 エージェントが不在の場合のパーク連絡先 「オプションは 選択された連絡先は保留され、エージェントが対応可能になるまで待機します。

  フロー実行は、エージェントへのキューアクティビティの後に接続されたアクティビティで続行され、次のことが可能になります。

  • 列に並んで待っている顧客に、あらかじめ設定された音楽を再生する - プレイミュージック 活動。
  • 折り返し電話 活動。
  • 再キューイング、つまり現在のキューから連絡先を削除し、別のキューに新しい連絡先を追加する エージェントへのキュー または キューコンタクト 活動。

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

  これにより、 メインフロー 実行とさらなるイベントがそれぞれの イベントフロー（設定されている場合）。

• エージェントが利用できず、「 エージェントが利用できない場合にコンタクトをパークする 」オプションが 選択されていない場合、キューイングは失敗します。

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

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

通話分配グループのエスカレーション アクティビティは、 チーム割り当てのあるキューでのみサポートされ、構成された待機期間後に次のグループへの自動拡張更新が行われるまで待機するのではなく、連絡先の 通話分配グループ をすぐに更新する機能を提供します。 これにより、連絡先をキュー内のすべての適格なエージェントに迅速にルーティングできるようになります。

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

• 次のグループ - チーム セットを拡張して、次の通話配分グループに追加されたチームを含めます。
• 最後のグループ - チーム セットを拡張して、キューに設定されているすべての通話配布グループにマップされているすべてのチームを含めます。

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

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

CDG 1 と CDG 2のチーム部分には対応可能なエージェントがいませんが、最後のコール分配グループに属する チーム 3 には対応可能なエージェントがいます。

フロー内でエスカレート コール配布グループのアクティビティが使用されていない場合、以下に示すように、待機時間が長くなります。

次のように、エスカレート コール配布グループのアクティビティを使用すると、待機時間を短縮できます。

選択した 次のグループ または 最後のグループ オプションに基づいて、以下に示すように、連絡先の待機時間が大幅に短縮されます。

アクティビティの設定、使用方法、および出力変数の詳細については、「 フローの構築と管理 > エスカレート コール配布グループ」を参照してください。

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

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

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

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

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

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

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

キュー内で 15 秒が経過するごとに、キュー内の EWT が長いことを顧客に通知する必要があるというシナリオ例を考えてみましょう。

これは、次のようにフロー内の Get Queue Info アクティビティを使用して実現できます。

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

• 連絡先のキュー内の現在の位置（ PIQ）、またはまだキューに入っていない場合は潜在的な位置。
• 指定されたスキル基準に一致する、連絡先の現在のコール分配グループ内でログインしているか対応可能なエージェントの数。
• 指定されたスキル基準に一致する、選択されたキューのすべてのコール分配グループでログインしているか利用可能なエージェントの数。
• 指定されたキューに連絡先が保留されている現在の通話配布グループ。
• 指定されたキュー内の通話分配グループの合計数。

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

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

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

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

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

スキル基準を満たすエージェントが利用できないことを考慮して、コールバックを受けることを顧客に通知する必要があるシナリオ例を考えてみましょう。

これは、次のようにフロー内の Advanced Queue Info アクティビティを使用することで実現できます。

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

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

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

録音コントロール アクティビティは、メニュー アクティビティと一緒に使用して、発信者からの録音の同意を取得するように設計されています。 これにより、録音を開始する前に明示的な同意を必要とする規制やポリシーへの準拠が保証され、このステップがワークフローにシームレスに統合されます。

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

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

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

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

この記録制御は以下のように表すことができます。

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

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

ブラインド転送は、エージェントの介入を必要とせずに、連絡先が IVR システムを通じて外部ダイヤル番号 (DN) に効率的にルーティングされるプロセスです。

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

フローがコンサルテーションのために実行される場合、ブラインド転送アクティビティはサポートされません。

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

ブリッジ転送アクティビティを使用すると、フローが通話の制御を維持しながら、連絡先を一時的に外部の宛先に転送できます。 外部宛先は、外部ブリッジまたは Interactive Voice Response (IVR) サービスにすることができます。

外部の宛先が通話を終了すると、エージェントへのキューイングなど、必要に応じて通話フローがさらに続行されます。

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

たとえば、コンタクト センターに Webex Contact Center エージェント リソースと、外部コール センターまたは構内交換機 (PBX) 上のエージェント リソースがあるとします。 顧客は、短時間 (たとえば 60 秒)、Webex Contact Center エージェントのキューに対して通話をキューイングしたいと考えています。 その期間中にエージェントが対応できない場合は、コンタクトを処理するために、コールをブリッジ転送（暗黙的なデキューを使用）して外部のコール センターに転送することができます。

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

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

これはフローに添付されたターミナル アクティビティであり、エージェントの介入なしにコンタクトを終了する場合に役立ちます。エラー パス フローに適しており、顧客へのコールバックを登録した後でも使用できます。

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

アクティビティの設定、使用方法、および出力変数の詳細については、「 フローの構築と管理 > 連絡先の切断」を参照してください。

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

フロー デザイナーは、通話の発信元である元のキューに連絡先を保持するか、設定に基づいて別のキューに割り当てるか、アクティビティを構成できます。 コールバックが元のキューに留まる場合、連絡先の位置、スキル、優先度、コンテキスト データが維持され、次に利用可能なエージェントにシームレスに割り当てることができます。 ただし、別のキューを選択した場合、連絡先はスキルなしでデフォルトの優先度で、選択したキューの最後にプッシュされます。

このアクティビティにより、顧客は好みのエージェントにコールバックをリクエストすることもでき、エクスペリエンスに個人的なタッチが加わり、顧客満足度が向上します。 これは、フロー内でコールバック アクティビティが QueueToAgent アクティビティに続く場合に実現できます。 さらに、コールバック アクティビティでは、コールバック プロセス中に使用される自動番号識別 (ANI) をカスタマイズするためのオプションの構成も提供されます。 このカスタマイズはブランドの一貫性を保つのに役立ち、認識可能な発信者 ID を確保することで通話拒否の可能性を減らします。

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

アクティビティの設定、使用方法、出力変数の詳細については、「 フローの構築と管理 > コールバック」を参照してください。

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

コールバックの試行中に留守番電話検出 (AMD) またはボイスメールが検出されると、システムはその通話を失敗したものとして認識します。 留守番電話検出 (AMD) の結果は、CallbackFailed イベント ハンドラーの理由出力変数にキャプチャされます。 この出力変数に基づいて、フロー デザイナーはコールバックの再試行を構成できます。

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