Amazon Connect Customer の IVR 入力結果をラップアップコードとしてダッシュボード集計してみた
はじめに
ラップアップコードは、コンタクト終了後の対応内容を分類するためによく利用されます。
たとえば、以下のような分類です。
- 解決
- 折返し要
- 問合せ
- クレーム
一般的には、エージェントが後処理中にラップアップコードを選択する運用を想定することが多いです。
一方、今回はダッシュボード集計の仕組みを確認するため、エージェントの後処理ではなく、IVR の番号入力結果をラップアップコードとして扱いました。
顧客が IVR で 1〜4 を入力し、その結果を Disposition というコンタクトセグメント属性に保存します。その後、Amazon Connect Customer のダッシュボードで Disposition ごとのコンタクト数を確認します。
2025 年 9 月に、Amazon Connect Customer でカスタム属性をインタラクションセグメントに関連付ける機能が追加されました。事前定義された属性を、フローまたは UpdateContact API からコンタクトセグメント属性として設定できます。
今回は、IVR の入力結果をラップアップコードとしてコンタクトセグメント属性に保存し、Amazon Connect Customer のダッシュボードでコードごとのコンタクト数を集計してみます。
今回の構成
今回の検証フローは以下です。
電話を発信
↓
IVR で 1〜4 を入力
↓
入力値に応じて Disposition を決定
↓
Disposition をコンタクトセグメント属性として保存
↓
終話
↓
ダッシュボードで Disposition ごとの件数を確認
IVR の入力値と Disposition の対応は以下のとおりです。
| 入力番号 | Disposition の値 |
|---|---|
1 |
解決 |
2 |
折返し要 |
3 |
問合せ |
4 |
クレーム |
事前定義された属性を作成する
Amazon Connect Customer の [ルーティング] → [事前定義された属性] から、ラップアップコード用の属性を作成します。
Amazon Connect Customer の属性管理画面
今回は、以下の内容で Disposition を定義しました。
- 名前：
Disposition - 属性タイプ：ユーザー
- 値：
解決、折返し要、問合せ、クレーム
Disposition の値と設定オプション
設定オプションでは、以下の 3 項目を有効にしました。
| 設定項目 | 用途 |
|---|---|
| 連絡先検索フィルターとして有効にする | コンタクト検索で Disposition を条件として利用する |
| 事前定義値の適用 | コンタクトセグメント属性として保存できる値を、定義済みの値だけに制限する |
| 詳細なインサイトのために分析で使用する | ダッシュボードの履歴コンタクトメトリクスで Disposition をフィルターとして利用する |
「事前定義値の適用」を有効にすると、コンタクトセグメント属性として保存できる値は、ここで定義した 4 つに限定されます。
たとえば クレーム を分類値にする場合、クレーム対応 や クレーム のような表記ゆれを保存しにくくなります。集計時に同じ意味の値が分散することを避けるため、分類値を固定したい場合に利用しやすい設定です。
また、「詳細なインサイトのために分析で使用する」を有効にしたユーザー定義属性は、履歴コンタクトメトリクスのフィルターとして利用できます。分析用の属性には、氏名、電話番号、メールアドレスなどの個人を特定できる情報を保存しないようにします。
事前定義された属性の作成方法は、以下のドキュメントに記載されています。
IVR フローで入力結果をセグメント属性として保存する
今回利用したフローは以下です。
1〜4 の入力値に応じて Disposition を設定して終話するフロー
フローでは [顧客の入力を取得する] ブロックで、顧客が入力した 1〜4 に応じて後続の処理を分岐させます。
各分岐では [コンタクト属性の設定] ブロックを実行します。
たとえば、1 を押した場合は Disposition = 解決 を設定します。
ここで重要なのは、通常のコンタクト属性ではなく、保存先として [セグメント属性] を選択することです。
| 項目 | 設定値 |
|---|---|
| 名前空間 | セグメント属性 |
| キー | Disposition |
| 値 | 解決、折返し要、問合せ、クレームのいずれか |
Disposition = 解決 をセグメント属性として設定する例
Disposition をダッシュボードの分析用フィルターに利用する場合、フローでの保存先はセグメント属性にします。名前空間に [セグメント属性] を選択すると、キーの候補に事前定義された属性が表示されます。
コンタクトセグメント属性の設定方法は、以下のドキュメントに記載されています。
コンタクト詳細で確認する
フローを公開後、テスト用の電話番号から発信し、1〜4 を入力して終話しました。
終話後、コンタクト検索から対象コンタクトを開くと、コンタクト詳細ページでセグメント属性を確認できます。
コンタクト詳細で Disposition のセグメント属性を確認できる
今回の検証では、入力した番号に応じて以下の値が保存されることを確認できました。
Disposition = 解決
Disposition = 折返し要
Disposition = 問合せ
Disposition = クレーム
ダッシュボードで意図した値が表示されない場合は、先にコンタクト詳細を確認し、Disposition がセグメント属性として保存されているかを切り分けると確認しやすいです。
ダッシュボードでラップアップコードごとに集計する
標準の「対応したコンタクト」では件数が表示されなかった
最初に、コンタクトの [コンタクトパフォーマンスの概要] ウィジェットで表示される [対応したコンタクト] を使って、Disposition ごとの件数を確認しようとしました。
しかし、今回の検証フローはエージェントへ接続しない構成です。
IVR の番号入力
↓
Disposition を設定
↓
終話
そのため、「対応したコンタクト」は 0 のままでした。
Contacts handled はエージェントへ接続されたコンタクトを数えるメトリクスです。一方、Contacts created は、指定期間中に作成されたコンタクトを数えるメトリクスです。
今回のような IVR 完結フローでは、エージェントへの接続有無に関係なく数えられる [作成されたコンタクト] を使う必要がありました。
カスタムメトリクスを作成する
今回確認した標準ウィジェットには、「作成されたコンタクト」をそのまま表示するものが見当たらなかったため、カスタムメトリクスを作成しました。
[ダッシュボードとレポート] → [ダッシュボード] → [カスタムメトリクス] から [メトリクスを作成] を選択します。
作成方法は [メトリクスビルダー] を選択しました。
設定内容は以下です。
| 項目 | 設定値 |
|---|---|
| コンポーネントの識別子 | M1 |
| メトリクス | 作成されたコンタクト |
| 定義 | SUM(M1) |
| 表示形式 | 整数 |
| メトリクス名 | ラップアップコード件数 |
「作成されたコンタクト」を合計するカスタムメトリクス
定義には、以下を入力します。
SUM(M1)
M1 に「作成されたコンタクト」を指定しているため、SUM(M1) により指定期間内に作成されたコンタクト数を表示できます。
このカスタムメトリクス自体には、Disposition のフィルターを設定していません。ダッシュボード上の各ウィジェットに対して、ラップアップコードごとのフィルターを設定するためです。
カスタムメトリクスの作成方法は、以下のドキュメントに記載されています。
ウィジェットごとに Disposition をフィルターする
ダッシュボードには、コンタクトの [コンタクトパフォーマンスの概要] ウィジェットを 4 つ追加し、各ウィジェットには、先ほど作成した ラップアップコード件数 を追加します。
ウィジェットの [アクション] → [編集] から、作成したカスタムメトリクスを追加できました。
ウィジェット編集画面で作成したカスタムメトリクスを選択する
また、各ウィジェットに Disposition の値を 1 つずつフィルタリング設定しました。
| ウィジェット名 | フィルター |
|---|---|
| ラップアップコード：解決 | Disposition = 解決 |
| ラップアップコード：折返し要 | Disposition = 折返し要 |
| ラップアップコード：問合せ | Disposition = 問合せ |
| ラップアップコード：クレーム | Disposition = クレーム |
ユーザー定義の事前定義属性は、ダッシュボードで任意の属性値ごとにグループ化する用途ではなく、フィルターとして使用します。
そのため、今回のように「解決」「折返し要」「問合せ」「クレーム」の件数を同時に確認する場合は、値ごとにウィジェットを用意し、それぞれ異なる Disposition のフィルターを設定する構成にしました。
事前定義された属性をダッシュボードで利用する方法は、以下のドキュメントに記載されています。
ラップアップコード別に集計したダッシュボード
最終的に、IVR の入力結果をラップアップコードとして保存した Disposition ごとのコンタクト数を確認できるダッシュボードを作成できました。
IVR 入力結果をラップアップコードとして保存した Disposition ごとのコンタクト数を表示するダッシュボード
各ウィジェットには異なる Disposition のフィルターを設定しているため、同じ期間に発生した「解決」「折返し要」「問合せ」「クレーム」の件数を並べて確認できます。
今回のように IVR で完結するフローでは、「作成されたコンタクト」を基礎にしたカスタムメトリクスを利用することで、Disposition ごとのコンタクト数を表示できました。
追記
本文では、以下のように記載しました。
今回確認した標準ウィジェットには、「作成されたコンタクト」をそのまま表示するものが見当たらなかったため、カスタムメトリクスを作成しました。
その後、標準ウィジェットを確認したところ、[コンタクトが作成されました] ウィジェットが存在していました。
「コンタクトが作成されました」ウィジェット
このウィジェットに Disposition のフィルターを設定することで、IVR 完結フローで発生したコンタクトについても、「解決」「折返し要」「問合せ」「クレーム」ごとの件数を表示できました。
ただし、ダッシュボードでラップアップコード別の数値を並べる用途では、[コンタクトが作成されました] というウィジェット名だけでは何の件数か判断しにくいと感じました。
そのため、本記事で作成したカスタムメトリクスを ラップアップコード件数 として表示する構成は、ダッシュボード上の数値の意味を分かりやすくする方法として利用できそうです。
まとめ
Amazon Connect Customer で、IVR の入力結果をラップアップコードとして Disposition のコンタクトセグメント属性に保存し、ダッシュボードでコードごとのコンタクト数を集計できました。
ポイントは、Disposition を分析用に有効化し、フローからセグメント属性として保存することです。
また、エージェントへ接続しない IVR 完結フローでは、「対応したコンタクト」ではなく、「作成されたコンタクト」を使ったカスタムメトリクスを利用しました。
