はじめまして、アプリケーションサービス部の上田です。
最近Amazon Connectを中心に案件を進めていますが、その中でいくつか気になった部分があったので動作検証してみました。 他のコールセンターサービスでは受電対応するユーザーをオペレーターと表記することが多いようですがここではAmazon Connectに合わせてエージェントの記載で統一します。
それではさっそく検証内容と結果を見ていきましょう。
検証
検証１：Connectインスタンスにログインしていない状態は、ログイン時Offlineの状態と同義か
結果→同義である。
Connectインスタンスにログインしていない状態はログインしていてもCPPでOfflineを設定している場合と同じ状態になります。
ただし、Connectインスタンスにログイン状態でAvailableのままCPPを閉じると受電できる状態になってしまうため、離席や就業の際には確実にOfflineにすることが望ましいです。
別パターンでCPPが別ウィンドウで表示されている状態でAvailable表示のままインスタンスからログアウトした場合は一定時間（体感時間１～２分ほど）経過すると自動的にOfflineとなりますが、その間に着信があるとAvailable状態としてエージェントが受電できる状態となってしまいます。この状態になると以降は一定時間が経過しても自動でOfflineとならない、つまりAvailable状態になりエージェントは閉じたと思っているのに電話が取れるような状態となるため注意が必要です。
検証２：エージェントが全員Offlineだった場合には「フル稼働(At capacity)」となるか「エラー(Error)」となるか
結果→Available状態のオペレータが出るまで顧客キューに入った状態となる
エージェントが全員オフラインの場合、キュー内の最大問い合わせ数の数を上回らない限りは顧客キューに入ります。
キュー内の最大問い合わせ数を上回っている場合はフル稼働状態となり通話が切断されます。設定していない場合のデフォルト同時接続数は10です。
また、こちらについてはAWSのドキュメント上で「routed down the error branch.（エラーブランチにルーティングされる）」となっているため、通常のエラーブランチかフル稼働のブランチか混乱するのですがこの場合はフル稼働の分岐に入りフローが処理される結果となりました。
検証３：コンタクトフローにて作業キューの設定ブロックで指定されたエージェントがOfflineの場合どのような挙動をするか
結果→エージェントが受電するまでDefault customer queueのプロンプトループ再生を実行し続ける
既存のDefault customer queueはコンタクトフローで「作業キューの設定」ブロックにてエージェントを指定した場合、そのエージェントが受電するまでDefault customer queueの「プロンプトのループ」ブロックを実行し続けます。
つまり、エージェントが電話を取らない限り延々と待ち時間が発生してしまう…ということですね。
なので実際の運用ではDefault customer queueにタイムアウトやキューの転送を設定し、別のエージェントにルーティングするような工夫が必要です。
別のエージェントに飛ばす実装例
①プロンプトのループにタイムアウトを設定する
②対応可能なエージェントが存在するか調べるために「人員の確認」ブロックを追加する
③対応可能なエージェントにキュー転送or見つからなかった旨のメッセージを残して切断
検証４：通話転送時指定されたエージェントがOfflineだった場合は「フル稼働」となるか「エラー」となるか
結果→どちらの状態にもならない
少しややこしいのですが、デフォルトのフロー設定だと転送元のエージェント側ではDefault agent transferとなったあとDefault customer queueに入り、発信者側は転送元のエージェントが通話を切断しない限りDefault customer hold状態となります。
なぜエージェント側がDefault agent transferのあとDefault customer queueフローに入るのかしっくりきていなかった（自分の感覚的にはDefault agent holdのフローに入ると思っていた）のですが、転送元のエージェントが転送先のエージェントに電話をかけている→電話をかける立場になっているためDefault customer queueに移行したと考えると納得できるような気がします。
なので転送先のエージェントが受電できるかどうか判断してからキュー転送を実行するようにブロックを追加してやるとよいです。
ちなみにデフォルトのフロー設定でこの状態になった後転送元のエージェントが通話を切断してしまうと発信者側では通話が切断されないままDefault customer holdからDefault customer queueに飛ばされてその中をさまよい続けます（検証３のように別エージェントやキューに飛ぶように設定していれば問題なし）。
まとめ
というわけで今回は4つの検証を実施してみました。
特にAmazon Connectのフローやエージェントの転送に関しては細かい挙動についてドキュメントで紹介されていないものもあるため、使用時には顧客のニーズやケースを考慮してフローとブロックの設定をする必要があります。
今後も気になった挙動があればブログでまとめていこうと思います。
