Amazon Connect CustomerでPBX型の内線要件をどこまで実現できるのか整理してみた
はじめに
Amazon Connect Customerの導入を検討する際に、一般的なPrivate Branch Exchange（PBX、構内交換機）のような内線機能を利用できるのか気になることがあります。
ただし、「内線機能」という言葉には、以下のような複数の要件が含まれます。
- 顧客との通話中に別の担当者へ相談、転送する
- 外部からの着信を特定の担当者へ接続する
- 代表番号への着信後に番号を入力し、特定の担当者へ接続する
- 通話中の担当者にも個人宛ての着信を提示する
- 待機中の担当者から別の担当者へ直接電話をかける
Amazon Connect Customerでは、これらをそれぞれ異なる機能や構成で実現します。
特に注意したいのが、代表番号への着信後に番号を入力して担当者へ接続する構成です。利用者からは「代表番号＋内線番号」のように見えますが、技術的にはInteractive Voice Response（IVR、音声自動応答）による担当者ルーティングであり、PBXの内線通話とは異なります。
本記事では、待機中の担当者が別の担当者を呼び出して通話する機能を「PBX型の内線通話」と表現し、外部からの着信を特定の担当者へ接続するルーティング機能と区別します。
そのうえで、Amazon Connect Customerで実現できる機能を、コンタクトの転送、特定担当者への着信ルーティング、通話中の担当者への割り込み着信、担当者間の直接発信に分けて整理します。
結論
Amazon Connect Customerで実現できる機能は、以下のように整理できます。
| 要件 | 主な実現方法 | 位置付け |
|---|---|---|
| 顧客との通話中に別の担当者へ相談、転送する | ユーザークイック接続 | 標準のコンタクト転送機能 |
| 個人用の外線番号への着信を特定の担当者へ接続する | フロー、エージェントキュー | 特定担当者への着信ルーティング |
| 代表番号への着信後に番号を入力し、特定の担当者へ接続する | IVR、Data Tables、フロー、エージェントキュー | 番号入力によるIVRルーティング |
| 通話中の担当者にも個人宛ての着信を提示する | Interrupt agentブロック |
割り込み着信 |
| 待機中の担当者から別の担当者へ直接発信する | Agent Workspaceのサードパーティーアプリなど | カスタム実装による担当者間通話 |
Amazon Connect Customerでは、コールセンターに着信したコンタクトのルーティングや、対応中のコンタクトの転送を標準機能で実現できます。
一方、待機中の担当者が別の担当者の短い番号を入力して発信する、一般的なPBX型の内線通話は、標準のユーザークイック接続では実現できません。
そのため、Amazon Connect Customerに内線機能があるかを一括りに判断するのではなく、実現したい要件を分けて考える必要があります。
1. 顧客との通話中に別の担当者へ相談、転送する
顧客との通話中に別の担当者を呼び出す場合は、Amazon Connect Customerのクイック接続を利用できます。
クイック接続には、以下の種類があります。
| 種類 | 接続先 |
|---|---|
| ユーザークイック接続 | 特定の担当者 |
| キュークイック接続 | 特定のキュー |
| 電話番号クイック接続 | 外部電話番号 |
| フロークイック接続 | チャット中に開始するフロー |
ユーザークイック接続を利用すると、以下の操作が可能です。
- 顧客を保留し、別の担当者へ相談する
- 顧客を別の担当者へ転送する
- 顧客と複数の担当者による通話にする
- 転送元の担当者が退出し、顧客と転送先担当者の通話を継続する
処理の流れは以下です。
担当者Aが顧客と通話中
↓
担当者Aがユーザークイック接続を選択
↓
顧客は保留
↓
担当者Bに着信を提示
↓
担当者Bが応答
↓
担当者Aと担当者Bが会話
↓
相談、転送、または複数者通話
転送先の担当者が応答した後、転送元の担当者は顧客を含めた複数者通話にするか、自分が通話から退出して転送を完了できます。
クイック接続の種類ごとの設定例は、以下の記事でも紹介しています。
ユーザークイック接続はPBX型の内線発信ではない
ユーザークイック接続とキュークイック接続は、担当者が対応中のコンタクトを転送する場合にContact Control Panel（CCP、コンタクトコントロールパネル）へ表示されます。
そのため、ユーザークイック接続は以下の用途に利用する機能です。
顧客との通話あり
↓
別の担当者へ相談、転送する
以下のように、顧客との通話がない状態から担当者同士の通話を始める機能ではありません。
顧客との通話なし
↓
担当者Aから担当者Bへ直接発信する
ユーザークイック接続による転送は、PBXの保留転送に近い機能ですが、待機中の担当者同士が通話を開始する内線発信とは分けて考える必要があります。
2. 個人用の外線番号への着信を特定の担当者へ接続する
Amazon Connect Customerでは、担当者用の外線番号への着信を、特定の担当者へ直接ルーティングできます。
この構成では、ユーザーごとに作成されるエージェントキューを利用します。
エージェントキューを利用する
Amazon Connect Customerでは、インスタンス内のユーザーごとにエージェントキューが作成されます。
エージェントキューを利用すると、標準キューに所属する複数の担当者ではなく、特定の担当者へコンタクトをルーティングできます。
フローの「作業キューの設定」ブロックでは、特定の担当者を直接選択できます。担当者を動的に指定する場合は、ユーザー名またはユーザーIDをコンタクト属性として渡します。
例えば、担当者用のDirect Inward Dialing（DID、ダイヤルイン）番号を用意する場合は、以下のような構成が考えられます。
担当者用のDID番号へ着信
↓
着信フローを開始
↓
対象担当者のエージェントキューを設定
↓
対象担当者へルーティング
利用者から見ると、特定の担当者に直接電話をかける動作になります。
ただし、これは担当者にPBXの内線端末を割り当てる機能ではありません。Amazon Connect Customerの外線番号への着信を、フローで特定の担当者へルーティングする構成です。
3. 代表番号への着信後に番号を入力し、特定の担当者へ接続する
代表番号への着信後に顧客が番号を入力し、その番号に対応する担当者へルーティングする構成も実現できます。
代表番号へ着信
↓
IVRで担当者番号を入力
↓
入力された番号から担当者を検索
↓
対象担当者のエージェントキューを設定
↓
対象担当者へルーティング
利用者に入力してもらう番号を「内線番号」として案内すれば、利用者からは「代表番号＋内線番号」のように見えます。
しかし、内部的には以下の機能を組み合わせたIVRルーティングです。
- 顧客入力の取得
- 入力番号に対応する担当者の検索
- エージェントキューの設定
- キューへの転送
そのため、機能分類としては「内線通話」ではなく、「番号入力による担当者直通ルーティング」と表現するのが正確です。
Data Tablesで担当者番号とルーティング先を管理する
番号入力による担当者直通ルーティングでは、入力番号と担当者の対応をData Tablesで管理できます。
Data Tablesは、Amazon Connect Customer内で運用データを表形式で管理し、フローなどから参照する機能です。Data Tablesの変更内容は、フローを再公開しなくても後続のフロー実行から参照できます。
例えば、以下のような対応表を作成します。
| 担当者番号 | 担当者名 | ルーティング先 |
|---|---|---|
1001 |
担当者A | 担当者Aの識別情報 |
1002 |
担当者B | 担当者Bの識別情報 |
1003 |
担当者C | 担当者Cの識別情報 |
フローの処理イメージは以下です。
開始
↓
顧客入力を取得
↓
Data Tableブロック
└ 入力された番号に対応する担当者情報を取得
↓
作業キューの設定
└ 取得した担当者を指定
↓
キューへの転送
Data Tableブロックは、Data Tablesに保存されたルーティングパラメータなどを検索し、その結果を後続のブロックから参照するために利用できます。
AWSのブログでも、Data Tablesに担当者番号と担当者情報の対応を登録し、顧客が入力した番号に基づいて対象担当者へルーティングする構成が紹介されています。
Data Tablesの役割
本構成では、各機能が以下の役割を持ちます。
Data Tables
→ 入力番号と担当者の対応を管理する
フロー
→ 入力番号に対応する担当者を検索し、ルーティング先を設定する
エージェントキュー
→ 特定の担当者へコンタクトをルーティングする
Data Tables自体が電話を発信したり、担当者へ着信を提示したりするわけではありません。
そのため、本構成は「Data Tablesによる内線機能」ではなく、Data Tablesで番号と担当者の対応を管理し、IVRで入力された番号に基づいて特定の担当者へルーティングする構成と捉えるのが適切です。
4. 通話中の担当者にも個人宛て着信を提示する
通常のルーティングでは、担当者が音声通話の最大同時実行数に達している場合や、ルーティング対象外のカスタムステータスになっている場合、新しいコンタクトはその担当者へ提示されません。
Interrupt agentブロックを利用すると、担当者の通常のルーティング設定を上書きし、通話中やカスタムステータス中の担当者にも、特定のコンタクトを提示できます。個人内線への着信や、優先度の高い連絡などが想定された機能です。
動作イメージ
担当者が顧客Aと通話している状態で、個人宛ての別の着信が発生するケースを考えます。
担当者が顧客Aと通話中
↓
担当者の個人宛て着信が発生
↓
Interrupt agentブロックで担当者を指定
↓
担当者に新しい着信を提示
↓
担当者が応答
↓
顧客Aとの通話を保留
↓
担当者が新しい通話に対応
担当者は、2つの通話を切り替えて対応できます。
Interrupt agentブロックは、通話を強制的に切り替える機能ではありません。新しい着信を担当者へ提示し、担当者が応答するかどうかを判断します。
IVRルーティングとは役割が異なる
番号入力による担当者直通ルーティングとInterrupt agentブロックは、代替関係ではなく補完関係です。
| 機能 | 役割 |
|---|---|
| IVR | 顧客から担当者番号の入力を受け付ける |
| Data Tables | 入力番号から対象担当者を検索する |
| エージェントキュー | 特定の担当者をルーティング先にする |
Interrupt agent |
通話中などの担当者にもコンタクトを提示する |
組み合わせる場合の処理イメージは以下です。
顧客が担当者番号を入力
↓
Data Tablesで対象担当者を検索
↓
対象担当者のエージェントキューへ転送
↓
カスタマーキューフローを開始
↓
Interrupt agentブロック
↓
通話中の担当者にも着信を提示
Interrupt agentブロックはカスタマーキューフローで利用します。利用条件やエラーになるケース、未応答時の設計については、公式ドキュメントを確認してください。
5. 待機中の担当者から別の担当者へ直接発信する
一般的なPBXでは、担当者が待機中でも別の担当者へ直接発信できます。
担当者Aが待機中
↓
担当者Bの内線番号を入力
↓
担当者Bを呼び出す
↓
担当者同士で通話
Amazon Connect Customerの標準のユーザークイック接続は、担当者が対応中のコンタクトを転送するための機能です。
そのため、顧客との通話がない状態で担当者Aが担当者Bを選択し、担当者間通話を開始するPBX型の操作は、標準のユーザークイック接続では実現できません。
サードパーティーアプリによる実装例
待機中の担当者から別の担当者へ発信する場合は、Agent Workspaceにサードパーティーアプリを組み込むなどのカスタム実装が考えられます。
AWSのブログでは、Agent Workspaceに担当者検索と発信操作を提供するサードパーティーアプリを組み込み、担当者間通話を実現する例が紹介されています
構成イメージは以下です。
担当者A
↓
Agent Workspaceのサードパーティーアプリ
↓
担当者Bを検索、選択
↓
発信開始用のAPI
↓
Amazon Connect Customerのフローを開始
↓
担当者Bへルーティング
↓
担当者Aと担当者Bを接続
AWSのブログ例では、Amazon API Gateway、AWS Lambda、Amazon DynamoDB、Amazon Kinesisなどを組み合わせています。
ただし、これは担当者間通話を実現するための実装例です。すべてのコンポーネントが、どの構成でも必須という意味ではありません。
実際の構成は、以下の要件によって変わります。
- 内線番号を入力するか、担当者名から検索するか
- 担当者の対応可否を表示し、発信先として選択できる担当者を制御するか
- 相手が応答しない場合に、別の担当者や留守番電話へ転送するか
- 担当者間通話をどのように記録、集計するか
内線番号と担当者の対応管理にはData Tablesを利用できますが、通話の開始には、担当者が操作する画面やAPI、フローなどを別途実装する必要があります。
外部電話番号への発信で代替できる場合
Amazon Connect Customerでは、電話番号タイプのクイック接続を利用して、登録した外部電話番号へ発信できます。
AWSドキュメントでは、上司の携帯電話番号などを電話番号タイプのクイック接続として登録し、担当者から発信する例が紹介されています。
電話番号タイプのクイック接続を電話帳のように利用し、Contact Control Panel（CCP、コンタクトコントロールパネル）から外部電話番号へ発信する設定例は、以下の記事で紹介しています。
例えば、担当者Bの携帯電話番号を電話番号タイプのクイック接続として登録すれば、担当者Aから担当者Bの携帯電話へ発信できます。
担当者A
↓
電話番号タイプのクイック接続
↓
担当者Bの携帯電話で応答
この場合、担当者BはAmazon Connect Customerの担当者としてではなく、外部の通話相手として応答します。そのため、担当者BのAgent Workspaceに着信を提示したり、担当者の対応可否に基づいて発信先を制御したりする構成にはなりません。
一方、Amazon Connect Customer内の担当者間通話では、担当者BのAgent Workspaceへコンタクトを提示します。
担当者A
↓
Amazon Connect Customer内でコンタクトを開始
↓
担当者BのAgent Workspaceへ着信
担当者同士で音声通話ができればよい場合は、電話番号タイプのクイック接続でも要件を満たせる可能性があります。担当者BがAgent Workspaceで応答する必要がある場合は、サードパーティーアプリやAPIなどを利用した担当者間通話の実装が必要です。
まとめ
Amazon Connect Customerでは、クイック接続によるコンタクトの転送や、エージェントキューによる特定担当者への着信ルーティングを実現できます。
代表番号で入力された番号から担当者へ接続する構成は、内線に近い利用体験を提供できますが、技術的にはData Tablesとフローを利用したIVRルーティングです。通話中の担当者にも着信を提示する場合は、Interrupt agentブロックを組み合わせます。
一方、待機中の担当者から別の担当者へ直接発信するPBX型の内線通話には、サードパーティーアプリやAPIなどを利用したカスタム実装が必要です。導入時は、コンタクトの転送、外部着信のルーティング、担当者間の直接発信を分けて要件を整理するとよいでしょう。
