目次
この記事の主張
- Twilioを用いたWebCTI構築で一番難しいのは受電である
- 保留も難しいと言われるが、保留の実装はドキュメントだけで解決する
- 手を動かす前に、仕様洗い出しと実装のイメージ作りをしましょう
こんにちは、@24guchiaです。
Twilio Advent Calendar 2017 の9日目です。
弊社では営業管理ツールリニューアルに伴い、
電話システムも某IP電話会社から、Twilioへの置き換えを行い、新たにCTIの仕組みを導入しています。
導入にあたり、仕様の洗い出しや提案、実装から各社間の調整まで仕事させてもらっています。
僕はTwilioに触る前まで、IP電話のサービスを使ってなかったし、Twilioは名前も知りませんでした。
1年ほどで得た経験を基に受電の難しさをまとめますので、参考にしてください。
この記事に書いてある内容はTwilioに詳しい人に質問できる環境にありながらも、
基本的には1人で得た知識と経験のため、これがベストプラクティスではないです。
むしろそんなのあったら教えて欲しい。
なぜ受電が難しいのか
IP電話やTwilioについて詳しくない人が、
そもそもネットワークを用いた電話の仕組みを理解できていないからです。
携帯電話はほとんどの人が持っていますが、仕組みが異なります。
電話番号1つに対して、通話を発信・着信できる端末が複数ある
普通の電話は番号1つに対して、発信・着信できる端末は1つだけです。
ですが、Twilioでは1つの電話番号で、複数人が同時に発信・着信できます。
一般的に思い込んでいる、電話番号と端末が1対1なのに対し、Twilioは一対多の関係にあります。
もちろん、1対1の作りでも構築できますが、月額108円が最低でも1人ずつにかかり、
管理コストも膨大なことになります。
これはTwilioが提供しているJavaScriptライブラリや、iOS/AndroidのSDKを使用し、
ブラウザなりアプリなりで仮想電話端末を実装することで解決します。
言われれば当然ですが、いざやってみないと身にしみて分からないこともあります。
同じ電話番号にかかってきた通話を誰に割り振るかを考えないといけない
先のことを理解した時に、この問題にぶつかります。
Twilioへ指示を出すことで誰に割り振るかの指示は出せますが、
誰に割り振るか自体は自分たちで考える必要があります。
この時点で、システムだけでは解決できず、現場で仕事している
営業やオペレーターなどと連携が必要です。
また、先の事実はエンジニアであればすぐに理解できるかもしれませんが、
必ずしもITリテラシーの高くない人へ納得性のある説明をした上で、
現場でどう割り振るのがベストなのかコミュニケーションを取る必要があります。
新しい技術に触れながら、現場の知識も取り込んでいかないといけない。
リアルタイムとの戦い
仕様も無事に決まりました。次に襲いかかる問題がこれです。
一般的なWebエンジニアであれば、実戦経験の少ない
リアルタイムとの戦いが待っています。
受電した通話を誰に割り振るかは決まっても、
その人が在席していないとその通話は空振りになりお客様を待たせることになります。
そこでかかってきた時点のオペレーターの状態を取得する必要があります。
リアルタイムで状態を取得する方法
下記3つが簡単に思いつきます。
- DBなどに管理し、逐一問い合わせてみる
- Twilio.Syncを使ってみる
- Twilio.Taskrouterを使ってみる
DBで管理する場合
在席状態を管理するために、逐一ajaxなどでその人の状態をupdateし続ける必要があります
これはサバクラ両方を1人でスクラッチしつつ、
保守フェーズですべて管理する必要があります。
人数が少なければ可能かもしれないですが、あまり現実的ではなさそうです。
Twilio.Syncを使う場合
SyncとはTwilioが提供しているWebsocketを用いた、リアルタイム通信ができる機能です。
最初に僕がやってみたのがこれでした。
Syncを使うとサーバ側実装がなく、インフラの設定や保守が不要で、
使用した分だけの料金で使うことが出来ます。
ただこの機能は検索性が高くなく、500件のデータを入れたSyncを検索した所、
10秒ほどかかってしまい、受電で使うには難しかったです。
人数次第では選択肢に入ってくるかもしれませんが、実装した上で弊社では採用しませんでした。
Syncを使おうとした時の記事は下記を参照。
Twilio.Taskrouterを使う場合
TaskrouterとはTwilioが提供しているACDです。
ACDとは通話を誰に割り振るか分配する機能です。
ロードバランサーというとイメージが付きやすいと思います。
Taskrouterは受電に特化した機能です。最終的に弊社で採用したのはTaskrouterです。
Taskrouterについては、下記記事参照。
Taskrouter実装との戦い
ライブラリは提供されているだけなので、当然実装する必要があります。
実装するにあたり、一番苦戦した点はドキュメントではもっとも単純なケースの例しかなく、
弊社の仕様ではどうTaskrouterを構築し、実装すべきなのかわからなかったことです。
自分のベストを尽くしたつもりだけど、
構築した環境が良いのかどうかは運用フェーズまで明らかにならないと思われます。
デバッグの大変さ
最終的にはPC4台＋サブディスプレイ2枚＋電話機1台＋私用携帯電話1台を用いた
デバッグ構成で実機デバッグをしました。
一般的なTwilioエンジニアの開発風景
受電した通話の情報を元にどのようなタスクが作成され、誰に割り振られるかまでは
実機がなくてもデバッグ可能です。(これもまあまあ大変ですが)
ですが、在席離席の挙動は想定通りか、リアルタイムで在席状態が正しく取得できるか、
クライアントの通話に問題はないか、タイムアウトとエスカレートの挙動の確認など、
実機で試さないとわからないことが多いです。
物理的にデバッグ環境構築が大変なのは初めてでした。
構築した後もなかなか大変なデバッグ作業になります。
すべてを乗り越えて
晴れて受電の機能が完成です。
受電1つ取ってもこれだけの大ボリュームが待っています。
特に失敗したなと感じたのは、Syncの速度感をもっと早く調べておくべきだと思いました。
弊社では、SyncもTaskrouterもどっちも使うよくばりプランなので、
Syncの実装自体は有用でしたが、最速の実装かと言われるとそうではなかったです。
弊社の場合、ACDを導入していなかったため、
とりあえず導入するだけでも改善効果が見込めます。
具体的には担当営業へ直接つながることによるお客様への安心感の提供、
取次時間を減らせることへの業務改善です。
タイムアウトやエスカレートの仕組みは今回あまり活用できていませんが、
今後の改善へ手が打ちやすくなる布石として考えています。
やっぱり難しそうだな〜と思うあなたへのメッセージ
https://twiliomeetup.doorkeeper.jp/events/68355
このイベントに参加しますので、ぜひ話しましょう！
僕だけでなく、Twilio開発に携わるエンジニアがたくさん参加しますので、
得られることもたくさんありますよ。
次回予告