Amazon Web Services ブログ

Amazon Connect を使用して内線番号ベースのダイヤルソリューションを構築する方法

本投稿は Connect Specialist SA の Sayed Hassan による寄稿を翻訳したものです。

コンタクトセンターでは、発信者が特定のエージェント(担当者)に直接かけられるよう、各エージェントに内線番号を割り当てることが一般的に行われています(訳注:米国の場合)。これにより、各エージェントに 直通電話番号(ダイヤルイン) を割り当てる必要性が低減されます。応答可能なエージェントに顧客がランダムに割り当てられるのではなく、希望するエージェントと直接話したいアカウント管理シナリオでは、顧客がエージェントに直接かけられるようにするのが一般的です。本投稿では、このようなビジネス上のユースケースを解決するために、Amazon Connect を使った内線番号ベースのダイヤリングの仕組みを見ていきます。

内線番号ベースのダイヤルソリューションを構築するには、Amazon Connect、AWS Identity and Access Management (IAM) ロール、Amazon DynamoDB テーブル、AWS Lambda 関数を含む AWS サービスを使用します。

概要

このソリューションを構築するには、次のステップを実行します。

1.   内線番号とエージェントID間のマッピングを保持する DynamoDB テーブルを作成します。

2.   Lambda 関数が DynamoDB 内のエージェント ID を参照できる IAM ロールを作成します。

3.   実際の検索用の Lambda 関数を作成します。

4.   Amazon Connect に Lambda 関数を追加します。

5.   Lambda 関数を実行する問い合わせフローを作成します。

前提条件

このソリューションを構築するには、Amazon Connect インスタンスをプロビジョニングし、エージェントを作成する必要があります。詳細については、Amazon Connect の開始方法を参照してください。

また、Amazon Connect インスタンスと同じ AWS リージョンで以下のステップを実施する必要があります。

ステップ1: 内線番号とエージェント ID間のマッピングを保持する DynamoDB テーブルを作成する

まず、プライマリパーティションキーとしてエージェント内線番号を持つテーブルを DynamoDB に作成します。次に、エージェント内線番号をエージェント ID に関連付ける DynamoDB 項目を作成できます。ユーザーがかけようとしているエージェントがログインしていない場合、フォールバックキューの列を追加することもできます。または、エージェントの携帯電話番号または留守番電話センターに通話を転送することもできます。ビジネス上のユースケースによって、最適なシナリオ処理方法が決まります。テーブルの設定とアイテムの追加手順については、DynamoDB の操作を参照してください。この例では、‘Extension’、AgentID、および FallBackQueue のキーと値のペアを追加します。フォールバックキューには「キューの設定」を動的に使用しますが、問い合わせ属性などを使ってキューを動的に設定するために「キューの設定」ブロックを使用するには、キュー名ではなくキューの ARN を指定する必要があります。キューの ARN を見つけるには、Amazon Connect 管理者コンソールのキューエディタでキューを開きます。ARN は、/queue の後にブラウザのアドレスバーに表示される URL の最後に含まれています。たとえば、…/queue/aaaaaaaa-bbbb-cccc-dddd-111111111111 です。

DynamoDB のプライマリキーとして4桁の内線番号を追加し、それらをエージェント ID にマッピングしてキューをフォールバックできます。ブログ後半の問い合わせフローに関する記述でも述べますが、メインメニューで5桁の内線番号を入力するように促すか、または内線番号でダイヤルしたいかどうかをまず尋ねてその後に4桁の内線番号の入力を促すか、いずれかの構成にします。メインメニューで5桁の内線番号の入力を促す場合、最初の DTMF キー入力を使用して 「顧客の入力を保存する」 ブロックに転送し、残りの4つの DTMF キー入力を使用して、Dynamo DB テーブルにマッピングされているエージェント内線番号をキャプチャします。このブログの後半の問い合わせフローに関する記述で詳しく述べます。

エージェント内線番号とフォールバックキュー ARN を含む Dynamo DB テーブル

 

ステップ2: IAM ロールを作成する

次に、IAM ロールを作成します。このロールは、DynamoDB でエージェント内線番号とエージェントのマッピングを検索する Lambda 関数によって引き受けられます。Amazon CloudWatch ログ記録および DynamoDB 読み取り操作のロールを作成し、アクセス許可を追加できます。CloudWatch ログ記録と DynamoDB の読み取り専用アクセスを有効にするための組み込みポリシーを追加することもできます。詳細については、AWS Lambda の実行ロールを参照してください。次の図は、DynamoDB 読み取り専用アクセスと、 Lambda 関数の実行時にトレースログを書き込むためのCloud Watch アクセス用に追加されたポリシーを組み込んだロールを示しています。

エージェント内線番号の Lambda 実行ロール

 

ステップ3: Lambda 関数を作成する

次に、Lambda 関数を作成し、ステップ2で作成したロールを割り当てます。以下は、Python 2.7 を使用して作成したサンプル Lambda 関数のスナップショットですが、Lambda 関数作成時に任意のプログラミング言語を選択できます。基本的に、この Lambda 関数は、Amazon Connect によってイベントデータで渡された内線番号の値を抽出します。その後、DynamoDB で検索を実行して、エージェント ID とフォールバックキューを取得します。エージェントがログインしていない場合は、通話を転送できます。エラー処理または内線番号が見つからないシナリオを処理できるように、Amazon Connect に true/false 成功フラグが返されます。Lambda 関数を最初から作成する方法については、コンソールでLambda 関数を作成するを参照してください。

Lambda 関数のサンプルコードは次のとおりです。

from __future__ import print_function
import boto3
import json
dynamodb = boto3.resource('dynamodb')

def lambda_handler(event, context):
    #print(event)
    extension=event['Details']['ContactData']['Attributes'].get('AgentExtension',"Not Available")
    table = dynamodb.Table('AgentsExtensions')
    try:
        response = table.get_item(
                Key={
                    'Extension': extension
                    }
                )
    except ClientError as e:
        print(e.response['Error']['Message'])
        return {
                "Success":"False",
                "Reason":e.response['Error']['Message']
            }
    else:
        #item = response['Item']
        print("GetItem succeeded:")
        print(json.dumps(response))
        if "Item" in response:
            return {
                "Success":"True",
                "AgentID":response["Item"]["AgentID"],
                "FallBackQueue":response["Item"]["FallBackQueue"]
            }
        else:
            return {
                "Success":"False",
                "Reason":"No Records Found"
            }

以下のサンプルのようなテストイベントを設定することにより、Lambda コンソールで基本的な単体テストを実行できます。”Attributes”(属性)セクションまたは“Parameters”(パラメータ)セクションを使用して、Amazon Connect から Lambda 関数に情報を渡すことができます。これらの 2 つのアプローチの主な違いは、属性が問い合わせ全体で持続するものであるのに対し、パラメータは一時的なものであることです。

次の例では、属性を使用して、問い合わせ存続期間を通じて内線番号の値を保持し、問い合わせが終了した後も問い合わせ追跡レコードで使用できるようにします。詳細については、Lambda 関数を呼び出すを参照してください。

{

	"Details": {

		"ContactData": {

			"Attributes": {

				"AgentExtension": "4051"

			},

			"Channel": "VOICE",

			"ContactId": "4a573372-1f28-4e26-b97b-XXXXXXXXXXX",

			"CustomerEndpoint": {

				"Address": "+1234567890",

				"Type": "TELEPHONE_NUMBER"

			},

			"InitialContactId": "4a573372-1f28-4e26-b97b-XXXXXXXXXXX",

			"InitiationMethod": "INBOUND | OUTBOUND | TRANSFER | CALLBACK",

			"InstanceARN": "arn:aws:connect:aws-region:1234567890:instance/c8c0e68d-2200-4265-82c0-XXXXXXXXXX",

			"PreviousContactId": "4a573372-1f28-4e26-b97b-XXXXXXXXXX",

			"Queue": "QueueName",

			"SystemEndpoint": {

				"Address": "+1234567890",

				"Type": "TELEPHONE_NUMBER"

			}

		},

		"Parameters": {

			"sentAttributeKey": "sentAttributeValue"

		}

	},

	"Name": "ContactFlowEvent"

}

ステップ4: Amazon Connect に Lambda 関数を追加する

次に、Amazon Connect 設定ページで Lambda 関数を追加します。Amazon Connect インスタンスの設定ページを開き、[問い合わせフロー] を選択します。AWS Lambda セクションまでスクロールダウンし、作成した Lambda 関数を検索します。[Lambda 関数の追加] を選択して、問い合わせフロー内で実行できるようにします。

ステップ5: Lambda 関数を実行する問い合わせフローを作成する

次のステップでは、内線番号ダイヤルロジックが組み込まれた問い合わせフローを作成します。問い合わせフロー(インバウンド)を作成し、その問い合わせフローで内線番号ダイヤルを有効にします。メニューレベルでエージェントの内線番号を入力できるようになります。あるいは、顧客が内線番号を入力したい場合は1度トーン信号 (DTMF) キーを押してもらい、その後に今すぐ内線番号を入力できる旨を知らせる音声案内を追加することもできます。さらに、Amazon Lex ボットを活用して、その意図を識別し、DTMF または音声で情報をキャプチャすることもできます。本投稿では例を単純化するために、DTMF のみのやり方を示します。問い合わせフローのサンプルをダウンロードします。

内線番号ダイヤルによる問い合わせフロー

メインメニューで、お客様にエージェントの内線番号を知っているかどうかを尋ね、今すぐ入力するように案内します。ここではすべてのエージェント内線番号が ‘9’ で始まると想定しています。最初の‘9’が入力されると、その後に続く4桁のエージェント内線番号をキャプチャする 「顧客の入力を保存する」 ブロックに移動します。なお、メインメニューで内線番号を直接ダイヤルしてもらうように設定するか、あるいは発信者にDTMF キーを1度押してもらうか、または Amazon Lex ボットを使用して内線番号の入力を希望するか判断させる、のどの方法を取るかはあなた次第です。

内線番号ダイヤルメニュー

メインメニューで内線番号ダイヤルを有効にするには、「顧客の入力を保存する」 ブロックに空白の文字列を入力します。[テキスト読み上げ] を選択し、テキストを入力します。顧客入力で [カスタム] を選択し、最大桁数とエントリ間の遅延を入力します。この例にあるスクリーンショットでは、最大桁数の値が4に設定され、エントリ間の遅延は5に設定されています。

内線番号入力ブロック

あるいは、次のようなメインメニュープロンプトにすることもできます。「営業にお繋ぎする場合は1を、内線番号でお繋ぎする場合は9を押してください。」 その後、「顧客の入力を保存する」 ブロックで、4桁のエージェント内線番号を入力するよう発信者に伝えることができます。

ユーザー入力をキャプチャしたら、問い合わせ属性に保存し、暗黙的に Lambda 関数に渡すことができます。以下の問い合わせフローを見ていただければ分かるように、「顧客の入力を保存する」 ブロックの後に問い合わせ属性を設定するブロックがあります。これにより、発信者が入力した内線番号を問い合わせ属性に保存できます。保存された属性は、問い合わせの終わりまで保持され、Lambda 関数に暗黙的に渡され、通話終了後に問い合わせ追跡レコードにも保存されます。または、その情報を保持したくない場合は、「問い合わせ属性の設定」ブロックを除外し、「顧客の入力を保存する」ブロックのエントリをLambda 関数呼び出しのパラメータとして明示的に渡すことができます。また、Lambda 関数のパスを変更して、属性ではなくパラメータで渡されたエージェント内線番号を抽出する必要があります。ただし、この例では、問い合わせ属性を使用してエージェントの内線番号を渡しますので、この内線番号は問い合わせの終わりまで持続し、問い合わせトレースレコードの属性としても表示されます。ドキュメントで Lambda 関数に渡された完全な JSON リクエストの例を見ることができます。この時点で、Invoke AWS Lambda 関数をコンソールにドラッグし、ドロップダウンから関数名を選択します。

問い合わせフローで Lambda 関数を呼び出す

また、Lambda を使った検索の一部として、フォールバックキューも作成しています。問い合わせフローは、希望するエージェントがログインしているかどうかを確認します。エージェントがログインしている場合、問い合わせはそのエージェントに転送できます。ただし、エージェントがログインしていない場合、現在のシナリオでは、発信者に告知した後にキューに転送されます。また、希望するエージェントにつなげるには、人員の確認時またはキューの設定時に [エージェント別] を選択することに注意してください。フォールバックキューの場合、人員の確認時またはキューの設定時に、[キュー別] を選択します。

問い合わせフローが完了したら、保存して公開します。最後のステップは、この問い合わせフローに電話番号を指定し、構築した機能全体をテストすることです。

問い合わせフローに関連付けられている電話番号にダイヤルします。入力を求められたら、電話機の DTMF キーを使用してエージェントの内線番号を入力します。通話は、選択したエージェントにルーティングされます。エージェントがログインしていない場合は、通話はフォールバックキューにルーティングされます。想定どおりに機能しない場合は、Amazon Connect の問い合わせフローログを使用して、問い合わせフローのデバッグを行います。

まとめ

本投稿では、Amazon Connect で内線番号ベースのダイヤルソリューションを構築する方法についてご紹介しました。DynamoDB、IAM、Lambda、Amazon Connect などの AWS エコシステムのサービスを活用して、本ユースケースを解決しています。このソリューションを発展させて、エージェント(担当者)がログインしていないときに通話を留守番電話センターや携帯電話に転送するなど、高度なシナリオに対応することもできます。これにより、顧客が各エージェントごとの直通電話番号(ダイヤルイン) を必要とすることなく、個別のエージェントに直接連絡することができます。

翻訳はソリューションアーキテクト清水 正直が担当しました。原文はこちらです。