[Amazon Connect] 各種「デフォルトフロー」の解説とカスタマイズ方法 – Amazon Connect アドベントカレンダー 2022

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

この記事は「Amazon Connect アドベントカレンダー 2022」の11日目の記事となります。

Amazon Connectアドベントカレンダー2022は、弊社クラスメソッド株式会社と株式会社ギークフィードさんの有志が集い「もっとAmazon Connectを盛り上げよう！」とチャレンジしている企画です。
Amazon Connectの支援サービスを行なっている2社が、初心者向けから技術寄りのところまで幅広い内容の記事を執筆していきます。

「デフォルトフロー」と「サンプルフロー」

Amazon Connectでインスタンスを新規作成した際、「コンタクトフロー」の一覧を見ると、最初から多くのフローが登録されていると思います。

これらのフローは、大別すると「Default ～」で始まるフローと「Sample ～」で始まるフローに分けられます。

「Default ～」で始まるフローは「デフォルトフロー」と呼ばれる特別なフローです。
今回のブログ記事では、この「デフォルトフロー」について解説します。

「Sample ～」で始まるフローは、Amazon Connectのフロー作成時のサンプルとなるフロー群です。
内容としては自動音声メニュー (IVR) の入力に応じて様々な処理へ分岐するという、かなり複雑なものとなっています。

サンプルフローについての解説は、下記のブログ記事を参照してください。
(記事執筆時と現在ではサンプルフローの内容が少し変更になっているようですので、あくまで参考情報としてください)

Amazon Connectにおける「フロー」の種類と「デフォルトフロー」

Amazon Connectでは9種類の「フロー」が存在し、その中で「コンタクトフロー」を除く8種類のフローに「デフォルトフロー」が1つずつ用意されています。

フローの種類 (デフォルトフロー)	説明
コンタクトフロー (デフォルトフローは無し)	発信時・着信時の顧客体験を記述する汎用のフロー
顧客キューフロー (Default customer queue)	エージェントへの接続を待つ間に、顧客が体験するフロー
顧客ウィスパーフロー (Default customer whisper)	エージェントに繋がる直前に、顧客が体験するフロー
顧客保留フロー (Default customer hold)	電話の保留中に、顧客が体験するフロー
発信ウィスパーフロー (Default outbound)	エージェントから顧客への発信時に、顧客が体験するフロー
エージェントウィスパーフロー (Default agent whisper)	顧客から繋がる直前に、エージェントが体験するフロー
エージェント保留フロー (Default agent hold)	電話の保留中に、エージェントが体験するフロー
エージェントへの転送フロー (Default agent transfer)	エージェントが別のエージェントへ転送を行った際、転送元のエージェントが体験するフロー
キューへの転送フロー (Default queue transfer)	エージェントがキューを指定して転送を行った際、転送元のエージェントが体験するフロー

各「デフォルトフロー」の解説

顧客キューフロー (「Default customer queue」)

• 対象： 顧客
• 実行タイミング： 顧客がキューに入っている期間 (＝エージェントへの接続待ちの時間)

顧客が電話を掛けた際、まず「コンタクトフロー」に記述された内容 (プロンプト再生やIVRによる分岐など) が実行されます。

そして、エージェントへ電話を接続する待ち行列である「キュー」に投入され、エージェントに「空き」が発生次第、キューから取り出されてエージェントに接続されます。

この「キュー」に入ってから出るまでの期間、つまり、顧客がエージェントへの接続を待っている間に流れるのがこのフローです。

デフォルトフロー「Default customer queue」の初期状態は下図のようになっています。

フローには「プロンプトのループ」ブロックのみが配置されています。

このブロックでは、メッセージと音楽を交互に繰り返し再生します。

• メッセージ：「Thank you for calling. Your call is very important to us and will be answered in the order it was received.」
• 音楽： デフォルトで用意されている「CustomerQueue.wav」

メッセージ内容は、日本語に訳すと「お電話ありがとうございます。あなたの電話を大変重要だと捉えており、順番にお繋ぎしております」という感じですね。

「顧客キューフロー」のカスタマイズ

顧客キューフローは、初期状態からカスタマイズすることを推奨します。

初期状態のままだと、顧客に対して英語でメッセージが流れてしまいますので、最低限ここは日本語に差し替えた方が良いでしょう。
(例えば「お電話ありがとうございます。順番にお繋ぎしておりますので、しばらくお待ちください」など)

(ちなみに、初期状態のメッセージが「さんきゅーふぉーこーりんぐ、・・・」とカタコトの英語っぽく聞こえる場合がありますが、これはキュー投入前にコンタクトフロー内で「音声の設定」を日本語にしているためです。メッセージ自体を日本語に差し替えれば、もちろん流暢な日本語で喋ってくれます)

音楽を差し替えたい場合は、任意の音楽ファイルを「プロンプトの管理」からアップロードした後、「プロンプトのループ」ブロックで参照するファイルを切り替えます。

あるいは、バックでBGMを流しつつナレーターがメッセージを喋ったものを録音して、そのようにして作成した音声ファイルを再生しても良いでしょう。(この場合は、メッセージ部分が不要になります)

「顧客キューフロー」をカスタマイズする際の注意点

「プロンプトのループ」ブロックの設定内容を変更して「保存」を行うと、同ブロックが以下のような状態になる場合があります。

「プロンプトのループ」ブロックに「エラー」ブランチが表示されており、ブランチに続くブロックが設定されていない状態です。

この状態でフローを「保存・公開」しようとしても、エラーが発生して公開することができません。

下図のように、「エラー」ブランチの先に「終了フロー/再開」ブロックを配置して接続してください。

(「終了フロー/再開」ブロックは、「プロンプトのループ」ブロックに設定すると、エラー発生時に通話を切断せずにループを再開する動作を行います)

「顧客キューフロー」の高度なカスタマイズ

キューの混雑度や待ち時間に応じて「顧客キューフロー」の動作を変化させることができます。

例えば、顧客がキュー内で一定時間以上待たされている場合に「大変お待たせしております」とメッセージを流したり、長時間キューに留まっている場合には「恐れ入りますが時間を置いてお掛け直しください」とアナウンスして電話を切るようなことができます。

また、「顧客キューフロー」自体のカスタマイズから少し外れますが、顧客をキューに入れる前に混雑度を判定して動作を変えることも、顧客の満足度を高めるのに有効だと思います。

顧客ウィスパーフロー (「Default customer whisper」)

• 対象： 顧客
• 実行タイミング： 顧客がキューから取り出されてエージェントへ接続された時 (顧客とエージェントとの会話が始まる直前)

顧客がキューに入っている状態から、エージェントに「空き」が発生してキューから取り出され、エージェントへ接続される「直前」に流れるのがこのフローです。

デフォルトフロー「Default customer whisper」の初期状態は下図のようになっています。

単に「ポピッ」というビープ音を鳴らしているだけです。

待ち状態からいきなりエージェントに接続すると顧客が驚くので、エージェントに接続することを音で知らせているということでしょうかね。

「顧客ウィスパーフロー」のカスタマイズ

顧客ウィスパーフローは、初期状態からのカスタマイズは必須ではありません。
必要に応じてカスタマイズすると良いかと思います。

ビープ音を鳴らす必要が無いということであれば、「プロンプトの再生」ブロック自体を削除してしまっても構いません。

あるいは、エージェントへ接続する前に「大変お待たせしました」などメッセージを流すことも可能です。
ただし、全然お待たせしていないのに「お待たせしました」と流れる場合もあるので、メッセージを流すにしても無難な内容にしておいた方が良いでしょう。

顧客保留フロー (「Default customer hold」)

• 対象： 顧客
• 実行タイミング： 電話が保留されている期間

顧客とエージェントの会話が始まった後、顧客またはエージェントのいずれかが電話を「保留」した際、保留中に「顧客側に対して」流れるのがこのフローです。

デフォルトフロー「Default customer hold」の初期状態は下図のようになっています。

保留音として、デフォルトで用意されている「CustomerQueue.wav」を繰り返し再生しています。

「顧客保留フロー」のカスタマイズ

顧客保留フローは、初期状態からのカスタマイズは必須ではありません。
必要に応じてカスタマイズすると良いかと思います。

保留音の音楽を他のものに変えたい場合は、任意の音楽ファイルを「プロンプトの管理」からアップロードした後、「プロンプトのループ」ブロックで参照するファイルを切り替えます。

(「顧客保留フロー」で使われる「プロンプトのループ」ブロックは仕様が特殊であるらしく、「エラー」のブランチが無いのが正常であるようです。「終了フロー/再開」ブロックを配置することもできないようになっています)

発信ウィスパーフロー (「Default outbound」)

• 対象： 顧客
• 実行タイミング： エージェントから顧客への発信時、顧客とエージェントとの会話が始まる直前

このフローは特殊で、顧客からの受信時ではなく、エージェントから顧客への発信時にのみ使われるフローです。

エージェントから顧客へ電話を発信して、顧客が電話に出た際に、エージェントとの会話が始まる「直前」に流れるのがこのフローです。

(なお、これに相当するエージェント側の体験を定義するフローは存在しません)

デフォルトフロー「Default outbound」の初期状態は下図のようになっています。

フローでは、以下の2つの処理を行うブロックが配置されています。

• 「記録と分析の動作を設定」ブロック： 通話記録の設定 (初期状態は「オフ」)
• 「プロンプトの再生」ブロック： メッセージ「This call is not being recorded.」

「通話記録の設定」とは、顧客とエージェントの会話を録音する設定です。

この設定が「オフ」になっており、再生するメッセージは「この会話は録音されません」となっています。

録音していないのであればわざわざ「録音していません」と言わなくても良さそうですが、アメリカやヨーロッパでの個人情報保護の考え方で敢えて明言しているのかもしれません。

「発信ウィスパーフロー」のカスタマイズ

発信ウィスパーフローは、初期状態からカスタマイズすることを推奨します。

初期状態のままだと、顧客に対して英語でメッセージが流れてしまいますので、何らかの修正を行った方が良いでしょう。

まず、「通話記録の設定」はデフォルトでは「オフ」となっていますので、通話記録を行わない場合には「記録と分析の動作を設定」ブロック自体が不要です。
その場合、あわせて「プロンプトの再生」も削除して良いと思います。

もし通話記録を行う場合には、「記録と分析の動作を設定」ブロックで通話記録を「オン」に設定します。

通話記録を行う場合、企業のポリシー等によっては「録音していること」を顧客へ伝える必要があるかもしれません。
その際は、「プロンプトの再生」ブロックの前に「音声の設定」ブロックを配置して、言語を日本語に設定する必要があります。
その上で、「プロンプトの再生」ブロックのメッセージ内容を日本語に書き換えてください。

エージェントウィスパーフロー (「Default agent whisper」)

• 対象： エージェント
• 実行タイミング： 顧客がキューから取り出されてエージェントへ接続された時 (エージェントと顧客との会話が始まる直前)

「顧客ウィスパーフロー」と同じタイミングですが、こちらはエージェント側に流れるフローです。

デフォルトフロー「Default agent whisper」の初期状態は下図のようになっています。

「プロンプトの再生」ブロックで、システム属性の「キュー名」(JSONPathでの記述は$.Queue.Name) を読み上げています。

ルーティングプロファイルの設定で複数のキューが関連付けられている場合、エージェントが「掛かってきた電話がどのキューからのものなのか」を判別できるようにしているのですね。

「エージェントウィスパーフロー」のカスタマイズ

エージェントウィスパーフローは、初期状態からのカスタマイズは必須ではありませんが、「キュー名の読み上げ」については改良の余地があります。

初期状態のままだと、キュー名の読み上げが不自然に聞こえると思います。
これは、キュー名が英語であるのに対してプロンプトの再生言語が日本語となっているためです。

もし、エージェント毎に単一のキューが割り当てられていて、キューの判別が不要である場合は、キュー名の読み上げは削除してしまって構いません。

キュー名の読み上げが必要な場合、多少不自然でも構わなければ、初期状態のままでも良いでしょう。

では、もっと聞き易い流暢な日本語で読み上げさせるには、どのようにすればよいのでしょう？
最初に思い付くのが「キュー名を日本語にしてしまう」ということですが、キュー名を日本語 (2バイト文字) にすることは非推奨です。

下図のようなフローで、日本語によるキュー名の読み上げを実現することができます。

「コンタクト属性を確認する」ブロックを使ってシステム属性「キュー名」を条件にフローの分岐を行い、分岐先で「プロンプトの再生」ブロックで固定の日本語テキストを読み上げるように設定しています。

この方法は、キューの種類が少ない場合に有効だと思います。
キューの種類が多い場合にはフローの構造が複雑になりますので、あまりお勧めはしません。

エージェント保留フロー (「Default agent hold」)

• 対象： エージェント
• 実行タイミング： 電話が保留されている期間

「顧客保留フロー」と同じタイミングですが、こちらはエージェント側に流れるフローです。

デフォルトフロー「Default agent hold」の初期状態は下図のようになっています。

「プロンプトの再生」ブロックで「You are on hold」(保留中です) と読み上げています。
SSML構文を使って、10秒の間隔を空けて、メッセージを繰り返しています。

顧客を待たせていることをエージェントが意識するようにしているのでしょう。

「エージェント保留フロー」のカスタマイズ

エージェント保留フローは、初期状態からのカスタマイズは必須ではありません。
エージェントに対して流れるメッセージが英語であるため、最低限ここだけ日本語に変えておくのが良いでしょう。

他にも、メッセージではなく音楽ファイルを使った保留音に差し替えてしまうという手もあります。

エージェントへの転送フロー (「Default agent transfer」)

• 対象： エージェント
• 実行タイミング： エージェントがクイック接続で別のエージェントへ転送した時 (転送元のエージェントが体験するフロー)

エージェントが顧客と通話中に「クイック接続」を使って別のエージェントへ転送を試みた時、「転送元のエージェント」が体験するフローです。

クイック接続を行った時点で、顧客との通話は保留状態になりますので、顧客に対しては「顧客保留フロー」が流れます。

デフォルトフロー「Default agent transfer」の初期状態は下図のようになっています。

まず、「Transferring now...」(転送中です) というメッセージを流します。

続いて、作業キューの設定を「転送先のエージェント」に設定しています。
※ 「エージェントへの転送フロー」においては、属性の名前空間「エージェント」は「転送先のエージェント」を示します。
https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/connect-attrib-list.html#attribs-agent

そして、キューへの転送を行います。
この時、キューがフル稼働、すなわち、転送先のエージェントが応対不可能 (顧客と通話中、オフライン、など) であった場合は、メッセージ「Faild to transfer.」(転送に失敗しました) を再生した後、転送を中止します。

「エージェントへの転送フロー」のカスタマイズ

エージェントへの転送フローは、初期状態からのカスタマイズは必須ではありません。
エージェントに対して流れるメッセージが英語であるため、最低限ここだけ日本語に変えておくのが良いでしょう。

ただし、このフローには転送時のメカニズム (転送先エージェントの状況によって処理を変える等) が組み込まれているため、フローの構成自体は変更しないのが安全だと思います。

キューへの転送フロー (「Default queue transfer」)

• 対象： エージェント
• 実行タイミング： エージェントがクイック接続でキューを指定して転送した時 (転送元のエージェントが体験するフロー)

エージェントが顧客と通話中に「クイック接続」を使ってキューを指定して転送を試みた時、「転送元のエージェント」が体験するフローです。

クイック接続を行った時点で、顧客との通話は保留状態になりますので、顧客に対しては「顧客保留フロー」が流れます。

デフォルトフロー「Default queue transfer」の初期状態は下図のようになっています。

かなり複雑なフロー構造になっています。

頭の方からフロー構造を確認していくと、まず、「オペレーション時間の確認」ブロックで転送先キューが受付時間内なのか時間外なのかを判定しています。

キューが受付時間内であった場合は、キューに応対可能なエージェントが存在するのかどうかをチェックします。
「人員の確認」ブロックのチェック条件で「配置済み (Staffed)」を指定すると、状態が「空き状態」「通話中」「通話終了後」のいずれかであるエージェントが1人でも存在すれば「True (応対可能)」と判定されます。
(「今すぐに応対できるエージェントがいなくても、待てばそのうち誰かが対応できる」という意味ですね)

そして、キューに対応可能なエージェントが存在する場合には、キューへの転送が行われます。

もし、「キューが受付時間外である」「キューに応対可能なエージェントが1人もいない」「キューがフル稼働状態である」の場合には、それぞれの場面に応じたメッセージが再生され、転送が中止されます。

「キューへの転送フロー」のカスタマイズ

キューへの転送フローは、初期状態からのカスタマイズは必須ではありません。
エージェントに対して流れるメッセージが英語であるため、最低限ここだけ日本語に変えておくのが良いでしょう。

「エージェントへの転送フロー」と同様に、フローに転送時のメカニズムが組み込まれているため、フローの構成自体は変更しないのが安全だと思います。

ただし、このフロー構成だと、キューの受付時間を過ぎてしまうと、キューへの転送が行えなくなってしまいます。

顧客からの受付時間が終わっても、コールセンター内ではエージェントは対応を続けているという場合もあるのではないかと思います。
そのような場合には、最初の「オペレーション時間の確認」ブロックを削除してしまって、受付時間内・時間外に関わらず、エージェントが応対可能であればキューへの転送を可能にするという方法も取れます。

「デフォルトフロー」についての質問・回答

ここからは、「デフォルトフロー」に関してよくある (と思われる) 疑問について、解説したいと思います。

「デフォルトフロー」は削除できる？

Amazon Connectコンソール上でフローの削除は行えませんが、AWS CLIを使うことで削除することができます。

しかし、デフォルトフローはAWS CLIを使っても削除ができないようになっているようです。
(削除しようとするとInvalid requestエラーとなって削除に失敗します)

ここまでに説明した通り、デフォルトフローは顧客から電話が掛かってきた時、顧客へ電話を掛ける時に発生する様々なシチュエーションで使用される重要なフローであるため、安全のために削除できないようになっているのだと思います。

なお、名前が「Sample ～」で始まる「サンプルフロー」の方は、AWS CLIを使って削除することができます。
(こちらは単なるサンプルですので、削除しても影響はありません)

「デフォルトフロー」の名前は変更できる？

デフォルトフローの名前の変更は、問題なく行えます。

恐らく、デフォルトフローの管理は名前ではなく「Contact Flow ID」を使っているためと思われます。

「デフォルトフロー」は直接編集しても良い？ コピーを作成してそちらを編集すべき？

AWS公式ドキュメントでは「通常は、デフォルトのフローを直接編集するのではなく、デフォルトフローのコピーを作成して編集することを推奨する」と説明されています。
https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/change-default-contact-flow.html

これは、重要なデフォルトフローを誤って編集してしまった場合、重大な影響に及ぶことを避けるためだと思われます。

しかし、デフォルトフローをコピーしてそちらを利用する場合には、コンタクトフロー内で「顧客キューフロー」「エージェントウィスパーフロー」など各フローについてどのフローを使用するのかを指定する必要が発生します。
そのため、コンタクトフローの記述が複雑になってしまいます。
(デフォルトフローであれば、そのような指定が無くても暗黙的に使用されるため、記述がシンプルになります)

フローの誤修正による影響への対策としては、以下のような方法が挙げられます。

• フローの「エキスポート」機能を使い、初期状態のフローのバックアップを作成しておく
• フローの「履歴」を利用して、誤って修正した時には前のバージョンに戻す
• このブログ記事を見て、初期状態のフローを復元する

このような対処を行うことで、デフォルトフローを直接編集することのリスクを最小限に抑えつつ、フロー構成をシンプルに保つことができるのではないかと思います。

個人的には、「メッセージ内容を英語から日本語に変更する」程度の変更であれば、デフォルトフローを直接編集しても問題はないと思います。

「デフォルトフロー」の他にフローを作成して、切り替えて使うことは可能？

デフォルトフローが用意されている8種類のフローは、それぞれデフォルトフロー以外にフローを作成して、用途やシチュエーションに応じて使い分けることができます。

例えば、受付内容に応じて「顧客キューフロー」の内容を変える、といったことが可能になります。

デフォルトフロー以外のフローを作成した場合、コンタクトフロー内で「どのフローを使用するか」を指定する必要があります。
各フローの種類毎に、設定を行うためには以下のブロックを使用します。

• 顧客キューフロー： 「顧客キューフローの設定」ブロック
• 顧客ウィスパーフロー： 「ウィスパーフローの設定」ブロック (「送信先: 顧客」を選択)
• 顧客保留フロー： 「保留フローの設定」ブロック (「送信先: 顧客」を選択)
• エージェントウィスパーフロー： 「ウィスパーフローの設定」ブロック (「送信先: エージェント」を選択)
• エージェント保留フロー： 「保留フローの設定」ブロック (「送信先: エージェント」を選択)

例えば、「顧客ウィスパーフロー」を指定するには、下図のように「ウイスパーフローの設定」ブロックで設定を行います。
(「顧客」と「エージェント」の設定を1つのブロックで同時に行うことはできないので、その場合はブロックを2つ配置してそれぞれのブロックで設定してください)

下記のフローの種類では、コンタクトフロー内ではなく、Amazon Connectコンソールの設定画面で設定を行います。

• 発信ウィスパーフロー： 「キュー」の作成画面で「アウトバウンドウィスパーフロー」を指定
• エージェントへの転送フロー： 「クイック接続」の作成画面で「ユーザー転送フロー」を指定
• キューへの転送フロー： 「クイック接続」の作成画面で「キュー転送フロー」を指定

おわりに

今回は、Amazon Connectの「デフォルトフロー」について、

• どのような種類があるのか？
• どのような場面で使われるのか？
• カスタマイズするにはどうすればよいのか？

といった点について解説しました。

Amazon Connectで「困ったこと」「やりたいこと」がある場合、デフォルトフローを確認したりカスタマイズすることで解決する場合も多いので、是非チェックしてみてください。

それでは、明日の「Amazon Connect アドベントカレンダー 2022」の記事にも期待してください！