[Amazon Connect] キューの待ち行列人数を判定して処理を行う4パターンの方法を検証してみた

みなさん、こんにちは！
福岡オフィスの青柳です。

Amazon Connetには「キュー」すなわち「待ち行列」の概念があります。

顧客から掛かってきた電話は一旦「キュー」へ入り、キューから順番に取り出されてエージェント (オペレーター) へ繋がります。

キューを使った処理の一つとして、キューの待ち行列の人数を判定条件にして特定の処理を行うことができます。
例えば、キュー内で待ち状態にある顧客の人数が非常に多い場合、以下のような対応を行うことが考えられます。

• 非常に多くの電話を受けているため案内に時間が掛かることをアナウンスする
• 時間を置いてから電話を掛け直してもらうようアナウンスした後に、電話を切る
• 折り返し先の電話番号を取得した上で一旦電話を切り、エージェントが対応可能になり次第コールバックする
• etc.

今回は、いくつかパターンがある「キューの待ち行列人数を判定する方法」を検証して、使いどころを探りたいと思います。

パターン 1： 顧客をキューに入れる前に判定する

「キューの状態を確認する」ブロックを使うことで、キューの待ち行列の人数を判定条件にして、後続の処理を分岐することができます。

コンタクトフローの「キューへ転送」ブロックの直前に「キューの状態を確認する」ブロックを配置します。
(「キューの状態を確認する」ブロックは「ブランチ」カテゴリに用意されています)

プロパティを開いて「別の条件の追加」をクリックします。

チェックする項目として「キューの容量」を選択して、条件式に「超過」「5」を指定します。

「キューの状態を確認する」ブロックの出力先のうち、まず「一致なし」の先を「キューへ転送」ブロックへ接続します。→①
これで、キューの容量が「5」以内である時は、顧客の電話がキューへ入ります。

一方、出力先のうち「キューの容量 > 5」の先には「プロンプトの再生」ブロックを配置します。→②
再生するプロンプトは、例えば以下のようにします。

ただいま電話が大変混み合っております。
このままお待ち頂くか、一度電話をお切りになって、しばらく経ってからお掛け直しください。

「プロンプトの再生」ブロックからは、①の「キューへ転送」ブロックへ接続します。
これで、キューの容量が「5」を超えている時は、混雑している旨のアナウンスを流した後に、顧客の電話をキューへ入れます。

このように、「キューの状態を確認する」ブロックを使うことで、キューの待ち行列の人数によって異なる動作を行うことができます。

パターン 2： 顧客をキューに入れた後に判定する

顧客がキューへ入ると「顧客キューフロー」と呼ばれる特殊なフローが実行されます。
この「顧客キューフロー」の中でも、キューの待ち行列人数の判定を行うことができます。

初期状態では「Default customer queue」という名前のフローがデフォルトの「顧客キューフロー」として設定されています。
このフローを編集していきます。

フローを開くと、エントリポイントに続いて「プロンプトのループ」ブロックのみが配置されています。
この「プロンプトのループ」ブロックのプロパティを開いて編集します。

ブロックには「Text to Speech」(テキスト読み上げ) と「Audio recording」(音声ファイル再生) の2つのプロンプトが設定されています。
これらのうち「Text to Speech」は英語のアナウンスとなっていますので、今回は「×」ボタンをクリックして削除してしまいましょう。

続いて、下の「割り込み」にチェックを入れて、割り込みを発生させるまでの時間を指定します。
今回は動作確認を行い易くするために、短めの時間「15秒」を設定します。

フロー画面に戻ると、「プロンプトのループ」ブロックに出力先「タイムアウト」が追加されていることに気付くかと思います。
この「タイムアウト」の先に「キューの状態を確認する」ブロックを配置します。→①

「キューの状態を確認する」ブロックのプロパティを開いて、パターン1の時と同様に以下の通り設定します。

• チェックする項目： 「キューの容量」
• 条件式： 「超過」「5」

「キューの状態を確認する」ブロックの先には「プロンプトの再生」ブロックを配置して、こちらもパターン1の時と同様のプロンプトを設定します。→②

「プロンプトの再生」ブロックの先、および、「キューの状態を確認する」ブロックの「一致なし」出力の先には、「終了フロー/再開」ブロックを配置します。→③
(「終了フロー/再開」ブロックは「終了/転送」カテゴリに用意されています)

「終了フロー/再開」ブロックは少し特殊な働きをするブロックで、このブロックでフローを終了した後、「プロンプトのループ」に戻るという動作をします。

作成した「顧客キューフロー」によって、顧客がキューに入ると以下のような動作を行います：

• お待たせ中の音楽を15秒間流す
• キューの待ち行列の人数をチェックする
  • 待ち行列人数が「5」を超える時： 混雑アナウンスを流した後、最初に戻る
  • 待ち行列人数が「5」以下の時： 何もせずに最初に戻る

つまり、15秒間隔でキューの待ち行列人数をチェックして、一定人数を超えていれば混雑アナウンスを流す、という動作を行う訳です。

実は・・・期待通りに動作しないんです

一見、上手く動作してくれそうなフローですが、実は期待通りの動作をしてくれません。

それは「キューの状態を確認する」ブロックの仕様に原因があります。

「キューの状態を確認する」ブロックは、ブロックを評価する時点でのキューの待ち行列人数をチェックします。
顧客がキューに入ってから、先にキューにいた別の顧客はそのうちオペレーターに繋がってキューから出ていきますし、また別の顧客が後からキューに入ってくることもあるでしょう。
そうやってキューの待ち行列人数が増減しますが、「キューの状態を確認する」ブロックは現在時点での待ち行列人数をチェックします。

しかし、よく考えてみてください。
顧客が気にするのは「自分の前に待っている人が何人いるのか」であって、「自分の前後を含めて待ち行列全体に何人いるのか」ではないはずです。

そうなんです。
「キューの状態を確認する」ブロックがチェックするのは「自分の前後を含めて待ち行列全体に何人いるのか」であるため、これを判定条件にするのは、実はあまり意味が無いのではないかと思います。

パターン 3： 顧客をキューに入れる前に判定する (アナウンスを繰り返し流すパターン)

パターン2で上手くいかなかった「顧客がキュー内にいる間、一定間隔で『混雑しております』アナウンスを繰り返し流す」を実現する方法を考えてみます。

まず、パターン1のコンタクトフローで、「キューの状態を確認します」ブロックの「キューの容量 > 5」出力の先に、「コンタクト属性の設定」ブロックを追加します。
(「コンタクト属性の設定」ブロックは「設定」カテゴリに用意されています)

「コンタクト属性の設定」ブロックのプロパティを開いて、下図のように設定します。

• 宛先タイプ： 「ユーザー定義」を選択します
• 宛先属性： 「isCrowded」と入力します
• 値： 「1」と入力します

これで、「isCrowded」という名前のコンタクト属性を定義して、値「1」をセットしたことになります。

続いて、「顧客キューフロー」を編集します。

さきほどのパターン2で「キューの状態を確認する」ブロックを配置していた場所に、代わりに「コンタクト属性を確認する」ブロックを配置します。
(「コンタクト属性を確認する」ブロックは「ブランチ」カテゴリに用意されています)

「コンタクト属性を確認する」ブロックのプロパティを開いて、下図のように設定します。

• タイプ： 「ユーザー定義」を選択します
• 属性： 「isCrowded」と入力します
• チェックする条件： 「等しい」を選択して「1」と入力します

これで、コンタクト属性「isCrowded」の値が「1」と等しいかどうかをチェックすることができます。

「コンタクト属性を確認する」ブロックの「= 1」出力の先には、「プロンプトの再生」ブロックを接続して混雑アナウンスを流します。

ここまでの一連の設定によって、以下の動作が実現できます。

• 顧客をキューに入れる前に「キューの待ち行列人数」をチェックして、その結果によって「混雑している」フラグを立てる (またはフラグを立てない)
• 顧客がキューに入った後に「混雑フラグ」をチェックして、フラグが立っていれば「混雑アナウンス」を流す

このようにすることで、「顧客キューフロー」の中で「キューの状態を確認する」ブロックを使ったチェックを行った場合の問題を解決することができました。

パターン 4： 「キュー内の最大問い合わせ数」の設定を使う

最後のパターンとして、キューの設定項目に存在する「キュー内の最大問い合わせ数」の設定を使う方法を試してみます。

まず、対象のキューの設定画面を開きます。

画面の下の方にある「キュー内の最大問い合わせ数」を以下のように設定します。

• すべてのチャネルにわたって制限を設定： チェックを入れる
• キュー内の最大問い合わせ数： 「5」を入力する

編集後に画面右上の「保存」ボタンを押すのを忘れないようにしてください。

これでキューの準備ができました。

続いて、コンタクトフローの編集を行います。

「キューへ転送」ブロックの「容量」出力の先に、「プロンプトの再生」ブロックを配置します。
再生するプロンプトの内容は、以下のようにしてみましょう。(これまでのプロンプト内容と若干異なることに注意してください)

ただいま電話が大変混み合っております。
恐れ入りますが、一度電話をお切りになって、しばらく経ってからお掛け直しください。

そして、「プロンプトの再生」ブロックの先は「切断」ブロックへ接続します。

「キューへ転送」ブロックの「容量」出力は、キューの設定項目「キュー内の最大問い合わせ数」で設定した数を超えて新たな顧客をキューへ入れようとした場合に、この出力先へ遷移します。

この時点で「キューに入ることができず、溢れてしまった」という扱いになりますので、プロンプトを流した後には「切断」ブロックで電話を切ることになります。
この点が、これまでのパターンとの大きな違いです。

この「パターン4」の方法は、他のパターンと比べて以下のような違いがあります。

• 待ち行列人数の上限について、他のパターンはフローの中で設定するが、パターン4はキュー画面で設定が必要
• 待ち行列人数の上限を超過した場合、パターン4は基本的に電話を切ることしかできない (キュー内に留まらせることはできない)

なお、最初の「パターン1」では、待ち行列人数の上限を超過した場合にアナウンスを流した上で顧客をキューに入れましたが、下図のようなフローにすることでアナウンスを流した後に電話を切る動作にすることも可能です。

このように、他のパターンの方が「パターン4」よりも応用が利くため、パターン4を採用する理由はあまりないかと思います。

おわりに

今回、「キューの待ち行列人数を判定する方法」として、以下の4つのパターンを検証しました。

• パターン 1： 顧客をキューに入れる前に判定する
• パターン 2： 顧客をキューに入れた後に判定する
• パターン 3： 顧客をキューに入れる前に判定する (アナウンスを繰り返し流すパターン)
• パターン 4： 「キュー内の最大問い合わせ数」の設定を使う

いずれの方法も動作はしましたが、「パターン2」は顧客観点での期待通りの動作をしないという点で、「パターン4」は制約が多く他のパターンで代用できるという点で、採用する理由はあまりないと思います。

残りの「パターン1」「パターン3」を以下のように目的に応じて使い分けると良いでしょう。

• パターン 1： 電話が混雑している時、最初に1回のみ「混雑しています」アナウンスを流せばよい場合、または、アナウンスを流した後に電話を切る場合
• パターン 3： 電話が混雑している時、一定間隔で「混雑しています」アナウンスを繰り返し流したい場合

状況に応じて適切なアナウンスを流すことで、顧客の体験を向上させることができるのではないでしょうか。