Amazon Connectを20ヶ月間運用してみて

はじめに

　ウェザーニューズの井村です。普段はイノベーション研究所というチームで新しいサービスのプロトタイピングや要素技術の研究開発をしています。この記事では弊社が2020年3月にAmazon Connectの導入を決定し、現在までの20ヶ月間運用してみた成功と失敗を共有します。Amazon Connectがリリースされてから月日が経ち、多くの方がQiitaを含む様々な媒体上で使い方や設定の仕方を説明されていて私も参考にさせて頂きました。その一方で実運用を前提とした際にどのようなリソースや設定の組み合わせが必要かを網羅する記事が無かったので、弊社の事例が参考になればと思い記事を立てました。電話を用いたカスタマーケア部門を擁する組織でクラウドのコンタクトセンター導入やリモートワークの推進を検討されている方の判断材料になれば幸いです。
　なお、Amazon Connectは電話に加えてチャットを含む複数チャネルのコンタクトセンターをコンセプトにしていますが、弊社での活用は電話に焦点を当てています。最初に「なぜ気象情報会社であるウェザーニューズがコンタクトセンターに関する記事を書くのか」を含めて説明しますが、読み飛ばして頂いても構いません。

COVID-19とリモートワーク率95%の達成

　ウェザーニューズでは海運、航空、道路、鉄道、地方自治体など、様々な領域の皆様に電話を使ったコミュニケーションを通じて気象に関するリスクと対応策をお届けしています。

　「天気予報はアプリやテレビで見れば良いのでは？」というのが一般的な認識かと思います。しかし急激な気象の変化や、それに伴う災害の発生は全てを事前に確定的に予見できるわけではありません。気象現象がある程度確実に予見できるようになるのは事象の発生の数時間から数十分前で、その予見にも多少の不確実性、例えば発生するタイミングが数十分から数時間ずれる、事象の規模（雨、雪、風の強さ、影響範囲など）が変わる、生じる場所が数キロから数十キロずれる、などが含まれます。その不確実性を含む情報を使ってリスクを回避するためには、気象と事業に対するドメイン知識を持ったスペシャリストが正確かつ迅速にそのタイミングで得られる情報を処理してリスク対応策を作成し、それが各事業者の責任者に伝わっている事が担保されないと適切な対処が行えません。各事業者の責任者に伝わったことが確認できるという点で電話という通信手段は2021年現在でも非常に有用です。もちろん他のコミュニケーションチャネル（ビデオ会議、Slack、E-mailなど）も用意はしていますが、お客様が現場に出られているタイミングでは両手や視覚を奪われるコミュニケーション手段が好まれないという現場特有の事情があります。

　ウェザーニューズではリスク分析を行い最適なタイミングでコンサルティングを行うスペシャリストをリスクコミュニケーターと呼んでいて、約300名のリスクコミュニケーターが24時間365日体制で顧客のビジネスをサポートしています。グローバルに存在する顧客に対して24時間体制のオペレーションを実現する上で、300名のリスクコミュニケーターは日本（幕張）、デンマーク（コペンハーゲン）、アメリカ（オクラホマ）の3拠点に分散して業務を行なっています。拠点を分散することで各拠点のタイムゾーンの日中にオペレーションが行われ、夜間勤務を極力行わない運用体制になっています。また、ウェザーニューズのビジネスにおけるリスクコミュニケーターの位置付けはサービスのサポートではなく、気象リスクを回避するためのコンサルティングを行うサービスそのもので、その点が一般的なコンタクトセンターと異なるかもしれません。

　BtoB / BtoCを問わず、多くの企業ではカスタマーケアのために電話対応チームを設置されているかと思います。しかし、2020年3月頃からのCOVID-19による影響で物理的に一箇所に集まって電話対応をするチームを運営していくことは非常に困難になりました。弊社では2020年4月に緊急事態宣言が発出される1ヶ月ほど前からAmazon ConnectやAmazon WorkSpacesなどの準備を始め、2020年4月時点で電話対応を行なっているチームのリモートワーク率が95%以上になりました。また、クラウドコンタクトセンターの導入とリモートワークでの運用を通して4つのアドバンテージを得ることができました。

• 従事するスタッフが出社した事に起因するコロナ感染が0であった
• 24時間365日体制を支えるための早朝/深夜勤務に従事するスタッフの負担が減った
• 大規模災害時のBCPとして分散したコンタクトセンターを構成する下地ができた
• コンタクトセンターのデータ解析から戦略を立て定量的に検証する下地ができた

これらのアドバンテージを得るにあたり必要だった作業・リソースや、失敗など含めてご紹介致します。

ウェザーニューズにおけるAmazon Connect運用

　前述の通り、ウェザーニューズには3つのオペレーションセンターがあります。3つのオペレーションセンターはそれぞれ別のリージョンにインスタンスを作成しています。これは通信のレイテンシの問題で、顧客とエージェント（Amazon Connect上で顧客の対応を行う人員）が存在する場所の近くにインスタンスを作成した方が通話品質上好ましいからです。また、弊社ではAmazon Connectを利用するにあたり、日本域ではNTT東日本が提供しているボイスワープという電話転送サービスを前段に噛ませています。これは、何らかの問題が発生した際に物理電話に切り戻せる手段を用意したかったからです。Amazon Connectは可用性が高いサービスですが、コンティンジェンシープランを用意しておくことは無駄ではありません。

　ボイスワープによってAmazon Connectに転送された通話は、リモートワークを行なっているリスクコミュニケーターのCCP（ブラウザ上でコンタクトを行うパネル）に転送されます。リスクコミュニケーターは顧客対応を行う上で必要な情報を社内システムやCRMから取得します。また、リスクコミュニケーター同士のやり取りが必要な場合はSlackやGoogle meetを用いています。リモートワーク環境で社内システムにアクセスする際はVPNを経由し、その他の通信は直にインターネットに流れます。

Amazon Connectを運用する上で必要なもの/こと

実際のコンタクトセンター運用に必要な作業、調整、リソースを並べます。

Amazon Connectインスタンス作成と電話番号の取得

　インスタンスはAWSアカウントがあれば数分で作れます。インスタンス作成後、そのままでは電話番号が取得できません。電話番号の取得についてはサポートケースから申請し、申請が通った段階でコンソールから作業を行います。申請時に必要な情報はAmazon ConnectのインスタンスARN、会社の所在証明（登記簿など）、担当者の身分証明（運転免許やパスポートなど）です。詳しい要件はドキュメントに記載されています。

UXのデザインとフロー・キュー・ルーティングプロファイルの作成

　Amazon Connectを運用する上で一番大切な部分です。「問い合わせフロー」は顧客からのコンタクトに対して、どんな条件の時にどのエージェントにルーティング（振り分け）するかを制御します。エージェントはいくつかのキューを担当することが可能で、キューを担当するエージェント以上に顧客がいる場合はキューの中で顧客が待機します。どのキューをエージェントが担当するかはルーティングプロファイルで定義します。これらを設定する上でプログラムを書く必要はなく、問い合わせフローはグラフを描くように設定ができます。ここをどのように組むかによってUXが決まります。

(Amazon Connect 問い合わせフロー設定画面のサンプルより)

　コンタクトセンターのUX（ユーザ体験）を考えた時にユーザは顧客と従業員の二者で、CX（顧客体験）とEX（従業員体験）を同時に考える必要があります。CXの側面からは顧客が電話をした際にスムーズに担当者まで繋がる事、繋がらない場合は折り返し電話の登録をして切断できるようにするか、待機する場合でもどの程度待てば良いのかが随時確認できるような仕掛けが大切です。あるいは緊急性の高い電話に対しては優先度を上げて対応する必要があるでしょう。これにより顧客のストレスは低減され、従業員にとってもスムーズなコミュニケーションを取りやすくなるでしょう。
　EXの側面から見ると、それぞれのエージェントはコンタクトへの対応を滞りなく行えることが重要です。転送されてきた電話がどういった経緯で転送されてきたか、顧客がどういった意図でコンタクトしようとしているのかが電話を取る前に共有されていれば、エージェントは情報整理や心の準備をした上で対応できるのでエージェント自身のストレスを低減できます。これは顧客から見てもコミュニケーションがスムーズに行えた印象を受けるでしょう。これらを実現する仕組みは全てフロー上で定義できます。
　フローの話から少し脱線しますが、EXを追求する上で業務に対する各エージェントの貢献度を計測する指標を設定しておく事は重要で、例えばルーティングされたコンタクトに対してどれくらい応答できたか、顧客の課題を何分で解決することができたかといった時間的な指標があるかと思います。これらはそれぞれ「応答率」「エージェントの対応時間」というメトリクスでAmazon Connectのコンソールから確認可能です。この指標を日々追いつつ優秀なエージェントを表彰したり評価することでEXの向上につながり、その評価体系によってCXも向上するといった効果が期待できます。
　提供しているサービスの品質にはコンタクトセンターの対応品質も含まれ、それらの総和によって自社のブランドが形成されるので、サービスを統括する人物がコンタクトセンターのCX/EXを含むUXの重要性に気付いて真剣に取り組むことが求められます。

ユーザの追加削除と権限設定

　Amazon Connectにログインできるユーザを作成します。ユーザを作成する際にはルーティングプロファイルとセキュリティプロファイルを指定する必要があります。このセキュリティプロファイルがユーザの権限を指定するもので、デフォルトではAdmin、Agent、CallCenterManager、QualityAnalystの4種類があります。

(Amazon Connect セキュリティプロファイル設定画面より)

　それぞれ名前通りの内容になっていて、Adminは全ての権限を、AgentはCCP（問い合わせコントロールパネル：電話の発着信を行うための画面）のみへのアクセス、CallCenterManagerは通話の統計的な情報や履歴に対するアクセスといった具合です。権限を組み合わせて任意のセキュリティプロファイルを作成することもできるので、必要に応じて設定すると良いでしょう。

監査ログ

　S3上に音声通話記録などのセンシティブな情報を保持する場合、誰がいつその情報を操作（追加、取得、削除）したかをログに残し、不自然なアクセスを把握して問題が発生する前に対処したり、問題が発生してしまった場合には何が起きていたのかを追跡できる事が重要です。ログの記録と確認については以下の記事が参考になります。

ネットワーク帯域と業務端末の確保

Amazon Connectの動作要件は以下の通りです。

• ブラウザ：最新バージョンの Google Chrome もしくは Mozilla Firefox
• ネットワーク：1台あたり最低 100 Kbps の帯域
• メモリ：2 GB
• CPU：2 GHz

　ブラウザに関しては最新バージョンとありますが、2020年にChromeのVersion86で音声品質の低下、2021年にFirefoxのVersion86でCCPにアクセスできなくなる不具合がそれぞれ発生しています。ブラウザのアップデートがリリースされたタイミングで全ての業務端末をアップデートするより、全体の一部をアップデートして様子を見た方が安全と言えるでしょう。
　ネットワーク帯域は最低100Kbpsと低めのRequirementですが、音声をUDPで送受信しているためパケットロスは天敵です。基本的には有線で接続し、パケットロスを監視する態勢を取る必要があります。

(From aws.amazon.com)

• ネットワーク要件について

• 端末要件について

パケットロスの監視

　CloudWatch上では様々な指標をベースにモニタリングが可能です。パケットロスの監視には ToInstancePacketLossRate を用います。

　パケットロスが増えた際にSlackにアラートが流れるように仕込んでおくと通話品質の低下が起きた際に現場で対処しやすくなります。AWS上でCloudwatch、SNS、Chatbotを使って簡単に設定ができるのでおすすめです。

（弊社の社内Slackのスクリーンショット）

障害の切り分け

障害が発生した際、構成の中のどこに問題があるのかを切り分ける必要があります。一般論になってしまいますが

• エージェント全員に発生しているか一部のみに発生しているかを確認する
  • 一人のエージェントのみで発生している場合は
    • そのエージェントの端末や周辺機器の構成が以前と変更されているか確認する
    • そのエージェントが通話している顧客の環境を確認する
• ネットワークの帯域が十分に確保できているか確認する
• 電話網に障害が発生していないか確認する
• SHD/PHD上でAmazon Connectに問題がないか確認する

あたりが調査の範囲になるかと。

　弊社ではエージェントが障害を察知した際にGoogle Formに記入を行い、登録されたものがSlack通知され、現場の監督者が手順に沿って問題の切り分けを行います。

※このケースは無線を使って接続しているため通信が不安定だったと思われます

AWS/Amazon Connectの導入とシステム面でのサポートをする人員

　エージェントの数にもよりますが、極論すれば1人のエンジニアが全て担える作業です。複数人で運用に関する知見を共有したり、あるいは有給や病欠などを取得する事を考えると最低でも2,3名のエンジニアが必要になるでしょう。この人員がAmazon Connectを使う上での初期設定や日常的なトラブルの解決を行います。
　弊社では最初の15ヶ月ほど私1人＋現場（運用中の各チームのリスクコミュニケーターが最低限のトラブルシューティングを行える状態）で運用を行なっていましたが、その後ネットワーク管理チームとCRM開発チームに引き継ぎを行なって組織的に運用しています。

プライバシーポリシーなど個人情報の取扱に関する取り決め

　Amazon Connectでは顧客との通話の音声記録をS3に保持させる機能があります。BtoBのコンタクトセンターの音声記録には大抵の場合、顧客の「企業名、部署名、氏名」が含まれ、これらは個人を特定できる個人情報です。それらの情報と電話番号をデータベースに保持し取り出せるような仕組みを用意する場合、これらは個人データに該当します。もしこれらの情報を保持したり活用する予定があれば、プライバシーポリシーにそれらの個人情報の用途、管理方法などを明記した上で、顧客とコンセンサスを持つことが重要です。
　なお、Amazon Connect自体は SOC や PCI といったスタンダードに準拠しているので、セキュリティ・コンプライアンス要件が厳しい場合などに参考にできるでしょう。

AWSアカウント

　クレジットカードやデビットカードが1枚あれば作れますが、企業として運用していく場合には請求書払いなどの方が取り扱いやすいでしょう。請求書払いであれば、クレジットカードへの請求額が限度額を超えていきなりアカウントごと停止するような事態を避けることができます。以前は代理店経由でしか請求書払いを行なえませんでしたが、2021年11月よりAWS Japanから直接の請求で支払いができるようになりました。

オーディオデバイスについて

ウェザーニューズのリスクコミュニケータの中での一番人気はApple製品に付属しているイヤホンです。

　これは弊社の業務端末の半数以上がMacであること、業務中にヘッドホンの着脱が頻繁に行われる事に起因していると考えています。Jabraのワイヤレスヘッドセットなどを検討した時期もあったのですが、装着感や充電の手間から敬遠された過去がありました。接続の安定性の観点からもヘッドセットは有線の方が良いですし、一定の割合で故障することが見込まれるので容易にリプレイス可能で品質が一定な製品の方が良いでしょう。

コスト

AWS部分に関して

初期費用がないので、使った分だけの課金になります。

　電話の機能だけを見た場合には固定電話を引くより安く、IP電話の中では平均的だと認識しています。Amazon Connectは純粋な電話以外の機能が充実しているので、その部分にどれだけ価値を見出せるかが導入の決断ポイントになると思います。

AWS以外に関して

　Amazon Connectの利用料以外にも、エージェント一人一人に貸与する業務端末やネットワーク環境の整備にコストがかかります。弊社の場合は日常的に一人一台の業務端末があったため、Amazon Connect導入のイニシャルコストとはなりませんでした。
　リモートワークを前提としたコンタクトセンターを運用する場合にはVPNや貸与している業務端末に対してよりシビアなセキュリティ対策が必要になるでしょう。Amazon Connect自体はVPNを必要とせず、またVPN経由の通信はオーバーヘッドが生じるため推奨されません。しかし、実オフィスで行われていた既存の業務をリモートワーク化する過渡期においては社内システムへのアクセスが必要になるケースが多いでしょう。弊社のリスクコミュニケーターは気象現象を把握するための各種社内ツールや社内ネットワーク内でしか閲覧を許可していないCRMなどを駆使して顧客対応を行なっており、これらを支えるためのVPN増強や業務端末のセキュア化、仮想デスクトップの利用など、ICT環境への投資を必要なだけ行いました。このあたりは組織のセキュリティポリシーに合わせてご判断頂ければと思います。VPNを構築する場合、トラフィックの種類や宛先によってルーティングを変更するスプリットトンネリングを利用してAmazon Connectや大きいトラフィックを直接インターネットに流すように設定できると良いでしょう。

成功した点

冒頭にも書きましたが

• 従事するスタッフが出社した事に起因するコロナ感染が0であった
• 24時間365日体制を支えるための早朝/深夜勤務におけるスタッフの負担が減った
• 大規模災害時のBCPとして分散したコンタクトセンターを構成する下地ができた
• コンタクトセンターのデータ解析から戦略を立て定量的に検証する下地ができた

が成果だと考えています。
　コンタクトセンターのデータ解析では応対品質の向上、顧客体験の向上、従業員体験の向上など様々な面で使えるデータが取得できるようになりました。これはキュー毎の平均レスポンス時間であったり、一人一人のエージェントのパフォーマンスであったり、業務の見直しやスタッフの教育、満足度が低下した顧客への素早いフォローなど、様々な用途に使えるデータの宝庫です。この辺りのツール作成や解析についてはまた回を改めて記事を書こうと思います。

障害、不具合、失敗など

　運用していると様々な問題が日々発生します。ここでは運用中に発生した不具合や障害、今となっては後悔している点を共有します。Amazon Connect や AWS に起因しない問題も含まれますが、ユーザから見ると「電話が使えない/使いにくい」に帰結するので、うまく問題を取り除く必要があります。

リモートワークにおける通信品質問題

　2020年3月の導入当初、自宅に品質が安定しているインターネット回線を引いていた社員は少数でした。集合住宅でVDSLしか導入できなかったり、あるいは賃貸物件に予め導入されている謎のインターネット回線を使っていたり、不安定なアクセスポイントを使っていたり、ポケットWi-Fiでどうにか凌いでいたりと十人十色なインターネット環境でした。現状でもインターネット環境は社員一人一人の判断に任せていますが、ここは会社側がある程度の支援をして光回線を導入させた方がサービス品質の安定につながるので現在進行形で準備しています。

NTT網の障害

　ボイスワープを前段に噛ませていたことから、NTT網の障害発生時にAmazon Connectへの着信を受けれなくなった事案がありました。2020年4月14日に発生し、原因は千葉県内のNTT交換局での機器故障、影響を受けた時間は約2時間でした。
　現場から情報が上がってきた際には「Amazon Connectが繋がらない」だったのですが、問題を切り分けていくとNTTの回線障害でAmazon Connectは何も問題なく使えていました。ユーザから見た障害と、実際にどこに問題があるかは別なので、障害が起きた時には冷静に対処しましょう。この事案が発生する前から現場で簡単な問題の切り分けを含めたトラブルシューティングができるようにマニュアルを整備していましたが、この事案を機にトラブルシューティングについて再教育を行いました。

Amazon Connectの障害

2021年9月2日にAmazon Connectが約6時間ほど通話できない / 通話品質の安定しない状態になりました。

Amazon Connectは電話網と接続する部分で通信キャリアパートナーと Direct Connect を用いて通信しているようなので

同日発生したDirect Connectの障害に巻き込まれた可能性があります。

　この障害発生時にはService Health DashboardとPersonal Health Dashboard共にAmazon Connectでの障害発生に関する通知は無く、障害の発生に気づくまでにラグがありました。この種の障害の発生に気付くためには、自動で定期的に外線発信を行いFailした時点でアラートを投げるような監視を行う必要があります。

認証認可

Amazon Connectの認証手段は以下の3つから選択可能です。

• Amazon Connect内にユーザを保存
• 既存のディレクトリへのリンク
• SAML 2.0ベースの認証

　弊社では Amazon Connect 内にユーザを保存しています。この手段のメリットは特に他の認証基盤との連携を考えることなく、とりあえずAmazon Connectを使い始める事ができる点にあるでしょう。デメリットはその逆で、他の認証基盤と連携していないために社内のユーザ管理が煩雑になってしまう事です。例えばスタッフの入退社の際に、社用メールアカウントの発行をしつつAmazon Connect上でのユーザを作成するといった二度手間になります。弊社でのAmazon Connect導入当時は社内共通のIdPが無かったのですが、現在はGoogle WorkspaceベースのIdPを使うコンセンサスが取れているのでSAML認証に移行し、煩雑さを解消したいと考えています。
　インスタンス作成時に選択した認証手段は途中から変更することができないのでインスタンスごと作り直しになりますし、Amazon Connect上で取得した電話番号はインスタンスに紐付いていて他のインスタンスに移行ができないので、時間に余裕があってAmazon Connectの導入を検討されている場合には認証基盤についても事前に検討すると良いでしょう。

AWSアカウントの切り分け

　Amazon Connectを事業部毎に準備するにあたり、AWSアカウントも事業部毎に分けて作成しています。当時はそれで良かったのですが、コミュニケーション基盤としてAmazon Connectを事業部横断的に整備し内製ツールセットなども開発していく方針に変わったので、今となっては1つのアカウントにまとめておけば管理が楽になったと後悔しています。
　これは各社のその時の状況によって左右されるものだと思うのでアカウントをどの単位で作成するかに最適解は無いと思いますが、可能であれば少し先の事を見越して計画を立てれると手間が減ると思います。

Amazon Connectの入門と情報収集

ハンズオン

「どこから始めて良いかわからない」という方は公式のハンズオンから始めてみると良いと思います。

• Webinar形式のハンズオン資料

• 2018年時点のちょっと古めの資料

内容やスクリーンショットが古く2021年現在のAmazon Connectにそのまま適用できない部分があるかもしれません。
スライド形式なので基礎的な概念や機能について大まかに理解するためには良い資料だと思います。

　上記ハンズオンで基本的な概念や操作が理解できるはずなので、その後は自社の業務に合わせたコンタクトセンターを仮組みしてテストし、現場で使えるかどうか検証するのが良いと思います。物理的な電話機を使ったコンタクトセンターからAmazon Connectに移行する過程では、エージェントが慣れて業務を遂行できる事が重要なので、必要に応じて何度も現場に足を運び不安を解消できると良いでしょう。

情報収集

　Amazon Connectは継続的にアップデートされているサービスです。この点については常に情報を収集しながら新しい機能 / 変更された機能を知っておく必要があります。また、Amazon Connectは柔軟性が高く多様な使い方ができるのに対してドキュメントは基本的な機能の紹介に留まるので、その基本的な機能をどう組み合わせると何ができるかというレシピについてはドキュメント以外の情報ソースを持っておいた方が良いでしょう。

• AWS Blog

AWS Blogの中に Contact Center の項目があります。応用するためのレシピや最新のニュースが入ってくるので、定期的に情報を追うと良いでしょう。

• Developers IO

Classmethod さんが提供している技術ブログです。

サクっと試せる小ネタが充実しています。

Amazon Connectが向くケースは？

　結論から言うと、まだクラウド化されていないコンタクトセンターを持っていて、今後クラウド環境をAWSに集約していく組織には向くと思います。

Amazon Connectの良いところを挙げます。

• AWSアカウントを持っていない状態から最短半日程度でコンタクトセンターが作れる

• 顧客からの着信をどのキューにどんな条件で割り当てて行くかを定義するフローの柔軟性が高い

  • デフォルトでもあまり困らないが、途中にlambdaを含めて独自の処理を入れる事ができる

• 情報の処理や保持がAWS上のサービスで完結しシームレスに連携されるのでAWS上での開発に習熟したエンジニアにとっては非常に楽

短所は概ねその逆になるでしょう。

• フローの柔軟性が故に「これもできるよね、あれもできるよね」状態になって魔改造が進む
  • こういったSaaSは機能に応じて業務を変更するのがセオリーだと思いますが、業務に合わせてSaaSの機能を追加していく魔改造が。。
  • 弊社の場合は素のAmazon Connectを使っているチームと魔改造したAmazon Connectを使っているチームがあります
• 何かしようとする際に全てがAWS上にあるので、AWS上での開発経験があるエンジニアが必要になる

使っている所感としては以下の通りです。

• コンタクトセンターの規模の大小を問わず使えそう
  • 従量課金なので事業の規模に合わせてコンタクトセンターを組める
  • 事業規模が急に拡大しても、それに応じてコンタクトセンターの規模を調整しやすい
    • （もちろん人繰りや教育は考える必要がありますが）
• チャットやIVR（自動音声応答システム）などを活用することで最大限のアドバンテージを享受できる
  • この部分に関してはAmazon Connect以外のサービスを検証したことがないのでゆくゆくは検証していきたいと思っています
  • FAQ系の問い合わせが多いコンタクトセンターだとオペレーターに対する問い合わせを減らすことが鉄則なので、IVRやチャットをうまく使うアプローチと共にhelpfeelさんのようなFAQ管理ツールを入れるアプローチも考えた方が良いと思います

（補足説明ですが、IVRは顧客の目的に応じたオペレーター振り分けや、オペレーターを必要としない単純な情報提供を行うための仕組みです。機械による音声ガイダンスが流れ、それに応じて顧客側で電話機の数字ボタンを押すことにより条件分けを行います。）

　既にコンタクトセンターのクラウド化が完了している組織ではメリットが薄いと思います。また、基本的に手取り足取りのサポートは無いので、エンジニアの確保が難しい場合でも導入はできると思いますが、トラブルが起きた際の対応で苦戦すると思います。

　業態によっては「どうしても物理的な電話機が必要」というケースがあると思います。Amazon Connectはソフトフォン（PC/Macのブラウザ上で動作する仮想的な電話機）しかないので、一人一人のエージェントがPC/Macの操作にある程度習熟していないと導入できないという短所もあります。

　ウェザーニューズの場合はクラウド環境をAWSに集約する方針で、かつコンタクトセンターが古くからの固定電話で、エージェント達は業務上PC/Macを日常的に操作していたので、あまり抵抗なくAmazon Connectの導入が完了しました。なお、Amazon Connectを使っていてIVRを使わないのはかなり勿体無いのですが、ウェザーニューズの業務の中で電話は緊急性の高いコミュニケーションのためのツールという側面が強いのでIVRを一切導入していません。

余談

Contact Lens for Amazon Connectの日本語対応

　いよいよ東京リージョンでも Contact Lens が使えるようになりました。開発用アカウント上で有効化してみたのですが、日本語の音声認識精度は残念ながら弊社の運用で活用できるレベルに達していませんでした。音声認識精度が上がるのを楽しみにしています。
　最終的にはTranscribeの精度が実用レベルに達してAWS上で完結するようになると良いのですが、そうなるまでの間はAWS外の音声認識エンジンを使うことになると思います。外部の音声認識エンジンを用いる上で、書き起こしの部分だけ外部にLambdaで投げて、戻ってきたテキストを再度Amazon Connectに取り込むAPIが用意されていると良いなーと思いました。

Amazon Connect以外の選択肢は？

　日本国内においては Twillio、Dialpad、NTTグループが提供している各種サービスが有り得ると思います。弊社においてはクラウドコンタクトセンターに目を向けていたエンジニアが少なかった事、私がAmazon ConnectをPoCで良く使っていて社内でも情報共有していた事などから、2020年3月の時点で導入時の学習コストが最も少ないAmazon Connectを導入することになりました。
　Twillioはコンタクトセンターソリューションとしてビデオ会議やWebへの統合に強みがあると思っています。実際、弊社の業務の中でも顧客とビデオ会議を行う場面がありますし、Web上でコンテンツを閲覧して頂くことも多いので、今後を考えると有力な選択肢の一つです。DialpadはAmazon Connectでできない同時発呼（一斉鳴動とも言う）ができます。同時発呼はアナログなコンタクトセンター運用を長くされていた企業さんで現状の運用手順を変えたくない場合には必須な機能と思います。
　どのサービスが向くかは現場の運用実態によって大きく左右されるので、特定のベンダーにこだわりがなければ複数検討してみると良いと思います。

ウェザーニューズのコミュニケーション手段の変遷について

　弊社は海運業の皆様へ安全な航路やスケジュールを提供するサービスが原点にあるため、創業時（1986年）より世界中のお客様に対して電話・ファックス・テレックスといったその時代で取り得る手段でコミュニケーションを行なっていました。コールセンターほど電話が主業務ではないものの、業務効率やスムーズさを求めて様々なデバイス、手法を導入し試行し模索してきました。その中にはIP電話やIVRも含まれます。残念ながら当時IP電話やIVRはオペレーションにフィットしませんでしたが、今後コミュニケーションはより多様化すると思われるので、そのタイミングでの最適なコミュニケーション手段を検討し続けて行きます。

そもそも何で研究開発部門の人間がAmazonConnectを触っているんだっけ？

　ウェザーニューズのサービスの特徴である「リスクコミュニケーション」を自動化するPoCの一環として、まずはインタフェース部分をデジタル化する必要からAmazon Connectを触り始めました。USのいくつかのリージョンではAmazon Connectが早い段階から使えましたしLexやTranscribeの性能も英語では実用レベルに達していたので、2017年頃は海運事業者様向けの全自動応対電話番を作っていました。これを様々な事業に広げていく上ではオペレーションをされる方の問い合わせの特徴と、実際に問い合わせをされる方一人一人が情報を求めるタイミングなどを把握した上で最適なタイミングで最適な情報をお届けする仕組みの研究開発が必要でした。
　その延長線上で2019年にAmazon Connect、RDSやFargateとGCPのSpeech to Textなどを組み合わせてCRMを2週間くらいで開発し、その時に社のプライバシーポリシーの整備や個人情報取扱に関する運用体系の整備を進めておいたので、2020年に社がリモートワークに舵を切ったときにコンタクトセンター業務のクラウド＆在宅移行は3週間ほどで完了しました。短期間で移行出来たのは方々で評価を頂いていますが、それ以上に個人情報保護的な観点で安心して移行出来たのは良かった点だと思っています。

おわりに

　2019年頃にコンタクトセンターのクラウド化を考えていた頃は、基盤と運用ルールは数週間で作れたとしても、教育とテスト運用を含めて浸透させるフェーズに数年かかると思っていました。しかし一度方針が決まって全員が同じ方向を向くと、実際の浸透にかかる期間は2,3週間なのだという事がわかりました。これは弊社だけではなく、同規模の企業であれば実現できる可能性を示唆しています。
　業務内容や規模によってはフルリモートワークなコンタクトセンターの実現が難しい場合もあるかもしれません。弊社もまだまだ改善の余地があると思っています。ここに至るまでに様々な企業様のコンタクトセンター運用事例を拝見して学んだ事が多いので、私共の事例もどなたかの参考になれば幸いです。