2019年11月に、リフォームのマッチングプラットフォーム「ヌリカエ」の開発チームにjoinした竹井です。
もう2022年ですね! 去年は弊社のアドベカで
を執筆しました!
最近、Amazon Connectを使ってプレディクティブコールっぽいものを実現させてみたので、その方法についてご紹介します。
そもそもプレディクティブコールとは?
プレディクティブコールとは、複数のお客様に同時に電話をかけ、その中で最初に通話に出た人と通話を繋ぐシステムのことです。
この動作を図にすると、以下のようになります。
- 架電を開始すると、複数件の電話番号に対して同時に架電を行う
- 複数件架電した中で誰かが着信を取る(今回は顧客2が出たとする)と、最初に着信を取った人以外の通話は終話させる (ここで終話させた方はいわゆる「放棄呼」となる)
- 着信に出た人と架電を開始したコーラーが繋がり通話を開始する
プレディクティブコールっぽいもの とは?
今回実現させた既存のプレディクティブコールに似た機能のことです。
プレディクティブコールはAmazon Connect上に用意されている機能ではなく、また、完全なプレディクティブコールを作る方法が見つけられなかったため、今の形になりました。
今回作成したものの動作は、図にすると以下のようになります。
- 架電を開始すると、複数件の電話番号に対してシステムはほぼ同時に架電を行う
- 複数件架電した中で誰かが着信を取る(今回は顧客2が出たとする)と、Amazon Connectに通話を転送する
- 転送された通話はAmazon Connectのキューに入り、それぞれ同時架電対応者が対応をする
従来のプレディクティブコールと大きく異なる点は、着信に出なかった方でも強制的に終話させることはないので、プレディクティブコールに比べて通話できる可能性のある人への接客回数を多くすることができることです。 (放棄呼を少なくできる)
ずっと「プレディクティブコールっぽいもの」と呼ぶのもなんなので、以降「同時架電」と呼びます。
なぜプレディクティブコールを必要としたのか
長期間通話が繋らないお客様に対しての架電は、通電率が非常に低いです。
しかし、通話に出ていただける可能性もあり、架電をしないわけにはいきません。
そこで、複数人に同時に架電を行えるものを作りました。
ヌリカエのCS(Customer Success) メンバーは、社内自作のツールを使用して日々、お客様へ架電を行っています。
架電業務では、なかなかタイミングが合わず着信が繋がらないお客様もいらっしゃいます。
時間を変えて架け直したりなどは行っているのですが、これが長期間続くこともあります。
中には、そもそもヌリカエのサービスを使う事を辞めた可能性のあるお客様もいらっしゃいます。
(n回以上不通だった場合は通話リストにお客様を出さないようにはしています)
この、いわゆる長期間お客様に架電が繋がっていない "長期リスト" への架電は、通電する確率が非常に低いです。
ですが、これは飽くまでも確率の話ではあり、電話に出てサービスを使用していただけるお客様もいますので、リストにある限りは全てに対して架電を行わなければなりません。
……しかし、これらの案件に人が1件1件対応するのは効率の良いものではありません。
そのため、1人が同時に複数件の架電に対応できるシステムを作りました。
なぜAmazon Connect上で実現しようと思ったのか
弊社ヌリカエチームのCSメンバーが使っている社内自作のツールの架電部分が、Amazon Connectを使って実現しており、放棄呼を少なくできるメリットがあったためです。
他サービスを使う場合、架電案件管理ツールもその他サービスと繋げるための開発を行う必要が出てきます。
今回は可能な限り素早く開発を行いたかったために現在連携させているAmazon Connectを使えないかと考えました。
また、最初に説明した仕組みによって「放棄呼」を限りなく少なくすることが出来るメリットも発見できたためにAmazon Connect上で実現しました。
作成方法
まずは、Amazon Connect側の問い合わせフローの設定を行います。
大切なのは、赤枠の中身です。
同時架電を受け取るためのキューを設定したら、そこへ転送できるようにした問い合わせフローを作成します。
ruby側は、以下のようにすることでシステムからの架電を行います。
def call(destination_phone_number) connect = Aws::Connect::Client.new( region: 'ap-northeast-1', # AWSのリージョンを設定 access_key_id: xxxx, # Amazon Connectへのアクセス権限を持つIAMのアクセスキー ID secret_access_key: xxxx, # Amazon Connectへのアクセス権限を持つIAMのシークレットアクセスキー ) connect.start_outbound_voice_contact( instance_id: xxxx, # 対象のAmazon ConnectのInstance ARNの最後の `/` 以降の文字列 contact_flow_id: xxxx, # ↑で保存した問い合せフローのURLの `/contact-flow/` 以降の文字列 source_phone_number: xxxx, # 架電元電話番号 destination_phone_number: destination_phone_number, # 架電先電話番号 (今回で言う、お客様の電話番号に当たります) ) end
これを対象の電話番号群に対してループしつつ呼び出せば、システムがほぼ同時に架電を行います。
ユーザが電話を取った場合は contact_flow_id で指定した問い合わせフローを実行するので、これによってキューへの転送を行い、キューに入った架電をオペレーターが対応する。
という流れで実現します。
発生しうる問題
- 放棄呼を少なくするための仕組みのため、1人の同時架電が2人以上に繋ることがある
- 同時架電を受け取ったお客様は、通話に出たのに、再度こちらのオペレーターが着信に出るまで「待ち」の状態になってしまう
- 留守番電話に繋ってしまう
- 自動で架電をしてしまう性質上のバグに気を付ける
- Amazon Connectの同時通話数を超過してしまう
それぞれ1つ1つ解決策として用意しているものを紹介します。
放棄呼を少なくするための仕組みのため、1人の同時架電が2人以上に繋ることがある
ヌリカエCSでは、同時架電対応者の他に、普段受電業務を行っているチームも一部バックアッパーとして同時架電の着信を受けられるようにルーティングプロファイルを設定しています。
同時架電を受け取ったお客様は通話に出たのに、再度こちらのオペレーターが着信に出るまで「待ち」の状態になってしまう
IVRを導入することでお客様にアクションを求め「オペレーターにお繋ぎします。少々お待ち下さい」と音声を流すことで自然な体験にできそうです。
従来のプレディクティブコールでは、架電者が発信をして、お客様が通話に出ると、通話が繋ります。
お客様の体験としては、普通に電話に出た。のみです。普通の受電体験です。
しかし、今回の実現方法では、お客様は電話に出たにも関らず、同時架電を開始した架電者が通話に出るまであたかも自分が発信をして相手が電話に出るまでのような「待ち」の時間が発生してしまいます。
この問題を解決するためにはIVRを導入することができそうです。
IVRとは、いわゆる電話に出たら自動音声で「○○のサービスについては1を。○○についての質問がある方は2を」みたく言われて、こちらが番号を押すことで担当先が変わる。みたいなものです。
IVRを導入すれば、お客様に対しては弊社サービス名を伝えることと「これからオペレータにお繋ぎいたしますが、よろしければ○○のボタンを押して下さい」とアクションを求めることで架電者に通話を繋ぐまでの待機時間を自然な体験にできるかと思います。
留守番電話に繋ってしまう
こちらもIVRでアクションを求めることで改善できそうです。
長期に電話に出られなかったお客様は留守番電話を設定していることが多く、同時架電からの着信に出たら留守番電話だった! ということが発生してしまいます。
こちらもIVRを導入することによって、お客様がアクションを起こさないとCSメンバーには繋らない仕組みを作れるため、↑と一緒に解決できそうです。
自動で架電をするため、架電先に誤りがないようにする
対策としては、通常の架電のエラーチェックだけでなく架電先のデータに誤りがない事をチェックするのはもちろん、テストを書くときも、メッセージやエラーだけでなく実際に架電されている案件をテストします。
また、実際のCSメンバーにステージング環境で触ってもらうのも良いかと思います。
同時架電は、システムに多くの架電処理を任せる性質上、1つの不具合が大規模なインシデントに繋る可能性があります。
特に、架電先のチェックや、ループで同時架電をさせる場合、そのループが意図しない挙動をしないかには細心の注意を払う必要があります。
テストではエラーのチェックやレスポンスなどだけではなく、実際に架電されている架電先のデータを元にテストする事を考えたり、導入前にステージング環境などで動作をCSメンバー含めチェックするなど、意図した挙動になっているかのチェックは手厚く行いましょう。
Amazon Connectの同時通話数を超過してしまう
こちらは事前に、Amazonのサポートに「上限緩和リクエスト」を送る必要があります。
「上限緩和リクエスト」の上限とは、Amazon Connectの「インスタンスあたりのアクティブな同時呼び出しの数」です。
つまり、この値が「現コーラーの数」+「同時架電数」よりも多い必要があります。
もしもこちらの数が足りなくなるようでしたら、事前にAmazonのサポートに「上限緩和リクエスト」を送る必要がでてきます。
まとめ
今回はヌリカエチームが新しく架電機能として導入したAmazon Connectでのプレディクティブコールについての記事を書きました。
まだ開発、導入を行ったばかりで目立った成果は出ていませんが、今まで長期リストに対応をしていた方の効率が良くなるハズですので、今後もシステムによって効率を良くし、お客様体験もより良いものにしていきたいなと思います。
以上です!
最後に
Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁
Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！
