CMSのECHとsendAsciiパッケージについて(第2弾)

Blog – Avaya Japan

Blog - Avaya Brasil - Seguranca_digital_Avaya

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

今回も前回に引き続き、ECHのご紹介をします。
「こんな使い方はできないだろうか?」という切り口で書かせて頂きたいと思います。

ご存知の通り、ECHとはCMSのコールデータの生データです。
生データであるがゆえに色々な分析に使うことができます。

それでは、活用のヒントを一つ一つ見て行きましょう!

■通話時間・後処理時間の分布を知りたい

CMSのコールプロフィールレポートは、応答時間と放棄時間の分布のレポートしか提供していません。ECHのデータは、生データなので、1件1件の通話時間・後処理時間を求めることができます。
したがって、これを使えば、例えば、あるスキルの通話時間の分布、後処理の分布などを求めることができます。
(1分以内の電話が100件、1分~2分の電話が200件、2分~3分の電話が300件など)

また、Avaya CMSのコールプロフィールレポートの間隔は10個しか定義できないですが、ECHのデータを元にすれば、見たい間隔を自分で自由に作ることが可能です。

■CTI側(業務アプリ)のデータとマッチングしてさらに高度な分析

CMSのECHデータのコールIDがありますが、CMSのコールIDとCTIのコールIDは違います。
しかし、ECHのデータの中には、UCID*(ユニバーサルコールID。以下UCID)があります。
また、CTI側のイベントにも、UCIDがあります。
つまり、ECHのデータとCTIのデータをマッチングさせることにより、CMS側の情報とCTI側の情報を統合して、さらに高度な分析ができるようになるのです。

CTI側でもコールワークコードのようなコールリーズンを入力していれば、リーズン毎、または、製品・サービス毎の通話時間・後処理時間の把握など、見たい切り口で、分析が可能となります。

もちろん、ACM・CTIクライアント側でUCIDを扱うように設定する必要もありますし、履歴データには、UCIDを入れる仕組み作りが必要となります。

注意点としては、ブラインド転送(相手の状況を確認せずに転送してしまう)時、CTI上ははじめに受けた呼のUCIDと、転送呼のUCIDが同じになりますが、CMSでは転送毎に異なります。
また、ログインをしていない電話機から転送し、さらに、ログインをしていない宛先へ転送したときに、CMSのUCIDが”00000000000000000000”になるなどの例外が存在します。
ただ、これは誤差と扱ってもよいと思います。

■1人のお客様は、1日に何回センターに電話を架けて来ているのだろうか?

放棄呼が多いお客様で導入したケースで以下のようなことがあったそうです。

あるお客様の電話にでると、「バカやろー!」と言って切られた。
理由がわからない。電話に出たエージェントさんは何も悪くないはずだ。
では、なぜ、このお客様は怒っているのだろうか?

これをECHのデータを元に調べて見たそうです。
すると、ある窓口に電話をしたが、繋がらないので、同センターの他の窓口の電話番号にも架けまくりました。
繋がったと思えば、「こちらではないから架けなおし下さい」と言われた。
そして、何度架けてもなかなか繋がらない。
ようやく繋がったが爆発して、「バカやろー」となったとか。

このようなこともECHがあるからこそ、トラッキングできるようになります。

ちなみに、「一人のお客様が1日に何回センターに電話してきているのか?」を調べるためには、ECHデータを取り込んだデータベースに、以下のQueryを投げてみましょう。

SELECT CALLING_PTY, COUNT(*)  ・・・発信者番号、件数
FROM call_rec  ・・・コールレコードテーブルから
WHERE SEGSTART BETWEEN '2007-06-28 00:00:00' AND '2007-06-28 23:59:59' ・・・6/28分のデータに対して
AND
LEN(CALLING_PTY) >=9     ・・・電話番号が9桁以上
GROUP BY CALLING_PTY   ・・・電話番号でグループ集計
ORDER BY COUNT(*) desc  ・・・件数が多い順に降順

上記のSQLで、発信者番号と架けた来た回数を、回数の多い順に表示することができます。
これで電話番号がわかれば、あとは、発信者番号をキーに検索して生データを見れば、いつ・どこに・どのようにを知ることができます。
何かおかしいな?というものがあれば、録音装置のデータを聞いてみる必要があるでしょう。
逆に、録音装置から発信者番号がわかれば、逆の検索もできるでしょう。

ちょっと話が変わってしまいますが、こんなこともできます。
Avaya IC(CTIのミドルウェア)を使えば、放棄の時間・回数を把握することができます。
これを使って、例えば、3時間以内に放棄時間・回数がしきい値を越えた場合、
そのお客様を優先して接続するといったことが可能となります。


■イレギュラーコールの発見(”平均値のマジックの罠”からの脱却)

CMSのヒストリカルデータ構造はサマライズ・平均化されてしまっています。
平均値の場合、本当に知りたいイレギュラーコールも、平均の中に埋もれてしまっています。

長時間保留・長時間通話・長時間後処理などのイレギュラーな通話を把握するためには、ECHのデータが必要になってきます。

また、平均値のマジックではないですが、「HOLDABN」という項目は、エージェントが保留中に放棄されたものですので、このような数値をみるのもイレギュラーコールの発見につながるかもしれません。

■UUIのデータを活用

例えば、IVRからエージェントへ転送するときに、IVR側で、過去に通ったメニューや、顧客のランク、その他の情報を付与すれば、ECHのデータでそのUUIを取得することができます。
これを使えばECHデータだけでよりビジネス的なレポートが可能となります。

*)UCIDとは

UCID(Universal Call ID)UCIDは、呼を識別するユニークな番号を提供します。
CTIの着信・応答イベントなどには、CallIDが付与されるのはご存知か思います。
CTIクライアントは、このCallIDをキーにして、自分が扱っている呼の識別をします。
ただ、CallIDは5桁までの数値を使いまわしているため、重複したIDが存在してしまいます。
そこで、呼を識別するためのユニークなIDとしては、UCIDがあります。

UCIDの仕様は以下のとおり
複数ノード(複数のACM・IVRなど)にまたがってユニークであることを保証するID(20バイト)で、以下のフォーマットになります。

 UCID=NNNNNCCCCCTTTTTTTTTT (20バイト)

 NNNNN = Network Node ID (leftmost 5 characters) <= PBX毎に付けるID
 CCCCC = Call Sequence Number (middle 5 characters) <= コールIDのこと
 TTTTTTTTTT = timestamp (rightmost 10 characters). <= 1970からの経過秒

また、UCIDはトラッキングの目的に使うことができます。
CallIDは、転送すると新しいCallIDになりますが、UCIDでは、転送前と転送後でも同じ値になります(1つの呼として扱っているのですね)。
さらに、IVRを経由したり他のサイト(もちろん相手はACM)に転送したとしても、呼には同じUCIDがくっついていきます。
したがって、呼が発生してから最終的にどうなったかという”ゆりかごから墓場まで”のトラッキングが可能となるのです。

UCIDを使うためには、ACMのFeature-Related System Parameters フォームで
Create Universal Call ID(UCID)?をYにし、UCID Network Node IDに任意の番号を入れる必要があります。
また、CTIのイベントに含ませるには、Send UCID to ASAI?をYにする必要があります。

■おわりに

CMSをさらに活用するために、ヒストリカルの分析にはODBCや今回ご紹介したECHの他、リアルタイムのデータの活用には”見える化”を手助けするAgent MAPCMS Webサービスなど、我々がお手伝いできるラインナップを揃えつつあります。
これはと思うものがございましたら、ぜひ使ってみて頂ければと思います。

第3回

「コールリーズンを取ろう!」