あなたの意見では、現代のコールセンターのオペレーターが同時に処理できる通話数は、1、2、または10ですか？
あなたの答えが「複数」である場合、この記事はあなたのためです。 これから、 エージェントキャパシティモデルと呼ばれる特別な処理アルゴリズムを使用して、複数のコールを同時に処理する問題を解決する方法を学習します。
1つの治療では十分ではありません
一般的な状況の普通の人は、1つのタスクに集中しています。 電話での会話は、この観察の良い確認です。 同じ原則に従って、CCの標準処理手順「 1回の呼び出し-1人のオペレーター 」が構築されます。
ただし、新しい種類の通話（電子メール、チャット、モバイルアプリケーション）では、集中力を必要とせず、他の問題を解決するための時間を割り当てることができます。 チャットセッションを検討してください。 エージェントがクライアントとチャットしているとき、エージェントは一定時間アイドル状態になり、応答を待ちます。 この時間はより生産的に使用できます。 たとえば、別のクライアントからのチャット要求を受け入れる機会を彼に与えます。 資格のあるオペレーターは、サービス品質を低下させることなく、同時に2-3のチャットセッションに参加できることが確立されています。
理論的には、オペレーターのロードに問題はありません。 しかし、それらは実際の実装で発生します。 コールセンター（外国および国内）のほとんどのプラットフォームで使用されている従来のコール配信スキームは、コールをオペレータに配信するときに、 ビジー/ビジー状態に転送します。
典型的な状況を考えてみましょう。オペレーターがクライアントからの電子メールに応答します。 ある時点で、電話のリクエストがコールセンターに到着するとします。 電話応答エージェントはすべて忙しいです。 この状況では論理的であるため、コールを失うことがないように、電子メールを処理するオペレータに転送してください。 なんで？
実際には、電話とは対照的に、電子メール処理ではリアルタイムの応答は必要ありません。 この状況では、従来の配布スキームは機能しません。 オペレータはビジー状態にあり、別のコールを受け入れることができません。
リッチコンタクトエクスペリエンス（RCE）コンセプトは、これらの問題を解決するのに役立ち、クライアントとCC間の統合された通信環境を作成できます。 リッチコンタクトエクスペリエンスを使用すると、任意のチャネルで任意の数の連絡先を処理できることに注意してください。 何のため？
この概念には、コールのタイプとオペレーターの作業負荷を考慮に入れた、特別なルーティングメカニズム（コール分散）の使用が含まれます。 マルチチャネルコールの処理にどのように使用できるかを見てみましょう。
オペレーター負荷の最適化
解決する必要がある問題：「 1つのコール-1人のオペレーター 」の原則から逃れ、オペレーターが複数のコールを同時に処理する機会を提供する（コールのタイプとオペレーターの負荷に応じて処理ルールを設定する）
これらの単語は、記事の冒頭で強調されていました。 「 エージェント容量 」パラメータは、タスクを解決するための鍵です。
「エージェントキャパシティ」は、オペレーターが単位時間あたりに処理できるコールの最大数として定義されます。 たとえば、1人のオペレーターが同時に3つのチャットセッションに参加できる場合、 エージェントキャパシティインジケーターは3です。特定の瞬間にオペレーターが1つのチャット要求を処理しているとします。 この場合、オペレーターはまだ完全にはロードされておらず、さらに2つのチャットコールを受け入れることができます（この例では「Agent Capacity」 = 3であるため）。
電話の場合、Agent Agentパラメーターは1に等しくする必要があります。 オペレーターは、単位時間あたり1つの電話しか処理できません（これはほとんどのコールセンターで採用されているルールに対応しています）。
記事の半分を読んだ後、合理的な質問をすることができます：「しかし、 異なる種類の呼び出しの同時処理はどうでしょうか？ 実際、この問題を解決することは不可能であり、 「ワンコール-ワンオペレーター」の原則に対する批判として引用されました。
答えは、 RCEの概念では、1つのタイプのコールが他のタイプのコールを中断できるかどうかを設定することです（設定によって異なります）。 たとえば、記事の冒頭に記載されている電子メールの処理の場合、電子メールを処理するように指定できます。 メールは電話の着信によって中断されますが、その逆はできません。 コールが着信すると、電子メールの処理が保留され、オペレーターが電話のリクエストに応答します。 完了すると、オペレーターは電子メールの処理に戻ります。 郵便で。
ルールを構成するために、2つの追加パラメーター、 中断マトリックス（中断マトリックス）および最大容量ベクトル（最大負荷ベクトル）が導入されています。
中断マトリックスは、サイズNxNのマトリックスです。ここで、 Nは、コールセンターが処理するコールのタイプの数（音声、電子メール、チャットなど）です。 各行列要素
例として、マトリックスINTとベクトルMAXを考えます。
INTマトリックスは、音声、電子メール、チャットの3種類の通話間の関係を示します。 最初の行は音声を指します。 つまり、音声は他の種類の通話（他の音声通話を含む）によって中断されることはありません。 2行目は、電子メールの処理を説明しています。 そのパラメーターは、電子メールが音声とチャットによって中断される可能性があることを示しています。 また、処理済みのメールに新しいメールを追加できます。 3行目は、チャットを音声と電子メールで中断できないことを示しています。 電子メールだけでなく、既存のチャットに新しいチャットを追加できます。
最大容量ベクトルMAXは、オペレーターが同時に処理できる1つのタイプの呼び出しの最大数を設定します。 この例では、音声-1、電子メール-5、チャット-3の値が設定されています。
オペレーターの現在のステータスは、サイズNxMの ASマトリックスによって記述されます。ここで、 Mはオペレーターが現在作業している連絡先（クライアント）の数、 Nはコールのタイプです。 例を考えてみましょう：
マトリックスのサイズは、オペレーターが2つの連絡先で作業していることを示しています。 最初の連絡先には電話のみが含まれます。 2番目の連絡先は、電子メールとチャットセッションの処理です。
エージェントキャパシティモデルは、エージェントが新しいコンタクトを受け入れることができるかどうかを決定する手順として機能します。 新しい連絡先に電子メールとチャットが含まれると仮定します。これらはベクトルCによって決定されます。
エージェントが新しいコンタクトを処理できるかどうかを判断するには、次の手順を実行します。
1.ベクトルCの非ゼロ要素ごとに、このタイプの呼び出しが現在のオペレーター操作に割り込むことができるか、それに追加できるかどうかがチェックされます。 検証は、 中断マトリックスと最大容量ベクトルを使用して行われます。 オペレーターを中断できないことが判明した場合、オペレーターは「 使用不可 」と見なされます。
2.すべての新しい呼び出しを中断または既存の呼び出しに追加できる場合：新しい呼び出しの数がMAXベクトルで指定された最大数を超えていないことを確認します。 この条件が満たされている場合、オペレーターはこのアピールを受け取る準備ができていると見なされます。 そうでない場合、演算子は「 準備されていない 」と見なされます。
この例では、オペレーターが新しい連絡先Cからの呼び出しを受け入れることができるかどうかを簡単に判断できます。 オペレーターは電話に出るため、電子メールやチャットで中断されることはありません。
「 エージェントキャパシティ 」パラメータを使用した場合のコールルーティングの動作を説明する図を次に示します。 上記の例のように、すべてのオペレーターが同じ割り込みマトリックスと値を持つ最大容量ベクトルを持っていると仮定します。
Vadimのクライアントは、チャットリクエストでコールセンターに連絡します。 すべての事業者は、すでに他の顧客からの電話に対応しています。 オペレーターIrinaは、1人のクライアントからの音声通話と電子メールを処理します。 この例で設定されたルールに従って、音声を中断することはできません。 オペレーターGalinaは、3つのチャットセッションで同時に3人のクライアントにサービスを提供します。 彼女はVadimからの新しいリクエストを処理できません。 この場合、リクエストの合計数（4）は、チャットコールに設定された最大値（3）を超えます。 オペレーターElenaはクライアントと連携して、電子メールとチャットコールを処理します。 行われた設定を考えると、彼女は新しいクライアントからのリクエストを受け入れることができます。
結論として、 RCEモデルのオペレーターロード設定が実際にどのように見えるかを見てみましょう。 これを行うには、 コールセンター管理者のアプリケーションに入ります。このアプリケーションでは、この例のオペレーターが作業します。
図に示されているいくつかの設定。 以下。
1列目（ 各インタラクションで取得されるキャパシティシェア ）は、各タイプのリクエストを処理する際のオペレーターの混雑度を決定します。 この例では、音声通話にはオペレーターの時間の100％がかかります（つまり、音声通話は1つしか処理できません）。 チャット：30％（3つのチャットセッションに同時に参加できます）; 電子メール：20％（5つの電子メールと同時に動作可能）。
2列目（ インタラクションを受信するために必要な予備容量 ）は、このタイプの通話をオペレーターが自由に受け入れることができる量を決定します。
たとえば、新しいチャットに参加するには、少なくとも30％の空きが必要です（つまり、70％がロードされている）。 つまり、3つのチャット（ダウンロード90％= 30 + 30 + 30）または電子メール+音声（ダウンロード120％= 20 + 100）を処理する場合、新しいチャット要求では、オペレーターは処理できません。電子メール+音声が完全に占有されているため、オペレーターは10％（100-90）チャットを利用できません。 また、オペレーターが1つのチャットセッションに参加し、電子メール（50％を読み込む：30 + 20）を処理すると、50％無料（100-50）であるため、チャットリクエストに答えることができます。
したがって、この例では、新しいチャット要求はオペレーターGalina （チャットに参加している）およびIrina （電子メール+音声）ではなく、オペレーターElena （チャット+電子メール）に配信されました。
3列目（ Precedence ）は、マルチチャネルコールセンターをオペレーターに配信する際のコール処理の優先順位を決定します。 オペレーターをロードすることで複数のタイプの呼び出しを処理できる場合、優先順位が最も高い要求が最初に処理されます。 たとえば、チャットセッションと電子メールのリクエストを受信した場合、チャットはElenaに配信され、電子メールはキューに入れられます。 チャットの優先度が高くなっています。
したがって、かなり単純な設定を使用して、マルチチャネルコールの分散アルゴリズムの正確な実装が実行されます。これについては、この記事で詳しく検討しました。
結論：
リッチコンタクトエクスペリエンスの概念の実装は、2つの問題の解決に役立ちます。
1）コール処理時間を短縮し、失われたコールの数を減らします
2）クライアントに現時点で都合の良い通信にチャネルを使用する機会を提供する（たとえば、1つのチャネルで通信を開始する、別のチャネルを何度でも切り替える、または使用する）。
その結果、最新のコミュニケーションチャネル（音声、電子メール、チャット、ソーシャルネットワーク、ビデオ）で作業するとき、および将来新しいチャネルを接続するときの両方で、マルチチャネルの使用の効果が高まります。