【Amazon Connect】 『Amazon Connect活用Tips』 問い合わせフローづくりからコスト最適化まで

コンタクトセンターに電話がかかってきたら、オペレータが電話を受けて話をし、必要な対応をおこなうまでがワンセットですよね。電話を受け付ける際にIVR（自動音声応答）機能を利用して、問い合わせ内容を番号で選択する流れはよくありますが、その後はオペレータにつながります。

が！このIVR機能をもっと使えば、オペレータにつなぐ前に問い合わせ対応を完結できるのでは？たとえば、要件（書類の再発行など）と会員番号を入力してもらえば、直接話をしなくても対応できる……という問い合わせ、それなりにありそうです。こういった問い合わせをオペレータに割り当てずに完結させることでオペレータの負担軽減になりますし、スムーズな手続きや待ち時間短縮になれば顧客満足度向上にもつながるでしょう。

ここでひとつ注意しておきたいのが、情報漏えい対策です。顧客から入力してもらった内容はログに保存するのが通常ですが、デフォルトではログは平文で保存されます。もしも、個人情報にあたるものを入力してもらう場合はそのままではNG！ログに保存されていたクレジットカード番号が漏えいしたという事故もありましたし、そういったケースでは暗号化して保存しましょう。暗号化の方法については、私の知識不足ゆえに説明についていけなかった感が否めませんが、AWSの各種サービスを利用していい感じにできそうです。詳しくは「AmazonAWSサイト」などで説明されているので、気になる方はぜひどうぞ！（丸投げ）

お客さまから電話がかかってきても、どうしてもオペレータが埋まっていて、待たせてしまうケースは出ます。短時間ならそのままお待ちいただく形で問題ないですが、待ち時間が長くなるならば、コールバック（折り返し）するのもひとつの方法です。なぜなら！Amazon Connectは電話に出ても出なくても、かかってきた瞬間から課金されているから！ただひたすらお待たせしている時間なのにコストがかかるのはなかなかツライものがあります。顧客体験的にも「延々保留音を聞きながら待つ」というのがあまり好ましくないのは、（実体験的に）わかる気がしますし、この方法は結構ありなのではないでしょうか。

ちなみにコールバック用のキューに保存されたものに関しては、担当するオペレータが「応答可能」のステータスになったタイミングで、自動でコールバックされるようです。「折り返し、忘れてた！」とならないのは安心ですよね。
ついでに、Amazon Connectではアナウンスのあとにメッセージを残してもらう「留守番電話」的なこともできます。これもAmazon Connect単体ではなく、Amazon Kinesis Video Streamsと連携して実現するのだそう。Amazon Kinesis Video Streamsは動画や音声といったストリーミングデータを処理・保存するためのサービスで、ここにお客さまからのメッセージ音声を保存する、ということですね。若干ハードルが高い気がしますが、選択肢として覚えておく価値はありそうです。

コンタクトセンターなどでは、対応の難易度が高いお客さまが一定数いたりします。かつてオペレータのバイトをしていたときは、顧客番号でシステムを検索すると、“要注意”的なマークが表示されるので、その場合は注意してね、なにかあったらすぐにスーパーバイザーを呼んでね、と言われていましたが、Amazon Connectならばかかってきた電話が要注意かどうかを自動で判定することも可能です。事前に要注意なお客さまの電話番号を「ブロック対象リスト」などにまとめておくことで、発信元の電話番号を突き合わせ。マッチした場合は「問い合わせは受けられません」とアナウンスして切ってしまう！ということも（結構大胆な対応ですが）できるそう。

さらに、Amazon CloudWatchと連携すれば、ブロック対象リストの電話番号から連絡があったことを、スーパーバイザーや管理者に通知することも可能。こういった情報があれば、フォローアップしたり、ほかの対処を考えたりと、いろいろ活かせそうです。

最後にもうひとつコスト削減策を。Amazon Connectでの通話内容はすべて録音し、Amazon S3に保存できます。これをコンプライアンスのためのログデータとしたり、文字に起こしていろいろ活用したりできるワケですが、当然Amazon S3に保存すると容量に応じてコストがかかります。そして、音声データは文字データと比べて容量が大きくなりがち。

貯めれば貯めるほどどんどんコストがかかるので、古くなったデータから削除するなどの対応は必須ですが、削除する前にAmazon S3 Glacierにデータを移動するのもおすすめとのこと。Amazon S3 Glacierはアーカイブなどのための低コストストレージで、Amazon S3よりもかなり低コストで利用できる一方、データの取り出しに時間がかかる、というもの。普段は使わないけれど、長期間保存したいというデータに適したサービスですね。
Amazon S3に関しては、以前のコラムで解説しているので、こちらを参照ください！

データの移動に関しても、Amazon S3の「ライフサイクルポリシー」を利用することで、簡単に設定できるようなので、これも押さえておいてもいいかもしれません。もちろん「Amazon S3 Glacierに移動したからあとはオッケー」ではなく、決まった保存期間を過ぎたデータをAmazon S3 Glacierから削除するところまで忘れずに。

今回は、比較的取り入れやすそうなものをピックアップしましたが、セッションではほかにも「問い合わせ内容によって重みづけをし、優先度の高いものを先に処理する」といったものや、「問い合わせのフローを細かく分けることで、変更時のリスクを最小化する」など、さまざまな方法が紹介されていました。コンタクトセンターの規模が大きくなると、問い合わせのフローも複雑になりやすいですし、「フローの運用保守」まで見据えて、作り込むとよさそうです。

ブラックリストの管理にしても、留守番電話にしても、イチイチほかのAWSサービスと連携するのはややハードルが高いような気がしますが、その分柔軟性が高く、自由にフローや通知を設計できると言えるでしょう。次回は、「AWSの各種サービスとの連携」のメインとなる機械学習系サービスとの連携についてフォーカス！在宅コンタクトセンター運用のポイントもあわせて紹介したいと思います。
以上、シイノキでした。