re:Invent 2024: PearsonがAmazon ConnectとSalesforceで顧客体験向上
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - How Pearson elevates CX with Amazon Connect & Salesforce Service Cloud (BIZ215)
この動画では、SalesforceとAWSの戦略的パートナーシップによって実現するSalesforce Contact Center with Amazon Connectについて解説しています。Service Cloud Voiceに新たに追加される機能として、チャット、In-app Web Video Calling、Screen Share機能などが紹介され、これらがSalesforce内でネイティブに統合される利点が説明されています。また、Pearsonの事例として、VP of Customer SuccessのShantel Loveが、Service Cloud Voiceの導入により250万ドルのコスト削減を実現し、CSATスコアが94%、Net Promoter Scoreが42から47ポイントに向上した成果を共有しています。さらに、Amazon ConnectのPrincipal Product ManagerのMarc Rudkowskiが、新機能のデモを通じて、エージェント、カスタマー、スーパーバイザーそれぞれの視点からの具体的な活用シーンを紹介しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Salesforce Contact Center with Amazon Connectの紹介
あらゆるチャネル - 音声、Webチャット、メール、テキスト、WhatsApp、そして今後登場するどんな手段でも - をシームレスに体験できる世界を想像してみてください。そこでは、エージェントが顧客の行動履歴やデータを、電話やチャットに応答する前に把握できます。顧客のニーズを予測し、さらには他のソリューションを提案することもできるのです。このとき、顧客とエージェントの満足度がどれほど向上するか想像してみてください。私はLaura Fraserです。AWSのPartner Development Managerとして、SalesforceとのStrategic Partnershipを担当しています。本日は、PearsonのVP of Customer SuccessであるShantel Loveにお越しいただいています。彼女は、AWSとSalesforceを活用したPearsonの取り組みについて、顧客満足度の大幅な改善につながった経緯をお話しします。また、コンタクトセンター技術の専門家であるMarc Rudkowskiもご参加いただいています。MarcはAmazon ConnectのPrincipal Product Managerで、2017年からSalesforce統合に携わってきました。本日は、デモを含めて、エキサイティングなニュースをお届けする予定です。このセッションでは、Salesforce Contact Center with Amazon Connectについてご紹介していきます。
カスタマーサービスの課題と技術による解決策
まず始めに、今日のカスタマーサービスのリーダーたちは、より少ないリソースでより多くのことを成し遂げることを求められています。サービスコストを削減しながら、収益への貢献度を高める必要があります。これは簡単な課題ではありません。彼らは、顧客の問題解決だけでなく、ロイヤリティを高め、企業に新たな収益源をもたらす組織への変革を進めています。 Qualtricsの調査結果についてお話ししましょう。最近の調査によると、55%のカスタマーサービスの問題が初回で解決されていないことがわかりました。つまり、2回に1回は問題が解決されず、顧客は再度連絡しなければならないのです。そして2回目の問い合わせでは、顧客満足度は劇的に22%も低下します。
これは、ビジネスにとって何を意味するのでしょうか？不満を抱えた顧客への対応、不満足な顧客による潜在的な収益損失、そしてブランドの評判への長期的なダメージについて考える必要があります。この問題に対処する余裕があるかどうかではなく、対処しないことができるのかという問題なのです。 希望が持てる統計もあります：顧客が企業に満足している場合、支出が62%増加する可能性があります。また、電話で話すエージェントから共感を得られた場合、待ち時間の長さに比べて、顧客満足度は2倍になります。つまり、効率性よりも共感が重要なのです。
初回解決と真摯な共感を組み合わせることで、単なる問題解決を超えて、収益成長の機会を生み出すことができます。「Laura、すべては共感にかかっているということですが、それをどのように実現するのですか？」と思われるかもしれません。そこで技術が役立ちます。Omni-channelやテキスト、音声分析により、顧客の感情やセンチメントを特定し、エージェントがリアルタイムで共感を持って対応することができます。リアルタイム文字起こしと組み合わせることで、Artificial Intelligenceは顧客の意図を明確にし、解決策を特定し、アップセルの機会を含む次のベストアクションを自動化することができます。
Service Cloud VoiceとAmazon Connectの統合ソリューション
このような背景から、4年半前に、SalesforceとService Cloud Voice with Amazon Connectを導入しました。これはService Cloudに初めてネイティブ統合された電話ソリューションです。 Service Cloud Voiceは、顧客データと行動履歴の統合ビュー、通話コントロール、リアルタイム文字起こし、そしてService Consoleからの次のベストアクションを提供します。これにより、エージェントは通話中や通話後に異なるアプリケーションを切り替える必要がなくなります。そして、統合されたチャネルにより、
シンプルな問い合わせについては、チャットボットに簡単に転送することができ、コストを削減しながら顧客により迅速な回答を提供することができます。顧客の問題がより複雑な場合は、それまでに収集されたコンテキストを保持したまま、シームレスにエージェントに転送することができます。Amazon ConnectとService Cloudの連携により、お客様は事前に統合されたデプロイメントと、2つのエンタープライズグレードのソリューションによる迅速な革新を手に入れることができます。これにより、顧客満足度とロイヤリティを向上させる新機能の提供に注力することができます。
私たちは、このソリューションが現在1,000社以上のお客様に採用され、世界中で10万人以上のエージェントに利用されていることを誇りに思っています。Toyota Motor North America、Air Canada Cargo、Credit Karma、Sonos、Sachsなど、様々な業界や地域のお客様に広く採用されています。それでは、私からの製品説明ではなく、2023年以降の実際のお客様であるPearsonの経験についてお聞きしましょう。Chantelle、Pearsonの紹介と、これまでの journey についてお話しいただけますか？
Pearsonの事例：電話システム移行の背景と課題
ありがとうございます、Laura。Pearsonをご存じない方のために説明させていただきますと、Pearsonは世界最大の教育企業です。私は特にClinical Assessmentsという部門に所属しており、全国の学区、政府機関、個人開業医の方々にサービスを提供しています。学習者一人一人の journey に合わせた臨床評価や心理評価を提供しています。
手を挙げていただきたいのですが、Wobbleというゲームをご存知の方は何人いらっしゃいますか？Wobbleというゲームを全く知らない方は？そうですよね。Wobbleを知っていると手を挙げた方々は、次世代のAIかもしれませんね。なぜなら、このゲームは私たちが今作り上げたものだからです。
Wobbleについて説明させていただきます。これは、商標の関係で名前を出せないあるゲームのスピンオフです。私がWobbleというゲームを初めて知ったのは、Pearsonでの仕事以外で参加したイベントでした。私は"Promote Your Damn Self"という本の著者でもあり、スピーカーとしても活動しています。そのイベントでこのゲームをプレイしていて、とても興味を持ちました。このゲームは、いわゆる「大人の飲み物」と一緒にプレイされることが多いんです。まだ5時ではありませんが、ここはLas Vegasですね。とはいえ、今回は「大人の飲み物」は省略させていただきます。
このゲームについてもう少しお話ししたい理由を説明させてください。 Wobbleは私の日常生活を思い起こさせるんです。プレイヤーはカードに書かれた文字が入り混じったフレーズを読み上げ、この部屋にいる皆さんのように、グループで協力して問題を解決していきます。時間に追われながら問題を解決し、明確な答えを導き出すために最適なコミュニケーション方法を活用しなければなりません。
このゲームが関連性が高い理由は、今からみなさんにこのゲームを実際にプレイしていただくからです。画面にこのカードを表示しますが、おそらく皆さんは「この単語は意味が通じない」と思われるでしょう。それが私たちの「Wobble」なのです。画面に表示されている単語を見ると、「MORE KIT TING STRUT EG」と書かれています。この意味不明なフレーズを解読できる方は手を挙げてください。分かる方はいますか？全く見当がつかない方は？大丈夫です、ここは安全な場所ですから。
この「MORE KIT TING STRUT EG」の正体は、実は「Marketing Strategy」なんです。賞品やボーナスをお渡しできたらよかったのですが。Marketing Strategyということで、このゲームを紹介した理由は、私たちの電話システムの移行について考えると、このWobbleゲームのような状況だと感じるからです。皆さんの電話システム全体を、今私たちがプレイしていたゲームのように想像してみてください。それが皆さんにとってどのように見えるか、考えてみてください。
では、皆さんがそれをどのように想像されているか、私たちの場合をお話しします。私たちが経験した電話システムの移行では、様々な課題が発生しました。これらのシステムを連携させる方法を見つけ出そうとして、あちこちWobbleしながら奮闘していました。また、レガシーテクノロジーと新しいテクノロジーの両方を扱い、グローバルな組織全体で多様なテクノロジーを活用することになりました。
私は時々、息子との類推を思い浮かべることがあります。7歳の息子は自称ゲーマーなのですが、私は80年代っ子でAtariで育ちました。Atariはこれくらいの大きさで、息子が遊んでいるNintendo Switchはこれくらいの大きさ、そしてゲームソフトはこれくらい小さいんです。このように小さなNintendo SwitchのゲームソフトをAtariに入れて動くと想像してみてください - うなずいたり笑ったりする人がいるように、おそらく動きませんよね。そして、これが私たちが経験したことなのです。
さらに、ゲームと同じように、現状を把握し、私たちがどこにいるのかを特定し、正直に向き合う必要がありました。そうすることで、私たちがどこに向かいたいのかを理解することができたのです。また、全てのチーム間でのコミュニケーションの取り方も考慮する必要がありました。これはカスタマーサービス部門とのコミュニケーションだけでなく、顧客と関わる全てのビジネスユニットを考慮に入れる必要がありました。さらに、迅速なソリューションを見つける必要に迫られていました。私たちの実装は2022年、パンデミックの真っ只中に始まったので、素早く機能するソリューションを見つける必要がありました。
最後に、Wobbleというゲームのように、一見支離滅裂なものを一貫性のあるものにしようと努めていました。この電話システムへの移行について考えると、私たちは何度も岐路に立たされました。そして、学習する企業の精神として、私たちが何度も立ち返った言葉があります。それは：「世界で最も大きな部屋はドバイにあるわけでもなく、人工的に作られたものでもありません。世界で最も大きな部屋は、改善のための余地なのです」。最適なパートナーやベンダーを特定する方法を考える際、現状だけでなく、改善の余地に焦点を当てることが重要でした。
Pearsonの移行プロセスと成果
さて、私たちの journey についてお話しする中で、私たちがどこからスタートしたのかをお伝えしたいと思います。まさに底辺、完全な底辺からスタートしたように感じます。というのも、以前はセールスリーダーとしての役割から、Customer Success という全く異なる世界の役割に移ったからです。電話システムを評価する中で、最初に思い浮かんだのは私たちの最大の課題でした。友人の間での話なので正直に言うと、私たちにとっての課題は、グローバルな組織であることでした。オフィスにいる時は非常にうまくいっていました。通話をモニタリングしたり、活動状況を直接確認したりすることができました。しかし、以前の電話システムは将来に向けて準備ができていませんでした。通話の聞き取りやモニタリングに苦労し、他のシステムに接続して何とか機能させようとしていました。コンタクトセンターの経験がある方なら、期待するものを検査・モニタリングする能力なしには、成功という方程式は成り立たないことをご存知でしょう。
また、移行時には米国内に17以上の異なる電話回線があり、その中には使用中のものと使用されていないものが混在していました。電話番号のポーティングでも課題に直面していました。
私たちは、データに関連するさまざまな課題に直面していました。皆さんご存知の通り、入力するデータが悪ければ、出力されるデータも悪くなります。そのため、理想の状態に到達するには、現状を正直に見つめ直し、データをクリーンアップするプロセスを経る必要がありました。当時、私たちは3つの異なるベンダーから電話システムのサービスを受けていました。Clinical Assessmentsを代表してここに立ち、私たちの経験をお話ししていますが、実は4万人規模の組織の中で、私たちは最初の移行部門だったのです。いわば実験台として、この移行プロセスを通じて多くのことを学ぶ必要がありました。
スタート時点で評価が必要だった他の側面としては、現行のQAシステム、営業部門のサポートと連携の方法、そして顧客の期待値がありました。電話システムという全体の方程式の中で、新しいシステムがどんなに優れていて輝かしくても、顧客と組織の課題を解決できなければ、それは逆効果となります。私たちは長い間、そのような状況に置かれていました。
移行は段階的に行い、まず米国の最大事業部門から始めました。その後、Asia Pacific市場、そしてEurope、Middle East、Africa市場へと移行していきました。この場にいらっしゃるグローバルな移行を検討されている方々に、ぜひグローバルなプロセスを持つことをお勧めしたいと思います。私たちにはグローバルなプロセスが必ずしもなく、後付けで設計する必要がありました。 最終的な結果と実現したい体験を考える際、エージェントやチャンピオンが指摘していた点を考慮に入れました。顧客やクライアントが求めているトレンドや特徴を特定するため、多くの時間をかけてセンチメント分析を行いました。それらは、明確性とコスト、インテリジェントなIVR、そして価値の低い、あるいは価値のないタスクのために待つ必要のないオプションでした。
このプロセスを後付けで設計する中で、先ほど触れたデータについてですが、私たちには大量のデータがありました。 データが本来あるべきでない場所に存在していました。コンタクトセンターの実態について正直に向き合う必要がありました。営業チームがカスタマーサービスの電話を受けていたため、適切なデータが得られていませんでした。European市場に関しては単なる通過点となっていたため、通過するデータすべてを特定することができず、パートナーに引き継ぐためのデータを正確にクリーンアップするのに時間がかかりました。
次に検討する必要があったのはシステム構成でした。 先ほど述べたように、一見小規模な事業部門に3つの異なる電話システムが存在し、それらは互いに連携していませんでした。Salesforce Service CloudとAWSの専門家と密接に協力して、システムを適切に構成するための最適なソリューションを見出す必要がありました。これは、アクティブな電話回線が使用できなくなる事態を最小限に抑え、回避するために重要でした。大規模な移行を行う際には、サービスの中断を最小限に抑えるため、古い電話回線に新しい電話回線をオーバーレイする必要があるからです。私たちは顧客へのサービス中断を回避することに重点を置いていました。
もう1つ重要だったのは、変更管理の方法論です。これは私たちにとって恐らく最も重要なステップだったと言えます。電話システムの変更は、単に電話番号を変えるだけの話ではありません。そのため、私たちは変更管理の方法論において、内側からのアプローチを取りました。
組織の構造によって、システム、レポート、そして様々なアウトプットに違いが生じます。変更管理の方法論を検討する際、私たちは単にスタッフに新システムの研修を行うことだけでなく、フェイルセーフについても考える必要がありました。初日にシステムが完全にダウンした場合はどうするのか？夜9時にローンチして米国で誰も起きていない場合はどうするのか？電話システムを使い始めた時に、エージェントやチャンピオンが適切なレベルのサポートを受けられない場合はどうするのか？変更管理プロセスを検討する際、私たちは内側と外側の両方からのアプローチを取る機会を逃したくありませんでした。
次に重点を置いたのがQA testingです。迅速に進めたいと考えていましたが、品質保証テストは絶対に妥協したくない要素の1つでした。組織内での移行を検討する際、その規模の大小に関わらず、ローンチ前のQA testingは極めて重要です。想定通りに機能するか確認し、本番環境に移行する前に安全な環境でテストを行い、統合するシステムやツールが適切に機能することを確認する必要があります。私たちは多くの時間を費やし、スピードを落としてでもQA testingの品質を最高レベルに保つことに注力しました。
エージェントが最も気に入ったのは、ユーザートレーニングでした。私たちはエージェントのことをチャンピオンと呼んでいますが、彼らはこの移行において重要な役割を果たしました。経営者やリーダーとして、私たちは往々にして上からの視点で物事を考えがちで、実際にシステムやサービスを利用する人々の視点を見落としてしまうことがあります。そのため、ユーザートレーニングとQAの際には、チャンピオンたちを議論に参加させ、機会を逃さないようにし、顧客により近い立場にいる彼らの視点を取り入れました。このアプローチは、ユーザートレーニングを開始する際の素晴らしいフレームワークとなりました。
さて、ここからが楽しい部分です。 一連の課題に対処し、電話システムのローンチに至った後の状況についてお話ししたいと思います。 特に強調したいのはコストに関する部分です。移行から1年以内に、すぐにコスト削減効果が表れました。これは、不適切な16の電話回線にコールが転送されなくなったためです。また、Next Best Actionのようなツールを活用することで、インバウンドコンタクトセンターがアップセルやクロスセルの機会を提案できるCustomer Success組織として機能できるようになり、コスト面でもメリットが生まれました。約12ヶ月後には、電話システムの移行により250万ドルのコスト削減を実現することができました。
もう1つの大きな改善点はグローバル化です。私たちは「Follow-the-sun」モデルで機能するコンタクトセンターを目指しています。ご存知ない方のために説明すると、これは地理的な制約に関係なく、24時間365日お客様に対応できる体制を意味します。これは現在も進行中のプロジェクトですが、以前は全員が異なる電話システムを使用していたため実現できませんでした。平均処理時間や初回解決率、その他のコンタクトセンターの重要な指標を把握することができなかったのです。
この移行により、この1年半の間に、現地の朝の時間帯にコンタクトセンターを稼働させ、米国の遅い時間帯のコストをサポートすることが可能になりました。これは私たちにとって大きな成功でした。コール量が増加する1、2時間の時間帯に、人員を増減させる必要がなくなり、コスト削減につながったのです。
もう1つの重要な側面は顧客満足度です。そして、顧客満足度について語る際に、従業員満足度に触れないわけにはいきません。従業員と話をし、正直な意見を言える場を設けると、彼らは何が問題なのかを教えてくれます。この電話システムを導入する際、私の従業員たちも例外ではありませんでした。以前のシステムは頻繁にシャットダウンし、何度もログインとログアウトを繰り返す必要があり、お客様からは音声がロボットのように聞こえるという苦情がありました。新システムの導入は、従業員満足度と顧客満足度の両方に大きく貢献しました。これは、現在すべての地域で合計94%を記録しているCSATスコアだけでなく、年間のNet Promoter Scoreが初年度に42ポイントから47ポイントに大幅に上昇したことからも明らかです。
Salesforce Contact Center with Amazon Connectのデモンストレーション
この移行の結果として、私たちはOmni-channel体験からも恩恵を受けました。Omni-channel体験で私が特に気に入っているのは、以前は異なるプラットフォームに分散していた情報を一元的に把握できるようになったことです。単一のプラットフォームで、チャットチャネル、通話中の通話記録、コールキュー、メールキューなど、すべてが一つのエンティティとして機能しているのを確認できるようになり、これは私たちにとって画期的な変化でした。
次のフェーズに移る前に、一つお伝えしたいことがあります。電話システムへの移行を検討する際は、単なるベンダーではなく、パートナーを確保することが重要です。これは私たちの経験から得た教訓です。私たちは、単に発注を求めるだけでなく、私たちの話に耳を傾け、私たちを主題専門家として扱いながら、次のステップや、カスタマーサービス組織からCustomer Success組織への移行における将来の可能性について考えるよう促してくれるパートナーを見つけることができました。
私たちの移行における次のステップについて、とてもワクワクしています。ここでMarc に引き継ぎたいと思います。Salesforce Contact Center with Amazon Connectの未来が、まさに今ここにあります。これは基本的に、Service Cloud VoiceとネイティブにインストールできるApp Exchange上のパッケージで、チャット、インアップボイス、統合ルーティングなど、追加のAmazon Connect機能を解放します。これらの機能セットについて、そのプレビューの内容を詳しく見ていき、それぞれの機能について説明していきます。最初の機能セットは、Amazon ConnectのチャットとSMSをBYO機能として、Salesforceの統合エージェントエクスペリエンス内でネイティブに活用できることです。Amazon Connectに電話やチャットが入ってくると、IVRを通じてルーティングされ、セルフサービス体験で解決できない場合は、エージェントにエスカレーションされ、最終的にSalesforceのOmni-channelエクスペリエンスにネイティブに提供されます。Service Cloud Voiceの統合エージェントエクスペリエンスで現在見られる機能は電話に関するものですが、Salesforce Contact Center with Amazon Connectを使用することで、さらなる機能が解放されます。
この先はSalesforce Contact Center with Amazon Connectと毎回フルネームで言うよりも、そう呼んだ方が簡単ですね。この追加機能セットにより、プレビューではIn-app Web Video CallingとScreen Shareの機能も解放されます。最初はIn-app Web Callingの機能をサポートする予定で、これについては後ほどデモでお見せします。その後、VideoとScreen Sharing機能のサポートも続けて提供していく予定です。
統合ルーティングに関しては、新たな機能が解放されます。現在、Amazon Connect内では、この統合ソリューションの一部としてVoiceとChatをルーティングできます。これに加えて、追加のSalesforceオブジェクトもルーティングできるようになります。例えば、Salesforceの外部ルーティングを活用して、CaseをAmazon ConnectのIVRエクスペリエンス内でネイティブにルーティングできます。これの利点は、特にコスト削減が必要なセルフサービスエクスペリエンスにおいて、Salesforce側のコンタクトセンター実装をシンプルにできることです。また、現在SalesforceのChatとAmazon ConnectのVoice機能を統合する際に見られる課題を解消する点でも、統合ルーティングは役立ちます。
Service Cloud Voice内でのパッケージのセットアップとインストールについては、ネイティブに行えます。デモでもお見せしますが、Service Cloud Voiceをセットアップすると、私たちの機能は自然な統合拡張として組み込まれます。Service Cloud Voiceのセットアップ後、数分で簡単にセットアップできるようになっています。デモでは、いくつかのペルソナを紹介します。最初のペルソナは、エンドカスタマーのNikkiです。彼女はソーラーパネルに問題があり、サポートを求めて連絡してきます。その対応として、エージェントのJohnと会話することになります。このデモの後、AnyCompany Energyのエージェントセンターを監督するスーパーバイザーのDiegoの視点からも見ていきます。
新機能の詳細と設定プロセス
このデモの後、実際にService Cloud Voiceをセットアップする方法をお見せします。管理者のペルソナとしてのNikhilの視点からご説明します。ライブデモは常にうまくいくとは限らないので - むしろそうではないので - これは録画されたデモです。このプロセスを通じて、時間と進行をより良くコントロールでき、デモをよりスピーディーに進めることができます。
AnyCompany モバイルアプリケーションを使用して電話をかけているNikkiのケースをご紹介します。基本的に同じ状況で、彼女が問題解決を試みる3つのパターンをお見せします。まず、現在一般的に見られるService Cloud Voiceのネイティブな使用例からご紹介します。すでにService Cloud Voiceをご利用の方にとっては、とても馴染みのある画面だと思います。現在のエクスペリエンスの基準として、まずこちらをご覧いただきます。そして、Service Cloud Voiceを活用することで、新たにIn-app Voice機能も利用できるようになりました。また、Chatの機能についてもご紹介します。
Nikkiは電話アプリケーションを通じて連絡してきました。彼女はAmazon Connect IVRとセルフサービスを利用しています。このセルフサービスでは、LexやQ and Connectを利用することができます。このやり取りの中で、ケースが作成されました。セルフサービスでは問題を解決できなかったため、エージェントのJohnに対応が引き継がれることになります。電話がかかってきてJohnが応答すると、スクリーンポップアップが表示されます。Service Cloud内にいくつかのコンポーネントが表示されているのがお分かりいただけると思います。音声通話を制御するコールコントロールパネル、Contact Lensからのリアルタイム文字起こしを表示するトランスクリプションウィンドウ、電話番号に基づく連絡先情報、Contact Lensから検出されたインテントに基づくNext Best Action、そしてIVRとのやり取りで作成されたケースが表示されています。
電話がかかってくると、 リアルタイムの文字起こしが始まります。Next Best Actionもご覧いただけます。JohnとNikkiが会話を進める中で、Johnはソーラーパネルの問題を調査するために技術者の現地訪問を予約する必要があると判断します。このインテントがContact Lensによって検出され、プロンプトが表示されました。そしてJohnは Omni Flowsを使用して予約のワークフローを進めていきます。
この時点で通話は終了となりますので、通話を終了してAfter-Call Work（後処理）に移ります。エージェントが「完了」をクリックすると、後処理フェーズに入ります。 ここでエージェントは、メモを確認して見落としがないかどうかを確認するために、通話の録音を再生することができます。また、感情分析を含むコールサマリーも生成されており、今後の展開も予見できます。エージェントはこれらの情報を活用して、ACWの観点から通話を完了することができます。
ここで、モバイルアプリケーションに話を戻して、別のパターンをご紹介します。 今度はNikkiが電話ではなく、In-appエクスペリエンスを通じて連絡してきます。AnyCompanyがネイティブモバイルアプリケーションを持っている利点は、In-app通話のためのUIを柔軟に活用できることです。 これは、モバイルアプリケーションのネイティブ機能として、あるいは小売のウェブサイトのような場合は埋め込み機能として、様々なユースケースで活用することができます。
また、お客様とチャットをしている際に、チャットから音声通話、ビデオ、画面共有へとエスカレーションする必要がある場合の対応にも非常に適しています。このような進行の流れを確認できますし、これらのチャネルを使用すれば比較的簡単に実行できます。電話の場合よりもずっと簡単です。先ほど見たように、電話のUXがポップアップ表示されます。さらに、このやり取りの中でお客様に通話料金が発生することもありません。
ここでも同様の流れを見ていきましょう。In-app通話が入ってきますが、ここで注目すべき点は、モバイルアプリケーション内でユーザー認証を行っているということです。In-app通話を使用する場合、電話番号は使用しません。代わりに、Webアプリケーションやモバイルアプリケーションでユーザーを認証する際に、メールアドレスなどの他の要素を使用することになります。ここでも同様に、そうしたコンテキスト情報がすべてSalesforceに渡され、エージェントに提示されます。
同じステップを踏んでいることがわかりますが、同じインタラクションモデルに従っているので、そのまま再生を続けさせていただきます。これが、Salesforce内の統合インターフェースを使用する利点です。次はチャットを見てみましょう。チャットが入ってきて、Nikkiがボットとチャットを始め、そこからエージェントにエスカレーションされます。音声通話でも、In-app通話でも、チャットでも、すべてSalesforce内のネイティブなOmni-channel UXを使用しているのです。
チャットが入ってくると、音声通話とは少し異なるレイアウトが表示されます。なぜなら、今は音声通話ではなくチャットでやり取りをしているからです。ここではチャットのメインウィンドウが表示されています。もう1つ注目すべき点は、Salesforceとの深い統合により、Amazon Connect ChatやSMSの機能を活用できるだけでなく、定型文の使用やスーパーバイザーへのフラグ機能など、Salesforceのチャット機能も利用できることです。
ここでも様々な動作を見ていきますが、全体的なワークフローは非常に似ています。アフターコールワークを作成し、通話を終了します。このように、チャネル間での一貫性と、ConnectからSalesforceへのネイティブなルーティング作業を、エンドツーエンドで簡単にセットアップできることがお分かりいただけると思います。
次は、Supervisorのデモに移りましょう。ここでは、コンタクトセンターを監視するSupervisorのDiegoが登場します。Service Cloud内に組み込まれたダッシュボードを使用して、音声通話やIn-app通話、そしてチャットなど、様々な通話を確認していきます。Service Cloud VoiceがSCVにネイティブに組み込まれているため、Salesforceに元々存在する多くのビルトインオブジェクトを活用できるという利点があります。そのため、音声機能を最大限に活用することができるのです。
これには音声オブジェクトとネイティブメッセージングオブジェクトが含まれています。Supervisorとして、NikkiがJohnと以前行った通話を確認することができます。その通話のコンテキストを見ることができ、やり取りの感情分析を含む情報を詳しく調べることができます。これにより、NikkiとJohnが以前行ったやり取りの全体像を把握することができます。メッセージングのやり取りについても、同様に様々なオブジェクトやメッセージにアクセスして確認することができます。
メッセージをクリックすると、エージェントが見ているのと同じようなビューが表示されます。Supervisorは、チャットの要約やそのやり取りから得られた全ての情報を含め、会話のあらゆる側面を確認できます。Diegoがエージェントのパフォーマンスを確認したい場合は、Salesforce Omni Supervisorにアクセスできます。チャット、In-app音声、その他のコミュニケーションチャネルとの深い統合があるため、これらすべてが音声通話やチャットのやり取りと共にOmni Supervisor内に統合されて表示されます。
Diegoは、Johnが対応しているケースや進行中の音声通話を含む作業を確認できます。このやり取りの中で、JohnはNikkiが要求した保証期間延長の承認が必要になります。先ほどチャットで説明した「フラグを立てる」機能を使用して、Diegoに通知します。DiegoはJohnからのチャットを確認し、回答を提供できます。Contact Lensの文字起こしをこの統合の一部として使用する大きな利点は、Supervisorが1つのウィンドウでも5つのウィンドウでも、複数のエージェントを同時にモニタリングできることです。これにより、Service Cloud Voice内の統合チャット機能を通じて、エージェントのモニタリングやコミュニケーションにおいてより高い拡張性を実現できます。
では、セットアップのプロセスを見ていきましょう。エージェントとカスタマーのやり取り、そしてSupervisorの体験を見てきましたので、これらの設定に必要な手順を確認していきます。AdminのNikhilの作業を見ていきましょう。Service Cloud Voiceをインストールする際、これが最初に行う設定プロセスです。ここでは時間を短縮して、セットアッププロセスを素早く進めていきます。Service Cloud Voiceを有効にした後、パッケージを有効にします。先ほど説明したように、これはService Cloud Voiceの上にインストールする無料のAppExchangeパッケージです。この統合がService Cloud Voiceのセットアッププロセスにネイティブに組み込まれているため、AppExchangeから別途ダウンロードする必要がないという利点があります。
まず、コンタクトセンターに関する情報を追加するためのインストール手順を進めていきます。これには名前の設定と管理者の割り当てが含まれます。次に、Service Cloud Voice用のコンタクトセンターを作成し、作成後、Amazon Connectを使用してSalesforce Contact Centerを設定していきます。Service Cloud Voiceのセットアッププロセスをご存知の方なら、コンタクトセンターの設定についてご理解いただけると思います。Salesforce Contact Center with Amazon Connectは、既存のService Cloud Voiceのセットアップを理解し、それを基盤として構築される自然な拡張機能です。例えば、Service Cloud Voiceとキューを同期する際、そのセットアップ時にその情報を活用することができます。
Salesforce Contact Center with Amazon Connectのセットアップを進め、コンタクトセンターを設定していきます。ここでは、セットアップの一環として有効にしたい追加機能を設定します。ご覧の通り、数分でService Cloud VoiceとSalesforce Contact Center with Amazon Connectの両方を設定し、使用できる状態にすることができます。Salesforceとの戦略的パートナーシップを通じて、私たちは新しい展開を進めています。AWS MarketplaceでのSalesforceソリューションについて詳しく知るために、Salesforceブースにぜひお立ち寄りください。AWS Marketplaceを通じたSalesforceライセンスの購入に関する新機能や、Amazon RedshiftとData CloudによるゼロコピーのETLに関するイノベーションについてもご紹介しています。
注目すべき新機能の一つが、Amazon Bedrockを使用して独自の大規模言語モデルを導入できる機能です。デモについてさらに詳しく見たい、または話し合いたい方は、AWSブースでお会いしましょう。そこでデモをお見せし、より詳細な説明をさせていただきます。Amazon Q for Businessについては、明日、Agentforce QとQ for Businessによる最新のGenerative AI機能について詳しく見ていくセッションがあります。
明日のre:Inventの残りのセッションについては、ここに表示されているセッションを必ずチェックしてください。スクリーンショットを撮りたい方のために少し表示したままにしておきますが、re:Inventの最終日には本当に素晴らしいセッションが用意されています。
パネルディスカッション：戦略、実装、今後の展開
それでは、パネルディスカッションに移りましょう。ありがとう、Mark。これは本当にエキサイティングで、長い間準備を重ねてきた成果が実を結んで、とても嬉しく思います。一つ質問があります。2024年のこのローンチにつながったAWSとSalesforceの広範な戦略について、お聞かせいただけますか？
私たちはAmazon ConnectとSalesforceとの歩みを続けてきました。長くご存じの方々は、2017年にCTI Adapterから始まったことをご記憶でしょう。私たちはSalesforceと緊密に協力してService Cloud Voiceを構築し、現在では大きな成功を収めています。お客様からは、Service Cloud Voiceは素晴らしいが、さらに多くのConnectの機能が欲しいという声を聞きました。そこで、CTIとService Cloud Voiceの機能を統合し、より多くの機能をService Cloud Voice内でネイティブに実現する方法についてSalesforceと話し合いを始めました。
現在、Generative AIの分野では両社とも急速に進化しており、お客様に選択肢と機能を提供しつつ、使いやすさも実現したいと考えています。先ほどのスライドで示したように、価値実現までの時間を短縮することが重要です。このソリューションは、SalesforceとAmazon Connectの最新機能を活用して、お客様がより迅速に進められるようにすることで、その課題を解決しています。
Chantelleさん、聴衆の皆さんが知りたがっているいくつかの質問があります。現在のエージェント数とその世界的な分布について教えていただけますか？現在、南極大陸を除く全大陸に約300人のエージェントがおり、その大半は米国に配置されています。これはPearson全体のエージェント数のほんの一部で、Higher Edには何千人ものエージェントチャンピオンがおり、全員がService Cloud Voiceを使用しています。
数字といえば、ビジネスの測定とレポートの重要性についてお話しされましたが、Pearsonにとって最も重要なKPIは何で、これまでどのような成果を上げられましたか？コンタクトセンターのリーダーとして、平均応答時間、コール後作業時間、初回解決率などを見ています。しかし、先ほど申し上げたように、私は従来型のコンタクトセンターリーダーではなく、営業出身です。そのため、売上高、維持した収益、コスト回避などが私が特に注目しているKPIです。
現在検討している事項の一つとして、Markが話していたワークフォース管理ツールについてですが、私たちは現在Service Cloud Voice以外のアウトソースのワークフォース管理ツールを使用しています。追加コストを避けるため、すでに利用可能なシステム内のワークフォース管理ツールをどのように活用するかを評価している段階です。最終的に、コストを回避し、経費を削減できれば、それはPearsonの全体的な収益に貢献します。そしてMark、これはイノベーションを継続的に追加できる戦略にぴったり合致しますね。ワークフォース管理についても再度触れましたが、現在ConnectとSalesforce間でチャネルをネイティブに統合することで、Salesforceとの統合を活用しながら、これらの機能を利用し始めることができます。もちろん、大きなプロジェクトには必ず課題がつきものです。
御社の以前のコンタクトセンターソリューションではどのような課題に直面し、Service Cloud Voiceを選択するに至ったのか、お聞かせいただけますでしょうか。この質問について考えると、まず思い浮かぶのはタイミングです。先ほど申し上げたように、私たちは2022年に実装と要件定義を開始しました。当時、AIに関する話題が非常に盛り上がっていました。Pearsonは10年以上前からAIを活用している企業ですが、他の多くの組織と同様に、この実装がどのようなものになるか慎重に検討していました。
以前のベンダーとの具体的な課題について考えると、最も苦労したのは、彼らが過去には適切なソリューションだったものの、私たちが目指す方向性には合わなくなっていたという点です。彼らはAIの進化についていけず、お客様のニーズや市場の変化に対応できませんでした。これは非常に大きな課題でした。何も対策を講じないことのコストを考えると、私たちにはそれを許容する余裕がありませんでした。組織の将来性を確保し、これからのコンタクトセンターの姿に備えたいと考えていた私たちにとって、これが以前のベンダーとの主な課題の一つでした。システムの断片化が著しく、組織の将来性を確保するための戦略や協力体制を築くことができませんでした。
将来について言えば、この新しいソリューションの今後のイノベーションサイクルについて、お客様は何を期待できるのでしょうか？今後の展開を見ると、今週発表したQICやWhatsAppの統合など、多くの新機能があります。これらの機能は既にチャット機能やIVR機能に統合されているため、すぐに活用を開始できます。今後は、QICガイドなどのネイティブなConnect機能をより統合された Salesforceのエージェントエクスペリエンスに組み込んでいく方法を検討しています。また、サービスエージェント向けのAgentforceについてもSalesforceと密接に協力しています。Connectでネイティブに有効化したいというお客様もいらっしゃるので、その点についても取り組んでいます。素晴らしい機能が多数登場する予定ですので、ぜひご期待ください。プレビューに参加していただき、機能の改善を重ねる中でフィードバックをいただけると幸いです。
実装についてですが、Neuro Flashが実装に関わっていたとのことですが、そのプロセスや移行、実装時に直面した主な考慮事項や課題についてお聞かせください。まず、主な考慮事項からお話しします。ベンダーとの会話を始める前から検討していた重要な点は、その関係の長期的な持続性でした。リーダーとして、私たちはサービス分野からセールス分野へと移行し、両者を統合していく過程にあることを認識していました。そのため、そうした展開をサポートできるソリューション、ベンダー、そしてパートナーを確保する必要がありました。
もう一つの重要な考慮事項はパートナーシップです。約1ヶ月前にエグゼクティブサミットに参加した際、ベンダーとパートナーの違いについて議論がありました。これらの言葉は同じように使われることが多いのですが、ベンダーはサービスを提供するだけなのに対し、パートナーはサービスを提供しながらコンサルタントとしても機能します。私たちが築いた関係で評価しているのは、まさにこの点です。従来のように単なる電話システムとして利用するための移行ではありませんでした。この非常に複雑なビジネスユニットの将来に向けた準備を検討していたのです。複雑というのは、カスタマーサービス、カスタマーサポート、インサイドセールス、更新業務、売掛金管理など、様々なビジネスユニットをサポートしており、それぞれが全く異なる方法で機能しているからです。このパートナーシップにおいて、私たちはこれを単なる着信・発信を扱うコンタクトセンターとしては捉えていませんでした。
私たちが求めていたものを確実に手に入れられるようにし、数多くの移行プロセスを通じて私たちをサポートしてくれるという点で、非常に明確なアプローチを取ってくれました。先ほど申し上げたように、地域ごとに段階的に移行を行いましたが、これは私たちにとって非常に重要な要素でした。また、リーダーとして多くの電話システムの移行を経験してきた私にとって、当初心配していたのはスコープクリープでした。通常は、Purchase Orderを出して承認を得た後、6ヶ月後に追加の費用が必要になることがありますが、今回の移行ではそのようなことはありませんでした。
すべてのコストは最初から明確で適正であり、コミュニケーションも簡潔でした。現在でもNeuro Flashのパートナーとは連絡を取り合っており、このプロジェクト以外でも支援を受けています。これが私が最も評価している点です。彼らはSalesforceの実装やAmazon Connect、その他のAWSサービスについて豊富な経験を持っています。適切なパートナーを選ぶことが非常に重要で、ここでいう「パートナー」という言葉が重要なキーワードとなります。
Mark、お客様はこのプレビューにどのように申し込めばよいのでしょうか？また、SalesforceとAWSはこのサービスの料金をどのように請求するのでしょうか？プレビューに関しては、私たちの「What's New」の投稿をフォローしていただければ - AWSのクリスマスと呼んでいますが - 特にService Cloud Voiceに関する投稿にプレビューの申し込みリンクがあります。その後、こちらから連絡させていただきます。プレビューへの参加に関しては、いくつかの基準があります。特にプレビュー期間が短いため、皆様との対話を通じて適合性を確認させていただきたいと思います。リンクが見つからない場合は、LinkedInで私を検索していただければ、フィードにも掲載されています。
料金に関して、現在のService Cloud Voiceの料金体系をご存知の方は、同じ仕組みだとご理解ください。基本的にはSalesforceから購入するバンドルがあり、すべての請求はSalesforceを通じて行われます。先ほど申し上げたように、このパッケージは無料で、その上にインストールされる追加サービスの料金がお客様に請求されます。多くの方が選択されるBYOAを使用する場合は、Service Cloud Voiceのライセンスが必要です。チャットには、Digital Engagementが必要で、すべてのConnectの請求は通常のAWSアカウントを通じて行われます。EDPやその他の関連するものすべてを活用することができます。
まとめと今後への期待
Chantelle、最後に共有したい洞察はありますか？ベンダーとパートナーの違いについて、もう一度お話ししたいと思います。リーダーや組織として、予算や本番環境への移行スピード、ソリューションの導入スピードに制約があることは承知していますが、一時的な関係ではなく、組織の進化に伴って共に歩んでくれるパートナーを見つけることに時間を費やすことを強くお勧めします。
私の視点から申し上げますと、私たちが構築したものに本当にワクワクしています。お客様とお話をさせていただく中で、現在お持ちの選択肢や、活用できる新機能、そして何よりもお客様のユースケースをより迅速に解決できるようになったことについて、非常にポジティブな反応をいただいています。すでにService Cloud Voiceをご利用の皆様、ぜひ対話を継続させていただき、このモメンタムを維持していきましょう。
皆様、セッションのアンケートにぜひご協力ください。皆様からのフィードバックは私たちにとって大変貴重で、今後のセッションに反映させていただきます。本日は貴重なお時間をいただき、ありがとうございました。残りのre:Inventもお楽しみください。 ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion