第2回 CMSのECHとsendAsciiパッケージについて（第2弾）
アバイア プロフェッショナルサービス シニアコンサルタント
長崎智洋
今回も前回に引き続き、ECHのご紹介をします。
「こんな使い方はできないだろうか？」という切り口で書かせて頂きたいと思います。
ご存知の通り、ECHとはCMSのコールデータの生データです。
生データであるがゆえに色々な分析に使うことができます。
それでは、活用のヒントを一つ一つ見て行きましょう！
■通話時間・後処理時間の分布を知りたい
CMSのコールプロフィールレポートは、応答時間と放棄時間の分布のレポートしか提供していません。ECHのデータは、生データなので、1件1件の通話時間・後処理時間を求めることができます。
したがって、これを使えば、例えば、あるスキルの通話時間の分布、後処理の分布などを求めることができます。
（１分以内の電話が100件、１分～2分の電話が200件、2分～3分の電話が300件など）
また、Avaya CMSのコールプロフィールレポートの間隔は１０個しか定義できないですが、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”になるなどの例外が存在します。
ただ、これは誤差と扱ってもよいと思います。
■１人のお客様は、１日に何回センターに電話を架けて来ているのだろうか？
放棄呼が多いお客様で導入したケースで以下のようなことがあったそうです。
あるお客様の電話にでると、「バカやろー！」と言って切られた。
理由がわからない。電話に出たエージェントさんは何も悪くないはずだ。
では、なぜ、このお客様は怒っているのだろうか？
これをECHのデータを元に調べて見たそうです。
すると、ある窓口に電話をしたが、繋がらないので、同センターの他の窓口の電話番号にも架けまくりました。
繋がったと思えば、「こちらではないから架けなおし下さい」と言われた。
そして、何度架けてもなかなか繋がらない。
ようやく繋がったが爆発して、「バカやろー」となったとか。
このようなこともECHがあるからこそ、トラッキングできるようになります。
ちなみに、「一人のお客様が１日に何回センターに電話してきているのか？」を調べるためには、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のミドルウェア）を使えば、放棄の時間・回数を把握することができます。
これを使って、例えば、３時間以内に放棄時間・回数がしきい値を越えた場合、
そのお客様を優先して接続するといったことが可能となります。
■イレギュラーコールの発見（”平均値のマジックの罠”からの脱却）
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では、転送前と転送後でも同じ値になります（１つの呼として扱っているのですね）。
さらに、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 MAPやCMS Webサービスなど、我々がお手伝いできるラインナップを揃えつつあります。
これはと思うものがございましたら、ぜひ使ってみて頂ければと思います。
第3回
