「コールフローとCMSレポートとの関係について」

Blog – Avaya Japan

Blog - Avaya Brasil - Seguranca_digital_Avaya

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


みなさま、こんにちは。少しご無沙汰になってしまいましたね。この連載を再開致します。いつまで続くかわかりませんが、またよろしくお願いします。

今回は、コールフローとCMSのレポートの関係について見ていきましょう。なぜ、このテーマを取り上げたのかというと、コールフローによってCMSのレポートが影響を受けるからです。コールフローを上手く使って少しでも上手くレポートできるように、また、日頃のCMSへの疑問の答えになるようなものが提供できればと思います。

マルチプルキューイング(複数同時キューイング)とレポートの関係

 

コールフロー(ベクター)では、3つのスキルまで同時キューイングすることができます。そのような状況で、応答・放棄・他のVDNへ転送のタイミングでレポートにどのような影響があるのか、考察してみましょう。

下図のような、マルチプルキューイングの例を考えてみましょう。
このフローでは、まず、スキル1へキューイングします。そして、15秒後にスキル2へキューイング。さらに10秒後にスキル3へキューイングしています。そして、そこから5秒たったとき、つまり、全体で30秒経過したあとに、「放棄・スキル2で応答・他のVDNへルーティング・スキル2のエージェントに着信中に放棄された」ときに、スキル1・スキル2・スキル3には各々どのような統計がされるかを示しています。

同時キューイングとレポートの関係同時キューイングとレポートの関係

上図がすべての場合を網羅しているわけではありませんが、あとは想像がつくかと思います。これを見て、いくつか注目すべき点を考えてみましょう。

  • 放棄呼について:
    放棄された場合、放棄呼のカウントは1番目のスキルで上がります。(他のスキルも放棄呼となってしまうと、1回の電話で3呼の放棄が上がってしまうため、そうはなりません。)
    あるスキルに着信中に放棄された場合、そのスキルに放棄が上がります。
  • スキルの統計はキューイングされた時点からはじまる:
    例えば、スキル2で応答した場合、ANSTIME(応答時間)が15秒になっている。着信してから15秒にスキル2にキューイングされ、15秒後に応答したからです。
  • デキュー(DEQUEUE)とフローアウト(OUTFLOWCALLS)について:
    この図を見れば、どのようなときにデキューが上がるのかが把握することができます。一旦キューイングされたが、キューから外れた場合にデキューになります。また、デキューとなるのは、メインスキル(1番目)ではなく、2番目、3番目にキューイングされたスキルのみです。メインスキルは、フローアウトが上がります。

この図をみれば、フローアウト、フローイン、デキュー、放棄呼などどのタイミングで計上されるかがおわかりになりましたでしょうか。

Redirection On No Answer (RONA:通称 ロナ、自動離席、不応答転送機能)とレポートの関係

*RONAは、英語読みだと、“ロゥナ”でしょうか。日本人は“ロナ”と言います。

RONAとは、受付可で着信したときに、設定した回数のリング数を超えると、その電話機を自動的に離席状態にし、同じスキルの他の空いているエージェントへリダイレクトする機能です。離席にし忘れて席を立ってしまった場合に、放棄される前に救うことができます。この状態が発生することは、センターばかりではなく、お客様にとってもよいことではありません。したがって、この状態が発生しているかどうかを知りたくなりますよね。

RONAした場合、標準のレポートでは以下の統計が上がります。

 Skillレポートでは:
 フローアウト(OUTFLOWCALLS)に1件
 応答した場合フローイン(INFLOWCALLS)にも1件
 VDNレポートでは:
 フローアウト(OUTFLOWCALLS)に1件


しかしながら、RONAした件数がダイレクトにわかるデータベース項目があります。それは、「NOANSREDIR」です。このアイテムは、VDNテーブル、スキルテーブル、エージェントテーブルにあります。

 VDN・スキル・エージェント テーブル:
 NOANSREDIR: RONAしたときに1件


したがって、どのエージェントでRONAしたかということがわかることもできます。
ただ、残念ながら標準のレポートにはありません。この項目を表示するためには、デザイナーレポートの作成が必要となります。

ヒント: エージェントさんの電話に鳴動中の放棄を知りたい

 エージェントテーブルには、ABNCALLS(放棄呼件数)、ABNTIME(放棄時間)という項目があります。ABNCALLSに件数が上がる場合は、エージェントさんに着信している最中に電話が切れてしまったことを意味します。ただ、ワン切りなどもあるので、一概に悪いとは言えないと思います。その場合は、ABNTIMEを参照すると良いかもしれません。ABNTIMEは合計値になります。
 離席をするときに離席ボタンを押す習慣がないとか、離席にするときに理由コードが押しづらいなど、運用やシステムが使いづらいなどもあると思います。
 イレギュラーとして見るべき項目の1つかもしれません。

強制切断呼について

CMSのレポート上に、強制切断呼というものがあります。これは、ベクターの中で、“disconnect after announcement [アナウンス番号]”としたステップに達したときに、件数が上がります。通常、時間外のアナウンスを流して、こちらから切断するときに使用します。また、アナウンスの途中でお客様が放棄した場合でも、それは放棄呼にはならず、強制切断呼にカウントされます。

しかし、下の右側の図ように、場合によっては、1つアナウンスを流してから、強制切断する場合があります。

問題は、この1つ目のアナウンスの途中で放棄された場合は、それは放棄呼として統計される点にあります。

時間外アナウンスの前のアナウンス
時間外アナウンスの前のアナウンス

VDNインターバル(時間帯)別レポートで営業時間内のみの放棄呼を見ていればよいのですが、VDN日別レポートで見ると、放棄呼として統計されてしまいます。

例えば、営業時間が18時までとします。営業時間外に電話が架かって来ました。右側のフローの場合、1つ目のアナウンスの段階で放棄されると放棄呼として統計されます。VDN時間帯別レポートを見て、18時までの放棄呼を集計するのであればよいのだが、VDN日別レポートを見ると、営業時間外(18時以降)の電話も放棄呼と統計されてしまうことになります。

時間外アナウンスの日次レポートへの影響
時間外アナウンスの日次レポートへの影響

したがって、なるべくならば強制切断の前にはアナウンスは入れないようにすることがおすすめです。

しかしながら、時間外のアナウンスの前に共通のアナウンスを入れる必要があったり、フリーダイヤルの地域アナウンスと時間外アナウンスがかぶらないようにするためにわざと一旦応答させたりするケースがあると思います。そのような場合は、やはりショートアバンダン(例えば10秒以内の放棄)は無視するなどの方法を用いるとよいかもしれません。

キューイングするときのコマンドによるレポートの違い

コールフローの中でスキル並ばせる(キューイングする)ときには、2つのコマンドがあります。
1つ目は通常にキューイングする”queue-to”コマンドとバックアップ専用の“check skill”コマンドです。

”queue-to”コマンドの例:

 queue-to skill 601 pri m
 (スキル601へ優先度Mediumでキューイング)


“check skill”コマンドの例:

 check skill 602 pri m if unconditionally
 (無条件にスキル602へ優先度Mediumでキューイング)


“check skill”コマンドは、if文で条件をつけることができます。

 check skill 602 pri m if calls-queued < 3
 (スキル602の待ち呼が3より小さい場合は、
  スキル602へ優先度Mediumでキューイング)


2つのコマンドの大きな違いの1つは、”queue-to”コマンドは条件を付けられませんが、”check skill”コマンドは、条件をつけて、その条件を満たしていればキューイングすることができます。例えば、スキルの待ち呼が3つ以下ならば、空きエージェントが3人いれば、予測待ち時間が1分以内ならば、とかです。もちろん、 if文に“unconditionally”とすれば、無条件にキューイングすることもできます。

条件をつけてキューイングできる他に、もう1つ大きな違いがあります。それは、”check skill”コマンドで応答された呼は、バックアップACD呼として統計されます。つまり、VDNレポートを見ただけで、何件メインで応答して、何件バックアップで応答したのかが、すぐに把握できるのです。

Queue-to とCheckの違い
Queue-to とCheckの違い

なお、先ほど紹介したRONAして応答された呼もバックアップACD呼に統計されます。

おわりに

さて今回はコールフローとCMSがテーマでしたがお楽しみ頂けましたでしょうか?
少しはCMSの謎が解けたのであれば幸いです。次回も引き続きCMSに関して何か書きたいと思います。

第14回

CMSの謎を解け -その1