Twilioコールセンターシステム（Twilio-MiniCC）にヒストリカルレポート機能を搭載しました。MySQLにデータを貯めるので、レポート参照はいろいろなツールを使えばいいでしょう、というのを言い訳にして、データ収集機能までの実装になります。
アプリケーションなんだから、適当なところでデータベースにデータ入力しておけばいいだろう、くらいのノリだったのですが、結構大変でありました。さんざん調べたり、考えたりして、とりあえず以下の３ポイントで、取れるデータをすべて取ってみたつもりです。さすがに不要なので、標準リクエストパラメータからAccountSidは抜きました。
これからの記述でおかしなところやもっとカイゼンするべき点があったら、ぜひご指摘ください。
データ取得のポイントは以下の３つ。本当はIVRの分岐点でもログを取って、お客様がどのようなルートを通っているのかを把握するべきなのですが、今回は割愛しました。
- キューのお客様側（Enqueue）から出た時
- キューのオペレータ側（Queue）から出た時
- 通話終了時
Twilioのキューの考え方はこちらが参考になります。お客様とオペレータとで同じQueueに入ります。入り方が異なっていて、お客様はTwiMLのEnqueueタグ（動詞）で、オペレータはDialタグ（動詞）のQueueタグ（動詞）で入ります。
まずはじめに、キューのお客様側（Enqueue）から出た時のデータ取得方法です。
Enqueue動詞ではaction属性が設定できます。ややこしいのですが、Enqueueのaction属性は、以下の動きになります。日本語サイトはやや怪しい（一部しか翻訳されていないところがある）ので、英語のサイトから引用します。
In the case where a call is dequeued due to a REST API request or the verb, the action URL is requested right away. In the case where a call is dequeued via the verb, the action URL is hit once when the bridged parties disconnect. If no ‘action’ is provided, Twilio will fall through to the next verb in the document, if any.
Twilio-MiniCCでは、今のところDial動詞のQueue動詞を使って呼をキューから出しますので、Enqueueのaction属性に指定されたURLは、接続された相手同士が切断されたときに、一度実行されることになります。
（キューから出たときではありません）
Enqueue動詞のaction属性でデータを取る意味は、「放棄呼」の情報を取ることができる点にあります。
一般的にコールセンターにおいて、お客様がキューに入って自分から切断した場合、その呼は「放棄呼」とされます。放棄呼が発生した場合には、actionに指定してあるURLが実行されます。そのURLで、データベースにデータを登録するプログラムを書いておけば、放棄呼の情報を取得することが出来ます。具体的には、QueueResultカラムでhangupが記録されることになります。放棄呼はコールセンターにとっては良くないことです。本来受け付けるべき呼を受け付けられなかったわけですから。放棄呼のデータを収集し、対策を打つことが極めて重要です。
なお、特に記載はないのですが、Enqueueのaction属性は、おそらく非同期で実行されています。Basic認証を使用している場合、以下のように書くとエラーが発生します。TwilioのAPPモニターに「11200 – HTTP 復帰エラー」が出て、内容を見ると、「401 Authorization Required」が出ます。
$response->enqueue('キュー名', array('waitUrl' => 'wait.php',
'action' => 'action.php');
そのため、以下のように修正する必要があります。
$response->enqueue('キュー名', array('waitUrl' => 'wait.php',
'action' => 'http://A:B@C/D/action.php');
A: Basic認証のユーザ名
B: Basic認証のパスワード
C: Webサーバのドメイン名
D: action.phpを置いた場所
あと、Twilio-MiniCCにおいて、本機能はexit_enqueue.phpで実装されているのですが、何もレスポンスが無いとオペレータから切断したときエラーメッセージになるため、空のTwiMLを出力するようにしています。
続いて、キューのオペレータ側（Queue）から出た時のデータ取得方法です。
Queue動詞においては、url属性を指定できます。英語のサイトから引用します。
The ‘url’ attribute takes an absolute or relative URL as a value. The url points to a Twiml document that will be executed on the queued caller’s end before the two parties are connected. This is typically used to be able to notify the queued caller that he or she is about to be connected to an agent or that the call may be recorded. The allowed verbs in this TwiML document are Play, Say, Pause and Redirect.
Queue動詞はオペレータが使うものなのですが、Queue動詞のurl属性には「お客様側」で実行したいことを書きます。ややこしい。オペレータとの接続前に、録音することをアナウンスするとか、そういうために使うそうです。お客様にアナウンスを流しつつ、裏でデータベースにデータを格納すれば、Queueのデータを取得できます。
最後に通話終了時のデータ取得方法です。
「How To Track and Report Your Twilio Usage」という記事に書いてありました。通話終了後にStatusCallback Requestを投げることが出来、そこでレポートを取得します。
StatusCallback occurs asynchronously and after a call has completed, this is an opportune time to update properties of your local call record. Your application also has more flexibility at this time to process database updates or compile larger reports without impacting user experience.
非同期処理なので負担もかからずオススメということらしい。
デフォルトではオフ。Twilioのページから、「電話番号」をクリックした後、 「Optional Voice Settings」をクリック。表示される「Status Callback URL」に、プログラムへのURLを書けばオッケー。通話終了後に実行されます。Basic認証を使っている場合は、先ほどのEnqueueのときと同様の書式にする必要があります。
最後に、データベース構造なのですが、まず型がわかりませんでした。Twilioのサンプルをいくつか見ましたが、全部SQLiteのTEXT型になっているし。
REST APIの資料とか見て、MySQLの型を決めましたが、これでいいのかどうかはわかりません。そもそも正規化とかしてないので、まだまだ検討が必要そうです。
ともあれ、Twilio-MiniCCのVersion 2が完成しました。
ヒストリカルレポート収集機能の追加と同時に、データベースアクセスをPDOにしたり、設定共通クラスを作ったりと、ソースコードをカイゼンしています。
Webクライアントも作成済みなのですが、まだ公開するまでのレベルではないので、次のバージョンとします。