【レポート】Amazon Connect デザインパターン & ベストプラクティス詳解 #AWSSummit

2020年9月時点のAmazon Connectのベストプラクティスが全て発表されておりました！

AWS Summit Online Japan 2020

#Amazon Connect

#AWS

洲崎義人

2020.09.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

2020年9月8日から9月30日の間で開催されているAWS Summit Online のセッションに参加しています。
AWS Summit Onlineではセッションを期間中に何度でも視聴することが出来ます。

今回はAmazon Connect デザインパターン & ベストプラクティス詳解に参加したのでレポートします。

セッション概要

スピーカー

松本和久氏
アマゾンウェブサービスジャパン
ソリューションアーキテクト

動画&資料はこちらになります。

セッションのゴール

Amazon Connectによるコンタクトセンターのワークロードを設計および運⽤するために、AWSが考えるベストプラクティスを持ち帰られること

Amazon Connectと関連するサービス群

Amazon Connectとはあらゆる規模のビジネスをサポートできるスケーラビリティをもつクラウドベースのコンタクトセンター・ソリューションです。
セルフサービスで設定変更ができ、オープンなプラットフォームとAWS関連のシステム連携でお客様に従量課金て価値を提供します。
Amazon Connectに関連するサービス群は以下です。

ベストプラクティスに基づくデザインパターン

ここでコンタクトセンターの技術用語について復習します。IVR、CTI、ACD、DTMF、ANI、PSTNというワードを覚えておきます。

AWSに関するベストプラクティスとして、Amazon Connectに限らず5つの柱があります。
今回もこの5つの柱を沿って設計していきます。なお、信頼性についてはAmazon Connectそもそもにシステムの回復が含まれている為割愛します。

運用におけるベストプラクティス

まず運用におけるベストプラクティスをみていきます。大きく分けて3点です。

キューイングやリトライ制御を実装する
問い合わせフロー変更のリスクを最小化する
問い合わせのルーティングを効率化する

①キューイングやリトライ制御を実装する
Amazon ConnectではAPIがアカウント毎にあり、リミットがあります。
Lambda関数からリクエストするとき、量が多いとリミットを超えてしまいます。
ここにSQSを挟むことで、API同時実行数を制御することが出来ます。

②問い合わせフロー変更のリスクを最小化する
問い合わせフローの管理が煩雑だと変更のリスクが発生します。
問い合わせの転送の設定ブロックの活用や、変更時の再帰テスト範囲を限定することでリスクを最小化することが出来ます。

他にも分散ブロックを用いたり、フローのバージョニングを用いて、万が一何かあった時に切り戻すことが出来るようにしておきます。

③問い合わせのルーティングを効率化する
3点目が問い合わせのルーティングを効率化する話です。
例えばエージェントを介さない形で、DTMF通信やLexと連携してセルフサービスで終了させることで効率化できます。
また営業日判定ではcsvのやり方の他、AWS Systems Managerを用いる事で営業日や営業時間を判定させることが出来ます。

スタッフの状況を確認するルーティングを入れる事も大事です。
また空きスタッフがいない場合はコールバックオプションを案内することが出来ます。
待ちが長い場合は留守番電話オプションを利用しましょう。

留守番電話オプションでは裏側でAmazon Kinesis Data Streamsが動いており、Amazon S3にデータが保存されます。
こちらは営業時間外での留守番録音等の利用でも活用することが出来ます。

問い合わせのルーティングを効率化するにあたって、ルーティングプロファイルを設定することは基本です。
ルーティングプロファイルとは、特定のスキルセットを持つエージェントにルーティングさせることです。
エージェントはある1つのプロファイルに割り当てられます。
ルーティングプロファイルはエージェントとスキルのマトリクスで決めることで、ACD機能として活用することができます。

また、異なるルーティングに、遅延の設定を入れる事で優先度を決めて振り分けることが出来ます。
この図だと、初めに新規申し込みエージェントに呼を割り当て、取れなくなった際にシニアエージェントに振り分ける事が出来ます。
この組み合わせによって最も長く受付可能なエージェントに割り当てる窓口を開設することが出来ます。

セキュリティにおけるベストプラクティス

次にセキュリティにおけるベストプラクティスを見ていきます。
今回はオレンジの箇所を注目して見ていきます。

①発見的統制
まずは発見的統制についてです。ログとモニタリングにおいては可用性・信頼性・パフォーマンスにおいて重要です。
ログをAmazon CloudWatch Logsに貯めて、アラートと通知を実装することが出来ます。

②インフラストラクチャ保護
Amazon Connectはオンプレミスとのコンポーネントについて意識する必要があります。
CCPとのファイアウォールについて確認していく必要があります。

NW関連のよくあるトラブルとしては2点あげられます。
1.オンプレミスのプロキシがWebSocketを通さない設定になっている。
回避策：ブラウザのプロキシ除外設定でConnectのエンドポイントドメインを例外として登録する
2.UDP/3478を通さない
回避策：CCPの代わりにデスクフォンを利用する

データ保護
最後にデータ保護です。DTMF入力を保管するときに暗号化をしましょう。
特に顧客に番号を入力させる場合は注意が必要です。
Amazon ConnectではLambda関数で復号化しAWS Secrets Managerに登録することで暗号化することが出来ます。

パフォーマンスにおけるベストプラクティス

次にパフォーマンスにおけるベストプラクティスです。
大規模コールセンターで複数の電話番号と複数フローを作ると、リソース上限と管理不可に繋がります。
この場合、Amazon DynamoDBとAWS Lambdaを活用することで複数のフローを1つのフローに纏めることが出来ます。

具体的にはDTMFで押した数字からDynamoDBで情報を取得し、外部属性として用いる形です。

また、Amazon PollyとSSMLタグの兼用で自然な会話体験を実現することが出来ます。

AIサービスと統合することで、リアルタイムで顧客の言葉を文字起こしして、翻訳・感情分析までを行うことが出来ます。

パフォーマンスを可視化することができます。
Contact Flow LogsはAmazon Cloudwatch⇒Lambda function⇒Amazon Elasticserach Serviceに、
CTRはAmazon Kinesis Data Firehose⇒Amazon Elasticserach Service、
Agent EventsもAmazon Kinesis Data Firehose⇒Amazon Elasticserach Serviceに貯めます。
Amazon Elasticserach ServiceからKibanaに出力することで可視化することが出来ます。