

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Amazon Connect のリアルタイムメトリクスでキューに入れられたコールバック
<a name="about-queued-callbacks"></a>

このトピックでは、キューに保存されたコールバックがどのようにリアルタイムメトリクスレポートとコンタクトレコードに表示されるかについて説明します。

**ヒント**  
コールバックを待機している顧客の数のみを表示するには、コールバックのコンタクトのみを受け取るキューを作成する必要があります。これを行う方法については、「[Amazon Connect でのルーティングの設定](connect-queues.md)」を参照してください。現在、コールバックを待機しているコンタクトの電話番号を表示する方法はありません。

1. コールバックは、コールバックキューでコールバックを作成するために [[キューへ転送]](transfer-to-queue.md) ブロックがトリガーされたときに開始されます。次のフローの画像は、フローの最後の **[キューへ転送]** ブロックを示しています。  
![\[最後に [キューへの転送] ブロックがあるフロー。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/queued-callback-flow-callback-initiation.png)

1. 初期遅延が適用されると、コールバックがキューに入れられます。エージェントが使用可能になり、コンタクトを提供できるようになるまで、コールバックはそのまま残ります。次の画像は、**[リアルタイムメトリクス]** ページの **[キュー内]** 列のコンタクトを示しています。  
![\[[リアルタイムメトリクス] ページの [キュー内] 列にリストされているコンタクト。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/rtm-callback-in-queue.png)

1. コールバックがエージェントに接続されると、コンタクトに対して新しいコンタクトレコードが作成されます。次の図は、3 つのコンタクトレコードを示しています。3 番目のレコードは、エージェント 3 に接続されたコールバック用です。  
![\[コンタクトレコードごとに 1 つずつ、計 3 つのブロック。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/ctr-diagram.png)

1. コールバックコンタクトレコードの **[開始タイムスタンプ]** は、ステップ 1 に示すように、フローでコールバックが開始された時点に対応します。次の画像は、**[コンタクトレコード]** ページの **[開始タイムスタンプ]** フィールドを示しています。  
![\[[コンタクトレコード] ページ、[開始タイムスタンプ] フィールド。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/ctr-callback-initiation-timestamp.png)

## [キューへ転送] ブロックのプロパティがこのフローに与える影響
<a name="transfer-to-queue-properties"></a>

[Transfer to queue](transfer-to-queue.md) ブロックには次のプロパティがあり、 がコールバック Amazon Connect を処理する方法に影響します。
+ **[初回ディレイ]**: このプロパティは、コールバックがキューに入れられるタイミングに影響します。フローでコンタクトのコールバックが開始されてから、顧客が次に使用可能なエージェントのキューに入れられるまでの経過時間を指定します。詳細については、「[Amazon Connect で初回ディレイがスケジュールされたメトリクスとキュー内のメトリクスに与える影響](scheduled-vs-inqueue.md)」を参照してください。
+ **[最大再試行回数]**: これが 2 に設定されている場合、 Amazon Connect は、顧客に最大 3 回発信を試みます。最初のコールバックと 2 回の再試行です。
+ **[試行間の最小時間]**: 顧客がコールに応答しない場合に、再試行するまでの待機時間です。

## コールバックメトリクス
<a name="callback-metrics"></a>

次のメトリクスを使用して、ビジネス内のコールバックの数をモニタリングします。
+ [問い合わせのコールバック](metrics-definitions.md#callback-contacts): このメトリクスは、キューに保存されたコールバックから開始されたコンタクトの合計数を示します。つまり、キューに入れられたコールバックを選択した顧客の数です。
+ [対応したコンタクトのコールバック](metrics-definitions.md#callback-contacts-handled): このメトリクスは、キューに保存されたコールバックから開始され、エージェントが対応したコンタクトの合計数を示します。つまり、応答されたコールバックの数です。
+ [コールバック試行](metrics-definitions.md#callback-attempts): このメトリクスは、コールバックを試みたものの、顧客が電話に出なかったコンタクトの数を表します。

# Amazon Connect で初回ディレイがスケジュールされたメトリクスとキュー内のメトリクスに与える影響
<a name="scheduled-vs-inqueue"></a>

[[キューへ転送]](transfer-to-queue.md) ブロックでは、**[初回ディレイ]** プロパティは、コールバックがキューに入れられるタイミングに影響します。例えば、**[初回ディレイ]** が 30 秒に設定されているとします。リアルタイムメトリクスレポートに表示される内容は次のとおりです。

1. 20 秒後、コールバックはすでに作成されていますが、**[初回ディレイ]** の設定により、まだキューに入っていません。次の **[リアルタイムメトリクス]** ページの画像では、**[キュー内]** = 0、**[スケジュール済み]** = 1 です。  
![\[スケジュールされているがキューに入っていないコンタクト。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/rtm-callback-scheduled.png)

1. 35 秒後、コンタクトのコールバックがキューに配置されています。次の画像では、コールバックは現在 **[キュー内]** になっています。もうスケジュールされていません。  
![\[[キュー内] 列は 1、[スケジュール済み] 列は 0 です。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/rtm-callback-in-queue2.png)

1. 40 秒後にエージェントがコールバックを受け入れると仮定します。[キュー内] 列 = 0、**[スケジュール済み]** 列 = 0。  
![\[[キュー内] 列は 1、[スケジュール済み] 列は 0 です。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/rtm-callback-accepted-by-agent.png)

# Amazon Connect でのコールバック試行の失敗
<a name="failed-callback-attempt"></a>

エージェントが、提供されたコールバックを受け入れない場合、これは失敗したコールバック試行としてカウントされません。むしろ、ルーティングエンジンは、エージェントが受け入れるまで、次の使用可能なエージェントにコールバックを提供します。

失敗したコールバック試行は、エージェントがコールバックを受け入れた後に何らかの問題が発生してから、エージェントが顧客と連絡をとるまでに行われます。

エージェントが、提供されたコンタクトのコールバックを受け入れるまで、このコンタクトはコールバックキューにあると見なされます。

Amazon Connect エージェントに接続すると、 はコールバックをキューから削除します。その時点で、 は顧客へのダイヤル Amazon Connect を開始します。

次の図は、コンタクトレコードでこれがどのようなるかを示しています。
+ キューから取り除かれた時刻: コールバックがエージェントに接続されたときのタイムスタンプ。また、Amazon Connect が顧客へのダイヤルを開始した時刻でもあります。

![\[キューから取り除かれた時刻を含むコンタクトレコード。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/ctr-enqueue-and-dequeue.png)


特定のコールバックログに対して、コンタクトレコードでのキュー滞留時間は、その特定のコールバックが試行される前にコンタクトがキューに入っていた時間に対応します。これは、すべてのコンタクトレコードにわたる合計キュー滞留時間ではありません。

例えば、着信コールは、コールバックがスケジュールされる前に 5 分間キューに入ります。その後、10 秒の初回ディレイ後、コンタクトのコールバックが 10 秒間コールバックキューに入ってから、エージェントがそのコールバックを受け入れます。この場合、次の 2 つのコンタクトレコードが表示されます。

1. InitiationMethod=INBOUND となっている最初のコンタクトレコードでは、キュー滞留時間は 5 分になります。

1. InitiationMethod=CALLBACK となっている 2 番目のコンタクトレコードでは、キュー滞留時間は 10 秒になります。

# キューに入れられたコールバックフローの Amazon Connect リアルタイムメトリクスの例
<a name="queued-callback-example"></a>

このトピックでは、キューに保存されたコールバックフローの例を示し、それに対するコンタクトレコードと時間の設定方法を確認します。

次のフローを設定したとします。
+ **[インバウンドフロー]** -- 顧客がカスタマーサービス番号に電話したときに実行されます。
+ [**顧客キューフロー**] – 顧客がキューで待機しているときに実行されます。この例では、顧客にコールバックを提供するフローをビルドします。顧客が [はい] を選択した場合、このフローは **[キューへ転送]** ブロックを実行し、CallbackQueue という名前のコールバックキューにコンタクトを転送します。初回ディレイは 99 秒です。その後、電話を切ります。
+ **[アウトバウンドウィスパーフロー]** -- キューに保存されたコールバックが配置されると、顧客は、応答後とエージェントに接続する前にこれを聞きます。例えば、「こんにちは、これはスケジュールされたコールバックです...」
+ **[エージェントウィスパーフロー]** -- エージェントは、コンタクトを受け入れた後と顧客に接続される前にこれを聞きます。例えば、「顧客の John に接続されようとしています。顧客は返金を要求しています...」

この例では、John がカスタマーサービスに電話します。次の状況が発生します。

1. インバウンドフローにより、コンタクトレコード-1 が作成されます。

   1. John が 11 時 35 分にカスタマーサービスに電話します。インバウンドフローが実行され、John が 11 時 35 分にキューに配置されます。

   1. 顧客キューフローが実行されます。John は 11:37 にコールバックをスケジュールすることを選択するため、インバウンドコンタクトが切断される前に 11:37 にコールバックコンタクト Amazon Connect を開始します。

1. コールバックフローにより、コンタクトレコード-2 が作成されます。

   1. コンタクトのコールバックが 11 時 37 分に開始されました。

   1. 初回ディレイが 99 秒であるため、99 秒経過するとコンタクトのコールバックが CallbackQueue に配置されます。この時間は 11 時 38 分 39 秒になります。これで、コンタクトのコールバックが利用可能なエージェントに提供されます。

   1. 21 秒後、11 時 39 分 00 秒にエージェントが利用可能になり、コンタクトを受け入れます。10 秒のエージェントウィスパーフローがエージェントに対して再生されます。

   1. エージェントウィスパーフローが完了すると、 は 11:39:10 に John を Amazon Connect 呼び出します。John が電話に出て、15 秒のアウトバウンドウィスパーフローを聞きます。

   1. アウトバウンドウィスパーフローが完了すると、John は 11 時 39 分 25 秒にエージェントに接続されます。彼らは 11 時 45 分まで話し、John は電話を切ります。

このシナリオでは、次のメタデータを含む 2 つのコンタクトレコードが生成されます。


| コンタクトレコード-1 | データ | 注意事項 | 
| --- | --- | --- | 
|  開始メソッド  | インバウンド  |   | 
|  開始タイムスタンプ  | 11:35  | インバウンド問い合わせは で開始されます Amazon Connect。  | 
|  ConnectedToSystem タイムスタンプ  | 11:35  | これはインバウンドコンタクトであるため、InitiationTimestamp = ConnectedToSystemTimestamp です。  | 
|  次のコンタクト ID   | コンタクトレコード-2 へのポインター  |   | 
|  [キュー]  | InboundQueue  |   | 
|  キューに入れられたタイムスタンプ  | 11:35  | インバウンドコンタクトがキューに入れられます。  | 
|  キューから出されたタイムスタンプ  | 11:37  | エージェントが応答しなかったため、これは DisconnectedTimestamp と同じです。  | 
|  ConnectedToAgent タイムスタンプ  | 該当なし  | John は、エージェントが応答する前にコールバックをスケジュールしました。  | 
|  切断されたタイムスタンプ  | 11:37:00  | John はフローによって切断されました。  | 


| コンタクトレコード-2 | データ | 注意事項 | 
| --- | --- | --- | 
|  PreviousContactId  | コンタクトレコード-1 へのポインター  |   | 
|  開始タイムスタンプ  | 11:37  | コールバック連絡先は に作成されます Amazon Connect。  | 
|  [キュー]  | CallbackQueue  |   | 
|  キューに入れられたタイムスタンプ  | 11:38:39  | 99 秒の初回ディレイが完了した後、コンタクトが CallbackQueue に入れられました。  | 
|  キューから出されたタイムスタンプ  | 11:39:00  | 21 秒後、エージェントがコンタクトを承諾します。  | 
|  キューの期間  | 120 秒  | これは、初回ディレイ (99 秒) と、エージェントが使用可能になるのを待機するキューに配置されている追加の時間 (21 秒) を加えたものです。  | 
|  ConnectedToSystem タイムスタンプ  | 11:39:10  | 10 秒のエージェントウィスパーフローが完了した後、John に電話をかけます。  | 
|  ConnectedToAgent タイムスタンプ  | 11:39:25  | 15 秒のアウトバウンドウィスパーフローが完了した後、John とエージェントが接続されます。  | 
|  切断されたタイムスタンプ  | 11:45  | John が電話を切ります。  | 