Amazon Connectで、カスタマーセルフサービスの“理想形”はどこまで実現できるのか？

カスタマーセルフサービスを生成AIで進化、とは言いますが、そもそもすでにだいぶセルフサービス化は進んでいるような気がします。Webでの予約も当たり前になりましたし、変更・キャンセルなどもかなりWebで完結できるようになっています。ただやっぱり、ちょっと複雑なことをしようとすると途端にどうにもならなくなる印象はまだまだ強く、挙句オペレータと話したいのに、延々チャットボットしか相手をしてくれない……みたいな新たな課題も出ていますよね。そして、ようやく電話をかけられても、IVRでどの選択肢を選べばいいのかわかりづらく、さらにオペレータにつながったら、チャットボット相手に一応書いていたことをイチから説明しないといけないとなると、ゲンナリ度合いはなかなかのものになります。

顧客の立場からすると、コンタクトセンターの営業時間などを気にせず、自分の好きなタイミングで、かつ自分の好きなチャネルで問い合わせを終わらせたいところ。さらに、「セルフサービスで問題を解決できないなら、サービスの利用自体をやめるという顧客も増えていて、セルフサービスの重要性はますます高まっていると言える」とのこと。

もちろん企業側のメリットも大きく、セルフサービスが実現できれば、オペレータが対応する場合と比較してかなりのコスト削減になります。この観点からもセルフサービスはどんどん進んでいきそうです。

じゃあこれをAmazon Connectでどう実現するのか、という話です。まずコンタクトセンターの問い合わせは大きく3つに分類できます。

・定型業務フロー：基本の流れに沿って処理するもの。料金支払い、パスワードリセットなど

・半定型業務フロー：基本の流れはあるが、いくつか判断や分岐が必要なもの。返品・返金、契約内容変更など

・非定型業務フロー：フローが複雑で、個々の状況にカスタマイズした対応が必要なもの。障害対応、トラブル・クレーム対応

パッと見た印象どおり、定型業務は自動化しやすく、ここからセルフサービスにして徐々に複雑なものへと進めていきましょう、という話ですが、じゃあ定型業務を生成AIで！というわけではありません。定型業務であれば生成AIではなく、チャットボットでも十分対応できるはず。決められたフローに沿って処理するチャットボットと、生成AIを組み合わせて全体を実現しよう、ということだと理解しました。

ここで使えるのが、Amazon Lexです。Amazon Connectはもともと専門的な知識や技術がなくても、セルフサービス体験を作成・編集・管理できることが特長でした。フローデザイナーというツールがあって、電話がかかってきたらIVRを呼び、何番が押されたらこっち、みたいな処理をドラッグ＆ドロップで作成できるんです。そしてさらにチャットボットサービスAmazon Lexと連携して、Amazon Connect内で会話型AIボットの作成までできるようになっていまして、つまり、電話がかかってきたときの対応のなかで、AIボットを呼び出せて、さらに複数ボットを組み合わせて全体のフローを作れる、ということ。

おそらくですが、電話がかかってきたらIVRの代わりになるような問い合わせ内容を聞きだすボットが対応、その結果を受けて、たとえば予約ボット、予約変更ボットなどそれぞれのボットへ連携、みたいなイメージかなと思いました。1つのボットで全部対処するのは厄介そうですが、分岐部分はフローデザイナー側で対応して、うまく組み合わせれば、結構便利に使えるのでは？と感じました。

もちろん生成AIにも対応します。AWSの生成AIアシスタントAmazon QはAmazon Connectにも対応し、「Amazon Q in Connect」として提供されています。最初はオペレータが顧客対応するときに「問い合わせへの回答をレコメンドする」など、オペレータサポートから使うといい、とされていますが、Amazon Q in Connectに顧客対応をさせることも可能です。

これが効果を発揮するのは、やっぱり「非定型業務フロー」。ルールベースのボットでは対応しきれないところをカバーできるのが強みです。例として、複雑な問い合わせの前捌きとして顧客の情報を明確にして定型業務フローに落とし込む、コンテキスト情報を活用して正確な回答やアクションに落とし込む、ニーズや履歴に基づいてパーソナライズされた応答を返すなどが挙げられていましたが、分かりやすいのはFAQでしょうか。社内の情報を検索して回答する……いわゆるRAGのような感じかなと思います。チャットボットと同じようにフローに組み込めるので、会話の途中からAmazon Q in Connectに対応させることもできる模様。どこからどこまでを定型・非定型として何で対応するのかの設計が難しそうな気はしますが、ちゃんとできれば、理想に近づけるのでは、という気がしました。

ちなみに、Amazon Q in ConnectでもAIガードレールなどの設定が可能です。望ましくないトピックを制御して、意図しない使われ方をしないようにこのあたりも注意が必要というのは覚えておいた方がよさそうです。

これをうまく使うことで、銀行に定期預金解約の電話を入れたときに、解約手続きをしつつ、次の商品案内を打診し、顧客の要望にあわせて提案、営業担当者に引き継ぐ……というところまでチャットボットと生成AIでできるよ、というのが理想形として提示されていました。そもそも定期解約で電話しなくない？というところが気になるのですが、それは置いておいて、この例のカギは、すべてAIで対応するのではなく、チャットボット（定型業務フロー・定期解約）から生成AI（非定型業務フロー・提案）に引継ぎ、最後は人（営業担当）につなぐところまでを実現できている点にあります。理想形とはいえ、解約の電話で案件取ってくれたら相当優秀ですよね。

まったくもって個人的な話ですが、チャットボットに問い合わせて期待する答えが返ってきたことがほとんどなく、中途半端だと逆にやる気をなくすしなー、という印象しかないのですが、この先「電話さえかければ、生成AIがよしなに対応してくれる」となったら、自分でちまちまWebサイトを調べるより、電話しちゃった方がラク、という未来も十分ありそうですし、なんなら意外とすぐ実現できるのかもしれない、と思いました。

IVRの代替のような領域には十分使えそうですし、人手不足が大きな課題となっているコンタクトセンターの負担軽減という意味でも、検討する価値は大きいのではないでしょうか。ソニービズネットワークスでは、Amazon Connectでの生成AI活用について詳しくまとめたホワイトペーパーも用意しているので、気になる方はぜひダウンロードを！次回は、Amazon Connectを使ったちょっと変わったユースケースをご紹介します。