はじめに
コンタクトセンター基盤の検証やトラブルシュートを行っていると、
- 電話がなかなか繋がらない
- 呼び出し音が長い
- ガイダンスが流れるまで時間がかかる
といった問い合わせを受けることがあります。
以前、Amazon Connect案件で「呼び出し音が長い」という事象を調査した際、フロー先頭で実行していたLambda処理によって、最初のガイダンス再生までリングバックトーンが継続していることを確認しました。
その時ふと、
「Genesys Cloudでは同じような構成の場合、発信者にはどのように聞こえるのだろうか？」
と思い、今回、簡単な検証を実施してみました。
- 発信者体験
- SIPシグナリング
- Architect実行履歴
の3つの観点からGenesys Cloudの着信処理を確認し、見えてきたことをまとめます。
検証内容
今回用意したフローは非常にシンプルです。
着信
↓
Data Action（約5秒待機）
↓
「お電話ありがとうございます。・・・」
↓
ACD転送
Data Actionでは約5秒間待機する処理を実装しています。
実際の業務であれば、
- CRM参照
- 顧客情報取得
- 外部API呼び出し
などに相当する処理をイメージしていただければと思います。
検証結果
検証した結果をまとめると以下のようになります。
発信者からはどう聞こえたか
実際に発信して確認したところ、発信者には以下のように聞こえました。
ぷるるる・・・
↓
無音（約5秒）
↓
「お電話ありがとうございます。〇〇です。」
↓
保留音
今回の検証では、Data Action実行中にリングバックトーンは継続せず、ガイダンス再生までの間は無音となりました。
まずは事実として、
Genesys Cloudでは着信後しばらく無音状態となり、その後ガイダンスが再生される
という結果が得られました。
SIPログとArchitect実行履歴を突き合わせる
前述の発信者体験の時、GenesysCloudではどのような処理が行われていたのでしょうか。
図を見ると
SIPシグナリングはACKまで完了
↓
その後Flow開始
↓
Data Action実行
↓
ガイダンス再生
という流れになっていることがわかります。
今回の検証結果を見る限り、Genesys CloudではACK完了後にフロー処理が開始されており、Data Action実行中は発信者に無音として聞こえていました。
AmazonConnectの場合
では、AmazonConnectではどうだったのか。
今回の検証では、発信者体験とコンタクトフローのログから、Lambda処理中もリングバックトーンが継続していました。そのため、発信者視点ではガイダンス再生のタイミングで接続されたように聞こえました。
一方で、Genesys Cloudでは、Data Action実行中は無音となっていたため、同じような構成であっても発信者が受ける印象は大きく異なりました。
今回の検証で見えてきたこと
今回の検証で興味深かったのは、発信者体験の違いが、単なる音声再生タイミングの違いではなく、着信処理そのものの違いとして現れていた点です。
Amazon Connectでは外部処理実行中もリングバックトーンが継続していましたが、Genesys CloudではACK完了後にフロー処理が開始され、その間は無音となっていました。
同じ「フロー先頭で外部処理を実行する」という構成であっても、発信者が受ける印象は大きく異なることが分かりました。
まとめ
今回は「5秒待機するだけ」という非常に単純な検証でしたが、製品ごとの着信処理の違いが発信者体験に影響することを確認できました。
普段はフローやルーティングロジックに目が向きがちですが、実際に利用者がどのように聞こえているのかという観点で見てみると、製品ごとの特徴が見えてくることがあります。
今回はAmazon Connect案件をきっかけにGenesys Cloudで検証を行いましたが、こうした比較を通して各製品の特性を理解することも、設計やトラブルシュートの引き出しを増やす上で有益だと感じました。
