こんにちは、@24guchiaです。
TwilioのConferenceとTaskRouterについて、以前、下記記事を書きました。
それに引き続き、Agent Conferenceで
モニタリングとウィスパリングを実装しましたので、
ハマりどころや考え方について、まとめておきます。
目次
そもそもモニタリング、ウィスパリングとは？
モニタリングとは
通話に第三者が参加し、通話をリアルタイムで聞くことができる機能です。
これはTwilioに限らず、ビジネスフォンであれば、
一般的に提供されている機能のようです。
一般的とはいえ、僕はTwilio触るまでは知りませんでしたが・・・
ユースケースとしては、売れっ子の営業の通話を聞いて、
どんなふうに顧客の囲い込みをするかというようなことを
参考にするとのことです。
ウィスパリングとは
通話に第三者が参加するのはモニタリングと同一ですが、
決定的な違いはその参加者が通話している一方の話者に対してだけ、
話すことが出来ます。
具体的には下記の図の通りです。
この図でいうと、CarolはBobに参加していることをさとられず、
Aliceに対してだけ、耳打ちすることができます。
図にするとこんな感じです。
| 参加者の名前 | 聞こえる | 聞こえない |
|---|---|---|
| Alice | BobとCarol | – |
| Bob | Alice | Carol |
| Carol | AliceとBob | – |
ウィスパリングも一般的なビジネスフォンで提供されている機能です。
最初に考えた人、天才ですね。
ユースケースは、モニタリングとは異なります。
うまく顧客の囲い込みをできていない営業に対して、
売れっ子営業が今こういうことを言え！というような
アドバイスをリアルタイムで耳打ちするらしいです。
混乱しそう。
実装について
技術的にはめっちゃ難しいということはないです。
Agent Conferenceを利用し、PSTNへの架電する方法は
下記Twilioのブログが役に立ちます。
Outbound Conference Call APIという項を読んでください。
そのまま流用できます。
これを利用し、二人での通話ができれば、
後は下記ドキュメントにある通話に参加するAPIやTwimlで
参加者を追加し、モニタリングであれば、mute=true、
ウィスパリングであれば、coach=call sidにするだけです。
そう、ざっくりと言えばこれだけなのですが、
やっぱりハマりどころはあります。
取次との兼ね合いを考える必要がある
以前の記事でも記載した通り、顧客を残して、
営業が抜ける際にhold=trueにすることで保留を実現しています。
取次はこの保留状態のConferenceに参加し、
保留解除して、取次を開始します。
Conferenceに参加する文脈がモニタリングとウィスパリングで更に増えるため、
この部分をうまい設計にしないと、ソースコードがぐちゃぐちゃになります。
UIの作り込みが大変
Twilio Syncを使ったリアルタイム在席状態確認ページに
モニタリングとウィスパリングを開始できるボタンを配置しました。
通話が開始したと同時にConference Sidを通知したりといった
リアルタイム部分が大変でした。
リアルタイム性に振り回される
Twilioのようなプロダクトを利用するとよく分かると思いますが、
リアルタイム性が高いプロダクトは考えるべきことが多いです。
モニタリングやウィスパリングしようとしたら、
通話が終わっていた場合などを正しく制御する必要があります。
先日のテストでは、唯一モニタリング、ウィスパリングしようとしていた
通話がタイミングよく通話終了した場合、
正しくエラーメッセージが表示されることという部分でだけ
バグが発生しました。
何回も手元で試したのに、テストで別の人にテストしてもらったら、
バグが発生し、驚きました。
デバッグがめちゃくちゃつらい
Agent Conferenceは仕様として250人まで通話に参加ができます。
現実的に250人が通話に参加しているというのはあまりありえませんが、
通話に4~5人参加しているという状態は、
モニタリング、ウィスパリングの機能提供すると普通に発生します。
そんなことある？ってお思いの方もいらっしゃるでしょうが、
下記のようなパターンが発生します。
- AliceがPSTNにあるBobの電話機に架電する
- Carolがモニタリングする
- DaveがAliceにウィスパリングする
たったこれだけで、4人も参加する通話が発生します。
これはごく一般的なユースケースです。
そのため、このユースケースをデバッグする必要があるのですが、
人間の耳は2つしかありません。
急に何言ってるんだ、と記事を閉じる前に下記写真を見てください。
上記ユースケースを1人でデバッグする際に必要になる
機材を順々に付けていった写真です。
- AliceがPSTNにあるBobの電話機に架電するのをデバッグする図
- Carolがモニタリングする図
- DaveがAliceにウィスパリングする
めちゃくちゃですね。
デバッグが大変なのが伝わるとうれしいです。
モニタリングとウィスパリングは僕が1人で実装したため、
いつもこの大変さと向き合っていました。
特にモニタリングやウィスパリングでは、
話し声が相手に送られないことや、
特定の相手にだけに話し声が送られることを確認する必要があります。
音が聞こえないことの確認はなかなかやっかいでした。
デバッグの大変さと向き合う
先に挙げたような大変さと向き合うには、
下記のような方法が考えられます。
人海戦術編
言葉通りです。人海戦術と言ってますが、
たった(?)4人テスターがいれば、全ユースケースを網羅できます。
最低限の組み合わせは下記です。
- 通話者2人と, モニタリング複数人(2人以上)
- 通話者2人と, ウィスパリング複数人(2人以上)
- 通話者2人と, モニタリング1人、ウィスパリング1人
この組み合わせの通り、最低4人必要です。
とはいえ、モニタリングやウィスパリングは僕のような
電話関連の開発者や実際に使ったことのある営業であればともかく、
普段ビジネスフォンを使わない人は、そもそもどういう状態が正解かが分からないため、
しっかりと説明してあげる必要があります。
しかし、デバッグのたびに4人も人を投入していたら、
人件費がとんでもないことになるので、
ある程度以上の精度を持って、少ない回数のテストで
合格できるよう実装を進めていきましょう。
仕様で防ぐ編
実装するにあたり、リアルタイムで通話に参加できる人数を
3人までにしてしまうという戦術です。
3人であれば、左耳にAliceのヘッドセット、
右耳にBobの携帯を当てた状態で、Carolのマイクをこすれば
ちゃんとモニタリング、ウィスパリングできているかどうかを確認できます。
ロボットを投入する編
これは試していないジャストアイデアなのですが、
CarolとDaveの役割をGoogle AssistantやAlexaで代用する方法です。
AliceかBobのマイクから、Ok, Googleと呼べばGoogle Assistantが反応し、
Alexaと呼べばAlexaが反応してくれるでしょう。
その後、各アシスタントに今の時間を教えてと聞けば、
その返答が電話機越しに聞こえるかどうかを確認することで、
正しく音声が届かないことが確認できます。
個人的にはかなり良い案だと思ってるので、そのうち試してみたいです。
まとめ
技術的にはAgent Conferenceの理解さえあれば、
そこまで実装は難しくないモニタリング、ウィスパリングについてまとめました。
現在の通話をリアルタイムで更新する必要がない仕様にしたり、
参加できる人数を3人までの仕様にしたりというような工夫をすれば、
すばやく導入も可能かと思われます。
一般的なビジネスフォンでも提供されている機能のため、
実際に使用する営業からの反応も上々です。
現場で使われていくにあたり、
売上の改善や予想もしてないような使われ方をすると思うので、
楽しみにしてます。