re:Invent 2024: EDDがAWS活用で実現したコンタクトセンター改革
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Driving transformation for California’s workforce (WPS322)
この動画では、California Employment Development Department (EDD)のモダナイゼーションプロジェクト「EDDNext」について、具体的な取り組みと成果が紹介されています。年間5,000万件の電話対応が必要なEDDが、Amazon ConnectとAmazon Lexを活用して構築した新しいコンタクトセンターソリューションにより、顧客の3分の2がセルフサービスで回答を得られるようになりました。また、コールバック機能やSalesforceとの統合により、エージェントの業務効率が大幅に向上。さらに、AWS Lambdaやその他のAWSサービスを組み合わせることで、複雑なレガシーシステムとの統合や、多言語対応、音声認識による自然な対話など、現代的な顧客体験を実現しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
EDDNextプロジェクト：カリフォルニア州の雇用開発局の近代化
みなさん、こんにちは。本日はお集まりいただき、ありがとうございます。この後、みなさんはおそらくHappy Hourや夕食に向かわれると思いますので、できるだけ手短にお話しさせていただきます。まず自己紹介させていただきますが、私はAWSのPrincipal Account ManagerのTony Driverです。本日ここにお集まりの皆様は、Public Sectorのお客様かパートナー様だと思いますが、その認識で合っていますでしょうか？ Public Sectorのお客様とパートナーの皆様ですね？ はい、では適切な場所にお越しいただいています。
始める前に、手を挙げていただきたいのですが、この1週間ほどでAmazonで何か購入された方はいらっしゃいますか？ほぼ全員ですね。返品された方はいらっしゃいますか？何人かいらっしゃいますね。実は私も2、3週間前に、息子のサッカーシューズがサイズが小さすぎて、生まれて初めてamazon.comでの返品を経験しました。注文履歴ページで返品をクリックし、受付場所を選択して、道路を渡ってUPS storeに行き、QRコードをスキャンして箱を預けただけでした。数時間以内にAmazonアカウントに返金が反映され、カスタマーケアから返品体験は満足いただけましたかという個別のメールまで届きました。
これだけを聞くと、特に驚くべきことや革新的なことには聞こえないかもしれません。しかし、amazon.comが世界中で毎日200万個以上の荷物を配送している規模を考えると、このような個別対応の顧客体験は全く異なる意味を持ってきます。この部屋にいる私たち顧客には、共通点が一つあります。AmazonやAWSから何を購入するにしても、すべての顧客に当てはまることが一つあります：私たちは決して満足しないということです。より速い配送、より多くの選択肢、より安い価格、より良い顧客サービスを常に求めています。そして、このように急速に変化する顧客ニーズの時代において、Public Sectorであれ民間企業であれ、それに追いつくのは困難です。
本日は、私のお客様であるCalifornia Employment Development Department（EDD）をご紹介できることを大変嬉しく思います。EDDは現在、EDDNextと呼ばれる複数年にわたる近代化プロジェクトの最中にあり、これについては後ほど詳しくお話しいただきます。このプロジェクトは、約4,000万人のカリフォルニア州民である彼らの構成員へのサービス提供方法を根本的に変革し、数十年にわたって蓄積された技術的負債を解消するものです。まず全体的な話として、EDDのDirectorであるNancy Fariasから、EDDとは何か、その公共に対する中核的な使命と責務についてお話しいただきます。その後、EDDNextプロジェクトのDeputy DirectorであるRon Hughesから、これまでの成果についてお話しいただきます。また、直近の展望や今後数ヶ月から数年で期待できることについてもお聞きします。そして最後に技術的な内容に入り、Amazon Connect SpecialistのChris Carterから、EDDNextプロジェクトがこれまでに提供してきたソリューションの一つである、障害保険プログラム向けのAmazon Connectについて詳しくお話しいただきます。
EDDの概要とパンデミック時の課題
みなさん、ありがとうございます。Tonyさん、ご紹介ありがとうございます。また、皆様の温かい歓迎にも感謝いたします。Amazonの皆様にも感謝申し上げます。ここまでとても楽しく、すべてのHappy Hourに参加してきましたし、この後も参加する予定です。つまり、私も自分のHappy Hourの邪魔をしているわけですね。Tonyの紹介にもありましたように、私はEmployment Development Department、通称EDDのDirectorを務めるNancy Fariasです。皆様の中にも、EDDについてご存知の方がいらっしゃるかもしれません。カリフォルニア州最大の部門の一つとして、約10,000人の従業員と225以上のオフィス拠点を持ち、失業保険、障害保険、有給家族休暇給付として年間数十億ドルを提供し、カリフォルニア州民の生活を支える安定的な存在として機能しています。また、労働力の支援も行っています。
EDDに関するあまり知られていない事実をご紹介します。私たちは州の一般財源の約40%を徴収しており、EDDはIRSに次ぐアメリカ最大の個人所得税徴収機関となっています。カリフォルニアは世界第5位の経済規模を持っているので、このような数字も納得できるでしょう。
本日は、EDDのモダナイゼーションプロジェクトについて少しお話ししたいと思います。Tonyも言及したように、私たちはEDDをEDDNextへと変革しています。これは、EDDの未来であり、私たちの部門の近代化を意味します。EDDNextを通じて、私たちはテクノロジーを活用し、そしてより重要な点として、常識的なアプローチによってEDDとお客様の体験を改善する取り組みを行っています。その使命は、顧客体験を変革し、求職者と雇用主をエンパワーメントし、このモダナイゼーションプロジェクトを通じてセキュリティを確保することです。私たちのアプローチは、顧客中心のイノベーションを活用し、革新的なデリバリーシステムを使用して雇用主と従業員を結びつけ、これらのサービスへのアクセスをシンプルで迅速、そして効率的にすることです - これらは州政府ではあまり耳にしない言葉かもしれません。
カリフォルニアの規模がどれほど大きいか、そして私たちがなぜこのモダナイゼーションプロジェクトに着手しているのか、少し背景をお話しします。パンデミック時、私たちのサービスへの需要は一夜にして急増しました。これは私たちの給付システムをかつてない規模でテストすることになりました。状況を理解していただくために申し上げますと、私たちは2,000万件の失業給付申請を受け付けました。これは大不況時の380万件と比較してもはるかに多い数字です。より具体的に言えば、パンデミック初期の数週間で、週間の失業申請件数が58,000件から翌週には100万件以上に急増したのです。
ご想像の通り、州のEDDレガシーシステムはこのような規模に対応できるようには設計されていませんでした。パンデミックは、進行中だったモダナイゼーションの方向性を再考させることになり、スタッフが手作業で完了しなければならなかった申請件数からも分かるように、私たちが顧客のニーズを最優先にしていなかったことを認識させられました。私たちがメディアや議会で取り上げられた回数も、それを物語っています。また、私たちのポリシーと手続きが時代遅れであることも明らかになりました。部門全体を包括的に見直す必要がありました。例えば、申請者の姓が15文字以上の場合にフラグを立て、スタッフによる手動レビューを必要とするポリシーがありました。ITと共にポリシーと手続きを変更しなければ、IT改善の意味がないことを私たちは素早く学びました。
パンデミック中の需要に対応するため24時間体制で働いた献身的なスタッフがいましたが、私たちはVendorパートナーからの追加サポートを受けることでスタッフを支援しました。パンデミック中、私たちは前例のない数の電話を受けました - ある週には約1,000万件の電話がありました。主に申請の状況を確認する、とてもシンプルな内容の電話でしたが、これだけの電話に対応できる州職員の数は世界中を探してもいません。申請状況を顧客に伝えることができれば、多くの電話を減らせることは直ちに分かりました。
Amazon Connectを活用したコンタクトセンターの近代化
このレベルの需要に対応するため、私たちはコールセンターをAmazon Connectをベースとした統合コンタクトセンターへと近代化を進めています。先週までに、Disability Insuranceのコンタクトセンターとオーバーフローコールサポートの移行を完了しました。この新しいソリューションにより、Disability Insuranceをご利用のお客様は、オペレーターと話すことなく請求状況や支払い状況を確認できるセルフサービス機能を利用できるようになりました。これについては後ほど実際にご覧いただきます。 一見大したことではないように思えるかもしれませんが、EDDのような部門にとって、また州政府にとって、このレベルのコール需要に対応できることは非常に重要な進展なのです。
AIとMLを活用したモダンなコンタクトセンターソリューションにより、会話型のInteractive Voice Responseシステムや、順番を失うことなく折り返し電話を受けられるコールバックオプションなど、多くの新しいサービスを導入しました。これにより、お客様とそのサポートに当たる職員に新しいサービスを提供するための基盤を整えることができました。Disability部門が最初の導入となりましたが、同じ技術をUnemployment Insurance部門や税務コールセンターにも展開していく予定です。
私たちは、お客様が成功体験を得るために、お客様が誰で、EDDに何を求めているのかをより深く理解する必要があることを認識していました。パンデミック以前は非常に限られていた翻訳サービスについて、Language Access Officeを設立し、そのサービスを充実させたことは、最も重要なソリューションの1つでした。カリフォルニアの5人に1人が家庭で英語以外の言語を話していることを踏まえ、多様なコミュニティをサポートするための大規模な投資を行いました。現在では、テクノロジーを活用して、重要な文書を主要な非英語言語に継続的に翻訳できるようになっています。
一般的に、行政サービスに関してお客様が求めているのは、行政との関わりを持たなくて済むことの他に、2つのことがあります。それは、セルフサービスか、電話をかけてすぐに担当者と話せることです。お客様が望まないのは、官僚主義の深みにはまることです。パンデミック後、最初に行った投資の1つは、お客様のニーズや好みを理解し、それを近代化の取り組みに活かすためのCustomer Experience Teamの設立でした。次に、User Experience Teamが、お客様にとって使いやすく、EDDにとって効率的な処理が可能となるよう、プログラムアプリケーションの調査を行っています。この2つのチームは連携して活動しています。
私たちは、Customer User Experience Teamのリサーチとフィードバックを活用し、Amazon Web Servicesと協力して、パンデミック以前には持っていなかったコールセンター技術を導入しました。待ち時間なしで折り返し電話を受けられるようになったことは、お客様との関係に大きな好影響を与えています。重要なのは、近代化に関して「ビッグバン」と呼ばれるような一括導入は行っていないということです。私たちは、段階的に変更を進めながら、お客様に変化を実感していただきたいと考えています。そして何より重要なのは、お客様からのフィードバックを得ることです。
EDD のような大規模な部門の成功を測る最良の方法の1つは、セルフサービスオプションの提供を通じて電話の問い合わせ件数が減少することです。私たちは Chatbot を Web サイト訪問者向けに移行し、EDD ウェブサイトの全ての外部向けページで Chatbot をサポートしています。この移行により、多様なコミュニティのための多言語サポートの基盤を築いています。これはまた、Live Chat や生成 AI によるセルフサービスサポートの基盤となり、コンタクトセンターでの FAQ 応答に対する音声認識・音声合成機能を段階的に構築し、2025年には州職員による EDD エージェントとの Live Chat に向けてセルフサービスを拡大していきます。
お客様が Bot を嫌う最大の理由は、エージェントに繋がれないことです。来年に向けて、できるだけ早くこのギャップを埋めていく予定です。私たちは Voice of the Customer プログラムを持っており、これによってお客様の体験を深く理解することができます。カスタマージャーニー全体を通じてフィードバックを収集し、良い点、悪い点、改善が必要な点をより良く特定し、良い点は増やし、悪い点は減らすか、リアルタイムで修正することができます。
EDDNextの包括的アプローチと顧客中心の改革
EDD の近代化への取り組みは、部門内のすべての部署と機能に及んでいます。先ほど申し上げたように、私たちは IRS に次ぐ米国第2位の個人所得税関連機関です。この大規模な業務をサポートするには、高性能でかつ堅牢なソリューションが必要です。最近、税務アプリケーションを EDD が管理する Amazon Web Services クラウドに移行することに成功しました。このアプリケーションは、カリフォルニア州の雇用主による年間1,100億ドルを超える給与税申告を処理しています。
AWS クラウドを通じて、より優れた災害復旧機能と、お客様をサポートするためのパフォーマンス向上を実現しています。最後に簡単なアドバイスをさせていただきます。まず、私たちのように後れを取った状態からスタートしないことです。お客様を中心に据えた改善を確実に提供しながら、反復的かつ頻繁に近代化を進めるべきです。公共サービスに携わる場合、お客様には職員も含まれます。また、カリフォルニア州にも予算の制約があることを理解しています。
この近代化は単なる技術以上のものです。お客様のニーズに焦点を当てた組織文化を構築し、近代化の一環として方針や手順も見直してください。想定だけに頼らず、お客様調査にコミットしてください。これらの取り組みを総合することで、優れた顧客サービスを提供する組織の構築に役立ちます。ご清聴ありがとうございました。
Amazon Connectを用いたDisability Insurance向けIVRシステムのデモ
Ronが登壇します。ありがとう、Nancy。Nancyは、私たちがEDDの近代化に取り組んでいること、そしてお客様中心のアプローチを採用している理由について素晴らしい説明をしてくれました。 私からは、技術的な観点から見た私たちの近代化プロジェクトと、なぜAWSのクラウドベースのソリューションを選択したのかについてお話ししたいと思います。EDDの近代化というと、多くの人が1つの大きなプロジェクトだと考えがちですが、実際にはそうではありません。これは一連のプロジェクトの集合体であり、すべてがパンデミック時に得た教訓から生まれたものです。Nancyも触れましたが、パンデミック時には週間58,000件だった申請件数が1週間で100万件を超え、最終的には週間250万件までピークを迎えました。
私たちのレガシーシステムは、この申請件数に対応できるスケーラビリティを持ち合わせていませんでした。オンラインシステムにログインしようとしても、多くの人がログインできない状況でした。この申請件数に対応できる技術やツールが整っていなかったのです。ログインできないため電話をかけてきましたが、その電話にも対応できませんでした。オンラインでも電話でも申請できないため、紙の申請書が大量に送られてきて、Document Management Systemがパンクしてしまいました。例を挙げると、私たちは年間1,500万から2,000万件の紙の書類を処理し、10億ドル以上の紙の小切手を扱っています。既存のシステムは20年前のもので、一度も近代化されていませんでした。
これらが、EDDNextを構成する7つのワークストリームです。私たちは、myEDDという共有カスタマーポータルを実装しました。以前は、各プログラムごとに別々の申請受付ポータルがありました。私たちは、すべてのプログラムに対応する単一のポータルとして、SalesforceクラウドでホストされるSalesforceベースの新しいカスタマーポータルを構築しました。最も重要なのは、パンデミック時に経験した負荷に20%上乗せしたワークロードまでスケール可能なように設計されていることです。あの時期はカリフォルニアにとって良い時期ではなかったので、二度とあのような負荷を経験することがないことを願っています。
また、コンタクトセンターソリューションとしてAmazon Connectを導入しました。このクラウドベースのコンタクトセンターソリューションにより、必要に応じてスケールアップが可能になり、以前のソリューションでは利用できなかったツールやテクノロジーにアクセスできるようになりました。また、何百万もの紙の書類をより効率的にスキャンして処理できる新しいDocument Management Systemの導入も進めています。
プロジェクトへのアプローチ方法と改善の優先順位付けについて、ロードマップをご覧いただくのも興味深いかもしれません。私たちは、一般市民に最も大きな影響を与えるプロジェクトを優先し、それらを最初に実施しました。2022年は、チーム編成、カスタマーリサーチ、カスタマーエクスペリエンスの向上に注力しました。2023年には共有カスタマーポータルをリリースし、当初は英語とスペイン語のみの対応でしたが、6言語を追加し、現在は8言語に対応しています。また、申請書の言語をよりシンプルにすることにも力を入れました。
2024年には、私たちは全ての障害保険コンタクトセンターをAmazon Connectに移行しました。また、Document Management Systemの近代化を開始し、ACESアプリケーションをAWSに移行しました。ACESアプリケーションはカリフォルニア州最大の税金徴収システムで、昨年は1,100億ドル以上の税金を徴収しました。2025年には、Unemployment Insurance（失業保険）プログラムをAmazon Connectに移行し、新しいフリクションレスなID Proofingソリューションを実装する予定です。2026年には、新しいICMSシステムの近代化に注力し、Unemployment Insurance、Disability Insurance、Paid Family Leaveを新しいソリューションに移行する予定です。
これらは、Amazon Connectへの移行によって実現した改善点の一部です。Nancy Fariasが言及した待ち時間の見積もり付きバーチャルホールドについてですが、以前EDDに電話をかけた際は、待ち時間が全く分からないまま保留にされていました。現在は、お客様に待ち時間をお伝えしています。待ちたくない場合は、コールバックのスケジュール機能を使って、都合の良い時間を選んでいただければ、担当者から折り返しの電話をさせていただきます。また、お客様の認証を最初に行うようにしました。これは非常に重要で、担当者と話さなくても請求に関する情報を提供できるようになりました。また、担当者が請求状況を確認する際の時間も短縮されました。
認証が完了すると、担当者を待つことなく、Interactive Voice Responseを通じて請求状況を確認できます。これは一見小さな改善に思えるかもしれませんが、請求状況の確認を希望するお客様の約3分の2が、Interactive Voice Responseを通じて確認できるようになり、担当者を待つ必要がなくなりました。これはコンタクトセンターの効率性を大きく向上させました。このソリューションは2025年にUnemployment Insuranceプログラムにも展開される予定です。
クラウドベースのソリューションを選択した理由と、なぜAWSを選んだのかについてお話ししました。このスライドは、その変更を決めた理由のいくつかを強調しています。スケーラビリティは極めて重要でした - パンデミックや不況時に請求件数が指数関数的に増加する可能性があるため、ワークロードの変化に応じてスケールできるソリューションが必要でした。AWSを選択する上で、インフラのスケーラビリティは重要な要因でした。冗長性と災害復旧機能がソリューションに組み込まれていることは、新しいコンタクトセンターの必須要件でした。コンタクトセンターがダウンすると、お客様がEDDに連絡して請求状況を確認できなくなってしまいます。また、適応性も重要でした - 毎年プログラムの変更があるため、プログラムのニーズの変化に応じてソリューションを修正できることが重要でした。
Document Management Solutionの近代化は、EDDNextの重要な部分でした。先ほど申し上げたように、年間1,500万から2,000万件の紙の文書を受け取っており、高度なDocument Management Solutionが必要です。新しいソリューションはAWS上で動作し、文書、スキャン、画像をより効率的に管理できるようになりました。 私たちは、クラウドベースのソリューションでしか実現できない機能を提供するソリューションを求めていました。文書量の変化に応じてソリューションをスケールできるスケーラビリティは重要でした。複数のAvailability Zoneでソリューションが利用可能な高可用性設計を持つ信頼性も重要な要素でした。効率性の面では、AWSにインフラを管理してもらうことで、本当に重要なことに集中できます - 私たちはデータセンタービジネスではなく、サービスビジネスを行っているのです。
最後にお話ししたいのは、現在調達プロセス中の統合クレーム管理システムについてです。45年前からのメインフレームベースの統合クレーム管理システムを、新しいクラウドベースのソリューションに置き換えています。先ほど説明した理由から、今回もクラウドベースのソリューションを指定しました。これは単一の統合システムとなります。最後に、
EDDの近代化に向けて懸命に取り組んでくれたチームの皆さんに感謝したいと思います。Nancyも触れていましたが、私たちには素晴らしい従業員がいて、これらのソリューションを成功させるために24時間体制で働いてくれています。また、パートナーであるAWSとInVisionにも感謝します。これらのプロジェクトについて、私は簡単に聞こえるように話してきましたが、実際はそうではありません。これらのソリューションがいかに複雑かは驚くべきものです。例えば、メインフレームからデータを取得する必要がある度に、APIを構築しなければならず、そのAPIは全て固有のものです。私が話してきたソリューションの全てが、複数のAPIを必要とします。
Amazon Connectをコンタクトセンターソリューションとして移行する際、単にプラットフォームを変更するだけではありません - それは実は簡単な部分です。クレームのステータスを確認するために必要なデータにアクセスするため、AWSを複数のシステムと統合しています。また、このプロジェクトについて話す機会を与えてくれたAWSにも感謝します。NancyとPrivate私は、このプロジェクトを本当に誇りに思っており、どなたとでも喜んでお話しさせていただきます。ここで、Contact Centerソリューションのデモを行うChrisにバトンタッチしたいと思います。
AWSサービスを活用したコンタクトセンターのアーキテクチャ
NancyとRonのEDDとEDDNextの紹介に感謝します。 私はChris Carterで、AWSのConnect Sales Specialistとして、カリフォルニア州や西部の他の州の政府機関と密接に連携し、コンタクトセンターとカスタマーエクスペリエンスソリューションに専念しています。EDDNextの重要な部分は、電話の負荷を軽減することでした。NancyとRonが言及したように、コロナ禍の間、EDDには年間5,000万件の電話がありました。これだけの電話に対応し、全ての顧客を支援できるだけのエージェントはいません。セルフサービスを提供することで、顧客は質問への回答を得られるだけでなく、エージェントは本当に1対1の対応が必要な顧客に集中できるようになります。
分かりやすく言うと、先週火曜日のローンチ時には、1日で23,097人の顧客がセルフサービスを選択しました。そのうち約8,400人が、認証やその他のプロセスを通じてセルフサービスで質問への回答を得ることができました。数日前の月曜日には、9,700人以上がセルフサービスで回答を得ることができ、実際にエージェントを必要としたのは5,000人の顧客だけでした。Ronが言及したように、現在では3分の2の人々がセルフサービスで回答を得られるようになっており、これはエージェントが顧客により多くの時間を費やせるようになったことと、顧客が質問への回答を得られるようになったことの両面で、大きな違いを生み出しています。
このデモをご説明する中で、Nancy氏とRon氏も述べた通り、これは特に革新的なものではありません。お客様サービスとして当然期待されることばかりですが、従来のレガシーシステムやテクニカルデットを抱えた状態では、これらの実現が非常に困難でした。 まず、お客様からの着信があった時点で、言語チェックを行います。お客様がどの電話番号にかけてきたかによって、使用言語が事前にわかることがあります。English専用の番号やSpanish専用の番号にかけてきた場合などです。Spanishの場合は、最初からSpanishのプロンプトを再生します。しかし、English専用の番号にかけてきた場合でも、単に最初に見つけた番号にかけてきただけかもしれないと想定します。この言語チェックの間、バックエンドシステムで電話番号に基づいてお客様の記録を検索し、言語設定が既に登録されているかどうかを確認します。
既に言語設定が分かっている場合は、「Englishは1を、Spanishは2を押してください」といった案内をスキップできます。同時に、オフィスが営業中かどうか、休日かどうかなどの重要な要素もチェックしています。これらの確認が終わり、言語が特定できたら、すべてのプロンプトを事前にロードします。Englishならすべての英語プロンプト、Spanishならすべてのスペイン語プロンプトというように準備します。
すべてのプロンプトを事前にロードすることで、コールフローの設計面では1つのフローを用意し、変数を使って「Spanish用のウェルカムプロンプトを再生」や「Spanish用の終了プロンプトを再生」といった指定ができます。コールフローを変更する際も、サポートする言語ごとに変更する必要がなく、1か所で済むようになります。これらすべてが、呼び出し音が鳴る前の段階で行われており、かなりの作業を事前に処理しているわけです。
ウェルカムプロンプトを再生します：「California Disability Insurance Programにお電話いただき、ありがとうございます。通常の営業時間は月曜から金曜の午前8時から午後5時までです。休日は除きます。メニューオプションが変更されていますので、よくお聞きください。Para Espanol di OK」。このウェルカムプロンプトは事前にロードされていました。この例では言語が特定できていなかったため、EnglishとSpanishの両方を再生し、この時点で言語を変更することができます。
ウェルカムプロンプトの直後に、スパム対策を行います。公的機関は多くのスパム電話やボットによる自動発信の標的になることがあるためです。この時点で、ランダムな番号を生成してお客様に再生し、その番号を入力してもらいます。ボットはこの対応が苦手です（もっとも、生成AIの進化でこれも変わるかもしれません）。現時点では、これをスパム防止に使用しています：「通話を続けるには、次の確認コード6113を音声で言うか、入力してください」。正しければ次に進み、間違っていれば通話は切断されます。
ここで使用している音声は、Amazon ConnectのPolyサービスを利用して組み込まれています。Polyは複数の言語と音声をサポートしており、テキスト読み上げ機能を提供します。Amazon Connectでは、プロンプトを直接入力するか、DynamoDBから読み込むことができます。Ronが言及したように、これにより音声俳優を雇うことなく迅速に変更を加えることができます。テキスト読み上げを活用することで、ビジネスのニーズの変化に素早く対応でき、これらのプロンプトは動的に変更することが可能です。
Claims Management Officeの発信システムとコールバック機能
メインメニューをお聞きください：「より迅速なサービスのため、Claim IDと週次給付額をご用意ください。これらは、My Accountのオンラインホームページ、または申請後に郵送された通知書（Notice of Computation）でご確認いただけます。ご用件をお聞かせください。」最も重要なのは、最後の「ご用件をお聞かせください」という部分です。私たちはAmazon Lexを自然言語理解サービスとして使用したインタラクティブな音声応答システムを採用しています。お客様は自然な言葉で話すことができ、それをIVR体験を導くIntentにマッピングします。
失業保険や障害保険に関する請求についてサポートが必要な場合、インタラクティブIVRがその対応を行います。質問に答えない場合は、「1を押すと○○、2を押すと△△」というメニューオプションが提供されます。しかし、自然な言葉で話すこともできます：「数週間前に障害保険を申請したのですが、請求の状況を確認したいのですが」。Lexはそれを聞き取り、Claim Status Intentにマッピングします。請求状況の確認は、領収書や支払いのコピーの請求を含む多くのセルフサービスオプションの1つです。また、オンライン申請給付、有給家族休暇、失業保険、給与税に関する問い合わせも可能です。
システムを通じて利用可能なセルフサービスオプションを拡張する追加機能は、今後順次提供される予定です。
ここからEDDでユーザー認証プロセスを開始します。Strong属性とFair属性と呼ばれる情報が必要です。Strong属性には、ソーシャルセキュリティ番号、Claim ID、最終勤務日などが含まれます。これらはその特定の個人に固有に紐づいている情報で、認証には3つのうち2つが必要です。そしてFair属性には、生年月日、週次給付額、電話番号があります。誰かが問い合わせてきた際に電話番号が認識できる場合は、すでに確認できているためその情報は求めません。
ここで最初のやり取りを再生させていただきます。というのも、これは双方向のやり取りになっているからです。「より適切なサポートのため、以下の情報をお伝えください。以下の指示をよくお聞きください。Social Security番号を音声で伝えるか、入力してください。」「222101103」「お伝えいただいたSocial Security番号は222101103です。これで間違いありませんか？正しい場合は『はい』と言うか1を押してください。間違っている場合は『いいえ』と言うか2を押してください。」「はい」「あなたの申請は処理されました。」
このような形で続いていきます。次にClaim IDを尋ねます。Claim IDを提供できない場合、システムは最終勤務日を尋ね、そこから質問を続けていきます。認証が成功すると、バックエンドシステムにアクセスします。Ronが言及したように、これらはメインフレームシステムで、Amazon ConnectはAPIを通じてこれらのバックエンドシステムを呼び出し、その申請者に関する全ての情報を取得します。
申請のステータス、最後の支払日、支払いの発送日、給付金の総額など、その申請者に関する情報を使って再生できるプロンプトは数十種類あります。申請者が何を求めているかによって、これらのプロンプトのいずれか、または複数を再生することができます。また、追加書類待ちなのか、申請が処理中なのか、小切手を発送済みなのかといった現在のステータスによっても異なります。バックエンドシステムにある情報に基づいて、プロンプトは全て異なります。
表面的には数個の質問をしてステータスを確認するだけのように見えますが、実際には裏側でかなり複雑な処理が行われています。この時点でステータスが再生されます：「あなたの申請は処理されました。2024年1月8日から2024年1月20日までの期間について、$2,367.86の支払いが2024年9月10日に発行されました。お選びいただいた支払方法によって、支払いの発行まで最大14日かかる場合があります。この情報をもう一度お聞きになりますか？『はい』と言うか1を押す、『いいえ』と言うか2を押してください。」「いいえ」
このようにステータスが確認でき、これが唯一の用件であれば問題ありません。他の用件がある場合は、さらにオプションをご用意しています。重要なのは、このプロセスのどの時点でも「オペレーター」と言えば、オペレーターに接続できるということです。セルフサービスの流れを強制されるわけではなく、オペレーターに繋がることは常に可能です。
この時点で、Call Deflectionチェックと呼ばれる確認を行います。このCall Deflectionチェックは、コンタクトセンターが営業中で、対応可能なエージェントがいるかどうかを確認するためのものです。週末に電話をかけることもできますし、実際、Ronが言及したように、この前の週の感謝祭から土曜日、日曜日にかけて1,400人の方がセルフサービスを利用するために電話をかけてきました。ただし、その時点でエージェントとの会話を希望しても、対応可能なエージェントはいなかったでしょう。
ここでは、対応可能なエージェントがいるかどうかの簡単な確認を行います。エージェントがいる場合は、のページに進みます：「前のメニューに戻るには『前のメニュー』と言うか9を押してください。担当者と話すには『エージェント』と言うか0を押してください。通話を終了するには『通話を終了』と言うか2を押してください。」もしエージェントが対応できない場合やコールセンターが営業時間外の場合は、セルフサービスに戻って別の質問をする選択肢を提供します。しかし、この場合はエージェントと話したいので、「エージェント」と言います。
認証が済んでいる場合は、アンケートも提供します。そのフィードバックを得ることは非常に重要です - 用件が解決したか、質問に対する回答が得られたか、エージェントに接続する場合はエージェントのパフォーマンスはどうだったか、といった点です。ここでもアンケートが提供されます：「私たちは質の高いサービスの提供に努めています。カスタマーサービスに関する簡単な自動アンケートにご協力いただける場合は、シャープを押してください。」
担当者とお話しいただくまでにお待ち時間が発生します。順番を保持したまま、約10分後にお電話を差し上げます。以下の電話番号におかけしてもよろしいでしょうか？18187303094。はいの場合は「はい」と言うか1を押してください。いいえの場合は「いいえ」と言うか2を押してください。「はい」。コールバックのスケジュールを設定しました。次の担当者が対応可能になり次第、お電話いたします。Amazon Connectのコールバック機能では、順番が保持されます。その方がシステムに接続した瞬間のタイムスタンプを保持し、キューでの順番はそのタイムスタンプに基づいています。電話で待ち続けるか、コールバックを選択するかに関わらず、順番は全く同じままです。
このような場合のAmazon Connectの利点は、この時点で課金が停止することです。順番は保持されたまま、順番が来たら、その方に対して発信が行われ、エージェントと接続されます。待つ必要はありません - 待ち時間が3時間かかるかもしれませんし、将来の日時にコールバックをスケジュールすることもできます。電話で待ち続ける必要はないのです。そしてコールバックが行われ、エージェントが応答します：「California Employment Development Department、Disability Insurance Branchにお電話いただき、ありがとうございます。本日はどのようなご用件でしょうか？」
折り返し電話があった際、Salesforceにこのような画面が表示されます。この例では、Amazon ConnectがSalesforceと完全に統合されています。Amazon Connectは、エージェントインターフェースやスーパーバイザーインターフェースを提供するスタンドアロンアプリケーションとして使用することもできますし、APIを使用してCRMやITSMシステムに組み込むこともできます。この事例では、ConnectをSalesforceに組み込んでおり、エージェントは1つの場所で作業できるようになっています。InterVisionとのパートナーシップを通じて、Connectの統合だけでなく、このような高度なGUIインターフェースを持たないバックエンドシステムとの統合も実現しました。
画面の右上で、認証が完了したことがエージェントに通知されているのがわかります。既に確認済みの項目すべてにチェックマークが付いています。この時点で、エージェントは顧客に誕生日やその他の確認情報を再度尋ねる必要がありません - すべての情報が既に揃っているのです。また、請求に関する情報も表示されています。エージェントとして、すぐに顧客対応を始めることができ、時間を節約してより多くの通話に対応することが可能になります。これが障害保険関連の着信通話のデモの全容です。
これは300レベルのセッションですので、もしこのセッションに申し込んでいない方がいらっしゃいましたら申し訳ありませんが、 今ご覧いただいた内容で使用されているサービスについて説明させていただきます。左上には、着信通話をかけているお客様がいます。この場合、Amazon Connectというクラウドベースのコンタクトセンターソリューションへの音声によるやり取りです。これは自然言語理解サービスであるAmazon Lexと、サーバーレス関数であるAWS Lambdaの両方を呼び出す機能を持っています。AWS Lambdaを使用して、ConnectがLexを通じて収集した情報を他のシステムに渡し、顧客情報とともにSalesforceの画面ポップアップを表示することができます。
ここに示されているAmazon DynamoDB（NoSQLデータベースサービス）にデータを渡すことができ、プロンプトやステータス、営業時間などの情報を保存できます。Amazon Connectの柔軟性により、これらの外部サービスを呼び出して活用することができます。最初に、Lexを使用して「ご用件は何でしょうか？」と尋ね、意図を理解します。また、認証にもLexを使用しています：ソーシャルセキュリティー番号は？生年月日は？といった情報です。特にこれらの情報は、DTMFを通じて - つまり電話のキーパッドで入力することもできます。しかし、「最後の勤務日はいつですか？」といった質問に対して、誰かが「11月24日」と答える場合、電話のキーパッドでは対応できませんが、言葉で話すことができます。そのためにLexを使用し、その情報をLambdaに渡してバックエンドシステムをチェックし、すべての情報をConnectに戻しています。
Amazon Connectで情報を受け取ると、支払い金額や日付などの変数を保持している既存のプロンプトと組み合わせることができます。そしてそれらのプロンプトをユーザーに再生します。ここでスタックを下っていくと、Lambdaを通じて請求と支払いのステータスを取得します。プロンプト、営業時間、ステータス指示などの情報は、AWS Lambdaを通じてAmazon DynamoDBに渡されます。
このシステム全体には監視機能が組み込まれています。各問い合わせには完全なトレースログがあり、IVRシステムのどの経路を通ったかを正確に把握できます。また、問い合わせ時刻、待ち時間、対応したエージェント情報などを示すContact Trace Recordも記録されています。これらのデータはすべてAmazon CloudWatchとAmazon S3の組み合わせで保存されています。また、まだ実装されていませんが、近々、お客様が最寄りのオフィスを問い合わせることができるようになり、郵便番号検索を使ってAmerican Job Center APIにアクセスし、その情報を提供できるようになります。最終的に、これらはすべて現在Salesforceをインターフェースとして使用しているエージェントにつながります。
請求管理プロセスの効率化：AIとクラウドの活用
次に、2つ目のデモである請求管理についてご説明します。障害保険の申請をする際、最終勤務日などの情報が申請に含まれていない場合があります。そのような申請は請求管理オフィスで処理されます。エージェントは、SDI Onlineというシステムを使用しており、Claims Management Office（CMO）担当者に送られる作業項目キューがあります。 SDI Onlineから請求を取り出すと、Salesforceに移動してその顧客への発信を開始することができます。
エージェントはSalesforce内に作成されたCMO発信用のリンクをクリックします。 クリックすると、請求IDや電話番号、その他その方の請求に関する情報を入力するフォームが表示されます。このフォームでは、その方の希望する言語や通話理由など、さまざまな詳細を入力することができます。 画面上部には請求IDが表示され、電話番号欄もありますが、プライバシー保護のため本日はぼかして表示しています。
この電話番号を使用してシステムが発信を開始します。発信時には2つのパターンがあります：エージェントが相手と接続できる場合と、できない場合です。接続できた場合、エージェントは「最終勤務日はいつでしたか？」といった質問をすることができます。相手はすぐに答えられる場合もあれば、そうでない場合もあります。Salesforce内で、エージェントが全ての情報を入力したら、電話番号をクリックして発信を開始します。Salesforceの発信画面には、その請求管理担当者向けのすべての情報が表示されます。
この時点で、質問への回答を得られる場合と得られない場合があります。回答が得られない場合やコールバックが必要な場合、エージェントはコールバックが必要であることを示すディスポジションコードを設定できます。これを行うと、エージェントの詳細を含むすべての情報がAmazon DynamoDBに記録されます。これにより、相手からコールバックがあった際に、その情報を参照して待ち受けていた電話かどうかを確認できます。元のエージェントが対応可能な場合、タスクを通じてそのエージェントに通話をルーティングできます。請求管理エージェントがすでに収集した情報がすべて残っているため、一からやり直す必要がなく、より効率的なプロセスとなります。 アーキテクチャはシンプルで、Salesforceから始まり、情報を入力します。
Connectは次にアウトバウンドコールを発信し、そのクレーム情報を使ってLambdaでAmazon DynamoDBに書き込みを行います。これは、その人からのコールバックを期待している場合です。この例では、相手が電話に出なかったため、ボイスメールを残したということにしましょう。 PIIが含まれており、誰が実際にそのメッセージを聞くかわからないため、ボイスメールには多くの情報は残しません。単に「折り返しのお電話をお願いします。こちらの電話番号にご都合の良い時にお電話ください」という内容だけです。
お客様がその電話番号に折り返しの電話をかけてきた場合、まず言語を英語に設定し、休日や営業時間外のチェックを行います。その後、ウェルカムプロンプトを再生します。DynamoDBテーブルを検索して、このお客様からのコールバックを期待しているかどうかを確認します。期待していない場合は、メインの障害保険の電話回線に転送されます。期待している場合は、エージェントが以前にフォームに入力した言語に設定を変更します。
その後、元のエージェントが対応可能な場合、その言語ですべてのプロンプトを再生します。上部のパスで見えるように、そのエージェントにルーティングし、この人から電話がかかってきていることを短いウィスパーで知らせます。画面上にもポップアップを表示します。 エージェントが対応可能な場合、電話がルーティングされ、応答することができ、以前と同じようにすべてのクレーム情報が画面に表示されます。まるで最初から電話に出られたかのようです。
しかし、エージェントが対応できない場合、お客様にメッセージを残すようプロンプトを表示します。ここでAmazon Transcribeを使用して、お客様の音声メッセージをテキストに変換し、右下に表示されているすべての情報を取得します。これらすべてをAmazon Connectのタスクに添付します。このタスクは、チャットや電話と同じようにエージェントにルーティングされますが、今回はタスクとして上がります。これはコンタクトセンターのエージェントが扱う帯域外のアクティビティだと考えてください。
メッセージが文字起こしされ、すべての情報がそのタスクに接続され、エージェントには電話のように表示されます。エージェントが昼食やその他の用事から戻り、再び対応可能になると、そのタスクが彼らにルーティングされます。タスクを開くと、そのクレーム発信者に関するすべての情報が表示され、お客様が述べた内容の文字起こしも含まれています。これは従来のボイスメールよりもはるかに効率的です。エージェントはもう音声を聞く必要がなく、エージェントがそのタスクに対応したか、お客様に連絡を返したかを追跡する方法もあります。分析の観点から、これらすべてが今では追跡可能になっています。
このアーキテクチャはそれほど複雑ではありません。音声によるインタラクションが行われ、それは顧客からのインバウンドコール、あるいはConnectからのアウトバウンドコールかもしれませんが、このケースでは顧客からのコールバックです。Amazon Lexを通じて顧客の入力を収集し、Lambdaを使用してDynamoDBとやり取りを行い、コールを予期していたためそのデータを全て読み込みます。エージェントの対応可否に関わらずタスクが生成され、そのタスクがエージェント用のSalesforceに反映されます。
セッションの締めくくりとアンケートのお願い
以上で私の発表は終わりです。ここからはQ&Aの時間とさせていただきます。Chrisとご来場の皆様、ありがとうございました。時間も5時30分となりましたので、そろそろお開きとさせていただきます。ご参加いただき、重ねて御礼申し上げます。画面にQRコードを表示していますので、この後のお時間やHappy Hour、お食事の際などに、アンケートにご協力いただければ幸いです。改めまして、Ron、Nancy、Chris、素晴らしいセッションをありがとうございました。また、会場の皆様からのご質問にも感謝申し上げます。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion