コンタクトセンターの科学:「大きいことはよいこと」

-必要な回線数を求めよう
Blog – Avaya Japan

Blog - Avaya Brasil - Seguranca_digital_Avaya

アバイア プロフェッショナルサービス シニアコンサルタント 
長崎智洋

前々回前回とアーランの基礎を学びました。すでにご活用されていますでしょうか?
エージェント数の算出だけてなく、例えば、IVRに必要なポート数(回線数)を求めることにも応用できます。

さて、今回は、前回学んだ内容を応用してみましょう。はじめてこの連載を読まれる方は、前回分を先におさらいして下さい。

大きいことはよいこと

前回学んだアーランを使って、1つの大きなサイトと3つの小さなサイトを数学的に比較してみましょう。
同じスキルの電話を受けるのに、ある条件下でシングルサイトと3つのマルチサイトで対応する場合とで、どのような違いがあるでしょうか?

以下の条件で考えてみましょう。

平均通話時間 191秒
平均後処理時間 180秒
1時間のコール数 180コール/サイト (3サイト合計540)
サービスレベル目標時間(秒) 20秒

 

数学的に立証されているスケールメリット - アーランC計算により -

同じサーベルレベルを維持するのに、シングルサイトでは63人のエージェントで済むのに対し、マルチサイトは、23x3=69人のエージェントが必要となります。
その差、なんと 69-63=6人になります。ピーク時に6人ものエージェントが少なく済むということは、センターにどのようなメリットがありますでしょうか?

逆に、シングルサイトに必要な63人で、マルチサイトで対応したとすると、サービスレベルは、58%にしかなりません。

ばらばらのセンターでばらばらに受けるより、まとめた方がよいのです。
これがスケールメリット、つまり、大きいことは良いことということなのです。

5分で理解するアバイアのIP PBXとは?

ちょっとだけ話が脱線しますが、この後に話すことに関係があるので先に説明させて下さい。

今のアバイアのIP PBX、Avaya Aura Communication Managerの前身に、DEFINITY(ディフィニティー)というPBXがありました。この時代のPBXは、呼制御をするプロセッサー(CPU部分、人間で言うと頭にあたる)と、電話機や局線を収容するパーツ(手足にあたる)が、1つのボディーに収められていました。そのため東京と大阪にそれぞれセンターがある場合、東京に1セット、大阪に別の1セットを用意する必要がありました。

TDMベースのPBX

ここにIP PBXビックバンが起きました。頭にあたる部分と手足にあたる部分を分離しIPネットワークで繋ぐ構造になりました。これにより、ネットワークさえ繋がっていれば、頭と手足を別々の場所に置くことができるようになったのです。

TDMベースのPBXからIP PBXへ

言い換えれば、1箇所のサイト(例えばデータセンターや東京)に頭をおいてしまえば、他の場所にあるサイトには手足を置くだけでよくなりました。
複数サイトがあっても、実は1つの頭だけで対応できる。言うなれば、マルチサイトだけど、バーチャルなシングルサイト - 分散型IPコンタクトセンターなのです。

アバイアのIP PBX-分散型IPコンタクトセンター

物理的にはマルチサイトですが、システム的にはシングルサイト(1つのシステム)であるがゆえ、CMSは1台ですみます。コールフローもサイト共通で持つこともできますし、1つのスキルの電話をサイトでまたがって対応できるようになります。ハードやライセンスなども圧縮できるので、コストも下げることができるでしょう。

この仕組みでは、「頭と手足の間のネットワークが切れたらどうなるのか?」、「障害に弱いのでは?」という疑問を持たれる方もいらっしゃいますでしょうが、ご安心下さい。もちろん、考えられています。

頭と手足の間のWANのネットワークを二重化することが可用性をあげることはもちろんなのですが、手足にあたるゲートウェイには、"小さな頭"をつけることができます。この"小さな頭"で、ネットワーク障害時にメインの頭と通信ができなくても呼を処理することができます。また、サーバー側(頭)の方も2重化構成がとれます。さらに、頭の分身を他のサイトに置く構成をとることもできるのです。メインが障害のときは、分身が代わりに呼処理をします。

スケールメリットを生かそう

分散型IPコンタクトセンターがどのようなものかお分かりになりましたでしょうか?
ではここで話を元に戻して、スケールメリットを生かすためにはどうしたらよいでしょうか?
3つ考えることができます。

スケールメリットを活かすためには

①マルチスキル化で、エージェントプールを大きくせよ。

まずは、マルチスキル化です。1人のエージェントが複数のスキルを持つことにより、全体で1つの電話に対する受け皿(エージェントプール)を大きくすることができます。

②複数サイト(複数PBX)ならばBSRでバーチャル化せよ。

これは物理的にもシステム的にも複数のサイト(複数のシステム)の場合、アバイア同士のPBXであれば、バーチャルルーティング機能の1つBSR(Best ServiceRouting:ベストサービスルーティング)を利用できます。この機能を使えば、複数サイトをあたかも1つのセンターとして振舞うように呼をルーティングすることができます。

③バーチャルなシングルサイト(分散型IPコンタクトセンター)を利用せよ。

これはIP PBX、分散型IPコンタクトセンターを使った場合になります。拠点は複数あるが、それを1台のIP PBXでカバーします。そのようにすれば、結局シングルサイトと同じことになります。同じスキルの電話をサイトにまたがって受電するため運用の問題をクリアする必要があるかもしれませんが、スケールメリットを十分に活用することができるでしょう。

コンタクトセンターをネットワーク化しこれらを利用することで、できる限りリソースを有効活用し、お客様を少しでもお待たせせず、スケールメリットで高いパフォーマンスを追及できるでしょう。

ロケーションIDを利用しよう

さて、ここからはCMSのレポートのお話です。
バーチャルなシングルサイトの構成の場合、1つのスキルが複数のサイトで受電されることになります。ここで1つ問題が出てきます。その1つのスキルがサイト毎に何件応答されたかをどうやって知るのでしょうか?

ここで利用できるのがロケーションIDです。ロケーションIDとは、電話機がどこのロケーションに所属しているかがわかるIDのことです。エージェント電話機にログインすると、ロケーションIDがCMSに渡されます。
では、これを利用しどのように求めるのかというと、方法は2つあります。
1つは、CMSのエージェントのテーブルを利用します。エージェントテーブルには、エージェントが、どこのロケーションIDにログインして、どのスキルで、何件応答できたかの情報を持っています。これを利用すれば、ロケーションIDをキーにして、サイト毎何件応答されたのかを計算することができます。なお、スキルやVDNのレポートには、ロケーションIDを含まないため、計算することはできません。

2つめの方法は、ECHのデータを利用します。ECHのデータは、呼ごとの明細情報となり、いつ・誰が・どのスキルで・どのロケーションでという情報を含んでいます。これを利用すれば、サイト毎(ロケーション毎)に応答した件数を計算することができます。
※ECHについては、この連載の第1回、2回を参照して下さい。

ロケーションIDを利用する

1つのシステムでもサイト毎に応答するスキルを分けたい

実は、先に説明したBSRは、複数のPBXをあたかも1つのPBXのようにするだけでなく、複数のスキルをあたかも1つのスキルかのごとく、ルーティングすることもできるのです。
これを利用すれば、物理的なサイト毎に、応答するスキルを分けることができます。1つの内容の電話をサイト毎(スキル毎)にCMSでレポートすることができます。

シングルサイトのBSR

おわりに

さて、今回は基礎を使って応用してみましたが、いかがでしたでしょうか?
次回もアーランを使った別の応用を考察してみたいと思います。

第10回

「今さらですがCTIを使いたい!」
-CTIをもっと使え(前半:理論編)