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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

強制切断呼について

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

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

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

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

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

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

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

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

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

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

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

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

“check skill”コマンドの例：

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

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

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

Queue-to とＣｈｅｃｋの違い

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

おわりに

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

第14回

CMSの謎を解け －その１