トップ > Amazon Connect > 【Amazon Connect】コンタクトイベントの配信タイミング

【Amazon Connect】コンタクトイベントの配信タイミング

Amazon Connect Amazon EventBridge
記事タイトルとURLをコピーする

Amazon Connectのコンタクトイベント（通話イベント）は、特別な設定なしで、ほぼリアルタイムでEventBridgeへ配信される便利な機能です。
実際に架電し、イベントタイミングと通知情報に含まれるタイムスタンプ値を確認します。

概要

コンタクトイベントがどのようなタイミングで配信されるのか、下記の手順で簡易的に確認してみます。

  • イベント情報をログ出力するLambda関数を作成
  • Lambda関数を実行するEventBridgeルールを設定
  • 架電し、出力ログ内容を確認

確認準備

Lambda関数を作成

受け取ったevent情報をJSONフォーマットでログ出力するだけの関数を作成します。

import json

def lambda_handler(event, context):
    print(json.dumps(event))

EventBrigdeルールを作成

イベントパターンを下記のように設定します。 ターゲットとして上記で作成したLambda関数を指定します。

{
  "source": ["aws.connect"],
  "detail-type": ["Amazon Connect Contact Event"],
  "detail.eventType": ["INITIATED", "CONNECTED_TO_SYSTEM", "QUEUED", "DISCONNECTED", "COMPLETED"]
}

CloudWatch Logs Insightsクエリを準備

各種タイムスタンプを確認するクエリを実行します。

fields @timestamp, 
 detail.contactId,
 detail.eventType,
 detail.initiationMethod,
 detail.agentInfo.agentArn, 
 detail.initiationTimestamp,
 detail.connectedToSystemTimestamp,
 detail.queueInfo.enqueueTimestamp,
 detail.agentInfo.connectedToAgentTimestamp,
 detail.disconnectTimestamp,
 detail.agentInfo.afterContactWorkStartTimestamp,
 detail.agentInfo.afterContactWorkEndTimestamp
| sort @timestamp
| filter source = 'aws.connect'
| limit 100

イベントタイプと動作について

eventTypeの値は下記のような内容になっています。

eventTypeの値 内容
INITIATED コンタクトが開始されました（今回の場合、Amazon Connectへの着信とともにコンタクト情報が作成された、と解釈して良さそうです）。
InitiationTimestamp が入力されます。
CONNECTED_TO_SYSTEM Amazon Connectへ接続し、メディア確立されました。
connectedToSystemTimestamp が入力されます。
QUEUED キューへ転送されました（キューイングされたタイミングであり、エージェント着信・応答ではない）。
enqueueTimestamp が入力されます。
DISCONNECTED 通話が切断されました（通常は同時にACWが開始されます）。
connectedToAgentTimestamp と disconnectTimestamp が入力されます。
COMPLETED ACWを含めてコンタクトが完了しました。
afterContactWorkStartTimestamp と afterContactWorkEndTimestamp 、つまりACW期間の開始・終了タイムスタンプが入力されます。

確認シナリオ１

Amazon Connectへの着信通話に対してエージェント受話通話、顧客が通話を切断する操作を行います。

確認シナリオ１の結果

出力されたログを確認します。表の見方は下記のようになります。

  • 縦横入れ替えて左から右へ時間が経過する表になっています
  • 空欄は値無しを示しています
  • “←“表示は左の列と同じ内容であることを示しています

同一コンタクトIDの情報について確認すると、情報が追加されていく動作になっていることが分かります。

確認シナリオ１のコンタクト情報との対応を確認

1秒以内の誤差はあるようですが、各タイムスタンプが対応していることを確認できます。

確認シナリオ２

Amazon Connectへの着信通話があり、エージェント通話開始。他のエージェントへ転送します。引き継いだエージェントと顧客が通話し、最後に顧客が切断する操作を行います。

転送するため、コンタクトIDが異なる2つのコンタクトが作成されます。コンタクトごとにログを確認します。

確認シナリオ２の結果

コンタクト１

転送元コンタクトのDISCONNECTEDイベントは転送先の切断と同じタイミングで発生します。 結果として、COMPLETEDイベントが先に発生しています。（ACW時間と転送後の通話の長さによります）

さらに、COMPLETEDイベント時点でDISCONNECTしていないため、disconnectTimestampが入力されていません。（※COMPLETEDイベントだから必ずdisconnectTimestampが入力される、という前提はNGということになります）

コンタクト２

initiationMethodが TRANSFER となります。

また、CONNECTED_TO_SYSTEMイベントが発生しません（転送元の着信時にメディア確立されているためと思われます）。connectedToSystemTimestamp へ値が入力されません。

転送先であるこちらのコンタクト切断タイミングで転送元コンタクトのDISCONNECTEDイベントが発生します。（コンタクト１セクション記載の通り）

確認シナリオ２のコンタクト情報との対応を確認

コンタクト１

コンタクト２

気になったポイント

  • 転送した場合については、転送先の通話終了時にDISCONNECTEDイベントが発生する動作となっています。転送元利用者は切断している感覚になるはずで、印象と異なるタイミングとなるため、分析時は意識が必要と思いました
  • COMPLETED イベントタイミングはACW終了から数秒（10秒以内程度）のタイムラグがあるようです
  • 現状の動作では、顧客とエージェントが接続したタイミングのイベントが定義されていません。表にしてみて気づいたのですが、対応できれば使いどころがありそうに思います

最後に

ベストエフォート通知となっているものの、クイックなイベント通知をトリガーにオペレーションサポート機能開発に生かせそうです。
ご参考になれば幸いです。